NoSql對於事務的支援

2021-08-05 22:41:39 字數 2182 閱讀 4925

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就實現了高吞吐量和強隔離性。

因此,實現高吞吐量分布式事務的關鍵是按照上述方法在時間上將分布式協作同隔離機制分開。

感謝郭蕾對本文的審校。

Hive 的事務支援

hive 開始支援事務,是在 hive 0.14 之後。hdfs 的檔案,只能允許新建,刪除,對檔案中的內容進行更新,不允許單條修改。hive 的檔案儲存是基於 hdfs 檔案存在的,所以原則上不會直接對 hdfs 做檔案內容的事務更新,只能是採取另外的手段來完成。即用 hdfs 檔案作為原始資料,...

InnoDB事務支援

innodb與myisam的最大不同有兩點 一是支援事務 transaction 二是採用了行級鎖。行級鎖和表級鎖本來就有許多不同之處,另外,事務的引入也帶來了一些新問題。更新丟失 需要應用程式對要更新的資料加必要的鎖來解決,因此,防止更新丟失應該是應用的責任。髒讀 不可重複讀 和 幻讀 其實都是資...

事務的概念和MySQL事務支援

事務是由一步或幾步資料庫操作序列組成邏輯執行單元,這系列操作要麼全部執行,要麼全部放棄執行。程式和事務是兩個不同的概念。一般而言 一段程式中可能包含多個事務。事務具有四個特性 原子性 atomicity 一致性 consistency 隔離性 isolation 和持續性 durability 這四...