近年來，隨著分布式事務型數據庫的快速發展，對它們進行公平的性能評估和比較受到越來越多人的關注。雖然現有很多為數據庫建立的評測基準，但對分布式事務型數據庫的適用性仍缺乏全面的研究。因此，本文分析了現有的事務型評測基準對分布式事務型數據庫的適用性。

我們首先總結了分布式事務型數據庫的代表性架構，然后概述了分布式事務型數據庫的瓶頸點。之后，我們根據現有的事務型評測基準的特點和設計目的對其進行了分類，并且分析它們是否仍然適用于評測分布式事務型數據庫的瓶頸點。

我們首先調研了常用的事務型評測基準和分布式事務型數據庫，將他們的發布的時間線標注在圖 1 中。可見現有的事務型評測基準基本上大多在 2010 年前發布，但分布式事務型數據庫卻在 2010 年之后開始嶄露頭角。因此，這就引發一個問題，現有的事務型評測基準是否仍然適用于評測分布式事務型數據庫？

圖1：分布式數據庫和OLTP基準的歷史

分布式事務型數據庫的典型架構

為了回答這一問題，我們首先調研了常見的分布式事務型數據庫并將它們分為三個類：Share-Nothing 架構、Share-Nothing 分離架構和 Share-Storage 架構。

Share-Nothing 架構

Share-Nothing 架構采用預定義的規則，將數據劃分為多個（分布式）節點，每個節點涵蓋了查詢、事務和存儲引擎的功能模塊，并在執行分布式事務或分布式查詢時協調其他節點。它解決了兩個關鍵的可擴展性問題，即存儲可擴展性和分布式事務處理可擴展性。Share-Nothing 架構代表性的分布式事務型數據庫有 H-Store，Spanner，VoltDB，Citus 和 OceanBase。

Share-Nothing 分離架構

Share-Nothing 分離架構將查詢引擎和存儲引擎分開，查詢引擎是無狀態的并且可以在任何數量的節點中運行，存儲引擎提供具有多個副本的事務性存儲訪問。同時，他們不依賴于預定義的分布規則，而是將數據分為子塊，并使用一個集中的管理控制器來平衡所有存儲節點之間的存儲和負載。因此，一個計算節點可以足夠靈活地訪問任何存儲節點，并安排數據和負載量，根據優化的目標來調度數據和負載。然而，由于這種方式會產生許多網絡開銷，在復雜的分布式事務下，性能會比較差。這種架構下具有代表性的數據庫有TiDB，CockroachDB 和 FoundationDB。

Share-Storage 架構

Share-Storage 架構為了處理復雜的事務型負載，犧牲了寫入的靈活性和可擴展性。具體來講，它們把查詢引擎和事務管理在一個計算節點上，然后使用多個存儲節點來存儲數據和日志，所有其他計算節點都是只讀節點，通過分離讀和寫，減輕了寫節點的負擔。這種架構在存儲和讀取負載方面具有可擴展性，但單個寫節點可能成為數據庫的瓶頸。然而，由于所有的事務都是在單個節點上執行的，即使是復雜的事務，其性能也不會受到分布式事務的影響。這種架構下具有代表性的數據庫有 Aurora，PolarDB，Socrates 和 Taurus。

分布式事務處理中的瓶頸點

我們將這三種架構及其代表性的分布式事務型數據庫在存儲能力、事務處理能力、查詢能力和調度能力這四個方面所涉及到技術羅列在圖 2 中。此外，我們分析分布式事務型數據庫在四個方面潛在的瓶頸點，其中存儲瓶頸點影響事務處理，查詢處理和調度，因此將它分散在這三個方面進行描繪。

圖2：分布式數據庫在支持事務處理方面的比較

事務處理能力

