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

简介：编者按：近几年国产数据库市场风生水起，涌现了多款优良的国产数据库产品，本文选取了三款典型的国产分布式数据库进行全方位比照压测，出现了国产分布式数据库的倒退现状。

对于所有的利用零碎，数据都是承载业务逻辑的外围资产，而存储数据的数据库系统则是最外围的零碎之一。随着国产化过程的一直推动，利用零碎基于国产化数据库进行构建越来越重要，也越来越成为数据库选型中的支流。

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

测试环境及数据库架构

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 亿行数据

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 单机的能力体现突出，在分区表模式下，能够通过分布式能力进一步扩大性能，对分区表的变更策略反对最欠缺。（完）

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