編者按:對于所有的應用系統,數據都是承載業務邏輯的核心資産,而存儲數據的數據庫系統則是最核心的系統之一。随着國産化進程的不斷推進,應用系統基于國産化數據庫進行構建越來越重要,也越來越成為數據庫選型中的主流。
近幾年國産數據庫市場風生水起,湧現了多款優秀的國産數據庫産品,各大廠商也在重金投入數據庫研發中。本文選取了三款典型的國産分布式數據庫進行全方位對比壓測,分析國産分布式數據庫的發展現狀,供各位讀者參考。
測試環境及數據庫架構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. 場景說明
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單機的能力表現突出,在分區表模式下,可以通過分布式能力進一步擴展性能,對分區表的變更策略支持最完善。(完)
三款典型國産分布式數據庫的對比評測
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!