空前的數據量正在驅動商業尋找傳統關係型數據庫的替代方案,它已經爲我們服務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千差萬別.
(相關鏈接: Thrift
, map/reduce
views
, Thrift
,
Cursor
, Graph
, Collection
,
Nested hashes
, get/put
, get/put
, get/put
)
部分重點內容介紹:
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 類似的活動.
可以到Google 討論組 找到與NoSQL相關的會議通知與討論.
