三款典型國産分布式資料庫的對比評測

對于所有的應用系統，資料都是承載業務邏輯的核心資産，而存儲資料的資料庫系統則是最核心的系統之一。随着國産化程序的不斷推進，應用系統基于國産化資料庫進行建構越來越重要，也越來越成為資料庫選型中的主流。

近幾年國産資料庫市場風生水起，湧現了多款優秀的國産資料庫産品，各大廠商也在重金投入資料庫研發中。本文選取了三款典型的國産分布式資料庫進行全方位對比壓測，分析國産分布式資料庫的發展現狀，供各位讀者參考。

測試環境及資料庫架構

PolarDB-X

環境	參數
PolarDB-X版本	polarx-kernel_5.4.11-16270254_xcluster-20210719
節點規格	16核64GB
節點個數	5個 (CN 16核64GB + DN 16核64G)

資料庫架構：

Oceanbase

TiDB

壓測名額分析

Sysbench壓測情況：

1. 壓測參數配置

	值
--rand-type	uniform
--table-size	1000,0000
--table-num	16
--db-ps-mode	disable
--auto-inc	false
--range-size	5
--skip-trx	off

測試表結構：
CREATE TABLE `sbtest1` (
  `id` int(11) NOT NULL,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT'',
  PRIMARY KEY (`id`),
  KEY `k_1` (`k`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4      

2. 場景說明

• 總計16 張表，每張表 1000 萬行資料，資料分布uniform。
• tidb場景：基于range水準拆分模式的分布式(tidb預設會把所有表的資料按照range做自動均衡，某一張測試表的資料會均勻分布到多個機器上)。
• OB模式：單表即官網預設推薦模式，sysbench腳本不作修改時自動建立的表，這裡簡稱非分區表；基于hash水準拆分模式的分布式，簡稱分區表。
• PolarDB-X場景：單表，sysbench腳本不作修改時自動建立的表，這裡簡稱非分區表；基于hash水準拆分模式的分布式，簡稱分區表，索引采用本地索引；基于hash水準拆分模式的分布式，簡稱分區表，索引采用GSI全局索引。

3. 測試結果資料

TPCC (5000倉)

TPCC是專門針對聯機交易處理系統（OLTP系統）的測試規範，一般情況下我們也把這類系統稱為線上業務處理系統。1992年7月釋出，幾乎所有在OLTP市場提供軟硬平台的國外主流廠商都釋出了相應的TPC-C測試結果，随着計算機技術的不斷發展，這些測試結果也在不斷重新整理。

TPCC通常用于模拟測試複雜的線上事務處理系統，在大壓力情況測試資料庫的事務處理能力，以下壓測彙總了三種分布式資料庫的最大tpmC名額：

// 資料導入  5000倉
tiup bench tpcc --warehouses 5000 -D tpcc -H xxx -P xxx -T threads_num prepare

// 運作
tiup bench tpcc run -U root --db tpcc2 --host xxx  --port xxx --time xxx --warehouses 5000 --threads
      

 TPCH (100G)

TPCH（商業智能計算測試）是美國交易處理效能委員會(TPC,TransactionProcessing Performance Council) 組織制定的用來模拟決策支援類應用的一個測試集。目前，在學術界和工業界普遍采用它來評價決策支援技術方面應用的性能。

這種商業測試可以全方位評測系統的整體商業計算綜合能力，對廠商的要求更高，同時也具有普遍的商業實用意義，目前在銀行信貸分析和信用卡分析、電信營運分析、稅收分析、煙草行業決策分析中都有廣泛的應用,以下以TPCH-100G來對比分析三種分布式資料庫的分析能力：

// 導入資料 100G
tiup bench tpch prepare --host xxx --port xxx --db tpch_100 --sf 100  --analyze --threads xxx

// run
tiup bench tpch run --host xxx --port xxx --db tpch_100 --sf 100 --check=true
      

DDL 能力

1. 場景說明

測試資料為tpch100g 生成的lineitem表，單表6億行資料

2. 并行DDL測試

并行DDL用于測試在達标的DDL過沖中，在前一個DDL未完成時，在同一張lineitem表下面加列、相同庫下建立一張表、給小表（如nation表）建立索引，觀察第二步是否能夠立即傳回，若能立即傳回，則表明支援并行DDL。

熱點行更新

對于有限的資料庫資源，如果有大量請求去消費的話，肯定會産生大量的鎖競争（資料庫對一條資料的更新會導緻在索引上給這條記錄加鎖），消耗伺服器資源，而且請求的成功率也不高（換句話說就是你在浪費伺服器資源，成本效益不高）；熱點行更新用來測試資料庫鎖控制能力和高并發大壓力下事務情況。

讀寫分離

場景介紹：一緻性讀用于在隻讀節點讀取資料的時候，是否可用控制讀的資料一緻，包括強一緻讀和弱一緻讀；并且隻讀節點延遲控制用于控制業務在讀取過程中，備庫最大支援多長時間的延遲。

分區變更特性

場景介紹：分區規則變更用于驗證資料庫的分布式調整能力，分區政策調整可以靈活适配線上表的業務場景，尤其從單表到分區表（分布式表），或者從單表到廣播表的場景。

特殊場景

1. 大事務

測試資料為tpch100g 生成的lineitem表，單表6億行資料
select * from lineitem;  
update lineitem set L_PARTKEY=L_PARTKEY+1;       

測試結果：

2. Json類型

3. 單機表數量

單機表數量用于測試在複雜業務場景下，單機上可以存儲的最大表（分區）的數量情況，驗證資料庫的中繼資料管理能力，并且考察在單機支援更多表的情況下可以降低分布式的存儲成本。

4. drop大表影響

TiDB、OceanBase、PolarDB-X均可以平滑删除，對線上業務無影響。

5. 應急限流

場景介紹：應急限流用于線上上緊急情況下，對部分爛SQL或者問題SQL進行緊急限流，保證大多數業務正常的情況下，限制部分爛SQL的運作，可用于緊急線上恢複。

6. 資源隔離

場景介紹：使用者驗證是否支援oltp和olap場景自動資源隔離，olap通常需要大量的資料查詢分析資源，如果無法資源隔離有可能影響線上業務的使用和穩定性。

7. 動态索引綁定

場景介紹：用于測試執行計劃綁定能力

測試結果分析

TiDB：

1. 開啟了實驗室特性(plan cache)，不建議生産直接使用。生産環境預設不開啟的話，point_select性能會有60%左右的性能下降，100核左右的資源點查場景隻有36萬QPS

2. sysbench測試場景中，會有比較大量的where id between xx and xx，但在實際業務中單純基于使用者id或者交易id的範圍查詢意義并不大，更多是在時間範圍的查詢。TiDB基于Range的分區政策，在between的分區裁剪可以做到隻通路1個資料分片，而PolarDB-X和OceanBase基于Hash的政策會通路5個資料分片，是以TiDB的資料結構會在sysbench單純名額能力上占一定的優勢。ps. 針對Range 和 Hash分區的性能差異，在PolarDB-X上基于read only場景下跑了下Range分區的對比測試，Range相比于Hash分區差不多有45%左右的性能提升(28萬 vs 19萬)

3. TPC-C場景下，整體劣勢比較明顯

4. TPC-H場景下，在tilfash模式下性能表現不錯，但在普通的tikv模式下，部分SQL跑不出結果

5. 特殊場景下，加索引的DDL性能有待提升，支援json但不建議生産使用，以及在熱點行更新下有明顯瓶頸

 OceanBase：

1. 非分區表(通常了解的單表)，在OceanBase内部會在分布式多個節點上做表級别的均衡，一張表的資料隻在一個節點，不同表可以在不同的節點，在非分區表下比較考驗純單機的能力。針對sysbench場景下的多張表在測試過程中是完全獨立的，這樣可以充分利用"多個單機"跑出一個更好的總吞吐值。這樣的模式下，相比于TiDB會有30%~70%的優勢，多個獨立的單表模式在真實業務場景中一般需要配合業務端的分庫分表。

2. 分區表，在OceanBase内部支援将一張表的資料分布到多台機器上，實作行級别的水準擴充能力，在分區表下會存在分布式事務、分片聚合查詢等額外代價，是最考驗分布式能力的地方。分區表和 非分區表在sysbench的性能測試結果上，兩者的性能差異巨大。尤其在寫入和混合讀寫場景，分區表隻有單表測試的1/5左右，分布式事務的性能還需要有進一步的提升空間。

3. TPC-C場景下表現優秀。在TPC-H場景下，通過并行計算+行存整體表現不錯。

4. 特殊場景下，不支援json，以及在熱點行更新下有明顯瓶頸。

 PolarDB-X：

1. 非分區表(通常了解的單表)，PolarDB-X上支援通過locality模式将表配置設定到不同的節點，一張表的資料隻在一個節點上，比較考驗純單機的能力。針對純讀和混合讀寫場景，相比于TiDB會有2~2.5倍的性能優勢。

2. 分區表，在PolarDB-X内部支援将一張表的資料分布到多台機器上，實作方式和TiDB、OceanBase分布式表基本一緻，在write only上整體性能會比TiDB好一些；在最常見的業務場景read write下，分區表和單機表性能都比OB要好很多，非分區表比TIDB有明顯的性能優勢，分區表跟tidb基本保持一緻

3. TPC-C場景下表現優秀。在TPC-H場景下，通過并行計算+行存整體表現不錯

4. 特殊場景下，快速加列DDL需要優化，支援json，以及針對熱點更新的優化明顯。

polardb-x對分區規則變更支援最好，基本支援所有常見的分區變更政策

總結

1. PolarDB-X/OceanBase/TiDB在分布式水準擴充的性能上大同小異，區分度并不大。

2. TiDB有一些不錯的實驗性質的功能(比如plan cache、json)，對性能和功能易用性幫助比較大，但眼下生産不推薦使用。

3. OceanBase的模型比較複雜，測試場景需要充分了解分區表和 非分區表(單表)。在非分區表(單表)模式下，性能表現不錯，重點考察的是純單機能力，性能尚可，略低于MySQL。但分區表模式下，性能下降比較多，需要業務區分來看。

4. PolarDB-X功能性和易用性比較不錯，json、大事務、熱點更新支援比較完整。在非分區表(單表)模式下，純MySQL單機的能力表現突出，在分區表模式下，可以通過分布式能力進一步擴充性能，對分區表的變更政策支援最完善。（完）