突破数据存储瓶颈！转转业财系统亿级数据存储优化实践

1.背景

1.1 现状

目前转转业财系统接收了上游各个业务系统（例如：订单、oms、支付、售后等系统）的数据，并将其转换为财务数据，最终输出财务相关报表和指标数据，帮助公司有效地进行财务管理和决策。

转转业财系统于2021年开始构建，前期为了满足需求短时间内上线，选择了主动接收上游业务系统的数据。然而随着时间的推移，数据量在不断增长，系统已经达到无法承载的边缘，引发了许多问题。因此，我们需要对数据存储进行优化。

1.2 数据量统计

业财系统数据量较大表统计：

以下是数据量较大的表数据增量趋势图，可以观察到近几个月由于新业务的增加，每月的数据增量已经达到一千万。

1.3 慢查询情况

从慢查询监控平台可以看到，每天慢查询个数已经到达千量级别。慢查询不仅影响用户体验，还会大量消耗所在机器资源，严重可能导致机器宕机。另外，转转MySQL数据库架构属于单机多实例，一台物理机上部署多套集群的实例，所以不仅会影响系统本身集群，还会拖累其他集群，引发雪球效应。

2.设计目标

2.1 解决数据量问题

在未来五年，不用考虑数据库数据量问题，能够轻松应对未来的业务增长和覆盖公司全量业务，且具备良好的扩展性，最终可以稳定向外输出更多数据报表等。

2.2 解决读写性能

通过此次优化，提升报表查询效率，减少定时任务执行时间，避免因为慢查询导致任务失败和接口超时问题，提高服务稳定性。

3.方案选择

3.1 db存储方案选型

为解决底层表数据量问题，我们对比了以下四个方案：

• 方案一：分库分表
• 优点

• 缺点

• 适用场景

• 业财系统适用分析

• 方案二：冷热库
• 优点

• 缺点

• 适用场景

• 业财系统适用分析

• 方案三：TiDB
• 优点

• 缺点

• 适用场景

• 业财系统适用分析

• 方案四：OceanBase
• 优点

• 缺点

• 适用场景

• 业财系统适用分析

综合以上各个方案的分析，目前最适用于转转业财系统的方案是TiDB。该方案能够在短时间内解决数据量问题，并且改动成本相对较低。

3.2 慢查询优化方案

在分析了慢查询语句以后，发现大部分慢查询都是由于联表查询导致的，所以此次主要解决联表问题。联表解决方案对比如下，根据适用分析选择ES方案。

4.方案实践

4.1 方案实践步骤

根据方案选择分析，最适合业财系统当前状况的方案是首先切换底层数据存储，然后再接入ES。在实施这两个方案之前，我们需要考虑它们的先后顺序，并分析业财系统的现状。由于数据量的突增，考虑到现有业务和后续新增业务，同时在不影响现有使用的前提下，首要需要解决的问题是数据量。因此，我们建议首先切换底层数据存储。这样做的好处是，即使在后续的实施中遇到问题，我们仍然可以回滚到原有的数据存储。这样既可以保证数据的完整性，也减少了实施过程中的风险。另一方面，如果我们选择先接入ES，就需要考虑如何保证数据切换过程中的数据完整性，并且同步方式也需要考虑两种不同数据存储方案之间的兼容性，这将增加许多额外的工作量和风险。

综上所述，我们选择的优化步骤是首先切换底层数据存储，待其稳定后再接入ES。这样能够有效解决当前的数据量问题，同时保证系统的稳定性和数据完整性。随后，我们可以继续进行ES的接入，以进一步优化业财系统的性能。

4.2 切换底层数据存储步骤

在选择数据迁移方式时，考虑到业财系统对实时性要求并不是很高，且评估了下目前大部分数据接入写入方式，是可以接受停写几分钟，这样便大大降低了整个数据迁移成本。

迁移过程要求：

迁移过程中需要做到可以回滚，一旦迁移过程中出现问题，可以立即回滚到MySQL库，不会对系统可用性造成影响。

4.3 接入ES

以下表格是对比了四种不同的同步方式，我们根据已设计的索引分析，考虑到每个索引涉及的表较多、相关业务代码尚未收口以及对实时性较高的需求，我们决定采用数据订阅的方式进行同步。在当前公司提供的实现方式中，我们选择了Kafka。

5.总结与成果

目前，业财系统已成功完成底层数据存储的切换，可以看到近几年来不再担心数据量存储的问题，并且成功接入了更多的业务数据。随着引入了Elasticsearch（ES），业务人员也不再反馈报表页面超时等问题。这次针对数据存储的优化实质上是对系统的重构，选择方案时考虑了对系统影响范围较小且不影响业务人员使用的因素，这也是优化的核心所在。

由于历史原因，业财系统仍存在许多需要优化的方面，如慢SQL的持续治理、定时任务优化等。因此，我们需要保持此优化的核心理念，并在后续的重构中继续完善，以使业财系统更加稳定。