Jonathan Ellis曾寫過一篇博文《NoSQL Ecosystem》，對多種NoSQL數(shù)據(jù)庫產(chǎn)品從可擴(kuò)展性、數(shù)據(jù)模型與查詢模型等方面進(jìn)行了比較， Jametong對本博文進(jìn)行了翻譯，現(xiàn)轉(zhuǎn)載于此，以方便大家學(xué)習(xí)。

空前的數(shù)據(jù)量正在驅(qū)動商業(yè)尋找傳統(tǒng)關(guān)系型數(shù)據(jù)庫的替代方案，它已經(jīng)為我們服務(wù)30多年了（今年5月份ACM剛剛給關(guān)系型數(shù)據(jù)慶祝40歲生日）。總體來講，這些替代方案就是目前知名的“NoSQL數(shù)據(jù)庫”。

關(guān)系型數(shù)據(jù)庫的基本問題是無法處理許多現(xiàn)代的工作負(fù)載。有三個(gè)具體的問題領(lǐng)域：向外擴(kuò)展 （Scale out）類似于Digg（3TB的綠色徽章數(shù)據(jù)）或Facebook（50T 的收件箱搜索數(shù)據(jù)）或Ebay（總共2PB的數(shù)據(jù)）的數(shù)據(jù)集，單機(jī)性能限制以及僵化的概要設(shè)計(jì)。

商業(yè)上（包含Rackspace Cloud公司）需要尋找新的方式來存儲并擴(kuò)展大規(guī)模的數(shù)據(jù)。我最近寫了一篇關(guān)于Cassandra的文章，一個(gè)我們投入了資源的非關(guān)系型數(shù)據(jù)庫。還有另外一些正在運(yùn)作中的非關(guān)系型數(shù)據(jù)庫，它們匯總在一起被我們稱為“NoSQL運(yùn)動”。

“NoSQL”這個(gè)術(shù)語實(shí)際上是由一個(gè)Rackspace 的員工Eric Evans最先提出的，當(dāng)時(shí)來自Last。fm網(wǎng)站的Johan Oskarsson提議組織一次開源分布式數(shù)據(jù)庫的研討會。 這個(gè)名稱與概念就一起流行了起來。

有些人反對NoSQL這個(gè)說法，因?yàn)樗犉饋硐袷莾H僅表明了我們不做什么，而不是我們在做什 么。 事實(shí)確實(shí)是這樣，我也基本同意此說法，但是這個(gè)術(shù)語仍然有其價(jià)值，因?yàn)楫?dāng)關(guān)系型數(shù)據(jù)庫是你所知道的唯一工具時(shí)，每個(gè)問題看起來都像個(gè)拇指（俗語， 如果你手里有一個(gè)錘子，你看到什么都是釘子，譯者補(bǔ)充）。NoSQL這個(gè)術(shù)語起碼讓人們知道還有其他的選項(xiàng)可供選擇。但是，當(dāng)關(guān)系型數(shù)據(jù)庫是解決問題的最 佳工具時(shí)，我們并不是反關(guān)系型數(shù)據(jù)庫者;它的涵義應(yīng)該是“不僅僅有SQL（Not Only SQL）”而不是“不再有SQL（No SQL at all）”。

有關(guān)NoSQL名稱的一個(gè)真實(shí)的憂慮是，它是如此大的一個(gè)概念，以致于差異巨大的設(shè)計(jì)都可以 涵蓋其中。如果在討論各種產(chǎn)品時(shí)沒有搞清楚這一點(diǎn)，就會導(dǎo)致概念混亂。因此，我建議大家沿著下面三個(gè)維度來思考這些數(shù)據(jù)庫選項(xiàng): 可伸縮性（scalability）、數(shù)據(jù)模型與查詢模型（data and query model）以及持久化設(shè)計(jì)（persistence design）。

我選擇了10種NoSQL數(shù)據(jù)庫作為示例。這不是一份詳盡的清單，但是這里討論的概念對于評估其他的NoSQL數(shù)據(jù)庫也至關(guān)重要。

可伸縮性（Scalability）

通過使用復(fù)制， 就可以輕易擴(kuò)展讀的規(guī)模，因此，每當(dāng)我在此文中談到規(guī)模伸縮（scaling），都是表示通過自動分區(qū)將數(shù)據(jù)分布到多臺機(jī)器以擴(kuò)展寫的規(guī)模。我們將做這種 事情的系統(tǒng)稱為“分布式數(shù)據(jù)庫”。它們包括Cassandra、HBase、Riak、Scalaris、Voldemort以及其他很多類似的系統(tǒng)。如 果你的寫容量或?qū)憯?shù)據(jù)大小已經(jīng)無法在一臺機(jī)器上進(jìn)行處理，如果你不想自己手工來管理分區(qū)的話，這些就是你的唯一選項(xiàng)了。（你不會這么做吧？）

人們使用分布式數(shù)據(jù)庫主要關(guān)注兩件事情：1） 是否支持多個(gè)數(shù)據(jù)中心以及； 2） 能否在對應(yīng)用透明的前提下往正在運(yùn)行的集群中添加新機(jī)器的能力。

