MongoDB、Cassandra、HBase的事務設計策略

MongoDB、Cassandra、HBase的事務設計策略

NoSQL資料庫（如MongoDB、Cassandra、Hbase、DynamoDB、Riak）讓應用程式開發變得更簡單。它們提供了相當靈活的資料模型和豐富的資料類型，而且與許多傳統資料庫系統相比，更易於安裝和配置。但缺少原子事務支援卻是一大退步。Daniel Abadi是耶魯大學的一名副教授，主要從事資料庫系統架構和實現研究。近日，他在一篇 文章 中剖析了NoSQL資料庫不支援原子事務的原因，並提供了兩種實現可擴充、事務型NoSQL資料庫的方案。

原子事務允許對資料庫中的不同資料項目同時進行寫操作，這些操作要麼全部執行，要麼全部不執行。而且，結合恰當的並發控制機制，原子性可以確保並發及後續事務要麼可以看到原子事務所有已完成的寫入，要麼一個都看不到。缺少原子事務，應用程式開發人員就需要自己處理一組寫操作僅有部分成功的情況。

也許有人會認為，NoSQL資料庫比較新，還沒有時間實現原子事務支援。實際上，Cassandra的“批次更新”特性可以視為向這個方向前進了一小步。不過，NoSQL資料庫已經出現了將近十年，它們沒有實現事務支援顯然有更深層次的原因，那就是對可擴充性的關注。按照設計，大多數NoSQL系統都要能夠跨多台不同的機器擴充，資料庫中的資料分布在不同的機器上。一個事務中的寫入操作可能會訪問多個分區（在多台機器上）的資料，這就是“分散式交易”。在分散式交易中確保原子性需要參與事務的機器相互協作。每一台機器都必須確定，事務在其它機器上能夠成功提交。而且，需要有一個協議，確保事務寫入操作涉及的機器在寫入資料狀態穩定之前都不會出現故障。這個協作過程不僅會消耗大量的資源，而且會增加資料庫請求延遲。更大的問題是，在協作過程完成之前，其它操作無法讀取該事務寫入的資料。並發事務延遲會導致其它與出現延遲交易在時間上存在重疊的事務延遲，最終導致系統“阻塞 (cloggage)”。分散式交易所需的分布式協作會嚴重影響資料庫系統的效能，包括事務輸送量和事務延遲。因此，大多數NoSQ系統都選擇了不支援事務。

MongoDB、Riak、Hbase和Cassandra都支援單個 鍵 的事務操作。這是因為單個鍵的所有資訊都儲存在單台機器上。因此，單個鍵的事務操作並不涉及上述複雜的分布式協作。由於分散式交易需要分布式協作，所以似乎必須在效能可擴充性和分散式交易支援之間進行權衡。事實上，許多NoSQL資料庫供應商都是基於這個假設，在構建可擴充系統時，為了防止伺服器效能退化，放棄支援分布式原子事務。

Daniel指出，這是 完全錯誤 的。可擴充系統是可以支援高效能分布式原子事務的。他們最近發表了一篇 論文 ，提出了一種在可擴充系統中支援原子事務的、新的權衡策略，具體是在公平性、隔離性和輸送量（FIT）三者之間進行取捨。其中，公平性是指任何事務的執行都不會因為其它事務被故意延遲，而隔離性可以確保相互衝突的事務可以看到其它事務的寫入操作。一個支援分布式原子事務的可擴充資料庫至少可以實現上述三個屬性中的兩個。FIT三者之間的取捨可以產生三種支援分布式原子事務的方案：

• 保證公平性和隔離性而犧牲輸送量的系統；
• 保證公平性和輸送量而犧牲隔離性的系統；
• 保證隔離性和輸送量而犧牲公平性的系統。

換句話說，下面兩種方法都可以構建出具備高分散式交易輸送量的可擴充系統。

放棄隔離性

如上所述，導致資料庫系統阻塞的根本原因是分布式協作。更確切地說，如果一個事務正在執行，那麼其它需要訪問共用資料的事務必須等到分布式協作完成後才能進行。這種等待就是由強隔離性所保證的，因為它確保事務可以看到與它衝突的事務。如果放棄隔離性，那麼其它事務就看不到其它事務的操作，也就不必等待分布式協作完成就可以執行和提交。而且，有一類資料庫約束可以確保分散式資料庫在事務弱隔離情況下的正確性。更多資訊可以閱讀Peter Bailis的文章《 多分區原子讀（RAMP） 》。

放棄公平性

分布式協作同隔離機制在時間上存在重疊。所以，可以通過重新設定分布式協作的順序最小化兩者之間的時間重疊，從而減輕二者之間的相互影響。以此為基礎構建的系統放棄了公平性，可以選擇最合適的時間進行分布式協作，Daniel將這樣的系統稱為 “隔離性-輸送量”系統 。比如，可以在事務之外進行協作，協作所需的時間不會增加並發事務的執行時間。

G-Store 就是一個很好的“隔離性-輸送量”系統樣本。它支援多鍵事務，並將事務範圍限制為應用程式動態定義的鍵集，即KeyGroup。該鍵集可以隨需建立和銷毀。當應用程式定義了一個KeyGroup，G-Store會將相應的索引值對全部複製到一個領導節點上，該鍵集上的所有事務都會在該領導節點上執行。因此，G-Store事務並不需要在事務執行期間執行分布式提交協議。這裡的關鍵是，G-Store仍然必須執行分布式協作，但協作過程在事務執行之前完成 ——在需要考慮事務隔離性之前。一旦協作過程完成，事務很快就會完成，共用資料的並發事務就不需要等待分布式協作。這樣，G-Store就實現了高輸送量和強隔離性。

因此，實現高輸送量分散式交易的關鍵是按照上述方法在時間上將分布式協作同隔離機制分開。

更多MongoDB相關內容可以看看以下的有用連結： 

MongoDB 3.0 正式版發布下載 

CentOS編譯安裝MongoDB

CentOS 編譯安裝 MongoDB與mongoDB的php擴充

CentOS 6 使用 yum 安裝MongoDB及伺服器端配置

Ubuntu 13.04下安裝MongoDB2.4.3

MongoDB入門必讀(概念與實戰並重)

Ubunu 14.04下MongoDB的安裝指南

《MongoDB 權威指南》(MongoDB: The Definitive Guide)英文文字版[PDF]

Nagios監控MongoDB分區叢集服務實戰

基於CentOS 6.5作業系統搭建MongoDB服務

MongoDB 的詳細介紹：請點這裡
MongoDB 的：請點這裡 

本文永久更新連結地址：