葡萄

标签： twitter  架构 

原文：http://www.25hoursaday.com/weblog/2008/05/23/SomeThoughtsOnTwittersAvailabilityProblems.aspx

看了这篇文章很是同情Twitter的工程师们，如此巨大的数据量，如此恶心的数据读取模式，如此疯狂的用户。

想当初做FEEDS的时候，为了讨论是PUSH还是PULL，讨论了很久很久，最终也没有得到一个最优的解决模式。理论上这件事情貌似很简单：
1）PUSH你的消息到所有你的好友或者关注者的页面；
2）PULL你关注的人的所有消息到自己的页面；
一旦数据爆炸，涉及分布式存储的时候，这类读写简直是要了DB的老命。最简单的还是牺牲写空间换取读时间，做PUSH（毕竟读的用户更多，他们的体验应该优先），但如果你的关注者达到万级的时候，这种状态下写的时间也会被恐怖的牺牲掉。

且看下一步Twitter的各位大拿怎么办吧，填机器生抗前途比较暗淡，或许会考虑限制好友数了。

我的胡思乱想：
1）用索引库，处理这类海量数据INDEX是强项，不过要想法弥补实时性的问题，做快慢表、大小库；
2）放弃关系型数据库结构，改为类似LDAP的文件系统管理；
3）哪位同学有好的建议，请告诉我。