Jonathan Ellis曾寫過一篇博文《NoSQL Ecosystem》，對多種NoSQL數據庫產品從可擴展性、數據模型與查詢模型等方面進行了比較， Jametong對本博文進行了翻譯，現轉載于此，以方便大家學習。
空前的數據量正在驅動商業尋找傳統關系型數據庫的替代方案，它已經為我們服務30多年了（今年5月份ACM剛剛給關系型數據慶祝40歲生日）。總體來講，這些替代方案就是目前知名的“NoSQL數據庫”。
關系型數據庫的基本問題是無法處理許多現代的工作負載。有三個具體的問題領域：向外擴展 （Scale out）類似于Digg（3TB的綠色徽章數據）或Facebook（50T 的收件箱搜索數據）或Ebay（總共2PB的數據）的數據集，單機性能限制以及僵化的概要設計。
商業上（包含Rackspace Cloud公司）需要尋找新的方式來存儲并擴展大規模的數據。我最近寫了一篇關于Cassandra的文章，一個我們投入了資源的非關系型數據庫。還有另外一些正在運作中的非關系型數據庫，它們匯總在一起被我們稱為“NoSQL運動”。
“NoSQL”這個術語實際上是由一個Rackspace 的員工Eric Evans最先提出的，當時來自Last。fm網站的Johan Oskarsson提議組織一次開源分布式數據庫的研討會。 這個名稱與概念就一起流行了起來。
有些人反對NoSQL這個說法，因為它聽起來像是僅僅表明了我們不做什么，而不是我們在做什 么。 事實確實是這樣，我也基本同意此說法，但是這個術語仍然有其價值，因為當關系型數據庫是你所知道的唯一工具時，每個問題看起來都像個拇指（俗語， 如果你手里有一個錘子，你看到什么都是釘子，譯者補充）。NoSQL這個術語起碼讓人們知道還有其他的選項可供選擇。但是，當關系型數據庫是解決問題的最 佳工具時，我們并不是反關系型數據庫者;它的涵義應該是“不僅僅有SQL（Not Only SQL）”而不是“不再有SQL（No SQL at all）”。
有關NoSQL名稱的一個真實的憂慮是，它是如此大的一個概念，以致于差異巨大的設計都可以 涵蓋其中。如果在討論各種產品時沒有搞清楚這一點，就會導致概念混亂。因此，我建議大家沿著下面三個維度來思考這些數據庫選項: 可伸縮性（scalability）、數據模型與查詢模型（data and query model）以及持久化設計（persistence design）。
我選擇了10種NoSQL數據庫作為示例。這不是一份詳盡的清單，但是這里討論的概念對于評估其他的NoSQL數據庫也至關重要。
可伸縮性（Scalability）
通過使用復制， 就可以輕易擴展讀的規模，因此，每當我在此文中談到規模伸縮（scaling），都是表示通過自動分區將數據分布到多臺機器以擴展寫的規模。我們將做這種 事情的系統稱為“分布式數據庫”。它們包括Cassandra、HBase、Riak、Scalaris、Voldemort以及其他很多類似的系統。如 果你的寫容量或寫數據大小已經無法在一臺機器上進行處理，如果你不想自己手工來管理分區的話，這些就是你的唯一選項了。（你不會這么做吧？）
人們使用分布式數據庫主要關注兩件事情：1） 是否支持多個數據中心以及； 2） 能否在對應用透明的前提下往正在運行的集群中添加新機器的能力。
非分布式NoSQL數據庫包括CouchDB、MongoDB、Neo4j、Redis以及 Tokyo Cabinet。它們可作為分布式系統的持久層;：MongoDB提供了受限制的數據分片（Sharding）功能，CouchDB也有一個獨立的 Lounge項目來支持做類似的分片功能，Tokyo Cabinet可用作Voldemort的存儲引擎。
數據模型與查詢模型
NoSQL數據庫之間的數據模型與查詢API千差萬別。
部分重點內容介紹：
Cassandra與HBase共同使用的ColumnFamily模型都是受到 Google的Bigtable 論文第2節的啟發。 （Cassandra丟棄了歷史版本，并增加了超級列 （SuperColumn）的概念）。在這兩個系統中，都有與你之前看到的關系型數據庫類似的行/列概念，但是此處的行是稀疏的行:你想要一行有多少列， 一行就可以有多少列，這些列并不需要事先定義好。
鍵值（Key/value）模型是最簡單也最容易實現的模型，但是，如果你僅想對值（Value）的一部分進行查詢/更新時，它的效率會比較低。要想在一個分布式的鍵值上，實現更加復雜的結構也會非常困難。
文檔數據庫實際上是更高級的鍵/值（Key/Value）數據庫，允許在每個鍵上關聯嵌套的值。相對于每次簡單地返回整個BLOB（二進制大對象） 來講，文檔數據庫支持更高效的查詢。
Neo4j擁有一個非常獨特的數據模型，它以節點與邊的形式在圖中存儲對象與關系。對于適合這個模型（例如，分層數據）的查詢，它的性能可能會達到其替代選項的1000 倍。
Scalaris的獨特之處在于，它可以提供跨越多個鍵的分布式事務。（關于一致性與可用性的權衡的討論超出了本文的范圍，但是，在評估分布式系統時，它也是需要記住的一方面。）
持久化設計
關于持久化設計，我的意思是“數據在內部是如何存儲的?”
持久化模型可以為我們提供大量關于這些數據庫適合處理多大工作負載的信息。
內存數據庫非常非常快（單臺機器上的Redis可以處理100，000次操作/秒）， 但是無法處理超過可用內存的數據集。持久性（Durability，數據不會由于服務器崩潰或停電而丟失）也是個問題; 在兩次刷新到磁盤的時間間隔內預期數據丟失量可能非常大。Scalaris是我們此列表中唯一的內存數據庫，它通過復制來解決持久性的問題，但是，由于它 不支持跨越多個數據中心，因此，如果遇到類似電源故障一類的問題數據仍將非常脆弱。
在為了持久性寫入一個僅可追加的提交日志之后，Memtable與SSTable會緩沖內存 中的寫操作。在接受了足夠多的寫操作之后 （Memtable達到一定的閾值），就會對memtable中的數據進行排序，并一次性寫入到磁盤，寫入的文件就是一個“sstable。” 這樣它就可以提供接近于內存處理的性能，因為它不涉及任何檢索操作，同時又可以避免純粹在內存中的方法那樣遭遇持久性問題。（在前面引用的 Bigtable論文的第5。3與5。4兩節，以及論文日志結構的合并樹 （The Log-Structured merge-tree）中對此都有詳細的描述）
幾乎從有數據庫開始，B-樹就開始在數據庫中使用了。它們提供健壯的索引支持，但是在旋轉磁盤（仍然是目前最經濟實用的存儲介質）上， 它的性能表現比較差，因為它讀寫任何內容都會涉及到多次磁盤檢索。
CouchDB的僅可做追加操作的 B-樹（Append-Only B-tree）是一個比較有趣的變體，它以限制CouchDB并發寫（one write at a time）的代價避免了其檢索的開銷。
結論
NoSQL運動在2009年取得了爆發性的效果，因為越來越多的企業需要處理大規模的數據。Rackspace Cloud公司很高興在NoSQL運動扮演了一個較早期的角色，還會持續為Cassandra投入資源并支持與NoSQL East類似的活動。
