作者介绍

杨牧，京东云数据库产品经理，总体负责京东云的数据库产品在云上的规划、落地以及整个京东集团数据库上云的相关工作。

本文介绍了京东物流从MySQL到Cloud-TiDB的应用实践及未来规划。TiDB不仅解决了京东物流在MySQL架构下遗留的“快、慢、烦”三大问题，更带来了意外的惊喜：按两年为周期计算，IT成本将下降到原来的1/3。TiDB在部分业务系统的应用带来的成本改善和效率提升，已经成为集团内部的标杆案例。预计到年年底，京东集团内部使用TiDB的规模会再增长%。

随着京东业务发展的快速发展，数据量的增长也越来越快，带来了几个方面的挑战：第一，快。业务增长快、数据量增长快，系统频繁需要扩容，每次扩容都比较麻烦，从资源申请的流程到风险评估，预案的准备以及跟业务方的沟通等，给我们的架构师带来了不少麻烦。第二，慢。随着数据量的增加以及业务复杂度的上涨，SQL查询的效率变得越来越低，研发需要持续不断地对系统进行优化，这给研发也造成了比较大的压力。第三，烦。为了解决数据量的问题，不少系统采用了分库分表的方式，但是这种架构运维比较繁琐而且容易出错，这个时候，运维踩雷可能性就急剧地上升了。

随着业务和数据量的不断增长，给架构师、研发和运维都带来了各种各样的挑战，我们也探索了一些业界主流的方案，比如说像分库分表。分库分表通常只适用于一些比较简单的业务，对业务的侵入性以及改造成本比较高，使用场景也比较受限，比如难以支撑跨分片的查询，一些复杂SQL不支持等，而且大型集群的运维比较困难。

在一些分析和查询的场景，我们还尝试使用了ElasticSearch和ClickHouse。这两种方案都需要把数据从交易库MySQL里面同步过来，还需要对业务进行代码改造。除此之外，还存在一些其他的限制，例如ClickHouse不支持事务且并发低等。

柳暗花明——打造一款适合Cloud的TiDB

京东云联合集团内部各个业务团队的专家进行了调研和分析，最后我们和PingCAP展开了深度合作，联合推出了云上的分布式数据库——Cloud-TiDB，提供京东云上的TiDB服务。京东云上的TiDB服务主要有以下三个特点：一键部署、一键扩容和多维监控告警。

一键部署是指在创建集群的时候，可以自定义节点的规格、节点的数目，同时也支持TiFlash，还可以在线的升级数据库版本，这些操作都是通过鼠标的点击，很轻易地完成。

一键扩容是说无论是TiDB、TiKV还是TiFlash节点，均可在线的水平增加节点的数目，提升整个集群的容量和处理能力，而且整个扩容过程，几乎是无感知的，对业务毫无影响。

多维监控告警是指我们将云上的云监控，和TiDB的Grafana和Dashboard有机地结合，进一步帮助我们的开发、运维人员更好地使用TiDB。

总而言之，对于用户来说就只管使用，其他的都可以交给京东云来处理。

我们选择Cloud-TiDB作为京东一些海量业务的支撑，主要是基于以下几方面考虑：

TiDB采用的分布式架构支撑海量数据扩展，可以有效地解决单机MySQL容量和性能的瓶颈问题。

最重要的一点，TiDB与MySQL兼容性非常好，迁移成本很低，接入周期短，收益见效快。

TiDB提供金融级可靠性，运维简单便捷。

支持在线扩容和在线DDL，业务几乎无感知。

数据具有强一致性，支持事务，使用场景不受限制。

意外惊喜——Cloud-TiDB的方案和收益

下面我们来看一下京东实际的一个案例，这个是物流业务跟一些费用相关的系统，这个系统的数据量比较大，我们能够看到它的几个主表的数量分别是20亿、50亿和亿，系统上线了半年后数据翻倍到了亿。因为数据量比较大，所以在最开始的时候，采用的就是基于MySQL的分库分表架构。在运行了一段时间之后，分库分表的架构就遇到了我们所说过的一些问题，比方说一些复杂的SQL不支持，一些跨分片统计报表难于实现等等。经过调研、测试之后，我们决定把这个数据库从MySQL切换到TiDB。

迁到TiDB之后，整体的性能表现比较优秀，写入和更新的效率在毫秒左右，查询和Sum查询只有20-30毫秒。大家可以猜一下，一个几百亿数据量的系统从MySQL迁移到TiDB，需要修改多少代码？实际业务代码是零修改的，系统只是更换了JDBC连接的用户名和密码，真正地实现了从MySQL到TiDB的零代码修改和无缝迁移。TiDB和MySQL良好的兼容性让我们在使用TiDB的时候，试错、测试和迁移的成本比较低，而且收益的周期也非常短，见效快。

除此之外，迁移到TiDB还给了我们一个意外的惊喜，我们做了一个评估，如果按两年的周期计算，TiDB的使用成本仅为MySQL的37%。为什么这么说？因为TiDB对数据的压缩率非常好，这是当时测试的结果，在MySQL里的数据占到10.8T，迁移到TiDB之后只有3.2T，而且这3.2T还是三副本的总数据量。所以，MySQL与TiDB的空间使用比是3.4:1。

原先的架构是一个四分片的MySQL集群，按照目前数据增长的速度，大概是每六个月就要进行扩容，每次要扩四套主备实例。TiDB按实际需要扩容就行了。可以看到在第24个月的时候，MySQL有32个节点，TiDB只有14个节点，使用的CPU核数MySQL是个，而TiDB只要多个，不到MySQL的一半。在存储空间上，TiDB更是只有MySQL的1/3。所以说，TiDB带给我们的惊喜就是帮助我们整个业务部门极大地降低了IT的投入成本。

第二个案例是京东物流大件分拣的业务系统。以前这个系统的一些实时看板和核心报表都是跑在MySQL上。随着数据量增加，而且SQL比较复杂，报表和看板的性能比较低，用户的体验不是特别好。当时我们也尝试过分库分表的方式，但是这种方式对代码侵入性比较大，架构需要大幅调整，风险比较高。

最后，我们选择了TiDB支撑业务的实时看板和核心报表。在MySQL和TiDB之间，用我们自研的蜂巢系统进行数据的准实时同步。从右下角的监控图可以看到，从MySQL迁移到TiDB后，总共数百个指标，整体性能提升了8倍。

第三个系统是京东物流的运单计提明细系统，主要是记录部分运单的明细数据，每天的数据增长大概在千万级别，单表最大记录接近亿条。很显然，这样一个数据量用MySQL是很难支撑的。我们曾经尝试使用Presto，其性能和容量都还可以，但对我们来说使用成本比较高，所以后来使用ElasticSearch来做查询工作。ElasticSearch存在着不稳定的情况，由于业务的特性，例如计费项经常需要调整意味着表结构的变化，所以维护的工作量很大。

把这个业务系统迁移到TiDB之后，首先解决了海量数据的问题，TiDB可以毫无压力地支撑百亿级的数据量。其次，TiDB成本比起以前使用的MySQL+ElasticSearch方案降低了30%。此外，TiDB性能也满足业务的要求，从百亿的单表里面查询出业务数据的TP99大概在毫秒左右。还有一点比较重要，TiDB整个表结构的调整修改操作非常简单，给我们带来了运维敏捷和成本下降。

京东物流使用TiDB的收益主要体现在成本、效率和体验三大方面。TiDB帮助我们降低了IT系统的投入成本和运营成本，成本降低之后，就意味着这个系统的架构师有了成绩，业务性能的提升可以极大地改善用户体验。研发也不再需要成天优化系统了，可以早点回家去过自己的二人世界了。运维效率得到了极大的提升，运维同学就不再需要经常熬夜去支持系统运维了，可以把精力投入到其他更有价值的业务中去。不熬夜之后，我们的头发也可以少掉几根。

