TiDB x 京东云 | 京东物流在云数据库上的选择和实战

业务挑战

京东物流业务的高速发展给系统带来了极大挑战：第一，数据量增长快，系统频繁需要扩容。第二，随着数据量的增长以及业务复杂度的上涨，SQL 查询的效率变得越来越低，给研发带来了不小的压力。第三，分库分表的方式对业务的侵入性以及改造成本比较高，使用场景也受限，难以支撑跨分片的查询，一些复杂 SQL 不支持等，且大型集群的运维比较困难。

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

解决方案

京东云联合集团内部各个业务团队的专家进行了调研和分析，和 PingCAP 展开了深度合作，联合推出了云上的分布式数据库 —— Cloud-TiDB，提供京东云上的 TiDB 服务，主要优势特性有：

TiDB 采用的分布式架构支撑海量数据扩展，可以有效地解决单机 MySQL 容量和性能的瓶颈问题；
TiDB 与 MySQL 兼容性非常好，迁移成本很低，接入周期短，收益见效快；
TiDB 提供金融级可靠性，运维简单便捷；
支持在线扩容和在线 DDL，业务几乎无感知；
数据具有强一致性，支持事务，使用场景不受限制。

物流业务费用系统

京东物流业务费用系统的数据量较大，几个主表的数量分别是 20 亿、50 亿和 100 亿，系统上线半年后数据翻倍到了 220 亿。原先 MySQL 分库分表的架构就遇到了一些复杂的 SQL 不支持、跨分片统计报表难于实现等问题。

系统迁移到 TiDB 之后，整体的性能表现优秀，写入和更新的效率在 100 毫秒左右，查询和 Sum 查询只有二三十毫秒。一个几百亿数据量的系统从 MySQL 迁移到 TiDB，实际业务代码零修改，系统只是更换了 JDBC 连接的用户名和密码，真正地实现了从 MySQL 到 TiDB 的零代码修改和无缝迁移。TiDB 和 MySQL 良好的兼容性，降低了用户的试错、测试和迁移的成本，且收益周期短，见效快。

物流大件分拣系统

京东物流大件分拣系统的一些实时看板和核心报表跑在 MySQL 上。随着数据量增加，而且 SQL 比较复杂，报表和看板的性能比较低，用户体验不佳。分库分表的方式对代码侵入性比较大，架构需要大幅调整，风险较高。

京东物流采用 TiDB 支撑业务的实时看板和核心报表，在 MySQL 和 TiDB 之间，用自研的蜂巢系统进行数据的准实时同步。从 MySQL 迁移到 TiDB 后，总共数百个指标，整体性能实现了 8 倍提升。

运单计提明细系统

运单计提明细系统用来记录部分运单的明细数据，每天的数据增长在千万级别，单表最大记录接近 200 亿条。从数据量看用 MySQL 难以支撑，京东物流尝试使用 Presto，但使用成本比较高，后来使用 ElasticSearch 做查询，但存在着不稳定的情况，维护工作量很大。

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

业务收益

目前，京东集团在云上已经使用了数十套 TiDB 系统，支撑了集团多个 0 级关键业务系统。这些 TiDB 系统都经过了京东 618 大促的严格考验，期间没有发生过任何故障，性能平稳。预计到 2021 年年底，京东集团内部使用 TiDB 的规模会再增长 100%，总 CPU 核数将超过 10000 核。