Facebook的实时消息系统:HBase每月存储135百万条以上的消息。
如果你的系统满足两个条件:大规模数据量(TB以上),需要实时分析处理。这篇文章对你或许有用。
Facebook的社交信箱集成了邮件,即时消息,短信息,文本消息,站内消息,为此facebook需要每个月存储1亿3千5百万条以上的消息(这是在2010年前,现在数据量更大了)。他们将数据存到哪里了?Facebook的Kannan Muthukkaruppan给出了惊人的答案:消息系统的底层技术采用了HBase。HBase击败了MySQL,Cassandra以及其它的方案。
让人惊奇的是,Facebook建立了Cassandra项目,但是他们发现Cassandra的一致性模型无法适应他们的新的实时消息产品(HBase和Cassandra的比较:http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/
,http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
),原以为他们要采用自己的Cassandra。Facebook拥有大量的MySQL集群,随着数据量和索引越来越多时,MySQL的性能就出现问题了,现在他们选择了HBase。
HBase的介绍我就不多说了,看看这些关键词:大规模数量,高可靠性,快速读写访问,分布式,线性扩展,高可靠性,开源,键值对,面向列的结构。Facebook之所以选择HBase是因为他们通过观测他们的系统,而真正领会到他们的系统的需求,要同时能够处理两种类型的数据模式:
- 临时存储的一小部分实时数据
- 很少访问的大量数据
这很容易理解,例如你阅读信箱里的当前消息以后,就会很少再看那些消息了。看起来这两种数据互相冲突,但是HBase能够很好的适应这两种情况。但是Facebook没有说清楚如何处理搜索,这方面不是HBase的强项(虽然它能够和其它的索引系统集成)。
Facebook实时消息系统的一些特点:
- HBase
- 相比Cassandra更简化的一致性模型
- 为它们的数据模式提供很好的扩展性和性能
- 很多他们想要的特性:自动负载均衡和故障保护,数据压缩,按服务器的分片
- HDFS,分布式文件系统,支持复制,端到端的数据验证,自动负载均衡
- Facebook团队在使用HDFS方面有丰富经验
- Haystack用于存储附件(参看:http://server.it168.com/a2009/0504/274/000000274726_2.shtml)
- 自己写的一个应用服务器,用于处理来自不同地方的大量消息流。
- 基于ZooKeeper写的用户发现服务。
HBase在处理大规模实时消息的能力,通过Facebook再次验证了。我们不迷信大公司,但是参照大公司的实践经验可以作为自己的一个很好起点,被证明过的经验,用的再怎么差,也不会偏离大的方向。下篇文章,我们要讨论“Facebook新的实时分析系统 - 每天处理200亿条数据 - 2011年”。
注:这篇文章大部分内容翻译自:http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html。其中加入了自己的一些理解,如果对原文感兴趣,请参看链接。