FeedLounge 使用 PostgreSQL 的经验

这是我唯一看到的 Web 2.0 公司使用 PostgreSQL 的,可惜还失败了。

FeedLounge 是一个提供在线 RSS Reader 的站点。已经在今年 6 月 1 日黯然宣布失败。这里不去讨论他们失败的各种原因,只说说从他们 Blog 上看来的关于他们选择数据库的经验。

FeedLounge 在数据库的使用上路线是这样的:

MySQL(MyISAM) --> MySQL(InnoDB) --> PostgreSQL 

最初是 MyISAM 方式,迁移到 InnoDB ,数据库从大约 1G 膨胀超出了 10G,而且发现引发了新的性能问题,经过尝试发现不能解决后,迁移到 PostgreSQL,总存储从 InnoDB 方式的 34G 缩小到 9.6G,而且,恢复时间也只是原来的大约 1/5 (导出用 Mysqldump,载入用 psql ). 此外,关于内存利用方式上也有一些差异, MySQL : innodb_buffer_pool 6GB + O_DIRECT flush, PostgreSQL 设置上限 2G,只用了 1.2 G。遗憾的是,看不到切换前后性能数据更为详细的对比。

FeedLounge 当时每天要处理的事务量:每天超过 400 万次查询,超过 200 万次的更新/插入操作,高峰期每秒钟有 2000 个更新/插入操作(这应该是批处理阶段)。硬件如何呢? 数据库服务器的硬件:两路 Opteron CPU,8 GB 内存, 6 SATA 7200RPM 16MB 硬盘, RAID 5 ,控制器有 128M. 可以看出来了吧, 7200 转的硬盘 + RAID 5 根本不适合这样的应用。从这一点上说,数据库类型切换其实解决不了本质的问题。

另外看到的有趣参考信息:

FeedDigest 在当时每天有超过 400 万次的查询,超过 200 万次插入,机器硬件只用了双奔四 CPU(2.8GHz) ,1G内存

EOF


22 thoughts on “FeedLounge 使用 PostgreSQL 的经验

  1. dawnh

    性能差可能是由于Sata阵列导致的吧,在我曾经接触过的应用中是感觉这样,7200 Sata Raid 5性能甚至不如7200 SCSI Raid1,虽然测试结果非常好,但实际web或数据库应用稳定性和性能以及负载能力差一大截.我感觉可能是阵列卡或者是操作系统以及驱动等层面造成的问题.
    另,双P4写错了吧,要么是双核,要么是双Xeon(Nocona),P4没办法一次上2个的说。
    另外关于这个案例,有更详细的架构资料吗?谢谢!

    Reply
  2. Fwolf

    我更关注myisam,innodb,psql之间的空间和速度差异的原因
    能不能给简单分析一下
    或者给点提示?

    Reply
  3. Fenng

    dawnh, p4 不能上两个麽 ? 没有双核之前 pc 服务器都是一个 CPU ?
    lihuawei, 环境都已经说得比较清楚了,还说”RAID 5写性能不一定差”,自然是和RAID 1 比啦
    Fwolf,Google,Google!

    Reply
  4. Fwolf

    我更关注myisam,innodb,psql之间的空间和速度差异的原因
    能不能给简单分析一下
    或者给点提示?

    Reply
  5. virushuo

    这种类型的数据存储,根本就不应该用数据库。
    这帮人就缺乏常识。
    看MySQL(MyISAM) –> MySQL(InnoDB) –> PostgreSQL 这个折腾就知道胡闹了。就算换数据库有点提高,这有用吗?早晚还会到的。这根本就不是正确的解决方案。
    正确的方案是,根据数据特点,选择适当的存储。数据库无非是存储的一种方案,真是,死脑筋。不失败才奇怪呢。

    Reply
  6. dawnh

    回博主,能上双U和不能上双U因为Intel商业的考量确实是需要区分不同CPU的,甚至能上2个和能上4个以上都要有不同型号的U,例如以前的PIII Xeon MP系列.P4系列和P4 Xeon系列就是分别为桌面和服务器产品线设计的,前者不可能实现多路,相应芯片组8X5系列也不支持多路,后者可以,相应为2路或2路以上有不同的芯片组支持.虽说2者技术架构几乎一样,但为了不同商业需求派生出多个品牌来,应该属于正常现象吧.
    另外楼上的2位,你们真的有类似的项目经验吗?不应该说出这么武断的话来吧.

    Reply
  7. Fenng

    双U 和双CPU可不是一回事
    不知道你说的是哪一个 ?
    另外,你楼上的两位经验都是很丰富地

    Reply
  8. dawnh

    双U难道不是指双CPU?按照普遍的说法双CPU一般称作双路,而单CPU双核心都被称作双核。
    另外关于楼上两位的结论,第一个说不使用数据库,难道对于Rss Reader这种高查询和更新量的应用还有比数据库更适合的存储方案?还有第二个,在这种硬件环境下oracle比起mysql,posttgres性能显著提高在哪里?

    Reply
  9. Fenng

    不知道服务期的U是怎么回事,可以去Google一下嘛
    是不是高查询高更新,完全看各自的认识了
    或许有人认为几百万已经很了不起了呢

    Reply
  10. dawnh

    我这里U是CPU缩写,难道你说的U是机架高度?如果是这个,那只有1U2U的说法而不是单U双U吧.
    对于这个案例我认为用数据库存储是比较恰当的.至于选用什么产品导致的性能差异在此案例我认为不会有太大影响.所以我对楼上2位说使用非数据库做存储和使用oracle表示怀疑,至于多少查询量算了不起那要看什么硬件什么架构.

    Reply
  11. kelly

    跑阵列的主要目的有:
    1。提高速度。需要2的n次方块硬盘来建立。
    跑Raid0理论上能够加快1倍的磁盘读写性能。RAID0是把所有数据分开奇偶数地读写,因此可以提速;但是当任意一块硬盘挂了就会丢失所有的数据。
    2。增加数据安全性。也需要2的n次方块硬盘来建立。
    跑RAID1的时候,理论上跟没跑阵列性能几乎一样,甚至还差一点点,但是当其中一块硬盘挂掉了,数据仍然不会丢失。RAID1就相当于做了磁盘镜像。
    现在比较流行的是raid0+1的方法,缺点是比较浪费硬盘,需要4个硬盘同时工作,但是速度和安全性都有保障。

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *