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做迁移。
。