- 老魚為一個新的SNS開發專案, 進行研究評估幾個雲端(分散式)儲存系統, 過程中也是棄了 HBase, MongoDB 選 Cassandra, 而當我這二天看到這篇文中的不少技術選型的出發點, 讓我閱讀後有不少處有所同感(在文章中標紅色的段落).
- 籍由這篇文選, 希望同是身為電腦科學工程與甚至任職企業資訊採購決策管理者一份子的您, 能從這篇文中, 去思考當我們在企業中扮演一個對資訊科技採購時, 不應只是表面名牌價格與廠商行銷手法, 龐大複雜且難以駕馭系統規劃被廠商合理化之, 反造成企業長期的營運維護成本上升, 企業逐漸受外在資訊廠商所“挾持”, 從而失去企業自我資訊自主的競爭本能.
- 這篇文中如果扣除作者在評論其二家產品, 各位看官也可以獲得不少目前電腦科學領域中當前最競爭的幾點新知, 尤其作者是以該領域的專家評論, 在出發點上就不會有太多被一般新聞過度炒作“雲端計算Cloud Computing”名詞上的疑慮.
- 文中作者也對 CAP, CA, AP 等理論給予突破性的實證觀點.
原文: http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/
原作者：Dominic Williams
原文發佈日期：February 24, 2010 at 7:27 pm
譯者：王旭（ http://wangxu.me/blog/ , @gnawux）
翻譯時間：2010年3月21-25日
簡體轉正體中文及校潤詞句：郭朝益( http://wisdomfish.org, @master)
我的團隊近來正在忙於一個全新的產品——即將發佈的網絡遊戲 www.FightMyMonster.com。 這讓我們得以奢侈地去構建一個全新的 NoSQL 資料存儲庫系統，也就是說，我們可以把恐怖的 MySQL sharding 和昂貴的可伸縮性拋在腦後了。最近有很多人一直在問，為什麼我們要把注意力再從 HBase 上轉移到 Cassandra 上去。我確認，確實有這樣的變化，實際上我們在基礎上已經把程式碼移植到了 Cassandra 上了，這裡我將作出解釋。
為了那些不熟悉 NOSQL 的讀者，在往後的其他文章中，我會介紹為什麼我們將會在未來幾年中看到如地震般的 從 SQL 到 NoSQL 的遷移，這正和向雲計算的遷移一樣重要。往後的文章還會嘗試解釋為什麼我認為 NoSQL 可能會是貴公司的正確選擇。不過本文我只是解釋我們選擇 Cassandra 作為我們的 NoSQL 解決方案的選擇。
免責聲明——如果你正在尋找一個捷徑來決定你的系統選擇，你必須要明白，這可不是一個詳盡而嚴格的比較，它只是概述了另一個初創團 隊在有限時間和資 源的情況下的邏輯。
Cassandra 的血統是否預言了它的未來我最喜歡的一個電腦工程師們用來找 bug 的謁語是 「廣度優先於深度」。 這也許可能對那些解決技術細節的人來說很惱人，因為它暗示著如果他們只是看看的話，解決方法就會簡單很多（忠告：只對那些能夠原諒你的同事說這個）。我之所以給出這個謁語的原因在於，我發現， 軟體工程問題中，如果我們強迫自己在進入某行程式碼的細節層面之前，先去看看那些較高層次的考慮的話，可以節省大量時間。
所以，在談論技術之前，我在做 HBase 和 Cassandra 之間的選擇問題上先應用一下我的箴言。 我們選擇切換的技術結論可能已經可以預測了：Hbase 和 Cassandra 有著迥異的血統和基因，而我認為這會影響到他們對我們的商業適用性。
嚴格來說，Hbase 和它的支持系統源於著名的 Google BigTable 和 Google 檔案系統設計（GFS 的論文期刊被發佈於 2003 年，BigTable 的論文發於 2006 年）。而 Cassandra 則是最近 Facebook 資料存儲庫系統的開放源始碼分支專案，它在實作了 BigTable 的資料模型的同時，使用了基於 Amazon 的 Dynamo 系統架構來存儲資料（實際上，Cassandra 的最初開發工作就是由兩位從 Amazon 跳槽到 Facebook 的 Dynamo 電腦工程師完成的）。
在我看來，這些不同的歷史也導致 Hbase 更加適合於資料倉儲、大型資料的處理和分析（如進行 Web 頁面的索引等等），而 Cassandra 則更適合於實時(Real-Time, RT)事務交易處理和提供交互型資料。要進行系統研究來證明這個觀點超出了本文的範疇，但我相信你在考慮資料庫的時候總能發現這個差異的存在。
注意：如果你正在尋找一個簡單的證明，你可以通過主要 Committer(對參與專案程式撰寫並提交貢獻者之稱) 的關注點來進行驗證：大部分 HBase 的 committer 都為 Bing 工作（M$[Microsoft] 在去年09收購了他們的搜尋公司，並允許他們在數月之後繼續提交開放專案的程式碼）。與之對應，Cassandra 的主要 committer 來自 Rackspace，用來可以自由授權獲取, 支持先進且通用的 NoSQL 的解決方案，用以與 Google, Yahoo, Amazon EC2 等所提供的鎖定在專有授權的 NoSQL 系統解決方案的相互抗衡。
Malcolm Gladwell 會說只是根據這些背景的不同就可以簡單地選擇了 Cassandra。不過這是小馬過河的問題。但當然，閉著眼睛就進行一個商業選擇是相當困難的……
哪個 NoSQL資料儲存庫風頭更勁?
另一個說服我們轉向 Cassandra 的原因是我們社群中的大風潮。 如你所知，在電腦科學平台行業裡，始終有著大者恆大的慣性——那些被普遍前景看好的系統平台，會有更多人群聚在這個平台周圍，於是，從長遠來看，你可以得到更好的生態系統的支援（也就是說，大部分支援的軟體工程可以從該社群中獲取，並且也會有更多的開發者可以因此被僱傭）。
如果從 HBase 開始時，我的印象就是它後面有巨大的社群力量，但我現在相信，Cassandra 更加強大。最初的印象部分來源於 StumpleUpon 和 Streamy 的兩位 CTO 兩位非常有說服力的出色的演講者，他們是 Web 行業中兩個在 Cassandra 成為一個可選系統之前的 HBase 的兩個重要的貢獻者，同時也部分來源於閱讀一篇名為「 HBase vs Cassandra： NoSQL 戰役！」的文章（大部分內容都己被廣泛證實了）。
勢力是很難被確證的，你不得不自己進行研究， 不過我可以找到的一個重要的標誌是 IRC 上的開發者動向。如果你在 freenode.org 上比較 #hbase 和 #cassandra 的開發這頻道，你會發現 Cassandra 差不多在任何時候都有達兩倍的開發者在線上。
如果你用考慮 HBase 一般的時間來考察 Cassandra，你就能發現 Cassandra 的背後確實有非常明顯的加速勢力。你可能還會發現那些逐漸出現的鼎鼎大名，如 Twitter，他們也計劃廣泛使用 Cassandra（ 這裡）。
註：Cassandra 的網站看起來比 HBase 的好看多了，但認真的說，這可能不僅是市場的趨勢。繼續吧。
深入到技術部分: CAP 和 CA 與 AP 的神話
對於分散式系統，有個非常重要的理論（這裡我們在討論分散式資料庫，我相信你 注意到了）。 這個理論被稱為 CAP 理論，由 Inktomi 的 聯合創始人兼首席科學家 Eric Brewer 博士提出。
這個理論說明，分散式（或共享資料）系統的設計中， 至多只能夠提供三個重要特性中的兩個——一致性(C)、可用性(A)和容忍網路分區(P)[ Consistency, Availability and tolerance to network Partitions. ]。簡單的說，一致性指如果一個人向資料庫寫了一個值，那麼其他使用者能夠立刻讀取這個值，可用性意味著如果一些節點(Node)失效了，叢集(Cluster)中的分散式系統仍然能繼續工作，而容忍分區意味著， 如果節點被分割成兩組無法互相通信的節點，系統仍然能夠繼續工作。
Brewer 教授是一個傑出的人物，許多開發者，包括 HBase 社區的很多人，都把此理論牢記在心，並用於他們的軟體系統設計當中。 事實上，如果你搜尋網路上攸關於 HBase 和 Cassandra 比較的文章，你通常會發現，HBase 社群解釋他們選擇了 CP，而 Cassandra 選擇了 AP ——毫無疑問，大多數開發者需要某種程度的一致性 (C)。
不過，我需要請你注意，事實上這些生命基於一個不完全的推論。 CAP 理論僅僅適用於一個分散式演算法（我希望 Brewer 教授可以統一）。但沒有說明你不能設計一個超出理論的系統，並在其中各種操作的底層演算法選擇上進行特性切換。所以， 在一個系統中，確實一個操作職能提供這些特性中的兩個，但被忽視的問題是在系統設計(SD)中，實際是可以允許調用者來選擇他們的某個操作時需要哪些特性的。不僅如此， 現實世界也非簡單的劃分為黑白兩色，所有這些特性都可以以某種程度來提供。這就是 Cassandra。
這點非常重要，我重申：Cassandra 的優點在於你可以根據具體情況來選擇一個最佳的折衷，來滿足特定操作的需求。Cassandra 證明， 你可以超越通常的 CAP 理論的解讀，而世界仍然在轉動。
我們來看看兩種不同的極端。比如我必須從資料庫中讀取一個要求具有很高一致性的值，也就是說，我必須 100% 保證能夠讀取到先前寫入的最新的內容。在這種情況下，我可以通過指定一致性水平為「ALL」來從 Cassandra 讀取資料，這時要求所有節點都有資料的一致的副本。這裡我們不具有對任何節點失效和網路分裂的容錯性。在另一個極端的方面，如果我不特別關心一致性，或僅 僅就是希望最佳性能，我可以使用一致性級別「ONE」來訪問資料。在這種情況下，從任意一個保存有這個副本的節點獲取資料都可以——即使資料有三個副本， 也並不在意其他兩個有副本的節點是否失效或是否有不同，當然，這種情況下我們讀到的資料可能不是最新的。
不僅如此，你不必被迫生活在黑白世界中。比如，在我們的一個特定的應用中，重要的讀寫操作通常使用「QUORUM」特定群體一致性級別，這意味著大部分存有此資料的節點上的副本是一致的——我這裡是個簡要描述，具體寫你的 Cassandra 程序之前最好還是仔細研究一下。從我們的視角看，這這提供了一個合理的節點失效與網路分裂的耐受性，同時也提供了很高的一致性。而在一般情況下，我們使用前面提到的「ONE」一致性級別，這可以提供最高的性能。就是這樣。
對我們來說，這是 Cassandra 的一個巨大的加分特點。我們不僅能輕易地調整我們的系統，也可以設計它。例如， 當一定數量的節點失效或出現 網絡連接故障時，我們的大部分服務仍然可以繼續工作，只有那些需要資料一致性的服務會失效。HBase 並沒有這麼靈活，它單純地追求系統的一個方面（CP），這讓我再次看到了 SQL 開發者和查詢優化人員們之間的那道隔閡——有些事情最好能夠超越它，HBase！
在我們的專案中，Cassandra 已經證明了它是有史以來最靈活的系統，雖然你可能在對這個問題進行投票（QUORUM）的時候發現的，主腦會遺失一致性 ？！。
什麼時候單體會比模組化強？
Cassandra 和 HBase 的一個重要區別是， Cassandra 在每個節點是一個單體 Java 進程(Process)，而完整的 HBase 解決方案卻由不同部分組成：有資料庫進程本身，它可能會運行在多個模式；一個配置好的 hadoop HDFS 分散式檔案系統，以及一個 Zookeeper 系統來協調不同的 HBase 進程。 那麼，這是否意味著 HBase 有更好的模組化結構呢？
雖然 HBase 的這種架構可能確實可以平衡不同開發團隊的利益，在系統管理方面，模組化的 HBase 卻無法視為一個被加分的專案。事實上，特別是對於一些小的初創公司，模組化倒是一個很大的負面因素。
HBase 底層相當複雜，任何對此有疑惑的人應該讀讀 Google 的 GFS 和 BigTable 的論文。即使是在一個單一節點的偽分散式模式下來架設 HBase 也很困難——事實上，我曾經費力寫過一篇快速入門的教程（如果你要試試HBase的話
看看這裡）。在這個指南里你可以看到，設置好 HBase 並啟動它實際包含了兩個不同系統的手工設置：首先是 hadoop HDFS，然後才是 HBase 本身。
再來，HBase 的配置檔案本身就是個怪獸，而你的設置可能和缺設的網路配置有極大的不同（在文章裡我寫了兩個不同的 Ubuntu 的缺設網路設置，以及 EC2 裡易變的 Elastic IP 和內部分配的網域名稱）。當系統工作不正常的時候，你需要查看大量的日誌。所有的需要修復的東西的資訊都在日誌裡，而如果你是一個經驗豐富的管理員的話，就能發現並處理問題。
但是，如果是在實際營運服務(Service)過程中出現問題，而你又沒有時間耐心查找問題呢？如果你和我們一樣，只有一個小的開發團隊卻有遠大的目標，沒有經歷 7*24 不停營運系統監控管理會怎麼樣呢？嚴肅地說，如果你是一個希望學習 NoSQL 系統的高級 DB 管理員的話，那麼選擇 HBase。這個系統超級複雜，有靈巧雙手的管理員肯定能拿到高薪。但是如果你們是一個像我們一樣盡力去發現隧道盡頭的小團隊的話，還是等著聽聽別的閒話吧。
勝在 Gossip！
Cassandra 是一個完全對稱的系統。也就是說，沒有主節點或像 HBase 裡的 Region server 這樣的東西——每個節點的角色是完全一樣的。不會有任何特定的節點或其他實體來充當協調者的角色，叢集(Cluster)中的節點使用稱為 「Cossip」 的純 P2P 通信協議來協調他們的行為。
對 Gossip 的詳細描述和使用 Gossip 的模型超出了本文的內容，但
Cassandra 改採用的 P2P 通信模型都是論證過的，比如發現節點失效的消息傳播到整個系統的時間，或是一個客戶應用的請求被路由到保存資料的節點的時間，所有這些過程所消耗的時間都毫無疑問的非常的短。我個人相信，Cassandra 代表了當今最振奮的一種 P2P 技術，當然，這和你的 NoSQL 資料存儲系統的選擇無關。
那麼，這個基於 Gossip 的架構究竟給 Cassandra 使用者帶來什麼顯示的好處呢。 首先，繼續我們的系統管理主體，系統管理變得簡單多了。比如，增加一個新節點到系統中就是啟動一個 Cassandra 進程並告訴它一個種子節點（一個已知的在叢集中的節點）這麼簡單。試想當你的分散式叢集可能運行在上百個節點的規模上的時候，如此輕易地增加新節點簡直是難以置信。更進一步，當有什麼出錯的時候，你不需要考慮是哪種節點出了問題——所有節點都是一樣的，這讓調試成為了一個更加易於進行且可重複的過程。
第二，我可以得出結論，Cassandra 的 P2P 架構給了它更好的性能和可用性。這樣的系統中，負載可以被均衡地三步倒各個節點上，來最大化潛在的並行性，這個能力讓系統面臨網路分裂和節點失效的時候都 能更加的無縫，並且節點的對稱性防止了 HBase 中發現的那種在節點加入和刪除時的暫時性的性能都懂（Cassandra 啟動非常迅速，並且性能可以隨著節點的加入而平滑的呈線性擴展）。
如果你想尋找更多更多的證據，你會對一個原來一直關注 hadoop 的小組（應該對 HBase 更加偏愛）的報告很感興趣……
一份報告勝過千言萬語。我是指圖表
Yahoo！進行的第一個 NOSQL 系統的完整評測。研究似乎證實了 Cassandra 所享有的性能優勢，從圖表上看，非常傾向於 Cassandra。目前這些論文還是草稿，你可以從這裡找到這些論文：
http://www.brianfrankcooper.net/pubs/ycsb-v4.pdf
http://www.brianfrankcooper.net/pubs/ycsb.pdf
注意：這份報告中 HBase 僅在對一個範圍的記錄進行掃瞄(Scan)這一項上優於 Cassandra。雖然 Cassandra 團隊相信他們可以很快達到 HBase 的時間，但還是值得指出，在通常的 Cassandra 配置中，區間掃瞄幾乎是不可能的。我建議你可以無視這一點，因為實際上你應該在 Cassandra 上面來實作你自己的索引(Index)，而非使用區間掃瞄。如果你對區間掃瞄和在 Cassandra 中存儲索引相關問題有興趣，可以看我的
這篇文章。
http://www.brianfrankcooper.net/pubs/ycsb.pdf
最後一點： 這篇文章背後的 Yahoo！研究團隊正嘗試讓它們的評測應用通過法律部門的評估，並將它發佈給社群。如果他們成功的話，我當然希望他們成功，我們將能夠看到一個持續的競 爭場面，不論 HBase 還是 Cassandra 無疑都會進一步提高它們的性能。
鎖(Lock)和有用的模組性
毫無疑問，你會從 HBase 陣營聽到這樣的聲音：HBase 的複雜結構讓它可以提供 Cassandra 的 P2P 架構無法提供的東西。其中一個例子可能就是 Hbase 提供給開發者-行(Row)鎖機制，而 Cassandra 則沒有（ 在 HBase 中，因為資料副本發生在 hadoop 底層，行鎖可以由 region server 控制，而在 Cassandra 的 P2P 架構中，所有節點都是平等的，所以也就沒有節點可以像一個網管囊樣負責鎖定有副本的資料）。
不過，我還是把這個問題返回到關於模組化的爭論中，這實際是對 Cassandra 有理的。 Cassandra 通過在對稱節點上分散式存儲資料來實作 BigTable 的資料模型。它完整地實作了這些功能，而且是以最靈活和高性能的方式實作的。但如果你需要鎖、事務交易和其它功能的話，這些可以以模組的方式添加到你的系統之中——例如，我們發現我們可以使用 Zookeeper 和相關的工具來很簡單地為我們的應用提供可擴展的鎖功能（對於這個功能，Hazelcast 等系統可能也可以實作這個功能，雖然我們沒有進行研究）。
通 過為一個窄領域目的來最小化它的功能，對我來說，Cassandra 的設計達到了它的目的——比如前面指出可配置 CAP 的折衷。這種模組性意味著你可以依據你的需求來構建一個系統——需要鎖，那麼拿來 Zookeeper，需要存儲全文索引，拿來 Lucandra ，等等。 對於我們這樣的開發者來說，這意味著我們不必部署複雜度超出我們實際需要的系統，給我們提供了更加靈活的構建我們需要的應用的終極道路。
MapReduce， 別提 MapReduce！
Cassandra 做的還不夠好的一件事情就是 MapReduce！對於不精通此項技術同學簡單的解釋一句，這是一個用於並行處理大量資料的系統，比如從上百萬從網絡上抓取的頁面提取統計資訊。 MapReduce 和相關系統，比如 Pig 和 Hive 可以和 HBase 一起良好協作，因為它使用 HDFS 來存儲資料，這些系統也是設計用來使用 HDFS 的。如果你需要進行這樣的資料處理和分析的話，HBase 可能是你目前的最佳選擇。記住，這就像小馬過河！
因此，我停止了對 Cassandra 的優點的讚美，實際上，HBase 和 Cassandra 並不一定是一對完全的競爭對手。雖然它們常常可以用於同樣的用途，和 MySQL 和 PostgreSQL 類似，我相信在將來它們將會成為不同應用的首選解決方案。比如，據我所知 StumbleUpon 使用了 HBase 和 hadoop MapReduce 技術，來處理其業務的大量資料。Twitter 現在使用 Cassandra 來存儲實時交互的社區發言，可能你已經在某種程度上使用它了。作為一個有爭議的臨別贈言，下面我們進入下一個話題。
註：在繼續下一個小節之前，我要指出，Cassandra 在 0.6 版本會有 hadoop 支持，所以 MapReduce 整合能獲得更好的支持。
兄弟，我不能失去資料…
作為先前 CAP 理論爭議的一個可能結果，可能有這樣的印象，HBase 的資料似乎比 Cassandra 中的資料更安全。這是我希望揭露的最後一個關於 Cassandra 的秘密， 當你寫 入新資料的時候，它實際上立刻將它寫入一個將要存儲副本的仲裁節點的 commit log 當中了，也被覆寫至節點們的 RAM 中。這意味著如果你完全讓你的叢集意外停機，只可能會損失極少資料。更進一步，在系統中，通過使用 Merkle tree 來組織資料的過分不一致（資料熵, data entropy ），更加增加了資料的安全性。
事實上，我對 HBase 的情況並不是非常確切——如果能有更細節的情況，我回盡快更新這裡的內容的——但現在我的理解是，因為 hadoop 還不支持 append，HBase 不能有效地將修改的塊狀資訊刷入 HDFS （新的對資料變化會被覆製為多個副本並永久化保存）。這意味著會有一個更大的缺口，你最新的更改是不可見的（如果我錯了，可能是這樣，請告訴我，我回修正文）。
所以，儘管希臘神話中的 Cassandra 非常不幸（譯註：Cassandra 是希臘神話裡，特洛伊的那個可憐的女先知的名字，如果你不知道詳情的話，可以參考wiki），但你的 Cassandra 中的資料不會有危險。
註：Wade Amold 指出， hadoop .21 很快就會發佈，其中將會解決 HBase 的這個問題。