第三代分散式資料庫（3）——一致性八仙圖

來源：那海藍藍知數行雲

十四屆中國資料庫技術大會（DTCC2023）很榮幸邀請到了李海翔老師分享他的《第三代分散式資料庫》系列。此文是三篇文章的第三篇，在這篇文章中，李海翔老師帶你學習瞭解如何閱讀一致性八仙圖，幫助你更好地評測各種資料庫

小故事：這幅圖為什麼叫做“一致性八仙圖”？

一致性八仙圖

所謂八仙過海各顯神通。這是該圖特點之一。

長期以來，資料庫界期待能有一套理論或工具，對資料庫的一致性進行測試和驗證，以掌握目標資料庫對於一致性的實現程度。這個需求，非常迫切。

任何一個資料庫系統，都缺乏系統性的一致性校驗的方法和工具，致使任何資料庫系統都沒有依據去講自己的一致性滿足程度是什麼樣子的。

Oracle雖能設定可序列化隔離級別，可在時間的長河中未經得起考驗而被後人發現其可序列化只是相當於SI的隔離能力，成為一個大家未笑（無奈而不能笑）、未重視（忍受而漸漸漠視麻木，沒有更好而只能忍受）的笑話。

當自家出具的東西，自己不可解釋、自己不能正確實現的時候，這個背後的因素，究竟是什麼？

著名的Jespen工具問世，似乎拯救了一大批資料庫系統，很多資料庫系統使用其做一致性測試，使得缺乏一致性驗證方法和工具的情況有所改善。

但亦如下所述，Jespen也有諸多不足（參考“第三代分散式資料庫(1)——踢球時代”之表1），不能夠很好地評測資料庫的一致性。

“一致性八仙圖”，卻能夠完美地評測各種資料庫，使得各種資料庫的一致效能被清晰地展現在大眾眼前，資料庫八仙在前，“盡顯”一致性神通（對比著看，會更有幫助哦）。

該圖給出瞭如下資訊：

1. 1.  評測任何資料庫系統（SQL介面或API介面的）的一致性實現能力。

圖中給出11個資料庫16個版本的一致性的評測結果，包括主流資料庫如Oracle、PostgreSQL、MySQL等。實踐中，測試了更多的資料庫系統，如國產Pg系列的、MySQL系列的等，評測結果同其母版，故不羅列。

1. 2.  評測每一個隔離級別下資料一致性的正確性實現能力和細節。被測試的每個資料庫的所有隔離級別的實現細節和差異一覽無餘。

2. 3.  評測系統，適用於事務型的單機資料庫系統、分散式資料庫系統。只要是提供事務處理能力的，都可被測試，連Greenplum、MongoDB這些也可被測試哈。

3. 4.  Cell單元格含義：

4. a)  黃色背景的A：出現資料不一致性

5. b)  綠色背景P：無資料不一致性（不一致性現象被避免）

6. c)  藍色背景R：無資料不一致性（不一致性現象被按一定規則回滾）

7. d)  紅色背景D：無資料不一致性（不一致性現象被死鎖檢測方法回滾）

8. e)  RU，讀未提交；RC，讀已提交；RR，可重複讀；SI，快照隔離；SER，可序列化

第一，從隔離級別級別的角度看：

1. 1.  首先，RU隔離級別下，MySQL和SQL Server“黃色背景A”最多，表明RC隔離級別下，這兩個資料庫的資料正確性存在較多問題，但這點沒什麼影響，因為應用開發通常都設定為RC隔離級別。部分資料庫如PostgreSQL雖然提供了RU級別的設定，但其實際效果等同於RC，“黃色背景A”不是很多，基本上符合ANSI-SQL的定義（但ANSI-SQL只定義了四種資料異常）。

2. 2.  其次，RC隔離級別中，SQL Server的“黃色背景A”最多，表明RC隔離級別下，這兩個資料庫的資料正確性存在較多問題；而Oracle、PostgreSQL、MySQL、TiDB、OceanBase在RC下相近，但都有較多的資料異常不能消除，這些不能被消除的資料異常，遠多於ANSI-SQL標準所對應的RC級別下只能消除的Dirty Write、Dirty Read這兩個。

3. 3.  再次，在RR隔離級別級別中，PostgreSQL的“黃色背景A”少於MySQL、TiDB、OceanBase等，說明PostgreSQL在該級別下一致性做得最好，其次較優的是MySQL。而SQL Server的RR和SER卻是有著相同的結果，消除了所有的資料異常。

4. 4.  第四，對於提供了SI隔離級別的SQL Server和MongoDB（圖中用SI表示），和對於提供了樂觀鎖實現類似SI隔離級別的TiDB（圖中用Opt表示採用樂觀鎖）相比，他們有著相同的一致效能力。

5. 5.  第五，不能完全保證資料一致的，即不提供SER級別的的資料庫如MongoDB、OceanBase（MySQL相容版本）、TiDB等資料庫的資料一致效能力止步於此，可以看到在RR級別下還有較多的“黃色背景A”。

6. 6.  第六，名義上提供SER的如Oracle、Greenplum、OceanBase（Oracle相容版本），SER下存在若干種資料不一致的問題。

7. 7.  第七，在SER即可序列化隔離級別下（除了不支援SER的外），SQL Server、CockroachDB、PostgreSQL、MySQL、TDSQL、MyRocks能完全確保資料的一致性；但是從一致性八仙圖中我們可以觀察到，這些資料庫為了確保SER，採用的方法是不同的，有的是“藍色背景R”如PostgreSQL採用的SSI演算法回滾某些資料異常（Write Skew等），有的是“紅色背景D”如SQL Server 和MySQL採用死鎖檢測的方式回滾Write Skew等。——這是一個有趣的現象，背後有著深刻的“洞察”，後續單獨成文。

8. 8. 事實上，ANSI-SQL標準定義的隔離級別，是一個雞肋。

第二，從同一個資料庫的角度看：

1. 1.  MongoDB和CockroachDB 提供單一的隔離級別，尤其是CockroachDB作為一個分散式資料庫，只提供可序列化隔離級別（其早期版本還提供SI隔離級別，但在後續的版本中被去掉了）。這是以一個非常正確的選擇，其技術路線的確定者必定深刻理解了分散式資料庫和分散式事務的實質，這點值得其他任何資料庫學習，分散式資料庫沒有必要提供弱隔離級別。一個分散式資料庫如果想在事務處理領域站穩腳跟，選擇學習CockroachDB的設計方式，是最佳選擇。——這也是一個有趣的現象，背後的“洞察”亦非常深刻，後續單獨成文討論。

2. 2.  PostgreSQL基於SSI演算法實現了可序列化隔離級別，消除了一致性八仙圖中的Write Skew、Write Skew Committed和Step IAT三類資料異常（請注意，SSI消除的不僅僅是Write Skew）。但是，SSI演算法對於PostgreSQL而言，卻是多餘的；PostgreSQL為實現可序列化化花費了巨大的力氣卻做了多餘的無用功，非常可惜，這是資料庫引擎研發人員的認知錯誤造成的，有效地展現了傳統的事務知識認知的侷限性。——這也是一個有趣的現象，背後的“洞察”亦非常深刻，後續單獨成文討論。

3. 3.  Greenplum的名義SER與PostgreSQL的RR級別能力相當，但是Greenplum作為一個分散式資料庫，其處理分散式一致性時的方法與單機的PostgreSQL是有所不同的。Greenplum處理分散式一致性時採用的方法，相當笨拙，也相當低效，有著巨大的改進空間。——這也是一個有趣的話題，背後的“原理”非經典教科書可見，後續單獨成文討論。

4. 4.  OceanBase（Oracle相容版本）只是名義上提供了SER，類似Greenplum，其SER與其RR級別能力相當。OB的早期版本透過超時機制解決分散式死鎖問題，2023年在ICDE發表了分散式死鎖解決演算法，但該演算法也侷限在傳統的死鎖解決演算法中，因此有著傳統的死鎖解決演算法的低效問題存在。這點其實和Greenplum很相似。——如何解決分散式資料庫的死鎖問題，是一個有趣且重要的核心的話題，背後的“原理”亦非經典教科書可見，後續單獨成文討論。

5. 5.  相比如上的幾個資料庫產品，TiDB的一致效能力，整體上較弱。其Opt方式的一致效能力，優於其RR級別。但該資料庫產品也存在著分散式死鎖解決方法低效的問題。

6. 6. SQL Server 和MySQL的一致效能力都較強，其解決資料異常的方式也相似。對比他們對於SER和RR的結果，我們會發現，其對於同一個資料異常如“Read Skew”、“Lost Update”和“Write-read Skew”等，兩種隔離級別對同一個異常的的處理方式卻不同，這其實違背了“隔離級別逐層遞進實現”的原則，表明其事務處理技術的實現，處於混亂狀態，沒有能統一規劃而被實現。而且，它們確保一致性的細節能力，卻弱於PostgreSQL。——MySQL在一致性實現能力方面弱的原因，涉及細節眾多，期待後續單獨成文討論。一致性八仙圖背後的理論能夠洞察資料庫的併發實現細節，並準確衡量併發程式碼層的優劣。

