TiDB与MySQL压测对比实践
神州控股李厚龙
技术人员如果有运营一个长期在使用的系统的经验,就会遇到这样的问题。随着新业务新客户的不断引入,应用系统功能的不断扩展,系统所产生的数据量将呈爆炸式增长,单一节点数据库面对大规模数据处理逐渐表现出其局限性,技术人员的大量时间陷在了不断优化代码、SQL和数据库来保持系统的访问速度体验。到了这个阶段,我们应该把目光转向分布式数据库。分布式数据库是指数据在物理上是分布的,而在逻辑上是集中管理的数据库。对应用系统而言,我们可以完全把它看做唯一数据源,无需考虑哪些数据在哪一个物理存储节点上,大大降低了应用系统的开发难度。
分布式数据库的产品有很多,今天我们要介绍的是TiDB,它是一款定位于在线事务处理/在线分析处理的融合型数据库产品,实现了一键水平伸缩,强一致性的多副本数据安全,分布式事务,实时OLAP等重要特性。同时兼容MySQL协议和生态,从MySQL迁移到TiDB非常便捷。那在同等数据量级的情况下,TiDB的性能表现与单节点MySQL比较会是一个什么样的结果呢?下面我们用两次压力测试对比来看一下实际情况。
为了能够更加直观的看出TiDB在实战中的表现,我们使用神州金库WMS3.0系统(神州金库系统是神州控股自研的,用于支持其智慧产业链业务的仓储系统,在每年双十一时要承受千万单量级增量的压力)作为应用系统,搭建两套几乎相同的应用环境,一套使用MySQL作为数据库,一套使用TiDB作为数据库,使用相同的数据源导入到两套应用系统中,用Jmeter对相同功能点进行压力测试,通过对压测结果的分析,可以让我们有一个相对清晰的认识。
测试环境硬件配置如下:
压测服务器应用系统环境:
测试场景:
压力测试分两个阶段进行,第一个阶段是在小数据量场景下,两环境性能对比;第二阶段稍大数据量场景下,两环境性能对比。从神州金库WMS3.0系统单量作为数据量评估依据,第一阶段测试数据库现存单量为万单,第二阶段测试数据库现存单量为万单。在此基础上,使用Jmeter压力测试10万单结果如下:
第一阶段少数据量场景:第二阶段大数据量场景:从两个阶段压测的结果我们可以看出,在第一阶段小数据量场景下,单节点MySQL与TiDB的表现各有千秋。这时候我们就会想,为什么我们投入了更多的硬件资源,反而运行速度还没有单节点MySQL快呢?这是分布式数据库的结构使然,在分布式场景下数据分节点存储,一个查询任务过来会被分发到各个节点执行操作,待各节点执行完毕还需要一个汇总的动作,这部分的开销还是不容小觑的。我们再来看第二阶段大数据量场景下,TiDB的表现几乎完胜单机MySQL,除简单的写入场景,其他场景几乎都有非常明显的性能提升。
总结来说,TiDB更适用于单表数据量千万量级以上的应用,低于千万量级的小数据量应用使用MySQL成本更优,运行更高效。神州金库WMS3.0目前使用的是MySQL库,可以按客户进行分库,以限制每个库的大小,如果未来单客户数据量就非常大,必然需要向TiDB做迁移。
预览时标签不可点收录于合集#个上一篇下一篇