这是我唯一看到的 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--
del.icio.us 收藏Generator | Trampoline
本文相关评论|Comments(22)
添加评论
那么FeedDigest用的RAID是什么样子的呢？
RAID 5 写性能差的，你说呢?
性能差可能是由于Sata阵列导致的吧,在我曾经接触过的应用中是感觉这样,7200 Sata Raid 5性能甚至不如7200 SCSI Raid1,虽然测试结果非常好,但实际web或数据库应用稳定性和性能以及负载能力差一大截.我感觉可能是阵列卡或者是操作系统以及驱动等层面造成的问题.
另,双P4写错了吧,要么是双核,要么是双Xeon(Nocona)，P4没办法一次上2个的说。
另外关于这个案例，有更详细的架构资料吗？谢谢！
RAID 5 写性能不一定差，关件在环境
我更关注myisam，innodb，psql之间的空间和速度差异的原因
能不能给简单分析一下
或者给点提示？
dawnh, p4 不能上两个麽 ? 没有双核之前 pc 服务器都是一个 CPU ?
lihuawei, 环境都已经说得比较清楚了，还说"RAID 5写性能不一定差"，自然是和RAID 1 比啦
Fwolf，Google，Google！
呵呵～！有道理,没注意看环境
我更关注myisam，innodb，psql之间的空间和速度差异的原因
能不能给简单分析一下
或者给点提示？
呵呵～！有道理,没注意看环境，RAID 5须要更多的磁盘来执行当然比不上RAID １
穷人不适合搞网络。连SCSI都买不起还做RSS Reader。
FeedDigest这种情况是可能的，但前提是不用任何通用数据库。
用raid5就是个错误
做DB Server，RAID10是不二的选择..
呵呵!~~这个嘛偶不懂,不过我的博客借鉴了点你的字体色彩方案,,,,
这种类型的数据存储，根本就不应该用数据库。
这帮人就缺乏常识。
看MySQL(MyISAM) --> MySQL(InnoDB) --> PostgreSQL 这个折腾就知道胡闹了。就算换数据库有点提高，这有用吗？早晚还会到的。这根本就不是正确的解决方案。
正确的方案是，根据数据特点，选择适当的存储。数据库无非是存储的一种方案，真是，死脑筋。不失败才奇怪呢。
你直接上oracle不就完了吗？费那些劲干嘛？---疯狂的oracle
回博主,能上双U和不能上双U因为Intel商业的考量确实是需要区分不同CPU的,甚至能上2个和能上4个以上都要有不同型号的U,例如以前的PIII Xeon MP系列.P4系列和P4 Xeon系列就是分别为桌面和服务器产品线设计的,前者不可能实现多路,相应芯片组8X5系列也不支持多路,后者可以,相应为2路或2路以上有不同的芯片组支持.虽说2者技术架构几乎一样,但为了不同商业需求派生出多个品牌来,应该属于正常现象吧.
另外楼上的2位,你们真的有类似的项目经验吗?不应该说出这么武断的话来吧.
双U 和双CPU可不是一回事
不知道你说的是哪一个 ?
另外，你楼上的两位经验都是很丰富地
双U难道不是指双CPU？按照普遍的说法双CPU一般称作双路，而单CPU双核心都被称作双核。
另外关于楼上两位的结论，第一个说不使用数据库，难道对于Rss Reader这种高查询和更新量的应用还有比数据库更适合的存储方案？还有第二个，在这种硬件环境下oracle比起mysql，posttgres性能显著提高在哪里？
不知道服务期的U是怎么回事，可以去Google一下嘛
是不是高查询高更新，完全看各自的认识了
或许有人认为几百万已经很了不起了呢
我这里U是CPU缩写,难道你说的U是机架高度?如果是这个,那只有1U2U的说法而不是单U双U吧.
对于这个案例我认为用数据库存储是比较恰当的.至于选用什么产品导致的性能差异在此案例我认为不会有太大影响.所以我对楼上2位说使用非数据库做存储和使用oracle表示怀疑,至于多少查询量算了不起那要看什么硬件什么架构.
跑阵列的主要目的有：
1。提高速度。需要2的n次方块硬盘来建立。
跑Raid0理论上能够加快1倍的磁盘读写性能。RAID0是把所有数据分开奇偶数地读写，因此可以提速；但是当任意一块硬盘挂了就会丢失所有的数据。
2。增加数据安全性。也需要2的n次方块硬盘来建立。
跑RAID1的时候，理论上跟没跑阵列性能几乎一样，甚至还差一点点，但是当其中一块硬盘挂掉了，数据仍然不会丢失。RAID1就相当于做了磁盘镜像。
现在比较流行的是raid0+1的方法，缺点是比较浪费硬盘，需要4个硬盘同时工作，但是速度和安全性都有保障。