分布式事務跟傳統的事務一樣,也必須滿足 ACID 約束, 但當數據被放置在不同的節點時,數據庫會面對以下兩個難題: 分布式并發控制和分布式提交。MVCC、OCC 和 2PL 被提出來以確保事務處理的正確性，表 2 中的 5 個分布式事務庫采用了 MVCC 和 2PL 的組合，TiDB 和 CockroachDB 中使用了 Percolator，它是 OCC 的變種。由于分布式事務的復雜性，我們還需要考慮到分布式事務的上下文和時間戳管理。分布式 2PL 需要考慮多個節點鎖的分配和釋放；在 MVCC 中，如何在所有參與者之間分配版本信息是至關重要的；而在 OCC 中，如何在所有參與者之間原子化地完成驗證也是很關鍵的。此外，全局性的時間戳管理是必不可少的，目前常見的有兩種解決方案：嚴格增加且唯一的時間戳，由全局時間戳分配；全球時間戳服務，如 Spanner 中使用的 TrueTime API 和 CockroachDB 中的混合邏輯時鐘。當一個分布式數據庫無法提供全局快照時，RC 是它能支持的最高隔離級別。為了保證事務執行的正確性，不同節點的提交管理是很重要的。兩階段提交（2PC）和三階段提交（3PC）幾乎是所有分布式數據庫的選擇。

查詢處理能力

分布式查詢處理在分布式集群中是必要的，一個查詢可能會訪問不同的節點，分布式查詢處理有兩個主要挑戰。一方面全局快照需要保證不同節點之間的數據一致性，如表 2 所示，除了 Citus，所有分布式數據庫都為用戶提供了全局快照；另一方面，查詢優化器應該適應分布式環境，它應該考慮到分布式的特點如節點的資源消耗和底層的數據放置。

分布式事務型數據庫中典型處理架構是將所有的客戶請求路由到 leader 副本，而 slave 副本負責在主節點故障時提供可用性。但隨著客戶請求的爆炸性增長，slave 副本也被用來處理讀請求來緩解 leader 副本的壓力，而 leader 副本負責寫入操作。為了獲得高性能，表 2 中的分布式事務型數據庫都采用了這種讀寫分離策略，盡管有幾個分布式事務型數據庫支持強一致性讀如 TiDB，但它們必須等待 slave 上達到最新的數據時才能響應，因此導致性能降低。

調度能力

分布式事務型數據庫中的調度包括自適應分割、彈性計算和存儲移動。自適應分割指當 region 過熱時，它采取自適應分片來分割這個 region，然后將其中一個 region 移動到其他節點上。彈性計算是用來調整物理資源，即當一個節點資源不足時，它將該節點的任務靈活地分配給其他空閑的節點。從表 2 來看，所有的分布式事務型數據庫都具有彈性計算能力，但是 Aurora 和 PolarDB 只會擴展只讀節點，因為它們只有一個寫節點。Share-Nothing 架構比 Share-Nothing 分離架構擴展的成本更高，因為它必須同時擴展兩種資源，即計算和存儲。存儲移動第一個目的是將分區均勻地分布在各節點上，從而減輕存儲壓力，避免單個節點上的磁盤爆炸。對于表 2 中的分布式事務型數據庫，它們都實現了這個功能，但是使用了不同的策略。例如，Citus 中提供了一個分片再平衡器。第二個目的是把客戶經常訪問的分片放在同一個節點上，這個功能在學術界被廣泛研究，但它的實施成本很高，所以表 2 中的分布式事務型數據庫都不支持這個功能。

評測基準對于分布式事務型數據庫的適用性

許多事務型評測基準被設計用來評估數據庫，我們把它們分為微觀評測基準、面向應用的評測基準和面向目的的評測基準。微觀評測基準是用于測試一個系統或程序中的單一組件或任務的性能，關心的是子組件的性能。面向應用的基準和面向目的基準都是宏觀基準，模擬一個應用程序的工作負載并用于評估系統的整體性能。面向目的的基準是面向應用的基準的一個特例，它更多地關注應用程序的特征，如秒殺應用中的高沖突和傾斜這一負載特征。

