系统性能提升 70%，华润万家核心数据库升级

本文摘自《OceanBase社区版在泛互场景的应用案例研究》电子书，获取完整版内容可直接点击链接。

作者：马琳，万家数科数据库专家。

从性能到扩展性：华润万家数据库系统面临的挑战

（一）华润万家与万家数科企业概况

华润万家是华润集团旗下优秀零售连锁企业，业务覆盖中国内地及香港市场。面对万家众多业务需求和互相关联的业务环境，集团亟需加强各业务耦合性，以适应线上、线下、物流、财务等各个业务环境的快速发展。在这样的背景下，华润万家成立了下属信息科技公司——万家数科商业数据有限公司。公司聚焦于零售领域，在服务华润万家的同时，市场化运营发展，为零售商及其生态提供核心业务系统的整体解决方案与运维服务。

图 1 华润万家集团概况

随着信息技术的快速发展和数字化转型的推进，数据库作为数据管理和存储的基石，正扮演着越来越重要的角色。华润万家希望通过数据库数字化升级及创新技术和智能化应用，为企业提供高效、可靠和安全的数据管理解决方案。对此，万家数科积极响应国家、集团以及华润万家自身信息安全的战略规划，通过引入自主研发的数据库系统，以实现关键业务的持续支撑，智能化运作，提升业务系统运营效率，继而提升终端消费者的服务质量，实现“降本-增效-风险合规”的高效循环，助力万家适应复杂多变的市场环境和业务可持续发展，为公司在激烈的市场竞争中赢得先机。

（二）传统数据库现状及使用痛点

1.传统数据库现状

传统数据库系统如 MySQL、Oracle 等，在数据存储和处理方面发挥了重要作用。然而，随着互联网和移动设备的普及，数据量呈现爆炸性增长。为了应对数据暴涨趋势，许多企业采用扩展架构的方式来提高和扩展传统数据库的性能和容量。其中，MySQL 是非常流行的扩展架构。常用的 MySQL 架构主要有以下三种。 第一，主从复制架构。通过复制数据到一个或多个从服务器来提高性能和容量。

图 2 MySQL 主从复制架构

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

图 3 MySQL 分库分表架构

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

图 4 MySQL 读写分离架构

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

图 5 MySQL 扩展架构

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

2.传统数据库在华润万家业务中的使用痛点

华润万家于 1984 年在香港成立了第一家门店，至今已有 40 年历史。在整体零售业务的发展的过程中，集团系统从最初简单的进销存系统演变为如今多套系统的配合，如物流供应链，会员系统、线上业务系统等。但新老系统的交替运行积攒了各种各样的问题，这些问题与传统数据库自身存在的局限交织在一起，可以分为以下几类。

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

（2）扩展性限制：传统数据库在扩展性方面存在一定限制，难以满足不断增长的数据需求。如硬件方面，受制于 CPU 内存存储限制，随着数据量增长会导致数据库性能下降，响应时间增加等问题。为了保证数据库健康，我们必须时刻监控数据量，定期清理数据。这实际是对数据库性能的妥协，因为对于业务来说尽可能地保证数据可查可用是最理想状态。同时随着系统规模的不断扩展，代码的复杂度增加，导致维护难度加大。如果扩展系统，不仅需要投入大量的资金，还需要大量的人力资源支持，企业要面临的成本压力极大，这也成为了限制企业发展的主要矛盾。

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

（4）多系统并行：随着华润万家业务发展阶段的演变，系统也从最初的套装系统转变为 Java 定制开发，使用了多种不同的数据库，如 IBM informix、Oracle、MySQL 等。不同数据库的差异化非常大，以至于不同团队需要频繁沟通，制定统一交互协议，确保数据流转顺畅，这会耗费大量的时间和精力。同时，由于各个系统之间的技术架构、数据格式、接口规范存在差异，需要定制化开发适配器和中间件，增加了集成难度。随着业务量增长，各业务系统之间的资源耗费也随之加剧，带来了成本压力，各团队需要合理分配硬件资源、网络带宽，优化系统配置，减少资源冲突，提升整体性能。

（5）用户体验降低：系统用户分为内部用户和外部用户，总体而言存在三点体验痛点。首先，不同用户对系统的功能、界面、操作方式等有不同的需求，满足个性化需求难度较大。其次，用户要求系统的响应速度越来越快，尤其是在高并发情况下，但保证系统的快速响应是一个挑战。第三是易用性，系统的复杂功能可能导致用户操作困难，降低用户体验。

（6）维护困难：一方面，传统数据库需要投入大量人力物力进行维护和管理。另一方面，由于各系统在数据传输过程中存在各种各样的问题。导致故障点难定位，需要经过多环节排查，增加修复时间，且链路中某环节容易造成瓶颈，影响整体性能，需要优化资源配置。运维人员使用监控手段定位问题，然而某些监控盲点需要一个更强大的运维团队做实时分析，这十分考验监控运维团队对业务的理解能力。

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

