TiDB与MySQL压测对比实践

神州控股

李厚龙

技术人员如果有运营一个长期在使用的系统的经验，，，，就会遇到这样的问题。。随着新业务新客户的不断引入，
，
，，应用系统功能的不断扩展，，，系统所产生的数据量将呈爆炸式增长
，，，单一节点数据库面对大规模数据处理逐渐表现出其局限性，
，
，，技术人员的大量时间陷在了不断优化代码、、、
、SQL和数据库来保持系统的访问速度体验
。。
。到了这个阶段，
，，，我们应该把目光转向分布式数据库。。分布式数据库是指数据在物理上是分布的
，，，，而在逻辑上是集中管理的数据库。。对应用系统而言，，，我们可以完全把它看做唯一数据源，
，，，无需考虑哪些数据在哪一个物理存储节点上，，大大降低了应用系统的开发难度。。。

分布式数据库的产品有很多，，，，今天我们要介绍的是TiDB，
，它是一款定位于在线事务处理/在线分析处理的融合型数据库产品，，，，实现了一键水平伸缩，，强一致性的多副本数据安全，
，，，分布式事务，，，实时OLAP等重要特性。。同时兼容 MySQL 协议和生态，
，，，从MySQL迁移到TiDB非常便捷。。。那在同等数据量级的情况下，，，，TiDB的性能表现与单节点MySQL比较会是一个什么样的结果呢？？
？下面我们用两次压力测试对比来看一下实际情况。。。

为了能够更加直观的看出TiDB在实战中的表现，，
，
，我们使用神州金库WMS3.0系统（神州金库系统是神州控股自研的，，
，，用于支持其智慧产业链业务的仓储系统，，，在每年双十一时要承受千万单量级增量的压力）作为应用系统，，，，搭建两套几乎相同的应用环境，，，，一套使用MySQL作为数据库，
，一套使用TiDB作为数据库，，使用相同的数据源导入到两套应用系统中，，用Jmeter对相同功能点进行压力测试
，，通过对压测结果的分析
，，可以让我们有一个相对清晰的认识。。。
。

测试环境硬件配置如下：

压测服务器

应用系统环境：

测试场景：

压力测试分两个阶段进行，，，，第一个阶段是在小数据量场景下，
，两环境性能对比
；第二阶段稍大数据量场景下，，，，两环境性能对比。
。从神州金库WMS3.0系统单量作为数据量评估依据，，，，第一阶段测试数据库现存单量为100万单，，，，第二阶段测试数据库现存单量为1300万单。。。在此基础上
，
，使用Jmeter压力测试10万单结果如下：

第一阶段少数据量场景：

第二阶段大数据量场景：

从两个阶段压测的结果我们可以看出
，
，，在第一阶段小数据量场景下
，，，单节点MySQL与TiDB的表现各有千秋。。这时候我们就会想，
，，，为什么我们投入了更多的硬件资源，，
，反而运行速度还没有单节点MySQL快呢？？？这是分布式数据库的结构使然，，，
，在分布式场景下数据分节点存储，，，一个查询任务过来会被分发到各个节点执行操作，
，待各节点执行完毕还需要一个汇总的动作
，，，，这部分的开销还是不容小觑的
。。。。我们再来看第二阶段大数据量场景下，，，TiDB的表现几乎完胜单机MySQL，，，除简单的写入场景
，，，其他场景几乎都有非常明显的性能提升。。

总结来说，
，TiDB更适用于单表数据量千万量级以上的应用，，，低于千万量级的小数据量应用使用MySQL成本更优，，
，运行更高效
。。。神州金库WMS3.0目前使用的是MySQL库，，，，可以按客户进行分库，，，以限制每个库的大小，
，，，如果未来单客户数据量就非常大，，，必然需要向TiDB做迁移。。。