TiDB + ES：转转业财系统亿级数据存储优化实践
TiDB + ES：转转业财系统亿级数据存储优化实践
转转业财系统在面对亿级数据存储挑战时，通过采用TiDB和Elasticsearch（ES）的方案，成功优化了数据存储和查询性能。本文详细介绍了这一优化实践，包括背景分析、方案选择、实践步骤和最终成果等多个方面。
背景
1.1 现状
转转业财系统于2021年开始构建，初期为了快速上线，选择了主动接收上游业务系统的数据。然而，随着数据量的持续增长，系统逐渐达到承载极限，面临诸多问题。
1.2 数据量统计
下表展示了业财系统中数据量较大的表：
从上图可以看出，近几个月由于新业务的增加，每月的数据增量已达到一千万。
1.3 慢查询情况
目前，系统每天的慢查询数量已达到千量级。慢查询不仅影响用户体验，还会大量消耗机器资源，严重时可能导致机器宕机。此外，由于转转MySQL数据库采用单机多实例架构，一台物理机上部署多套集群实例，慢查询还可能影响其他集群，引发连锁反应。
设计目标
2.1 解决数据量问题
目标是在未来五年内无需考虑数据库数据量问题，能够轻松应对业务增长和全量业务覆盖，同时具备良好的扩展性，为输出更多数据报表奠定基础。
2.2 解决读写性能
通过优化提升报表查询效率，减少定时任务执行时间，避免慢查询导致的任务失败和接口超时问题，提高服务稳定性。
方案选择
3.1 DB 存储方案选型
方案一：分库分表
优点
将数据分散到多个数据库和表中，减轻单一数据库负载压力，提高读写性能和响应速度。
拆分的表结构相同，程序改造较少。
缺点
需要提前规划分片规则，扩展性较差。
拆分规则难以抽象。
存在跨库事务问题。
适用场景
高并发访问且需要处理海量数据的场景。
数据有统一业务规则主键，可均匀分布。
业财系统适用分析
业财系统数据多样且复杂，难以定义业务主键。
数据量快速增长或接入新业务时可能再次面临数据量问题。
方案二：冷热库
优点
将不常用数据移动到归档存储，降低成本。
减少在线存储数据量，提高性能。
长期保存历史数据，支持数据恢复。
缺点
需保证归档事务性，防止数据重复。
需考虑合适的归档策略。
业务复杂的数据不适用。
适用场景
存在大量低频访问的历史数据。
写入操作比读取操作更频繁。
需要降低成本的场景。
业财系统适用分析
业财系统业务数据复杂，现阶段还会更改和查询历史数据，边界模糊。
后续接入更多业务数据时，可能需要重新考虑边界等问题。
方案三：TiDB
优点
高度兼容MySQL，迁移成本低。
支持水平弹性扩展，轻松应对高并发、海量数据场景。
缺点
仍有一些MySQL特性和行为不支持或表现有差异。
系统复杂，组件较多。
适用场景
金融行业属性场景，要求高可靠性和可扩展性。
大量数据及高并发的OLTP场景。
数据汇聚、二次加工处理场景。
业财系统适用分析
TiDB兼容MySQL，改动少。
可以应对近几年的数据量增长。
支持大表的列操作，扩展性高，符合业财现状。
方案四：OceanBase
优点
采用读写分离架构，性能高。
高兼容性，支持MySQL/ORACLE功能。
高可用性，数据多副本存储。
缺点
对环境要求极高，需使用指定服务器。
学习和运维成本高。
依赖底层硬件和网络稳定性。
适用场景
金融级数据可靠性需求。
面对飞速增长的业务数据量。
业财系统适用分析
目前运维团队未维护，暂不考虑此方案。
综合分析，TiDB是最适合转转业财系统的方案，能够在短时间内解决数据量问题，且改动成本较低。
3.2 慢查询优化方案
大部分慢查询是由于联表查询导致的，因此主要解决联表问题。经过对比分析，选择ES方案。
方案实践
4.1 方案实践步骤
考虑到数据量突增和业务连续性，建议先切换底层数据存储，再接入ES。这样既能保证数据完整性，又能降低实施风险。
4.2 切换底层数据存储步骤
迁移过程要求：
- 检查TiDB是否兼容现有SQL语句。
- 保证数据完整性，迁移前后数据一致。
- 支持回滚，确保系统可用性。
4.3 接入 ES
- 根据报表查询页面的功能和联表SQL分析，设计索引模型以优化查询性能。
- 考虑DB与ES之间增量数据的同步方式，最终选择Kafka进行数据订阅。
- 使用公司内部提供的ECP工具完成历史数据同步。
总结与成果
目前，业财系统已成功完成底层数据存储的切换，解决了数据量存储问题，并成功接入更多业务数据。引入ES后，报表页面超时等问题也得到解决。此次优化的核心理念是在不影响业务使用的前提下进行系统重构，后续将继续完善慢SQL治理和定时任务优化等工作。