系统性能提升70%！华润万家某核心系统数据库升级实践

华润万家是华润集团旗下优秀零售连锁企业，业务覆盖中国内地及香港市场，面对万家众多业务需求和互相关联的业务环境，亟需加强各业务耦合性，以适应线上、线下、物流、财务等各个业务环境的快速发展。

随着信息技术的快速发展和数字化转型的推进，数据库作为数据管理和存储的基石，正扮演着越来越重要的角色。华润万家希望通过数据库数字化升级及创新技术和智能化应用，为企业提供高效、可靠和安全的数据管理解决方案。

万家数科积极响应国家、集团以及华润万家自身信息安全的战略规划，通过引入自主研发的数据库系统，以实现关键业务的持续支撑，智能化运作，提升业务系统运营效率，继而提升终端消费者的服务质量，实现“降本-增效-风险合规”的高效循环，助力万家适应复杂多变的市场环境和业务可持续发展，为公司在激烈的市场竞争中赢得先机。

（一）传统数据库现状

传统数据库系统如 MySQL、Oracle 等，在数据存储和处理方面发挥了重要作用。然而，随着互联网和移动设备的普及，数据量呈现爆炸性增长。为了应对数据暴涨趋势，许多企业采用扩展架构的方式来提高和扩展传统数据库的性能和容量。

（二）常用 MySQL 架构及 MySQL 扩展架构

在常用的 MySQL 架构中，主要有以下三种：

第一，主从复制架构。通过复制数据到一个或多个从服务器来提高性能和容量。

第二，分库分表架构。将数据分散到多个数据库实例中，以实现水平扩展。

第三，读写分离架构。将读操作和写操作分别分发到不同的数据库实例，以提高并发性能。

MySQL 扩展架构通常出现在业务膨胀的情况下，上述三种架构仍无法保证业务稳定时，可以通过分库分表与读写分离综合运用的方式来解决性能问题。

需要注意的是随着集群膨胀架构复杂度上升，其运维开发成本急剧上升，需面临各种问题。如木桶效应：一块“短板”拖累整个系统稳定。

（三）使用痛点

尽管传统数据库在很多场景中表现出色，但它们仍然存在一些使用痛点。

性能瓶颈：在面对大量并发请求时，传统数据库的性能会受到限制。如监控系统，几百台主机 1~2W 监控项，后台数据库还游刃有余。当上万台主机 50~100W 监控项时 MySQL 出现大量数据延时，严重时延时超过 30 分钟，此时监控数据已无实际意义。

扩展性限制：传统数据库在扩展性方面存在一定的限制，难以满足不断增长的数据需求。如硬件限制，受制于 CPU 内存存储限制。随着数据量增长，导致数据库性能下降，响应时间增加等问题。为了保证数据库健康，我们必须时刻监控数据量，定期清理数据。这实际是对数据库性能的妥协，对于业务来说尽可能地保证数据可查可用是最理想状态。

高维护成本：传统数据库需要投入大量的人力物力进行维护和管理。

安全性问题：传统数据库的安全性通常是关注的重点之一，需要采取多种措施来确保数据的安全性。如备份恢复问题，MySQL 数据库在备份恢复方面缺乏整体解决方案，导致备份不完整、备份文件丢失或损坏、恢复时间长等问题。如在基于中间件的 MySQL 架构中，审计问题困难较大，对用户访问、数据修改查询等操作的跟踪是较为棘手的问题，通常很难查到历史问题 SQL 的发起者。

高可用性不足：传统数据库在面临故障时，往往难以保证高可用性，影响业务连续性。华润万家在集群高可用性上也是做足了各种准备，主从架构、多从、分库、异地灾备等传统新型方案均有设计。在极端状态下其 RTO 时间也需要 10 分钟至半小时。某些情况下需要人为判断系统是否必须切换，对于风险等级业务重要度更高的数据库操作，需要整个团队共同分析、判断。

基于以上种种，近年来较为火热的国产自研数据库进入华润万家的调研视野。

在选择数据库时，我们主要考虑以下几点。

符合自主研发需求：数据库为完全自主研发具有自主知识产权的国产数据库，同时适配自研系统兼容性要求。
兼容性：与现有系统的兼容性（数据库如 MySQL、Oracle，系统如 CentOS、Red Hat 等），包括协议、数据格式和 API 等方面。
高可用性：节点故障处理、容灾能力和数据备份等。
可扩展性：节点扩展、数据分区和负载均衡等。
性能：读写速度、并发处理和数据处理能力等。
成本：迁移成本、开发成本、主机存储成本等。
业务耦合性：不同场景下与各个业务的耦合性，表现为应用适配，以及 SQL 在不同场景中性能抖动。

万家数科技术团队选择了两款国产数据库进行了基准测试和压力测试，观察二者在性能、成本及兼容性方面的表现。

（一）基准测试性能对比

由于数据库架构不同，为保证公平性，以总 CPU 及总内存作为基本参数，不以主机数量为评判。

系统主机规格：总 CPU 64C、总内存 256 GB，测试结果如下：

从测试结果看，OceanBase 对比某分布式数据库：

在 oltp_update_index 场景下，OceanBase 不同并发下 QPS 几乎都是 200% 或以上；

