[雲端計算] NOSQL 背後的共通原則

同樣的這篇文章, 也是老魚從簡體中文譯者那“借來”的, 除了加工再潤詞成正體中文(當然也用紅筆自行畫了重點～呵), 在文中作者提到了 Google 檔案系統論文中最初的設計基礎, 建立在“硬體與網路的失效(Failure)是必定會發生的！”, 這才是一個真正的世界, 大多的 NOSQL 實作可分為二大觀點, 重視使用硬碟, 抑或盡可能的利用 RAM做為一級存儲, 作者也進行了比較說明, 本文中對於想進入 NOSQL 技術領域者, 可以視為一篇入門文選, 所以老魚在此分享本文給各位.

1. Wikipedia - NOSQL, http://en.wikipedia.org/wiki/NoSQL
2. NOSQL Database ORG, http://nosql-database.org/

---

原文: http://natishalom.typepad.com/nati_shaloms_blog/2009/12/the-common-principles-behind-the-nosql-alternatives.html
Posted by Nati Shalom at 12:01 PM Dec 15, 2009
譯文: 王旭（http://wangxu.me , @gnawux）2009年12月 16/19日
簡體轉正體中文及校潤詞句：郭朝益(http://wisdomfish.org, @master)

---

幾個星期之前，我寫了一篇文章描述了經常被稱作 NOSQL 這一類新型資料庫的背後需求動機。幾個星期之前，我在 Qcon 上發表了一個演講，其中，我介紹了一個 可伸縮性（scalable）的 Twitter 應用的構建模式，在我們的議論中，一個顯而易見的難題就是資料庫的 規模可伸縮性(scalability)。要解答這個問題，我試圖尋找隱藏在各種 NOSQL 背後的共通模式，並展示他們是如何解決資料庫規模可伸縮性問題的。在本文中，我將盡力勾勒出這些共通的原則。


實作者們的共通原則

假設失效是必然發生的
Assume that Failure is Inevitable

---

與我們在此之前認知通過昂貴硬體之類的手段，盡力去避免失效的手段不同，NOSQL 實作都建立在硬碟、機器和網路都會失效(Failure)這些假設之上。我們有需要承認，我們不能徹底阻止這些失效，相反，我們需要讓我們的系統能夠在假使非常極端的條件下也能應付這些失效。Amazon S3 就是這種設計的一個好例子。你可以在我最近的文章 Why Existing Databases (RAC) are So Breakable! 中找到進一步描述。在那裡，我介紹了一些來自 Jason McHugh 所講演的以"失效"為導向的架構設計內容（Jason 是在 Amazon 做 S3 相關工作的高階工程師）。

對資料進行分區
Partition the Data
通過對資料進行分區(分割)，我們最小化了失效帶來的服務失效影響，也將讀寫操作的負載分佈到了不同的機器上。如果一個節點(Node)失效了，只有該節點上存儲的資料受到影響，而不是全部的資料。

對同一資料保持多個副本
Keep Multiple Replicas of the Same Data
大部分 NOSQL 實作都基於資料副本的熱備份(hot-backup)來保證連續的高可用性(high availability)。某些實作產品提供了 API，可以控制副本的複製，也就是說，當你存儲一個物件的時候，你可以在物件級別指定你希望保存的副本數量。在 GigaSpaces，我們還可以立即複製一個新的副本到其他節點，甚至在必要時啟動一台新機器。這讓我們不必在每個節點上保存太多的資料副本，從而降低總存儲量以節約成本。
你還可以控制副本複製是同步(synchronous)還是異步(非同步, asynchronous)的，或者兩者兼俱。這決定了你的叢集(Cluster)的一致性、可用性與性能[consistency, reliability and performance]三者。對於同步複製，可以犧牲性能保障一致性和可用性（進行寫入作業之後的任意讀取作業都可以保證得到相同版本的資料，即使是發生失效也會如此）。而最為常見的 GigaSpaces 的配置是同步副本到被分界點，異步存儲到後端存儲。

動態伸縮
Dynamic Scaling
要掌控不斷呈線性增長的資料量，大部分 NOSQL 實作提供了不停機或完全重建分區的擴展叢集的方法。一個已知的處理這個問題的演算法稱為一致性雜湊法(consistent hashing)。有很多種不同演算法可以實作一致性雜湊演算。

演算法會在節點加入或失效時 通知某一分區的鄰近節點。僅有這些節點受到這一變化的影響，而不是整個叢集。有一個協議用於掌控需要在原有叢集和新節點之間重新分佈的資料的變換區間。

另一個（簡單很多）的演算法使用邏輯分區。在邏輯分區中，分區的數量是固定的，但分區在機器上的分佈式動態的。於是，例如有兩台機器和 1000 個邏輯分區，那麼每 500 個邏輯分區會放在一台機器上。當我們加入了第三台機器的時候，就成了每 333 個分區放在一台機器上了。因為邏輯分區是輕量級的（基於在記憶體中的雜湊表[hash table]），分散這些邏輯分區非常容易。
第二種方法的優勢在於它是可預測並且一致的，而使用一致性雜湊演算方法，分區之間的重新分佈可能並不平穩，當一個新節點加入網路時可能會消耗更長時間。一個使用 者在這時尋找正在轉移的資料會得到一個異常。邏輯分區方法的缺點是可伸縮性受限於邏輯分區的數量。
更進一步的關於這一問題的討論，建議閱讀 Ricky Ho 的文章 NOSQL Patterns 。

對查詢式的支持
Query Support
在這個方面，不同的實作有著本質上相當的區別。不同實作的一個共通性在於雜湊表中的 key/value 匹配。有些實作提供了更高階的查詢式支持，例如文檔導向(document-oriented)的方 法，其中資料以 blob 的方式存儲，關聯一個鍵值對屬性列表(List)。這種模型是一種無預定義結構的（schema-less）存儲，對一個文檔增加或刪除屬性是非常容易 地，無需考慮文檔結構的演變。而 GigaSpaces 支持很多 SQL 操作。假如 SQL 查詢沒有指出特定的鍵值(key)，那麼這個查詢就會被平行地(parallel query) map 到所有的節點去，由客戶端完成結果的聚合(aggregated)。所有這些都是發生在系統後端的，使用者程式碼無需關注這些。

使用 Map/Reduce 處理聚合
Use Map/Reduce to Handle Aggregation
Map/Reduce 是一個經常被用來進行複雜分析的模型，經常會和 Hadoop 聯繫在一起。 map/reduce 常常被看作是平行聚合查詢(parallel aggregated queries)的一種模式。大部分 NOSQL 實作並不提供 map/reduce 的內建支持，需要一個外部的框架來處理這些查詢。對於 GigaSpaces 來說，我們在 SQL 查詢中隱含了對 map/reduce 的支持，同時也顯式地提供了一個稱為 executors 的 API 來支持 map/reduce。在這模型中，你可以將程式碼發送到資料所在地地方，並在該節點上直接運行複雜的查詢。這方面的更多細節，建議閱讀 Ricky Ho 的文章 Query Processing for NOSQL DB 。

磁碟基礎 vs. 內部記憶體的實作
Disk-Based vs. In-Memory Implementation

---

NOSQL 實作分為基於檔案的方法和在記憶體(RAM)中的方法。有些實作提供了混合模型，將RAM和磁碟結合使用。兩類方法的最主要區別在於每 GB 成本和讀寫(R/W)性能。

最近，Stanford University 斯坦福的一項稱為「The Case for RAMCloud」的調查，對磁碟和 RAM 兩種方法給出了一些性能和成本方面的有趣比較。總體上說，成本也是性能的一個函數。對於較低性能的實作，磁碟方案的成本遠低於基於 RAM 的方法，而對於高性能需求的場合，RAM 方案則更加廉價。

記憶體型態雲端系統 (RAMClouds)最顯而易見的缺點就是單位容量的高成本和高電能耗損。對於這些指標，RAMClouds 會比純粹的磁碟系統差 50到 100倍，比使用快閃記憶體(flash memory)的系統差5-10倍（典型配置情況和指標參見參考文獻[1]）。RAMClouds 同時還比基於磁碟和快閃記憶體的系統需要更多的機房面積。這樣，如果一個應用需要存儲大量的廉價資料，不需要高速存取，那麼，快閃記憶體將不是最佳選擇。
然而，對於要求高吞吐量需求的應用，RAMClouds 將更有競爭力。當使用每次操作的 成本和電能耗損作為衡量因素的時候，RAMClouds 的效率是傳統硬碟系統的 100 到 1000 倍，是快閃憶記體系統的 5-10 倍。因此，對於高吞吐量需求的系統來說，RAMClouds不僅提供了高性能，也提供了更高的效率。同時，如果使用 DRAM 動態記憶體晶片組提供的低功耗模式，也可以降低 RAMClouds 的電能功耗，特別是在系統閒置的時候。此外，RAMClouds 還有一些缺點，一些 RAMClouds 無法支持需要將資料在多個資料中心之間進行資料複製。對於這些環境，更新的時間延遲將主要取決於資料中心間資料傳輸的時間消耗，這就喪失了 RAMClouds 的時延方面的優勢。此外，跨資料中心的資料複製會讓 RAMClouds 資料一致性更能難保證。不過，RAMClouds 仍然可以在跨資料中心的情況下提供低時延的讀寫存取。

僅僅是炒作?
近來我見到的最多的 問題就是 「NOSQL 是不是就是炒作？」 或 「NOSQL 會不會取代現在的資料庫？」
我的回答是——NOSQL 並非始於今日。很多 NOSQL 實作都已經存在了十多年了，有很多成功案例。我相信有很多原因讓它們在如今比以往更受歡迎了。首 先是由於社交性網路(social networking)和雲端計算(cloud computing)的發展，一些原先只有很高端的組織才會面臨的問題，如今已經成為普遍問題了。 其次，已有的方法已經被發現無法跟隨需求一起擴展了。並且，成本的壓力讓很多組織需要去尋找更高性能的成本效益的價比方案，並且研究證實基於普通廉價硬體的分散式存儲解決方案,  甚至比現在的高端且高貴的關聯式資料庫系統(RDBMS)更加可靠。（進一步閱讀）所有這些導致了對這類「可伸縮性優先資料庫」的需求。這裡，我引用 AWS團隊的接觸工程師、VP， James Hamilton 在他的文章 One Size Does Not Fit All 中的一段話：

「規模可伸縮性優先考慮是那些必須具備無限可伸縮性的應用，能夠不受限制的擴展比更豐富的功能更加重要。這些應用包括很多需要高可伸縮性的網站，如 Facebook, MySpace, Gmail, Yahoo 以及 Amazon.com。有些網站實際上使用了關聯型資料庫系統(RDBMS)，而大部分實際上均並未採用之。這些服務的共通性在於對規模可伸縮性的需求比功能更重要，他們無法將應用泡製在一個單一 RDBMS 上。」

總結一下——我認為，現有的 SQL 資料庫可能不會很快淡出歷史舞台，但同時它們也不能解決世上的所有問題。NOSQL 這個名詞現在也變成了 Not Only SQL，這個變化表達了我的觀點。

參考

---

• No to SQL? Anti-database movement gains steam – My Take
• Why Existing Databases (RAC) are So Breakable!
• NoSQL Ecosystem By Jonathan Ellis,
• NoSQL: Distributed and Scalable Non-Relational Database Systems by Jeremy Zawodny
• NOSQL Patterns by Ricky Ho
• Query Processing for NOSQL DB by Ricky Ho
• One Size Does Not Fit All  by James Hamilton
• NOSQL debrief by Johan Oskarsson,
• The Case for RAMClouds: Scalable High-Performance Storage Entirely in DRAM by Department of Computer Science Stanford University
• GigaSpaces Map/Reduce API

[雲端計算]HBase vs Cassandra: 我們遷移系統的原因

首先要跟各位聲明的, 這篇文章內容主要是老魚去申請轉載而來, 而我僅是用長年閱讀簡體中文詞彙的經驗加以正體中文和稍加校詞潤飾, 特別選這篇文, 有幾個目的：

1. 老魚為一個新的SNS開發專案, 進行研究評估幾個雲端(分散式)儲存系統, 過程中也是棄了 HBase, MongoDB 選 Cassandra, 而當我這二天看到這篇文中的不少技術選型的出發點, 讓我閱讀後有不少處有所同感(在文章中標紅色的段落).
2. 籍由這篇文選, 希望同是身為電腦科學工程與甚至任職企業資訊採購決策管理者一份子的您, 能從這篇文中, 去思考當我們在企業中扮演一個對資訊科技採購時, 不應只是表面名牌價格與廠商行銷手法, 龐大複雜且難以駕馭系統規劃被廠商合理化之, 反造成企業長期的營運維護成本上升, 企業逐漸受外在資訊廠商所“挾持”, 從而失去企業自我資訊自主的競爭本能.
3. 這篇文中如果扣除作者在評論其二家產品, 各位看官也可以獲得不少目前電腦科學領域中當前最競爭的幾點新知, 尤其作者是以該領域的專家評論, 在出發點上就不會有太多被一般新聞過度炒作“雲端計算Cloud Computing”名詞上的疑慮.
4. 文中作者也對 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 中存儲索引相關問題有興趣，可以看我的 這篇文章。

最後一點： 這篇文章背後的 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 的這個問題。