7. 7.  國產資料庫中，TDSQL在一致性方面的能力最強，且作為一個分散式產品，其一致效能力之強是較為少見的。TDSQL在金融行業的應用範圍是最廣（國內Top10銀行TDSQL已佔6成）的，其一致性等核心技術對商業起到了重要的支撐作用。但可惜的是，其實現演算法同樣存在效率差的問題。

8. 8.  基於PostgreSQL的一些其他品牌產品其一致效能力基本等同PostgreSQL，基於MySQL的一些其他品牌產品其一致效能力基本等同MySQL。

第三，從使用者的角度看：

1. 1.  金融電信證券等行業，對資料一致性的要求最高，期待資料庫沒有任何資料異常，該要求是對事務型資料庫系統選型的核心標準之一。所以，一個資料庫的一致效能力，決定了其資料的正確效能力，也影響著其是否能進入金融等行業的核心業務。使用者期望有一個客觀的一致性評測標準，能精準的驗證目標資料庫的一致效能力。這個期盼，自事務處理技術誕生之日起至今，已經過了花甲之年。漫漫歷史長河中短暫的人生，一粒塵沙，又有幾個花甲之年可等待？

2. 2.  各個資料庫廠商，同樣期盼，在資料庫版本發行前，能很好地測試驗證其發行版本的一致效能力，但可惜，一直沒有好的方法。於是，資料庫廠商只能依靠長年累月積累下的各種測試用例和bug集作為迴歸測試用例集，來驗證“新版本不再有已經被發現過的一致性錯誤”，對於未來是否會被發現新的一致性bug，心裡沒底。

3. 3.  資料庫研究者，也一直期望，能有一套方法論，能夠在理論層面，全面說明一致性的驗證方法。但自從有了“可序列化理論”，自從“可序列化理論”被奉為為黃金聖律後，一部分早期的研究者便認為一致性的實現已經有了理論保證則不必再費心血研究什麼是不一致等事情了，於是……。但是，研究者們卻未深入思考：一致性又何從驗證呢？可序列化理論為什麼不能驗證資料庫的一致性呢？“確保一致性的方法”和“驗證一致性的方法”之間，會有什麼關係嗎？——這是一個非常重要也很有趣的話題，值得深入思考，後續單獨成文討論。一個理論如果完備，是不是應該既能保證正確性，又能驗證正確性？

4. 4.  有了一致性八仙圖，從此資料庫的一致效能力，有了驗證了評測的方法和工具，各個資料庫的一致效能力，相信能有大的改進與突破。

業界，有一個普遍被認可的觀點：一個新的資料庫產品，至少需要10+年才能成熟可用？

那麼：

Q1：為什麼一個新的資料庫產品，其研發、打磨、推廣週期需要10+年？

Q2：如何能加速這個過程？

A：這兩個問題，可從多個角度思考。我們單獨從資料正確性的角度來分析，因為這是資料庫最基本的核心問題：

1. 1.  事務型資料庫的核心目標有2個：在併發操作下，一是保證資料正確性、二是儘可能高效能。

2. 2.  為確保核心目標，需要一套理論來論證目標的可行性，這就是傳統的可序列化理論，可是該理論有2點缺失：

3. 2.1依據可序列化和衝突可序列化，理論層面尚不能保證資料100%正確。這意味著理論層面有缺失。--重要問題，單獨成文討論。或許很多人會說：你竟瘋了不成，敢如此大膽、對金科玉律胡言亂語！嚓~嚓~嚓

4. 2.2 完備的理論，至少具備2點：正確性和驗證方法。一個完備的理論應該既能夠提供正確的解釋和預測，又能夠給出方法驗證其正確性。這兩個方面的考量是評估一個理論是否完備的重要標準。可序列化理論，缺乏對依據其研發的資料庫產品的一致性驗證方法，這是該理論的缺失之處，也是不完備之一（還有不完備之處）。

5. 2.3 因此，在理論缺失的情況下，資料庫產品的正確性不能被很好地驗證，該產品何以有理由被推向市場？

6. 3.  但是，Oracle等廠商就是把不成熟的產品推向了市場，其採取了三種方式：

7. 3.1 定義隔離級別：1992年ANSI-SQL標準把該問題“標準化”，似乎該問題在隔離級別的背景下成為了“天經地義”之事！標準如此，何人可質疑之？芸芸之口，堵之！眾生之腦，塞之！--隔離級別是可以靈活定義的，不應被限制在ANSI-SQL標準內（參考文獻 [1] ），可不同於ANSI-SQL標準

