# Facebook 的新实时消息系统：HBase 每月可存储 135 亿条消息 > 原文： [http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html](http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html)  您可能已经在某处阅读了 Facebook 推出了一个新的[社交收件箱](http://blog.facebook.com/blog.php?post=452288242130)，该电子邮件集成了电子邮件，IM，SMS，文本消息，Facebook 站点上的消息。 他们每个月总共需要存储 1,350 亿条消息。 他们将所有这些东西存储在哪里？ Facebook 的 Kannan Muthukkaruppan 在[消息的基础技术](http://www.facebook.com/note.php?note_id=454991608919#)： [HBase](http://hbase.apache.org/) 中给出了惊奇的答案。 HBase 击败了 MySQL，Cassandra 等。 为什么会有惊喜？ Facebook 创建了 Cassandra，它是专门为收件箱类型的应用程序而构建的，但是他们发现 Cassandra 的最终一致性模型与其新的实时 Messages 产品并不匹配。 Facebook 还拥有广泛的 [MySQL 基础架构](http://highscalability.com/blog/2010/11/4/facebook-at-13-million-queries-per-second-recommends-minimiz.html)，但他们发现随着数据集和索引的增大，性能会受到影响。 他们本可以构建自己的，但是他们选择了 HBase。 HBase 是 *[扩展表存储，支持对大量数据](http://www.cloudera.com/blog/2010/06/integrating-hive-and-hbase/)* 的很高级别的行级更新。 消息系统确实需要什么。 HBase 还是建立在 [BigTable](http://en.wikipedia.org/wiki/HBase) 模型上的基于列的键值存储。 它擅长通过键获取行或扫描行范围并进行过滤。 消息系统还需要什么。 但是不支持复杂查询。 通常会向查询工具提供诸如 [Hive](http://wiki.apache.org/hadoop/Hive/HBaseIntegration) 之类的分析工具，该工具是 Facebook 创建的，以理解其多 PB 数据仓库，并且 Hive 基于 Hadoop 的文件系统 HDFS，HBase 也使用该文件系统。 Facebook 之所以选择 HBase 是因为他们**监控了其使用情况，并弄清了真正需要的**。 他们需要的是一个可以处理两种数据模式的系统： 1. 一小段时间数据往往易变 2. 不断增长的数据集，很少被访问 说得通。 您会一次阅读收件箱中的最新信息，然后很少再看一次。 这些是如此不同，可能期望使用两个不同的系统，但是显然 HBase 对于两个系统都足够好。 尽管它们确实与 v [各种搜索系统](http://mail-archives.apache.org/mod_mbox/hbase-user/201006.mbox/%3C149150.78881.qm@web50304.mail.re2.yahoo.com%3E)集成在一起，但它们如何处理通用搜索功能尚不清楚，因为这并不是 HBase 的优势。 他们系统的一些关键方面： * HBase： * 具有比 Cassandra 更简单的一致性模型。 * 它们的数据模式具有非常好的可伸缩性和性能。 * 大多数功能满足其需求：自动负载平衡和故障转移，压缩支持，每台服务器多个分片等。 * HFS 使用的文件系统 HDFS 支持复制，端到端校验和和自动重新平衡。 * Facebook 的运营团队在使用 HDFS 方面具有丰富的经验，因为 Facebook 是 Hadoop 的大用户，而 Hadoop 使用 HDFS 作为其分布式文件系统。 * [Haystack](http://www.facebook.com/note.php?note_id=76191543919) 用于存储附件。 * 从头开始编写了一个自定义应用程序服务器，以服务来自许多不同来源的大量消息流入。 * 在 [ZooKeeper](http://highscalability.com/blog/2008/7/15/zookeeper-a-reliable-scalable-distributed-coordination-syste.html "http://hadoop.apache.org/zookeeper/") 之上编写了一个用户发现服务。 * 可以通过以下方式访问基础结构服务：电子邮件帐户验证，朋友关系，隐私决策和传递决策（是否应该通过聊天或 SMS 发送消息？）。 * 随着他们的小团队以惊人的方式做事，一年内有 15 位工程师发布了 [20 个新的基础架构服务](http://www.theregister.co.uk/2010/11/15/facebooks_largest_ever_engineering_project/)。 * Facebook 不会在单个数据库平台上实现标准化，他们将使用单独的平台来完成单独的任务。 我不会想到 Facebook 已经作为 HBase 的重要推动者，已经在 HDFS / Hadoop / Hive 方面拥有丰富的经验。 任何产品都可以与另一个非常受欢迎的产品合作，以期成为生态系统的一部分，这是梦想。 这就是 HBase 实现的。 鉴于 HBase 如何在持久性频谱中占据一席之地-实时，分布式，线性可伸缩，健壮，BigData，开源，键值，面向列-我们应该看到它变得越来越流行，尤其是在 Facebook 的油膏。 ## 相关文章 * [集成 Hive 和 HBase](http://www.cloudera.com/blog/2010/06/integrating-hive-and-hbase/) ，作者 Carl Steinbach * [Adob​​e 选择 HBase](http://highscalability.com/blog/2010/3/16/1-billion-reasons-why-adobe-chose-hbase.html) 的十亿个理由 * [HBase Architecture 101-预写日志](http://www.larsgeorge.com/2010/01/hbase-architecture-101-write-ahead-log.html)来自 Lars George * [HBase Architecture 101-存储](http://www.larsgeorge.com/2009/10/hbase-architecture-101-storage.html)和 Lars George * [具有 Cassandra 和 HBase 的 BigTable 模型](http://horicky.blogspot.com/2010/10/bigtable-model-with-cassandra-and-hbase.html)，作者 Ricky Ho * [新的 Facebook 聊天功能可使用 Erlang 扩展到 7000 万用户](http://highscalability.com/blog/2008/5/14/new-facebook-chat-feature-scales-to-70-million-users-using-e.html) 似乎每个人都在跳 Cassandra 船：Digg，Twitter，现在甚至是 Cassandra 的原始创建者 facebook 它不是仍然使用案例驱动的 Andy 吗？ 当订单很重要时，收件箱的最终一致性可能不是一个很好的匹配，但这是针对其他问题的。 从操作上看，这两者都不是一件容易的事，因此，利用您的 Hadoop 技术具有很大的价值。 HBase 从 0.20.6 开始不稳定。 我认为他们对此进行了很多修补。 希望他们会尽快发布所有这些内部补丁。 这三个服务都没有停止使用 Andy 的 Cassandra。 Twitter 正在采取缓慢的方法来扩大投资。 Facebook 的投资停滞不前，Digg 看到了一些问题，但仍在继续使用 Cassandra。 每个用例都应单独考虑，但是 FUD 在合理的技术决策中没有位置。 兰迪 卡桑德拉（Cassandra）正在遭受自己的公关策略。 随着 Facebook，Digg 和 Twitter 使用该系统，它在很大程度上得到了推广。 乍一看，这似乎是一个明智的策略，因为无数行家愚蠢到足以认为，如果某些软件对 Google / Facebook / Twitter 有用，那么对初创公司也将足够。 但是 Cassandra 和 HBase 一样，都是不成熟的软件，因此迟早会遇到麻烦。 怪罪应该提供可扩展性和容错能力的软件基础架构是自然的，尽管不公平。 更糟糕的是，Digg 并未像 Foursquare 或 Google 过去那样发布任何详细的停机后详细信息。 但是当您说 Twitter 正在投资 Cassandra 时（主要是用于新产品/服务），您说对了。 顺便说一句，我特别好奇地看到他们基于 Cassandra 的实时分析引擎。 希望他们意识到 Cassandra 还不够成熟，无法支持其现在的工作规模，因此他们正在以较小的规模工作，直到 Cassandra 摆脱了问题/限制（自动负载平衡，压缩，内存不足异常，不良的客户端 api） ，数据损坏，gc 风暴，缺少查询语言等）。 这些问题中的一些已经得到解决，而其他一些问题仍然被推迟。 卡桑德拉问题远远超出了 当谈到 Digg 时，至少有三名 Cassandra 专家退出公司，因此除非另有说明，否则 Digg 中 Cassandra 的未来似乎是有问题的。 但是无论如何，这家公司注定要失败，所以让它永远走下去。 最后，正如您所指出的那样，Cassandra 在 Facebook 内部的投资已经停止，因此自然而然地假设这将是该系统的遗留系统。 如果我理解正确，FB 将 Cassandra 用于 Inbox 搜索，他们将用 Messages 服务取代它，那么那里的 Cassandra 用途是什么？ 不过，我想从现在开始的一年后，我们将更好地了解 Cassandra 在这些公司中的使用情况。 弗拉基米尔：确实，HBase 0.20.6 的稳定性远不如当前的主干，我们即将发布的主干为 0.90。 Facebook 的所有工作都已经整合到了主干中-他们已经与开源社区合作了几个月。 -Todd Lipcon（HBase 提交者） Todd，我们都希望 0.90 会比当前版本更稳定。 非常有趣的是，他们不需要牺牲一致性，而使用了完全一致的系统 HBase。 曼迪 “无数的潮人足够愚蠢” 这种毫无意义的谴责对辩论有何帮助？ 坦迪 就这一点而言，这种“毫无意义的抨击”令人大开眼界。 我不知道您在软件行业工作了多长时间，但是*如果您从未见过有人争论“看，Twitter 使用 Ruby on Rails，他们对此很满意，那就让我们使用 现在！”* ，那么您在软件行业的时间还不够长（或者您是一个非常幸运的人）。 令人惊讶的是，有多少工程师采用**技术，只是因为**“ X”公司（您命名）使用了该技术。 当然，没有人会毫不掩饰地承认这一点，但这是软件业务运作的方式。 仅举几个例子：EJB 被过度炒作，Ruby on Rails 被过度炒作，Linux 被过度炒作，Application Server 被过度炒作，现在轮到 NoSQL 系统了。 **上面引用的许多技术都相当不错，但是要在开放思想和保守主义之间取得一定的平衡就不能落入陷阱（Digg？）。** 随着时间的推移，工程师获得了使用“ A”技术的经验（何时使用，什么时候不使用），赶时髦的人被砍掉了，炒作逐渐消失，一些“ A”系统消失了，而最合适的“ A”系统得以生存并 成长（达尔文主义很棒，不是吗？） > 卡桑德拉（Cassandra）正在遭受自己的公关策略。 卡桑德拉有公关策略吗？ 不，我可以这样来命名，但这不是您通常在公司中找到的正式 PR。 **这是一个临时性的口碑广告，是粉丝们在 Twitter，quora 等人身上所做的新闻的无尽回响。“瞧瞧，Twitter 的新实时分析服务得到了 Cassandra 的支持。 是吗？您也应该使用 Cassandra！”** 这个星期几乎快要结束了，但是这个帖子仍然丢失了转发。 :) 尽管如此，这并不是 Cassandra 社区的错，因为到目前为止，这是由所有 NoSQL 系统以及 Hadoop 员工完成的。 问题是，当**与**软件项目一起使用时。 我怀疑 Twitter / Quora 是宣传软件的最佳渠道（最好的选择：技术会议），但是 Twitter 充满了狂热的粉丝，您必须忍受这一点。 :(