三款典型国产分布式数据库的对比评测

2021年09月15日 阅读数:1
这篇文章主要向大家介绍三款典型国产分布式数据库的对比评测,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

简介: 编者按:近几年国产数据库市场风生水起,涌现了多款优秀的国产数据库产品,本文选取了三款典型的国产分布式数据库进行全方位对比压测,呈现了国产分布式数据库的发展示状。数据库

对于全部的应用系统,数据都是承载业务逻辑的核心资产,而存储数据的数据库系统则是最核心的系统之一。随着国产化进程的不断推动,应用系统基于国产化数据库进行构建愈来愈重要,也愈来愈成为数据库选型中的主流。json

近几年国产数据库市场风生水起,涌现了多款优秀的国产数据库产品,各大厂商也在重金投入数据库研发中。本文选取了三款典型的国产分布式数据库进行全方位对比压测,分析国产分布式数据库的发展示状,供各位读者参考。服务器

测试环境及数据库架构

PolarDB-X

数据库架构:数据结构

1.png

Oceanbase

2.png

数据库架构:

3.png


TiDB

4.png

数据库架构:

image.png

压测指标分析

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. 测试结果数据app

image.png

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

image.png

 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

image.png

DDL 能力

1. 场景说明

测试数据为tpch100g 生成的lineitem表,单表6亿行数据

image.png

2. 并行DDL测试

并行DDL用于测试在达标的DDL过冲中,在前一个DDL未完成时,在同一张lineitem表下面加列、相同库下建立一张表、给小表(如nation表)创建索引,观察第二步是否可以当即返回,若能当即返回,则代表支持并行DDL。

image.png

热点行更新

对于有限的数据库资源,若是有大量请求去消费的话,确定会产生大量的锁竞争(数据库对一条数据的更新会致使在索引上给这条记录加锁),消耗服务器资源,并且请求的成功率也不高(换句话说就是你在浪费服务器资源,性价比不高);热点行更新用来测试数据库锁控制能力和高并发大压力下事务状况。

image.png

读写分离

场景介绍:一致性读用于在只读节点读取数据的时候,是否可用控制读的数据一致,包括强一致读和弱一致读;而且只读节点延迟控制用于控制业务在读取过程当中,备库最大支持多长时间的延迟。

image.png

分区变动特性

场景介绍:分区规则变动用于验证数据库的分布式调整能力,分区策略调整能够灵活适配线上表的业务场景,尤为从单表到分区表(分布式表),或者从单表到广播表的场景。

image.png

特殊场景

1. 大事务

测试数据为tpch100g 生成的lineitem表,单表6亿行数据
select * from lineitem;  
update lineitem set L_PARTKEY=L_PARTKEY+1; 

测试结果:

image.png

2. Json类型

image.png

3. 单机表数量

单机表数量用于测试在复杂业务场景下,单机上能够存储的最大表(分区)的数量状况,验证数据库的元数据管理能力,而且考察在单机支持更多表的状况下能够下降分布式的存储成本。

image.png

4. drop大表影响

TiDB、OceanBase、PolarDB-X都可以平滑删除,对在线业务无影响。

5. 应急限流

场景介绍:应急限流用于在线上紧急状况下,对部分烂SQL或者问题SQL进行紧急限流,保证大多数业务正常的状况下,限制部分烂SQL的运行,可用于紧急线上恢复。

image.png

6. 资源隔离

场景介绍:用户验证是否支持oltp和olap场景自动资源隔离,olap一般须要大量的数据查询分析资源,若是没法资源隔离有可能影响在线业务的使用和稳定性。

image.png

7. 动态索引绑定

场景介绍:用于测试执行计划绑定能力

image.png

测试结果分析

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单机的能力表现突出,在分区表模式下,能够经过分布式能力进一步扩展性能,对分区表的变动策略支持最完善。(完)

原文连接
本文为阿里云原创内容,未经容许不得转载。