Facebook的新實時消息系統(tǒng)：Hbase——每月存儲1350億條消息
你或許已經(jīng)知道，facebook已經(jīng)介紹過全新的social inbox產(chǎn)品，集成了email，IM，短信，文本信息，facebook的在線消息。最為重要的是，他們每個月要存儲超過1350億條消息。他們如何存放這些信息呢？facebook的Kannan Muthukkaruppan在《郵件的底層技術：HBase》一文中給了一個十分意外的答案——HBase，打敗了MySQL，Cassandra和其他一些技術，成為facebook的選擇。
為什么說是一個意外的答案？facebook創(chuàng)造了Cassandra，并且其就是為郵件類型的應用而打造的，但是他們發(fā)現(xiàn)Cassandra的最終一致性模型并不適合他們的全新的實時郵件產(chǎn)品。Facebook同樣擁有大量的MySQL架構，但是他們發(fā)現(xiàn)性能會隨著數(shù)據(jù)和索引的增加變差。他們同樣可以選擇自己來開發(fā)一個新的存儲模型，但是他們最終選擇了HBase。
HBase是一個可擴展的、并且支持海量數(shù)據(jù)下的高并發(fā)記錄級別更新操作的表存儲產(chǎn)品——為郵件系統(tǒng)量身定做。HBase同樣支持基于BigTable模型的key-value存儲。這樣能夠很好的支持按key來查找記錄以及按范圍來搜尋或者過濾，這也是郵件系統(tǒng)的特性之一。然而，復雜一點的查詢卻并不被支持。查詢是通過一個叫Hive的工具來進行分析的，這是facebook創(chuàng)造的用以處理他們幾個P的數(shù)據(jù)倉庫的，Hive是基于Hadoop文件系統(tǒng)HDFS，這也是HBase所采用的文件系統(tǒng)。
Facebook檢視了他們的應用場景，指出他們?yōu)槭裁匆x擇HBase。他們所需要的系統(tǒng)應該能處理以下兩種數(shù)據(jù)：
- 一個較小的臨時數(shù)據(jù)集，是經(jīng)常變化的。
- 一個不斷增加的數(shù)據(jù)集，是很少被訪問的。
有點意思哈。你閱讀了收件箱里的郵件，以后就很少再去看它一眼了。這兩種截然不同的數(shù)據(jù)使用方式，你可能會用兩個系統(tǒng)來實現(xiàn)。但是顯然HBase就能搞定這一切。目前尚不清楚它是如何（在兩種數(shù)據(jù)集上）來實現(xiàn)通用的搜索功能的，盡管它集成了多種搜索引擎。
他們系統(tǒng)的一些關鍵特性：
·HBase：
·擁有一個比Cassandra更簡答的一致性模型。
·非常好的可伸縮性和性能。
·大多數(shù)特性對他們的需求來說是足足有余的：自動負載平衡和故障轉移，支持壓縮，單機多個切片（multiple shards）。
·HDFS是HBase使用的文件系統(tǒng)，支持冗余復制，端到端的校驗以及自動恢復平衡。
·facebook的運維團隊在使用HDFS方面有豐富的經(jīng)驗，他們是Hadoop的大客戶，Hadoop就是使用HDFS作為分布式文件系統(tǒng)的。
·Haystack用來做為存儲附件用的。
·重頭開始寫了一個自定義的應用server，以便處理大量來自不同源的消息。
·在ZooKeeper的頂層實現(xiàn)了一個“用戶發(fā)現(xiàn)服務”。
·使用了一系列的基礎服務：email帳戶驗證，好友關系鏈，隱私控制，消息傳送控制（消息是通過chat系統(tǒng)發(fā)送還是通過短信系統(tǒng)發(fā)送）。
·保持了他們一貫的作風，小團隊做出令人驚訝的事情：15個工程師花了1年的時間發(fā)布了20個新的基礎服務。
·facebook不打算只使用一個數(shù)據(jù)庫平臺并在這之上實現(xiàn)標準化應用，他們會針對不同的應用使用不同的平臺。
Facebook在HDFS/Hadoop/Hive上有了豐富的經(jīng)驗，并且成為HBase的大客戶，這讓我夜不能寐。與一個十分流行的產(chǎn)品合作并成為其產(chǎn)業(yè)鏈的一部分是所有產(chǎn)品的夢想。這正是HBase所得到的。由于HBase涵蓋了諸如持久性，實時性，分布式，線性擴展，健壯性，海量數(shù)據(jù)，開源，key-value，列導向（column-oriented）等熱點。我們有理由相信它能變得更加流行，特別是基于它被facebook使用的事實。
（原文作者Todd Hoff，C++代碼規(guī)范的作者）