在 oltp_read_only、oltp_read_write、oltp_update_non_index、oltp_insert 场景下，OceanBase 表现更优，不同并发下平均提升 40% 的 QPS；
在 oltp_point_select、oltp_write_only 场景下，不同并发下两款数据库性能各有优劣，总体性能持平。

（二）压力测试对比

压力测试的环境和基准测试环境相同，测试结果如下：

从业务压测结果来看，OceanBase 表现更优，对比某分布式数据库，写业务的 QPS 是其 2 倍，查询业务的 QPS 是其 4 倍；但延迟仅为其 1/4。

根据各项对比结果来看，OceanBase 的表现均为最优，并且使用 OceanBase 能够最大化利用技术存储资源，降低碎片化资源，对比 MySQL 可降低存储成本约60%，保守测算综合成本可降低 30%。至于其他项如兼容性、高可用性、可扩展性，两款数据库差别不大，详情可见下表：

经过前期详尽的系统测试后，万家数科技术团队选定一核心业务系统作为数据库升级改造对象。

首先进行迁移评估，对现有数据库的性能、可用性和可扩展性等方面进行评估，并确定迁移目标和计划。其次，根据评估结果制定详细的迁移方案，包括数据备份、数据转换、节点迁移和测试等。最后，在完成迁移融合后，需要对新系统进行长期的监控和维护，确保其稳定运行并满足业务需求。

（一）迁移评估

该系统使用基于中间件的 MySQL 读写分离分库分表集群，架构见下图。

数据库采用 5 实例，每个实例 10 个分库，共50分库；每个实例两从库，使用中间件合并为一逻辑库读写分离。

第一，估算性能。实际生产核算 15TB 数据量。并发量估算 3000 并发。高频 SQL 通过后台监控抓取 Top 50。

第二，可用性及可扩展性。基于中间件的 MySQL 架构，在扩展性已有极大提升，通过添加新的 MySQL 集群及中间件路由配置可快速扩展集群容量及集群算力，但在集群扩容期间仍需短暂停机。

第三，评估迁移后数据量。预估迁移后大约 6TB 数据，OceanBase 数据库需最少7TB数据盘保证数据空间健康。

第四，装载测试数据进行高频 SQL 压测，验证数据库承载情况。

第五，评估分析系统关联业务，对每一个关联业务进行详细地摸底排查，逐一验证。

通过模拟评估，我们验证了使用新系统的可行性，预估使用 OceanBase 数据库资源量 CPU、内存、硬盘等初步数据。

（二）迁移方案

对于 7*24 小时运行业务，稳定运行阶段如何能够业务无感知平滑迁移是这次的迁移难点。为此，万家数科技术团队设计了巧妙的步骤。分步迁移数据库，按照读写分离策略，先迁移读业务，后迁移写业务，保证系统稳定、平滑地过渡至新系统。最大程度保证用户无感知。

MySQL 分库分表集群迁移 OceanBase 需考虑合库问题，如何合库合表是迁移难点。需对每张大表检查验证，确认每条数据的唯一性，并配置合适的大表分区键，确认热点 SQL 的性能最优。同时也要考虑历史数据能够快速卸载，保证运维清理能够简单高效。

对此，万家数科技术团队对数据库进行了详细地分析和验证，确定迁移改造方案。

首先，对于可以确认合表后数据无重复大表无需改造。其次，对于迁移后有可能存在数据重复大表进行改造，保证数据一致。

最后，对读写业务进行应用改造以适配双数据源，设置合理的规则，在整个迁移过程中分批次进行业务迁移直至迁移完成。

（三）流数据实时处理

在数据库业务关联数据流的处理中，Kafka 的使用是非常关键的。Kafka 的存放格式有很多，其中 Canal、Shareplex 和 Debezium 等是业内使用较多的格式。这些格式在 OceanBase 中得到了广泛支持，使数据流转更加稳定可靠，同时也极大地降低了迁移开发的成本。OMS（数据同步迁移工具）为这些格式提供了全面的支持，使数据流转过程更加顺畅，不再是一个棘手的问题。

1. 原系统基于 BinLog+CA 调度的数据流处理。

原系统基于 BinLog 日志变更使用 kafka-connector 监听对集群数据进行实时捕获。需对每个 MySQL 节点进行日志监听，维护复杂难度大。CA 任务调度不能保证实时性，推送延时大，业务量庞大时存在推送不及时、可靠性较差。

2. 改造基于 OMS+Flink 调度的流数据实时处理。

OMS 提供可视化的集中管控平台，界面化操作，可以基于时间点同步，维护成本低。同时使用 Flink 流实现实时数据处理逻辑。通过 Flink 的 StreamSink 和 TableSink 将处理后的数据实时推送到目标系统。确保目标系统支持实时数据的接收和处理。其 checkpoint 机制，实现任务的持续检查和恢复。在任务运行过程中，定期检查 checkpoint 状态，确保任务在异常情况下能够恢复到一致的状态。

OMS+Flink 方案保证了用户操作简单和数据实时性，整个数据流转可在 2s 内完成，保证每一笔数据消费都能准确实时可靠地推送至每一个用户。

（四）迁移融合成果

经过多次充分准备和验证成功将万家某核心系统迁移融合至 OceanBase 数据库平台，在迁移过程中，用户无感知，业务系统稳定运行，经过实际生产验证，较原系统性能提升约 70%，成本降低约 50%，本次迁移融合项目取得了圆满成功。