從CouchDB guide：CouchDB與關係數據庫的分佈式一致性？
單個數據庫節點內保持一致性相對 容易大多數數據庫。當您嘗試在多個數據庫服務器之間保持一致性時，真正的問題開始浮出水面。如果一個 客戶端在服務器A上執行寫操作，我們如何確保 這與服務器B或C或D一致？對於關係型數據庫 而言，這是一本非常複雜的問題，整本書都專注於其解決方案 。您可以使用多主，主/從，分區，分片，直寫緩存以及各種其他複雜的技術。
爲什麼很難在關係模型中維護數據庫服務器之間的一致性？爲什麼CouchDB方法更簡單更簡單？
沙發通過兩種方式簡化它。
首先，它有一個更高級別的複製模型，由系統內置和實施。其次，它的數據元素較粗糙，因此樂觀鎖定和衝突解決方案模型不太適合。
作爲一般規則，RDBMS本身不支持樂觀鎖定。建立在它們之上的許多框架都可以，但不是DBMS本身。有些人可能會在內部支持它，但如果他們這樣做，它不會暴露給最終用戶。
Couch本質上支持樂觀鎖定/版本控制，並依賴於它的複製。
在RDBMS中，大多數大數據項被分解到它們的規範化的關係組件。一個簡單的順序可能由六個表格組成，每個表格都有自己的行結構。但是表格及其關係的組合是構成「訂單」的組成部分。考慮到訂單的這種更細粒度的表示，數據庫很難在更高的層次上捕捉到「變化」的概念。 「訂單改變」是什麼意思？數據庫可以看到節點和關係的集合，而不是像「訂單」這樣的高階元對象。
應用程序可以定義更改，但不像數據庫那樣容易。
現在，如果您要複製整個數據庫，那麼這不是一個問題，但是如果您要複製數據庫的一部分，則它會複雜得多。
在沙發中，例如，訂單是整個文檔。更改文檔，並且整個訂單「更改」，從而整個訂單被複制。在RDBMS中，如果一個訂單項發生了變化，那麼很容易檢測到一行更改，但這是否意味着「訂單」更改？如果訂單所指的項目發生了變化，會改變訂單嗎？你可以看到這變得更復雜。
所有這些都可以建立在RDBMS的基礎之上，但是它是應用程序在執行更改管理和促進複製，而不是數據庫。
但是，不管是什麼支持CouchDB的報價，也只是到目前爲止，並警告在報價強調：
在複製過程中的文件發生衝突的兩個版本， 中獎版本保存爲文檔的 歷史記錄中的最新版本。 CouchDB並沒有將丟失的版本扔掉，而是將其保存爲 歷史記錄中的以前版本，以便您可以在需要時訪問它。這種情況自動且始終如一地發生 ，所以兩個數據庫都會使 完全相同。
這是由你來處理衝突以適合您的 應用程序的方式。您可以保留選定的文檔版本， 恢復爲舊版本，或嘗試合併這兩個版本並保存結果 。
在複製過程中，沙發只是有確定性的規則來使兩個系統保持一致。但一致並不能使它們正確。當Couch檢測到兩個衝突文件時，它確定性地選擇一個文件，並且勝者踩踏輸家。但就您的申請而言，失敗者可能是「正確的」，或者正確的文件是兩個文件的融合。
你必須編寫那些合併的邏輯句柄。這是所有主 - 主複製方案的一個基本問題。確定「誰贏」的技術。對於數據應該看起來像什麼的不同意見，「現在怎麼樣」的問題到達相同的十字路口。
沒有系統可以爲您處理。系統所能做的就是選擇一些遵循的規則，或者讓你配置來處理問題，因爲問題幾乎總是取決於應用程序。
如果Couch支持併爲您設計的簡單模型起作用，那就太棒了。如果沒有，那麼你有點卡住了。許多RDBMS對主從複製提供了堅實的支持，因爲它是一種更簡單的模型，並且通過這種支持，它對最終用戶應用程序非常透明。