CouchDB與關系數據庫中的分布式一致性？

Question

從CouchDB指南 ：

對於大多數數據庫而言，在單個數據庫節點內維護一致性相對容易。 當您嘗試維護多個數據庫服務器之間的一致性時，真正的問題開始浮出水面。 如果客戶端在服務器A上執行寫操作，我們如何確保它與服務器B或C或D一致？ 對於關系數據庫而言，這是一個非常復雜的問題，整本書都專門針對其解決方案。 您可以使用多主服務器，主/從服務器，分區，分片，直寫式緩存以及各種其他復雜技術。

為什么在關系模型中很難維護數據庫服務器之間的一致性？ 為什么CouchDB方法變得越來越簡單？

Answer 1

Couch通過兩種方式簡化了這一過程。

首先，它具有系統內置並由系統強制執行的更高級別的復制模型。

其次，它的數據元素更粗糙，從而減少了樂觀鎖定和沖突解決方案模型的使用。

通常，RDBMS本身不支持樂觀鎖定。 建立在它們之上的許多框架都可以，但是DBMS本身卻不能。 有些人可能會在內部支持它，但如果這樣做，最終用戶就不會知道。

Couch固有地支持開放式鎖定/版本控制，並依賴其進行復制。

在RDBMS中，大多數較大順序的數據項被分解為它們的標准化關系組件。 一個簡單的訂單很可能由六個表組成，每個表都有自己的行結構。 但是表及其關系的組合才構成“訂單”。 考慮到訂單的這種細粒度表示，數據庫很難在更高級別上捕獲“更改”的概念。 “訂單已更改”是什么意思？ 數據庫看到的是節點和關系的集合，而不是諸如“ orders”之類的高階元對象。

應用程序可以定義更改，但不能輕易定義數據庫。

現在，如果您要復制整個數據庫，那么就不成問題了，但是如果要復制數據庫的一部分，則要復雜得多。

例如，在Couch中，訂單是整個文檔。 更改文檔，整個訂單“更改”，因此整個訂單被復制。 在RDBMS中，如果訂單項發生更改，那么很容易檢測到某行發生了更改，但這是否意味着“訂單”已更改？ 如果訂單所指的項目發生更改怎么辦？ 您會看到情況變得越來越復雜。

所有這些都可以在RDBMS之上構建，但是，應用程序是在進行變更管理並促進復制，而不是數據庫。

但是，無論CouchDB提供什么支持，它都只能走得那么遠，並且在引號中突出了警告：

如果在復制過程中兩個版本的文檔發生沖突，則勝出版本將另存為文檔歷史記錄中的最新版本。 CouchDB不會像您期望的那樣丟掉丟失的版本，而是將其保存為文檔歷史記錄中的先前版本，以便您可以在需要時訪問它。 這是自動且一致地發生的，因此兩個數據庫將做出完全相同的選擇。

由您決定以對您的應用程序有意義的方式來處理沖突 。 您可以將選定的文檔版本保留在原位，還原為較舊的版本，或者嘗試合並兩個版本並保存結果。

在復制過程中，Couch僅具有確定性的規則即可使兩個系統保持一致。 但是一致並不能使它們正確。 當Couch檢測到兩個有沖突的文檔時，它將確定地選擇一個，獲勝者將在失敗者身上腳。 但是就您的申請而言，失敗者可能是“正確的”，或者正確的文檔是兩個文檔的融合。

您必須編寫該邏輯來處理那些合並。 這是所有主-主復制方案的基本問題。 確定“誰獲勝”的技術。 當對數據的外觀有不同的意見時，“現在是什么”問題到達了相同的十字路口。

沒有系統可以為您解決這個問題。 系統所能做的就是選擇遵循的規則集，或者讓您配置以處理問題，因為問題幾乎總是取決於應用程序。

如果Couch支持並為您設計的更簡單的模型能夠正常工作，那太好了。 如果不是這樣，那么您就有點卡住了。 許多RDBMS都是主從復制的可靠支持，因為它是一個更簡單的模型，有了這種支持，它對最終用戶應用程序幾乎是透明的。