数据库选型：MySQL 与 OceanBase 各项测试对比

基于以上种种痛点和挑战，近年来较为火热的国产自研数据库进入华润万家的调研视野。在选择数据库时，我们主要考虑以下几点。

• 符合自主研发需求：数据库为完全自主研发具有自主知识产权的国产数据库，同时适配自研系统兼容性要求。

• 兼容性：与现有系统的兼容性（数据库如 MySQL、Oracle，操作系统如 CentOS、RedHat 等），包括协议、数据格式和 API 等方面。

• 高可用性：节点故障处理、容灾能力和数据可扩展性：节点扩展、数据分区和负载均衡等。

• 性能：读写速度、并发处理和数据处理能力。

• 成本：迁移成本、开发成本、主机存储成本等。

• 业务耦合性：不同场景下与各个业务的耦合性，表现为应用适配，以及 SQL 在不同场景中的性能抖动。

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

（一）基准测试性能对比

由于对比的数据库架构不同，为保证公平性，我们以总 CPU 及总内存作为基本参数，不以主机数量为评判。系统主机规格：总 CPU64C、总内存 256GB，测试结果如图 6、图 7。

图 6 OceanBase 与某分布式数据库的性能测试结果对比

从测试结果看，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 场景下，不同并发下两款数据库性能各有优劣，总体性能持平。

图 7 OceanBase 与某分布式数据库性能对比细节

（二）压力测试对比

压力测试的环境和基准测试环境相同，测试结果如图 8、图 9。

图 8 OceanBase 与某分布式数据库的压力测试对比结果 

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

图 9 OceanBase 与某分布式数据库压测对比细节

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

图 10 OceanBase 与某分布式数据库其他项目对比

经过对比，华润万家最终选择将原有数据库替换为原生分布式数据库产品 OceanBase。

引入 OceanBase，性能提升 70%，成本效益显著

（一）OceanBase 迁移过程

2022 年 6 月，万家数科引入 OceanBase 3.x 版本，并开始 POC 测试、核心系统验证。直至 2022 年 12 月，我们了解到单机分布式一体化的 OceanBase 4.0 版本即将发布，便等到新版本发布后及时跟进了系统迁移测试。经过几个月生产环境的上线实践，取得的效果让我们非常满意。在 2024 年，我们将大批系统迁移到 OceanBase 数据库，将其作为技术底座。

包括新项目的生产开发与旧项目的迁移在内，目前万家数科已有五六十个项目使用 OceanBase，未来将有更多的项目建立在 OceanBase 数据库之上。

（二）OceanBase 迁移经验解析

在引入 OceanBase 数据库方案的初期，万家数科技术团队选定了华润万家的某核心业务系统作为数据库升级改造对象。我们使用了 OMS 进行数据库迁移方案，而原 MySQL 集群是基于中间件的多实例分库分表集群。

OceanBase 迁移服务（OceanBase Migration Service，OMS）是 OceanBase 数据库提供的一种支持同构或异构数据源与 OceanBase 数据库之间进行数据交互的服务，具备在线迁移存量数据和实时同步增量数据的能力。OMS 提供可视化的集中管控平台，只需要进行简单的配置即可实时迁移数据。OMS 可以低风险、低成本、高效率地实现同构或异构数据库向 OceanBase 进行实时数据迁移和数据同步。OMS 的优势包括以下几点。

• 支持多种数据源。OMS 支持 MySQL、Kafka 等多种类型的数据源与 OceanBase 数据库进行实时数据传输。

• 在线不停服迁移，业务应用无感知。在不停服的情况下，可以通过 OMS 无缝迁移数据至 OceanBase。应用切换至 OceanBase 后，OceanBase 数据库上所有的变更数据会实时同步至切换前的源端数据库。

• 高性能、安全可靠的数据迁移。OMS 能够准实时实现异构 IT 基础结构之间大量数据的秒级延迟复制。因此可以应用于数据迁移、跨城异地数据灾备、应急系统、实时数据同步、容灾、数据库升级和移植等多个场景。OMS 能够实现在业务应用无感知和不中断的前提下，运行数据迁移和数据同步任务，并保证数据的完整性和事务的一致性。全量迁移性能可以达到 100 MB/s，20 万 TPS，数据同步性能可达 50000RPS。同时，OMS 提供高可用的部署架构方案，为数据迁移和实时同步提供稳定可靠的传输任务。

• 一站式交互支持数据迁移的全生命周期管理。可以在管理控制台界面操作完成数据迁移任务的创建、配置和监控，交互简便。

• 实时数据同步助力业务解耦。OMS 支持 OceanBase 两种租户与自建 Kafka、RocketMQ 之间的数据实时同步，可应用于实时数据仓库搭建、数据查询和报表分流等业务场景。

• 多重数据校验。OMS 提供多种数据一致性校验方式，更加全面、省时、高效地保证数据质量。同时展示差异数据，提供快速订正途径。

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

1. 迁移评估

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

图 11 某系统原有 MySQL 架构

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