那么就有一個問題，這些基準是否仍然適用于評測分布式事務型數據庫？為了回答這個問題，我們對數據放置策略等做了規范。對于這些評測基準的數據放置規則，例如 Hash 或 Range，我們假定表是根據相關表的主鍵劃分數據的，即分區鍵，假定其他表和分區鍵的放置是綁定的。在此基礎上，如果一個事務寫（修改，刪除）不同的分區 ID 的主鍵，就定義該事務為分布式事務；分布式查詢訪問來自不同分區的數據；自適應拆分可以在幾種情況下被觸發，例如負載中的熱點；存儲移動可能發生在數據項被頻繁一起訪問的時候；彈性擴展需要數據和負載同時滿足可擴展性。

我們從數據 schema，負載等來探索這些評測基準評測分布式事務型數據庫關于事務處理，查詢處理和調度能力。如表 2 所示，“Yes”和“/” 意味著該評測基準是/否具備評測該項的能力，在分布式事務和分布式查詢兩項中注明了涵蓋這項的事務。

圖4 不同分布式事務比例下的 TPC-C 在 OceanBase 上的性能表現

微觀評測基準

雖然現有很多微觀基準，但它們是為了證明某些數據庫組件的設計或算法改進的而提出的。由于它們并不是為測試整個數據庫而設計的，所以我們在這里只提兩個常用的微觀評測基準：一個是用于早期數據庫的 AS3AP，另一個是用于 NoSQL 數據庫的 YCSB+T。AS3AP 由于沒有把 CRUD 操作包裝成事務，連最基本的事務的原子性都無法評測，因此，這邊就不細說了。YCSB+T 是 YCSB 的擴展，用來評估 NoSQL 數據庫的事務能力。YCSB+T 只含有 1 張表，6 類事務（insert, random-scan, range-scan, update, delete 和 read-modify-write），其中 random-scan 和 range-scan 事務很大概率涉及分布式查詢，read-modify-write 事務每次讀寫兩行，可能引發分布式事務。YCSB+T 可以控制參數分布訪問（zipfian 分布），因此會引發熱點。

面向應用的評測基準

DebitCredit 模擬了一個虛擬的銀行交易系統，之后 TPC Council 在它基礎上增添了一些新的特征和規范，形成了 TPC-A，但這兩款由于過于簡單，目前已經棄用了，便不再贅述了。TATP 評測基準模擬了一個電信業務，有 4 張表，其中 3 張表依賴于 Subscriber 表，可根據該表進行分區。TATP 有 7 個事務（Get-Subscriber-Data, Get-New-Destination, Get-AccessData, Update-Subscriber-Data, Update-Location, InsertCall-Forwarding 和Delete-Call-Forwarding），其中的寫事務都是單點操作，故而沒有分布式事務。TATP的評價指標有兩個：MQTH（平均吞吐）和每類事務的響應時間。TPC-C 模擬了一個以倉庫為中心的訂單處理應用，這是最流行的基準之一。TPC-C 包括 9 張表，除了 Item 表，其他的表都依賴于 Warehouse 表按照特定的規則進行擴展，如每個倉庫為 10 個地區提供服務。TPC-C 中有 5 類事務（NewOrder, Payment, Order-Status, Delivery 和Stock-Level），New-Order 是一個讀寫事務，當 item 由遠程倉庫供應時，會產生 1% 的分布式事務，但是沒有考慮分布式事務的跨節點數。StockLevel 是一個只讀事務，但是都當存在良好分區時，該事務不會存在分布式查詢。TPC-C 中考慮了 ACID 的功能測試，主要的評價指標有 tpmC，price/tpmC，watts/KtpmC。TPC-E 模擬一家股票公司的業務，包括 33 張表，12 類事務，盡管有些事務可能有引發分布式事務和分布式查詢，但卻無法控制它們跨節點的數目。

面向目的的評測基準