8. 3.2 把球踢給使用者，發明了“SELECT…FOR UPDATE”的方式，讓使用者自己為資料的一致性負責。（文後附了一個小故事，可以從時間脈絡，看出Oracle在此方面的“貢獻”）

9. 3.3 既然把球踢給了使用者，那麼意味著有了海量的測試場景可驗證資料的正確性，一旦發現問題，作為bug修復即可。這也是在理論層面沒有辦法的背景下，實踐中可選的一種方式。據說，Jim Gray提出的Write Skew和Read Skew等就是在實踐中被使用者發現資料出現了不一致而經過大量分析論證才被提出的。因此，把使用者作為小白鼠，使得各個資料庫產品以10+的週期長期積累bug（使得廠商的迴歸測試用例逐漸完善），一致性問題才逐步趨於穩定，實踐中被報告的資料異常才越來越少，這使得資料庫產品的可用性增強。但是，也使得一個資料庫產品成熟週期變得無比得長，10+年、20+年…。理論和實踐都不行，使用者不得不忍受之，產品不得不依靠時間來打磨。

10. 3.4 但是，從20世紀90年代到現在的30+年中，新的資料異常還是被不斷報告出來，意味著資料的正確性依然有多種風險（應用日益豐富，使得資料正確性的風險暴露的可能性增加），意味著資料庫正確性無論是在理論還是在產品實踐方面，不得不做徹底地改進了。具體情況可參考文獻[1]。

Q3：那麼，資料庫一致性的保證，是否能夠加速，如把一個產品成熟週期，壓縮到2年甚至1個年？如果能，如何加速？

A:我們大家能感受到一個趨勢，最近的若干年內，各種新資料庫產品越來越多，對不？

  新應用大幅增多對資料庫提出豐富的新需求，老資料庫產品演進包袱太重而進化困難，這些新情況使得新的資料庫越來越多百花齊放。

可是儘管新產品增多，但是它們依然面臨難以進入核心應用的窘境。從技術層面看，這是為何？

而只要提供“艱難繁複”的事務處理技術，新的資料庫產品，都將面臨著著如何快速成熟穩定、如何加速推向市場的問題。--這是時代的需求！

一個資料庫產品，無論新舊，如果不能從理論和實踐兩個方面為使用者徹底解決最基礎的一致性問題，即使該產品被用到了若干環境中，但終究難以讓使用者100%心安。

   順應時代之需，一致性八仙圖和其背後的技術問世——該技術從理論和實踐兩個層面加以著手。

首先，資料異常現象可被統一建模，包括所有已知和未知的資料異常，從理論層面首先解決資料正確性問題。

其次，一致性八仙圖，可全面驗證資料庫資料的正確性。這使得理論層面具備了最基本的2個特徵（一個完備的理論應該既能夠提供正確的解釋和預測，又能夠給出方法驗證其正確性）。

第三，一致性八仙圖背後的一致性評測技術，可加速資料庫資料正確性的驗證（分鐘級），即加速資料庫產品的成熟穩定，大幅縮短一個產品推出的週期。

未來，經歷過一致性八仙圖的評測認證的資料庫產品，將會在公眾中樹立起良好的資料正確性形象，獲得大眾的信任。在實踐中加速產品走向核心應用也將指日可待。

在資料庫界，多年以來，無論傳統資料庫技術大廠還是開源資料庫還是新研發的NewSQL資料庫，都不能體系化地建立一致性迴歸驗證系統。【這個聽起來，似乎是一個非常令人匪夷所思的事情，居然資料庫廠商們也做不了這樣的工作，他們只能零星地構造個別測試用例，放到迴歸用例集中驗證一致性；而完整地測試、評價每一個版本的資料庫系統的一致性，卻沒有任何好的辦法】

之後，業界誕生了一個很知名的系統，就是大名鼎鼎的Jepsen/Elle[2]。該系統是迄今為止最好的資料庫一致性驗證工具。這裡，我們不對Jepsen/Elle的特性展開介紹，而是討論一下Jepsen/Elle的不足。

Jepsen/Elle之所以有價值，是因為其原理基於衝突圖，其採用了Adya的論文（參考文獻《Generalized isolation level definitions》）。Jepsen/Elle在構建一致性測試用例的時候，是基於衝突圖進行的。Adya在如上參考文獻中把髒讀和中間讀異常作為特例未納入其定義的衝突可序列化體系，故Jepsen/Elle對髒讀和中間讀異常的測試也是作為特例加以構造。