评估时，我们首先估算了系统性能。实际生产核算 15TB 数据量。并发量估算 3000 并发。高频 SQL 通过后台监控抓取 Top50。其次评估可用性及可扩展性。基于中间件的 MySQL 架构的扩展性已有极大提升，通过添加新的 MySQL 集群及中间件路由配置可快速扩展集群容量及集群算力，但在集群扩容期间仍需短暂停机。第三，评估迁移后数据量。预估迁移后大约 6TB 数据，OceanBase 数据库需最少 7TB 数据盘保证数据空间健康。第四，装载测试数据进行高频 SQL 压测，验证数据库承载情况。第五，评估分析系统关联业务，对每一个关联业务进行详细地摸底排查，逐一验证。

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

2. 迁移方案

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

图 12 某系统迁移过程

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

该业务大表主键使用雪花算法，这种算法只能保证每一个 DB 有唯一性，在多个 DB 中有极小的概率会存在主键冲突。对于这种问题，如果是小表，可以通过查询、排除主键的方式来更改；如果是几十亿上百亿数据量的大表，使用排除主键法是不可行方案，会耗费大量资源。因此我们对主键做了一些改造，抛弃现有基于雪花算法的主键，新增了自增主键，并对所有 DB 的自增链设置了一个范围的起始值，如图 13。这样能够保证在一定时间内数据库的主键不会冲突。而在这个时间段内，需要尽快合库合表并完成迁移。

图 13 业务大表迁移方法

在切割方案中，我们对读写业务进行应用改造以适配双数据源，设置合理的规则，在整个迁移过程中分批次进行业务迁移，直到迁移完成，如图 14。

图 14 迁移切割方案

这样做的好处是可以把整个业务的迁移风险降到最低。第一步只是利用小部分流量做迁移测试，确定没问题后再进行后续步骤，逐一迁移读写业务。每步迁移过程在 10 秒内即可完成业务迁移，对业务影响极低。

3. 流数据实时处理

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

Debezium 格式是万家数科在推进 Flink 生态时所采用的统一格式，而当时 OMS V3 版本不支持此格式，如果为此进行改造，涉及的上下游链路非常多，预估改造工作量巨大。经过沟通，OceanBase-OMS 开发团队针对 Debezium 格式进行了相应的开发与适配，保证了我方项目的顺利进行，在此感谢 OceanBase 技术团队的倾力支持。

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

图 15 原有任务调度模式

迁移到 OceanBase 后，我们基于 OMS+Flink 调度的流数据实时处理，取代了此前基于 MySQL+Kafka 的延时较高的任务调度模式，如图 16。

图 16 基于 OMS+Flink 的流数据处理

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

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

4. 迁移融合成果

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

（三）OceanBase 优化案例解析

利用 OceanBase 丰富的生态体系，我们还极大简化了监控运维的工作，不仅提升了运维管理细粒度，还提高了运维效率。

以 OCP 和 ODC 的性能优化为例。

1.问题出现

某日凌晨，业务人员反馈在程序发布后，新增业务需求执行效率低下，该场景在 UAT 环境中性能稳定，但上线后效率较之前降低几倍，造成业务单据压单，无法实时处理业务单据。

2.问题分析

OCP：通过 OCP-SQL 诊断功能，发现该时间点 TOPSQL 中无明显慢 SQL，通过与开发沟通得知该场景为高频 SQL 场景，平均响应时间慢几毫秒均会对业务产生影响，随即确定问题 SQL。发现其并无相关索引问题呈现。 ODC：将问题 SQL 在 ODC 执行查询其实际执行计划，定位问题发现 SQL 存在较多 RPC 调用，如图 17。

图 17：ODC 性能问题

3.问题解决

新建表组避免 RPC 调用。图 18 为建立表组后的 SQL 执行计划基本信息，可见已没有 RPC 调用。

图 18 ODC 性能问题解决方法

（四）OceanBase 迁移收益

我们将迁移后的具体收益总结为以下 5 点。

• 成本节约：高压缩存储技术，原存储迁移后容量降低约 60%，硬件成本节约 50%，业务综合成本节约 25%左右。

• 资源有效利用率提高：使用集群汇聚多个实例，多租户资源隔离，减少资源碎片，充分利用资源。

• 改善业务韧性，开发效率提升：优化业务架构，统一技术栈，降低开发难度，提升开发效率，增强业务稳态和扩展性。相比此前整个运维团队都忙于稳固 MySQL 集群，现在大家轻松多了。

• 性能提升：解除当前架构中的性能瓶颈，系统性能提升 70%，同时支持实时报表查询，减少了数据链路开发与维护的工作，兼备混合分析场景的支持。

• 运维效率提升：数据库平台化管理，支持 DBA 白屏化操作，提升了运维效率，降低了运维工具开发和运维成本。

未来展望

未来，万家数科技术团队将致力于构建一套完整规范的数据库体系，加强团体培养建设，充分发挥其优势，优化资源配置和监控运维机制，实现降本增效与业务可持续发展的目标。