雖然NoSQL很火熱，但是真正應用NoSQL的用戶不多。本文將為大家以對比的形式來介紹不同NoSQL產(chǎn)品的特點，希望對大家有所幫助。

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

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

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

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

有些人反對NoSQL這個說法,因為它聽起來像是僅僅表明了我們不做什么,而不是我們在做什么. 事實確實是這樣,我也基本同意此說法,但是這個術語仍然有其價值,因為當關系型數(shù)據(jù)庫是你所知道的唯一工具時,每個問題看起來都像個拇指(俗語,如果你手里有一個錘子,你看到什么都是釘子,譯者補充).NoSQL這個術語起碼讓人們知道還有其他的選項可供選擇.但是,當關系型數(shù)據(jù)庫是解決問題的最佳工具時,我們并不是反關系型數(shù)據(jù)庫者;它的涵義應該是“不僅僅有SQL(Not Only SQL)”而不是“不再有SQL(No SQL at all)”.

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

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

可伸縮性(Scalability)

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

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

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

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

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

(相關鏈接: Thrift, map/reduce views, Thrift, Cursor, Graph, Collection, Nested hashes, get/put, get/put, get/put)

部分重點內(nèi)容介紹:

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

鍵值(Key/value)模型是最簡單也最容易實現(xiàn)的模型,但是,如果你僅想對值(Value)的一部分進行查詢/更新時,它的效率會比較低.要想在一個分布式的鍵值上,實現(xiàn)更加復雜的結構也會非常困難.

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

Neo4j擁有一個非常獨特的數(shù)據(jù)模型,它以節(jié)點與邊的形式在圖中存儲對象與關系.對于適合這個模型(例如,分層數(shù)據(jù))的查詢,它的性能可能會達到其替代選項的1000倍.

Scalaris的獨特之處在于,它可以提供跨越多個鍵的分布式事務.(關于一致性與可用性的權衡的討論超出了本文的范圍,但是,在評估分布式系統(tǒng)時,它也是需要記住的一方面.)

持久化設計

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

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

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

在為了持久性寫入一個僅可追加的提交日志之后,Memtable與SSTable會緩沖內(nèi)存中的寫操作.在接受了足夠多的寫操作之后(Memtable達到一定的閾值),就會對memtable中的數(shù)據(jù)進行排序,并一次性寫入到磁盤,寫入的文件就是一個“sstable.” 這樣它就可以提供接近于內(nèi)存處理的性能,因為它不涉及任何檢索操作,同時又可以避免純粹在內(nèi)存中的方法那樣遭遇持久性問題.(在前面引用的Bigtable論文的第5.3與5.4兩節(jié),以及論文日志結構的合并樹(The Log-Structured merge-tree)中對此都有詳細的描述)

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

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

結論

NoSQL運動在2009年取得了爆發(fā)性的效果,因為越來越多的企業(yè)需要處理大規(guī)模的數(shù)據(jù).Rackspace Cloud公司很高興在NoSQL運動扮演了一個較早期的角色,還會持續(xù)為Cassandra投入資源并支持與NoSQL East類似的活動.

原文鏈接：http://www.dbthink.com/?p=458

[[11560]]

【編輯推薦】

1. 用NoSQL來替代MySQL在Digg中的原因
2. MongoDB CEO談NoSQL的大數(shù)據(jù)量處理能力
3. 51CTO專訪蓋國強：NoSQL很火 但還需市場檢驗
4. 詳解NoSQL數(shù)據(jù)庫使用實例
5. 云計算時代NoSQL當?shù)?關系數(shù)據(jù)庫日薄西山