在衝突圖中，一個有向環圖中，其頂點和邊的個數，是可多可少的，即環的樣子是無窮多個，這導致Jepsen/Elle在理論上需要構造無窮多個環，才有希望能把大部分環測試到。一旦使用Jepsen/Elle測試，如果想測試到所有的環，則只能用無窮多的時間來執行該工具。顯然，在資源有限和時間有限的情況下，我們是不會有機會無休止地執行該工具進行測試的。因此對於一個目標資料庫進行測試的時候，每一次測試都是“不完備”的，這是Jepsen/Elle最致命的問題。測試不完備，意味著測試只能靠“運氣”，正確性無法完全得到保證。

另外，什麼情況下能夠構成“衝突環圖”？用幾個或幾十個乃至幾十萬個併發事務，就一定能精確的構造出環嗎？如果不知道環的組成規律，何以每次測試都能構造出足夠多的環來驗證正確性、並且提高其驗證、測試的效率呢？衝突圖的理論，不能在這個層面對Jepsen/Elle提供理論支援，因此Jepsen/Elle構造測試用例有個特點：隨機。隨機的構造測試用例，使得其驗證一致性的目的性和效率大幅度降低，同時使得每次測試，都不能容易“復現”之前發現的問題（不能復現問題是構造測試用例的禁忌之一）。

因此採用該工具進行驗證，其實既不可信也不可用（沒有更好工具的時候，只能退而求其次了）。

有些有Jepsen/Elle實踐經驗的同學，未必同意該結論，因為在實際的使用中，有時候確實能憑藉該工具發現一些問題（即不一致的bug）。可是，分析其原理我們可知，代表了業界最高水平的Jepsen/Elle其能力也僅限於此了（不完備和隨機是兩大弊端）。如採用Jepsen/Elle能發現一個系統存在較多問題，其實應該反觀該系統的設計和實現質量了（這也說明前述的資料庫系統需要一個完備的一致性迴歸驗證系統的重要性，也說明了目前一致性理論的侷限性；另外這裡討論的是Jepsen/Elle事務的一致性的測試能力，不是作為混沌測試的故障注入的測試能力），而不是奉Jepsen/Elle為神了。

如下內容，由ChatGPT提供，請讀而笑之！

Q（問ChatGPT）：在各個資料庫產品中，“SELECT…FOR UPDATE”語法是在哪個產品中最先出現的？給出各個資料庫的名稱、對應的資料庫版本號、出現該SQL語法的時間。

A（ChatGPT答）：

"SELECT...FOR UPDATE"語法是用於在資料庫中鎖定選定的行，以防止其他事務對其進行修改。這個語法最早出現在Oracle資料庫中。

以下是一些常見資料庫產品中"SELECT...FOR UPDATE"語法的出現時間：

1. Oracle資料庫：

- 版本：Oracle 6

- 出現時間：1988年

2. IBM DB2資料庫：

- 版本：DB2 2.3

- 出現時間：1989年

3. PostgreSQL資料庫：

- 版本：PostgreSQL 6.3

- 出現時間：1998年

4. MySQL資料庫：

- 版本：MySQL 3.23

- 出現時間：2001年

5. Microsoft SQL Server資料庫：

- 版本：SQL Server 2005

- 出現時間：2005年

需要注意的是，不同資料庫產品對於"SELECT...FOR UPDATE"語法的支援和語法細節可能會有所不同。因此，在使用時請參考相應資料庫產品的文件和版本說明。

那海藍藍備註：

1. 1.  可序列化（Serializability）的基本概念，出現在20世紀60年代。

2. 2.  衝突可序列化，出現在20世紀70年代。

3. 3.  隨後的幾十年中，可序列化理論還在繼續發展而未定型的過程中。其中資料一致性的概念一直處於模糊混亂狀態中，理論缺位。

4. 4.  Oracle，資料庫的龍頭老大，在1988年即帶頭實施了“把球踢給使用者的策略”，隨後在1989年的DB2、1998年PostgreSQL的無奈地跟進。

5. 5.  Adya的論文《Generalized isolation level definitions》2000年發表，為Jespen提供了理論依據。可惜如3所述，理論缺位為測試工具帶來硬傷。

6. 6.  之後，在2001年的MySQL、2005年的SQL Server也無奈地跟進。

之前，我們談到了“100%保證資料正確性”，那麼， 什麼是資料正確性？下一篇，我們將來談談這個。這個內容，有些理論化，但是理解本系列文章的基礎，也是錘鍊資料庫內功的好機會。

[1] 李海翔，李曉燕，劉暢，杜小勇，盧衛，潘安群.資料庫管理系統中資料異常體系化定義與分類.軟體學報，2022，33(3)：0

[2] 《Elle: Inferring Isolation Anomalies from Experimental Observations》，

1.  第三代分散式資料庫（1）——踢球時代

2.  第三代分散式資料庫（2）——創新之源