创意电子

标题: 三款典型国产分布式数据库的对比评测 [打印本页]

作者: 凌云时刻    时间: 2021-9-9 10:40
标题: 三款典型国产分布式数据库的对比评测
编者按:对于所有的应用系统,数据都是承载业务逻辑的核心资产,而存储数据的数据库系统则是最核心的系统之一。随着国产化历程的不停推进,应用系统基于国产化数据库进行构建越来越紧张,也越来越成为数据库选型中的主流。
近几年国产数据库市场风生水起,涌现了多款良好的国产数据库产品,各大厂商也在重金投入数据库研发中。本文选取了三款典型的国产分布式数据库进行全方位对比压测,分析国产分布式数据库的发展现状,供各位读者参考。
测试环境及数据库架构

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 = utf8mb42. 场景说明
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来对比分析三种分布式数据库的分析能力:
// 导入数据 100Gtiup bench tpch prepare --host xxx --port xxx --db tpch_100 --sf 100  --analyze --threads xxx// runtiup 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单机的能力表现突出,在分区表模式下,可以通过分布式能力进一步扩展性能,对分区表的变更策略支持最美满。(完)
三款典型国产分布式数据库的对比评测
作者: 坐云观潮    时间: 2021-9-11 21:08
转发了




欢迎光临 创意电子 (https://www.wxcydz.cc/) Powered by Discuz! X3.4