# 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 充滿了狂熱的粉絲，您必須忍受這一點。 :(