簡介： 編者按：近幾年國產數據庫市場風生水起，涌現了多款優秀的國產數據庫產品，本文選取了三款典型的國產分布式數據庫進行全方位對比壓測，呈現了國產分布式數據庫的發展現狀。
對於所有的應用系統，數據都是承載業務邏輯的核心資產，而存儲數據的數據庫系統則是最核心的系統之一。隨着國產化進程的不斷推進，應用系統基於國產化數據庫進行構建越來越重要，也越來越成為數據庫選型中的主流。
近幾年國產數據庫市場風生水起，涌現了多款優秀的國產數據庫產品，各大廠商也在重金投入數據庫研發中。本文選取了三款典型的國產分布式數據庫進行全方位對比壓測，分析國產分布式數據庫的發展現狀，供各位讀者參考。
測試環境及數據庫架構
PolarDB-X
數據庫架構：
Oceanbase
TiDB
壓測指標分析
Sysbench壓測情況：
1. 壓測參數配置
測試表結構： 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（商業智能計算測試）是美國交易處理效能委員會(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億行數據
並行DDL用於測試在達標的DDL過沖中，在前一個DDL未完成時，在同一張lineitem表下面加列、相同庫下創建一張表、給小表（如nation表）建立索引，觀察第二步是否能夠立即返回，若能立即返回，則表明支持並行DDL。
熱點行更新
對於有限的數據庫資源，如果有大量請求去消費的話，肯定會產生大量的鎖競爭（數據庫對一條數據的更新會導致在索引上給這條記錄加鎖），消耗服務器資源，而且請求的成功率也不高（換句話說就是你在浪費服務器資源，性價比不高）；熱點行更新用來測試數據庫鎖控制能力和高並發大壓力下事務情況。
讀寫分離
場景介紹：一致性讀用於在只讀節點讀取數據的時候，是否可用控制讀的數據一致，包括強一致讀和弱一致讀；並且只讀節點延遲控制用於控制業務在讀取過程中，備庫最大支持多長時間的延遲。
分區變更特性
場景介紹：分區規則變更用於驗證數據庫的分布式調整能力，分區策略調整可以靈活適配線上表的業務場景，尤其從單表到分區表（分布式表），或者從單表到廣播表的場景。
特殊場景
1. 大事務
測試數據為tpch100g 生成的lineitem表，單表6億行數據 select * from lineitem; update lineitem set L_PARTKEY=L_PARTKEY+1;
測試結果：
單機表數量用於測試在復雜業務場景下，單機上可以存儲的最大表（分區）的數量情況，驗證數據庫的元數據管理能力，並且考察在單機支持更多表的情況下可以降低分布式的存儲成本。
TiDB、OceanBase、PolarDB-X均可以平滑刪除，對在線業務無影響。
5. 應急限流
場景介紹：應急限流用於在線上緊急情況下，對部分爛SQL或者問題SQL進行緊急限流，保證大多數業務正常的情況下，限制部分爛SQL的運行，可用於緊急線上恢復。
場景介紹：用戶驗證是否支持oltp和olap場景自動資源隔離，olap通常需要大量的數據查詢分析資源，如果無法資源隔離有可能影響在線業務的使用和穩定性。
場景介紹：用於測試執行計划綁定能力
測試結果分析
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單機的能力表現突出，在分區表模式下，可以通過分布式能力進一步擴展性能，對分區表的變更策略支持最完善。（完）
原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。