TiDB x 银联商务｜采用 TiDB 替换 MySQL 分库分表

业务挑战

银联商务综合查询业务系统原先采用 Oracle 作为数据存储。随着业务的发展数据量快速增加，Oracle 单机数据库因为无法横向扩展承载更多数据量和并发交易。经过评估选型，结合应用上云的计划，银联商务将数据库从 Oracle 替换为 MySQL 分库分表方案，虽然解决了数据存储问题，但仍面临一些挑战：

查询效率问题：缺乏计算下推和存储节点间的数据交互能力，导致在执行多表关联查询时，必须将数据汇总到中间件层进行 Join 计算，在许多情况下会导致关联查询失败。
运维复杂性：由于存在多个 MySQL 实例，运维工作包括备份、监控等变得更加复杂。在集群扩容时，需要备份数据、恢复和安排停机时间来修改配置，在可操作性和易用性上存在不足。
数据热点问题：当某个分片出现数据热点时，需要调整分片算法并重新导入数据，这一过程既复杂又耗时。
应用侵入性：应用在与数据库交互时必须携带分片键，否则分库分表中间件会将请求发送到所有分片，导致执行效率低下。

解决方案

综合查询服务系统数据包括联机数据和后线数据两部分。通过卡交易产生的联机交易数据存储在 MySQL 分库分表中，联机数据保留 7 天。联机数据通过 Canal 实时同步到 TiDB 集群中，称为后线数据。TiDB 集群处理用户对 7 天前历史数据的查询以及复杂的大表或多表关联查询。那些在 MySQL 分库分表方案下难以执行的关联和聚合查询也由 TiDB 承担。

目前，TiDB 集群已承载超过 100TB 的数据量，并且随着业务数据量的增长，可以在线扩展集群的节点来满足更大容量的数据存储需求。