SmallBank 用于評價快照隔離下不同可串行協議，模擬了一個銀行系統。它包括 3 張表(Account, Saving 和 Checking)，都依賴于 Account 表進行擴展，有 5 類事務，可能存在一定的分布式事務，但不可控。PeakBench 模擬了高沖突，動態變化和極度傾斜的負載特征，設計了一個精細控制沖突的生成器。它含有 8 張表，4 類讀事務和 6 類寫事務。由于它沒有明顯的分區鍵可以保證讀事務在一個節點上，因此可能會引發分布式查詢，故而，也會引發分布式事務。此外，PeakBench 能很好地模擬熱點和沖突，因此能評測數據庫在調度上的處理能力。

實驗

在這節中，我們探索不同分布式事務比例和沖突強度下的性能表現，這對分布式事務型數據庫的設計方面起著舉足輕重的作用。我們將 OceanBase（v3.1.1）部署在 10 節點的集群上，其中有 9 個 OBServer 和一個 OBProxy，將某友商國產數據庫也部署在 10 節點的集群上。

我們通過控制分布式事務比例和沖突強度擴展了 TPC-C 中的 NewOrder 事務，在原始的 TPC-C 中，NewOrder 更新 Stock 表的 5-15 個 item，涉及到 1% 的分布式事務。我們將該值進行參數化來評測不同分布式事務比例下的數據庫性能。此外，以前的倉庫 ID 的訪問是均勻分布的，我們也擴展了倉庫 ID 的生成來生成不同的沖突。

TPC-C 的不同分布式事務比例

在圖 4-5，我們通過調整不同分布式事務比例，展示了 NewOrder 事務在 OceanBase 和某友商數據庫上的吞吐。首先，OceanBase 的吞吐遠遠高于某友商數據庫的吞吐，盡管當分布式事務比例增長時，吞吐呈現下降趨勢，但吞吐始終高于某友商數據庫。其次，無論是 OceanBase 還是某友商數據庫，當分布式事務比例增長時，吞吐都呈現下降的趨勢。這說明不同的分布式事務比例對分布式事務型數據庫的性能影響非常大，在評測分布式事務型數據庫時需要把這一因素考慮在內。

圖4 不同分布式事務比例下的 TPC-C 在 OceanBase 上的性能表現

圖5 不同分布式事務比例下的 TPC-C 在友商數據庫品牌上的性能表現

TPC-C 的不同數據訪問分布

在圖 6-7中，我們通過控制倉庫 ID 的數據訪問分布展示了 TPC-C 中的 NewOrder 事務在 OceanBase 和某友商數據庫上的吞吐。訪問分布從均勻分布到 Zipfian 分布中 s 為 0.5，0.99 和1.5。從圖中，我們可以看到沖突對OceanBase和某友商數據庫的影響都很大，當沖突強度越大，吞入下降的越劇烈。從數據訪問分布從均勻分布到 Zipfian0.99 時，OceanBase 下降了 38%，而某友商數據庫下降了 81%。這是因為某友商數據庫是 Share-Nothing 分離架構，事務鏈路更長，沖突處理能力更差。

圖6 不同沖突強度下的 TPC-C 在 OceanBase 上的性能表現

圖7 不同沖突強度下的 TPC-C 在某友商數據庫上的性能表現

結語

在以上所提及的事務型評測基準上，如果我們想要評測數據庫在沖突下的處理能力，可以使用 YCSB+T，TATP，SmallBank 和 PeakBench。雖然上面提到的基準都涉及到分布式事務除了 TATP，但是它們都不能控制分布式事務的比例和跨節點的數量，這對分布式事務型數據庫的性能有很大的影響。若是想評測分布式事務型數據庫中對分布式查詢的處理能力，用戶可以利用 YCSB+T，TPC-E 和 PeakBench；至于彈性計算能力，可以使用 PeakBench 進行評估。最后，沒有一款評測基準考慮到了存儲移動，而這對分布式數據庫中調度能力的評測是至關重要的。

總之，一方面，現有的評測基準可以被改變用于評估上述瓶頸點；另一方面，考慮到分布式事務型數據庫在未來的發展和成熟度，急需一款全新的能夠評測所有分布式事務型數據庫瓶頸點的評測基準。

責任編輯：Rex_08