Facebook的新实时消息系统：Hbase——每月存储1350亿条消息
你或许已经知道，facebook已经介绍过全新的social inbox产品，集成了email，IM，短信，文本信息，facebook的在线消息。最为重要的是，他们每个月要存储超过1350亿条消息。他们如何存放这些信息呢？facebook的Kannan Muthukkaruppan在《邮件的底层技术：HBase》一文中给了一个十分意外的答案——HBase，打败了MySQL，Cassandra和其他一些技术，成为facebook的选择。
为什么说是一个意外的答案？facebook创造了Cassandra，并且其就是为邮件类型的应用而打造的，但是他们发现Cassandra的最终一致性模型并不适合他们的全新的实时邮件产品。Facebook同样拥有大量的MySQL架构，但是他们发现性能会随着数据和索引的增加变差。他们同样可以选择自己来开发一个新的存储模型，但是他们最终选择了HBase。
HBase是一个可扩展的、并且支持海量数据下的高并发记录级别更新操作的表存储产品——为邮件系统量身定做。HBase同样支持基于BigTable模型的key-value存储。这样能够很好的支持按key来查找记录以及按范围来搜寻或者过滤，这也是邮件系统的特性之一。然而，复杂一点的查询却并不被支持。查询是通过一个叫Hive的工具来进行分析的，这是facebook创造的用以处理他们几个P的数据仓库的，Hive是基于Hadoop文件系统HDFS，这也是HBase所采用的文件系统。
Facebook检视了他们的应用场景，指出他们为什么要选择HBase。他们所需要的系统应该能处理以下两种数据：
- 一个较小的临时数据集，是经常变化的。
- 一个不断增加的数据集，是很少被访问的。
有点意思哈。你阅读了收件箱里的邮件，以后就很少再去看它一眼了。这两种截然不同的数据使用方式，你可能会用两个系统来实现。但是显然HBase就能搞定这一切。目前尚不清楚它是如何（在两种数据集上）来实现通用的搜索功能的，尽管它集成了多种搜索引擎。
他们系统的一些关键特性：
·HBase：
·拥有一个比Cassandra更简答的一致性模型。
·非常好的可伸缩性和性能。
·大多数特性对他们的需求来说是足足有余的：自动负载平衡和故障转移，支持压缩，单机多个切片（multiple shards）。
·HDFS是HBase使用的文件系统，支持冗余复制，端到端的校验以及自动恢复平衡。
·facebook的运维团队在使用HDFS方面有丰富的经验，他们是Hadoop的大客户，Hadoop就是使用HDFS作为分布式文件系统的。
·Haystack用来做为存储附件用的。
·重头开始写了一个自定义的应用server，以便处理大量来自不同源的消息。
·在ZooKeeper的顶层实现了一个“用户发现服务”。
·使用了一系列的基础服务：email帐户验证，好友关系链，隐私控制，消息传送控制（消息是通过chat系统发送还是通过短信系统发送）。
·保持了他们一贯的作风，小团队做出令人惊讶的事情：15个工程师花了1年的时间发布了20个新的基础服务。
·facebook不打算只使用一个数据库平台并在这之上实现标准化应用，他们会针对不同的应用使用不同的平台。
Facebook在HDFS/Hadoop/Hive上有了丰富的经验，并且成为HBase的大客户，这让我夜不能寐。与一个十分流行的产品合作并成为其产业链的一部分是所有产品的梦想。这正是HBase所得到的。由于HBase涵盖了诸如持久性，实时性，分布式，线性扩展，健壮性，海量数据，开源，key-value，列导向（column-oriented）等热点。我们有理由相信它能变得更加流行，特别是基于它被facebook使用的事实。
（原文作者Todd Hoff，C++代码规范的作者）