非分布式NoSQL數(shù)據(jù)庫包括CouchDB、MongoDB、Neo4j、Redis以及 Tokyo Cabinet。它們可作為分布式系統(tǒng)的持久層;：MongoDB提供了受限制的數(shù)據(jù)分片（Sharding）功能，CouchDB也有一個(gè)獨(dú)立的 Lounge項(xiàng)目來支持做類似的分片功能，Tokyo Cabinet可用作Voldemort的存儲引擎。

數(shù)據(jù)模型與查詢模型

NoSQL數(shù)據(jù)庫之間的數(shù)據(jù)模型與查詢API千差萬別。

部分重點(diǎn)內(nèi)容介紹：

Cassandra與HBase共同使用的ColumnFamily模型都是受到 Google的Bigtable 論文第2節(jié)的啟發(fā)。 （Cassandra丟棄了歷史版本，并增加了超級列 （SuperColumn）的概念）。在這兩個(gè)系統(tǒng)中，都有與你之前看到的關(guān)系型數(shù)據(jù)庫類似的行/列概念，但是此處的行是稀疏的行:你想要一行有多少列， 一行就可以有多少列，這些列并不需要事先定義好。

鍵值（Key/value）模型是最簡單也最容易實(shí)現(xiàn)的模型，但是，如果你僅想對值（Value）的一部分進(jìn)行查詢/更新時(shí)，它的效率會比較低。要想在一個(gè)分布式的鍵值上，實(shí)現(xiàn)更加復(fù)雜的結(jié)構(gòu)也會非常困難。

文檔數(shù)據(jù)庫實(shí)際上是更高級的鍵/值（Key/Value）數(shù)據(jù)庫，允許在每個(gè)鍵上關(guān)聯(lián)嵌套的值。相對于每次簡單地返回整個(gè)BLOB（二進(jìn)制大對象） 來講，文檔數(shù)據(jù)庫支持更高效的查詢。

Neo4j擁有一個(gè)非常獨(dú)特的數(shù)據(jù)模型，它以節(jié)點(diǎn)與邊的形式在圖中存儲對象與關(guān)系。對于適合這個(gè)模型（例如，分層數(shù)據(jù)）的查詢，它的性能可能會達(dá)到其替代選項(xiàng)的1000 倍。

Scalaris的獨(dú)特之處在于，它可以提供跨越多個(gè)鍵的分布式事務(wù)。（關(guān)于一致性與可用性的權(quán)衡的討論超出了本文的范圍，但是，在評估分布式系統(tǒng)時(shí)，它也是需要記住的一方面。）

持久化設(shè)計(jì)

關(guān)于持久化設(shè)計(jì)，我的意思是“數(shù)據(jù)在內(nèi)部是如何存儲的?”

持久化模型可以為我們提供大量關(guān)于這些數(shù)據(jù)庫適合處理多大工作負(fù)載的信息。

內(nèi)存數(shù)據(jù)庫非常非常快（單臺機(jī)器上的Redis可以處理100，000次操作/秒）， 但是無法處理超過可用內(nèi)存的數(shù)據(jù)集。持久性（Durability，數(shù)據(jù)不會由于服務(wù)器崩潰或停電而丟失）也是個(gè)問題; 在兩次刷新到磁盤的時(shí)間間隔內(nèi)預(yù)期數(shù)據(jù)丟失量可能非常大。Scalaris是我們此列表中唯一的內(nèi)存數(shù)據(jù)庫，它通過復(fù)制來解決持久性的問題，但是，由于它 不支持跨越多個(gè)數(shù)據(jù)中心，因此，如果遇到類似電源故障一類的問題數(shù)據(jù)仍將非常脆弱。

在為了持久性寫入一個(gè)僅可追加的提交日志之后，Memtable與SSTable會緩沖內(nèi)存 中的寫操作。在接受了足夠多的寫操作之后 （Memtable達(dá)到一定的閾值），就會對memtable中的數(shù)據(jù)進(jìn)行排序，并一次性寫入到磁盤，寫入的文件就是一個(gè)“sstable。” 這樣它就可以提供接近于內(nèi)存處理的性能，因?yàn)樗簧婕叭魏螜z索操作，同時(shí)又可以避免純粹在內(nèi)存中的方法那樣遭遇持久性問題。（在前面引用的 Bigtable論文的第5。3與5。4兩節(jié)，以及論文日志結(jié)構(gòu)的合并樹 （The Log-Structured merge-tree）中對此都有詳細(xì)的描述）

幾乎從有數(shù)據(jù)庫開始，B-樹就開始在數(shù)據(jù)庫中使用了。它們提供健壯的索引支持，但是在旋轉(zhuǎn)磁盤（仍然是目前最經(jīng)濟(jì)實(shí)用的存儲介質(zhì)）上， 它的性能表現(xiàn)比較差，因?yàn)樗x寫任何內(nèi)容都會涉及到多次磁盤檢索。

CouchDB的僅可做追加操作的 B-樹（Append-Only B-tree）是一個(gè)比較有趣的變體，它以限制CouchDB并發(fā)寫（one write at a time）的代價(jià)避免了其檢索的開銷。

結(jié)論

NoSQL運(yùn)動在2009年取得了爆發(fā)性的效果，因?yàn)樵絹碓蕉嗟钠髽I(yè)需要處理大規(guī)模的數(shù)據(jù)。Rackspace Cloud公司很高興在NoSQL運(yùn)動扮演了一個(gè)較早期的角色，還會持續(xù)為Cassandra投入資源并支持與NoSQL East類似的活動。