目前京东集团在云上已经使用了数十套TiDB系统，支撑了集团多个0级业务系统，0级业务系统是指如果这个系统发生故障超过30分钟就要上报到CEO，所以说0级业务系统属于京东的关键业务系统。这几十套TiDB系统都经过了京东大促的严格考验，期间没有发生过任何故障，性能也很平稳。同时，TiDB在部分业务系统的应用带来的成本改善和效率提升，已经成为集团内部的标杆案例。我们预计到年年底，京东集团内部使用TiDB的规模会再增长%，总CPU核数将超过00核。

除了TiDB之外，市面上还有一些其他的分布式数据库，我们在当初选型的时候，也做了一些对比。从集群规模来看，TiDB可以支持数百个节点，而其他的分布式数据库大都是1主15从，共支持16个节点，从节点规模上来说就差了一个数量级。从读写的扩展上看，TiDB是一个多活架构，其所有对外提供服务的TiDB节点都是可以读可以写的，都是对等的，而其他产品多数只有主节点可以写，从节点只能提供读的能力，写还是和以前MySQL一样受限于单机能力，没法得到提升。从数据容量上来看，TiDB可以达到PB级的数据量，而其他数据库都是在TB左右。除此之外，TiDB支持实时数据分析，而其他的数据库不具备这个能力。TiDB的备份效率会稍低一些，希望TiDB今后在这方面有更多的提升。

最重要的是TiDB是一个开源的产品，不会被某个云厂商所绑定，基于TiDB用户可以很轻松地实施多云战略，可以把TiDB部署在任何一个云上，不受到任何的绑定。如果你用得不爽了，直接换个云就行了，不像以前很多企业都是用Oracle数据库，现在想换也换不了，非常痛苦。

蒸蒸日上——未来展望和经验分享

接下来分享一下我们在TiDB使用过程当中的一些实践经验。

第一个是查询计划的改变，这是一个比较常见的情况，以前在MySQL有一些比较好的SQL，在TiDB里面使用性能有一些问题，需要进行逐个地分析和优化，通过加一些索引以及查询计划，最后都可以得到解决。第二个就是自增主键容易引起热点数据，可以通过使用AUTO-RANDOM来解决。第三，在TiDB的默认配置参数中，在大数据量下新建索引的时候，tidb_ddl_reorg_worker_cnt、tidb_ddl_reorg_batch_size两个参数配置比较小，我们可以调大一些，在重建索引的时候，性能可以得到比较大的改善。第四，TiDB默认是严格区分大小写，而MySQL默认是不区分的，我们只能在数据库集群初始化的时候进行配置，后面修改不了。最后就是SQLMode，如果在MySQL中使用了一些特殊的SQLMode，迁移到TiDB中的时候，有些SQL可能没法正常执行，只需查看当前使用的MySQL的SQLMode并直接替换就可以。

最后，结合我们的使用经验谈谈对TiDB的期望。首先，我们希望单个TiKV可支持更大的存储空间，目前官方给的建议是2T，希望可以提升到4T或者是5T，可以进一步降低TiDB的使用成本。第二，提升备份效率，TiDB集群的数据量通常比较大，所以备份效率比较重要，希望TiDB今后能够通过其他一些方式，比如支持通过硬盘快照的方式进行备份和恢复。第三，希望TiDB能够支持一些外部表的读写，例如OSS、HDFS、NFS等，用户可以把历史数据放到这些低成本的存储中，实现数据的冷热分层，降低使用成本。第四，进一步提升TiCDC的性能和稳定性，有些同步任务可以通过接口和K8sJob进行配置，希望通过在生产环境实现主从集群的方式，进一步扩大TiDB在京东内部的使用场景和规模。

我们希望PingCAP和TiDB能够发展得越来越好，成为国产数据库的一面旗帜，同时也欢迎大家来京东云试用Cloud-TiDB。