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