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

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

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

测试环境及数据库架构

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来比照剖析三种分布式数据库的剖析能力：

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

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