您可能已经在某个地方了解到 Facebook 已经推出了新的整合了电子邮件，即时通讯，手机短信，Facebook 站内信的  社会收件箱  的消息。所有的这一切加起来，他们每个月需要存储超过1350亿条消息。   他们用什么存储这些消息呢？Facebook的Kannan Muthukkaruppan给出了一个让人惊讶的回答：  消息系统的底层技术 ：  HBase 。   HBase 击败了MySQL，Cassandra，和其他几种备选方案。

为什么惊讶？   Facebook 开发了 Cassandra，最初的目的就是用来搭建类似收件箱的应用，但他们发现 Cassandra 的最终一致性模型与新的实时消息系统的要求不相匹配。   Facebook也拥有广泛的  MySQL基础设施 ，但他们发现当数据集和索引快速增长时，mysql 的性能会受到很大的影响。   他们也可以选择建立自己开发一套系统，但他们没有那么做，而是选择了 HBase。

HBase的是一种  在大数据量下仍支持快速的行级别的更新的可扩展表存储 。这正是消息系统所需要的。 HBase 是建立在  BigTable的  模型上的，基于列的 key-value 存储。   它擅长于根据 key 获取一行或多行数据，或者扫描数据区间，以及过滤操作。  这也是消息系统需要的 。  HBase 不支持 复杂的查询。  复杂的 查询通常由分析工具来完成，比如  Hive ，Hive 也是 Facebook 开发的，用来分析他们 PB 级别的数据仓库。Hbase 和 Hive 一样，都使用 Hadoop的文件系统，HDFS。

Facebook 选择 Hbase，是因为他们  分析了消息系统的使用情况 ，并找出了系统真正需要的特性 。   他们需要的是一个可以处理两种模式类型的数据的系统：

1. 一个经常被访问的，不稳定的，小的临时数据集
2. 一个不断增长的，很少访问的，大的数据集

就这样。   你读过了当前收件箱中的消息，然后很少，如果有的话，会再去看它。 这两种模式差别很大，所以 人们可能需要两个不同的系统。恰巧的是， HBase 能很好的支持两者。  目前尚不清楚 他们是如何处理通用搜索功能的，这是 HBase 的弱点，尽管它能够整合  多种搜索系统 。

他们的系统的一些关键点：

• HBase：
  • 比Cassandra简单一致性模型。
  • 对于他们的数据模式来说，HBase 具有很好的扩展性和性能。
  • 功能丰富：自动负载平衡和故障转移，支持压缩，每个服务器上可部署多个分片等
  • HDFS，HBase 使用的文件系统，支持复制，端到端的校验，和自动平衡。
  • Facebook 的运维小组有很多使用HDFS的经验，因为 Facebook 是 Hadoop 的大用户，而 Hadoop 也使用分布式文件系统 HDFS。
• 使用  Haystack  存储附件。
• 全新开发的自定义应用服务器，以服务来自不同源的大量消息流入。
• 基于  ZooKeeper  的用户自动发现服务 。
• 提供基础服务：电子邮件帐户验证，朋友关系，个性定义，和交付路由（消息通过聊天还是通过短信发送？）。
• 保持他们小团队做大事情的传统，目前  15个工程师一年发布20个基础服务 。
• Facebook 不会在单一的数据库平台上做标准化，他们使用不同的平台承担不同的任务。

我很惊喜的看到，Facebook 选择 HBase，是因为他们有很多使用 HDFS/ Hadoop/ Hive 的经验。  借着作为另一个很流行的产品的好搭档的方式，来加入它的生态系统，这是任何一个产品都有的梦想 。   这是 HBase 已经取得的成就。   鉴于 HBase 在持久存储方面涵盖的特性： 实时，分布，线性可扩展，健壮，BigData，开放源码，键值存储，面向列存储， 它将会变得越来越受欢迎，特别是在 Facebook 宣布了他们的选择以后。