作者：杨泽，宝付支付数据团队负责人

随着#数字化转型 升级进入关键期，数据库已从被动的存储仓库，转变为主动赋能业务的智能数据中枢。以现代金融行业为例，业务对数据库提出了更高要求：既要满足事务，又要实时分析，同时安全、高效、弹性、智能地处理多模数据，并支撑实时决策与业务创新。这意味着，符合要求的数据库需在TP、AP、KV、AI方向均具备出色的数据处理能力。

作为在银行、消费金融、零售、跨境等行业深耕多年的一站式综合支付解决方案商，宝付支付产品种类丰富，且深谙技术创新与业务稳健的关系，不断引进先进技术维护和保障公司业务稳步运行，全方位为商户资金安全和交易安全保驾护航。

近年来，宝付支付的原数据库方案已不能满足业务需求，故而寻求技术升级。本文分享宝付支付在KV场景使用OBKV替换HBase的技术实践。

出于架构痛点，寻求支持 TP+AP + KV + AI 的数据库

宝付支付所属集团——漫道集团采用基于MySQL的集中式架构，由于近年来业务高速增长（2023 年初交易量约 3000万笔/日，2024 年 12月 已突破 9000 万笔/日）带来的海量数据（TB级），系统压力陡增。

最直观的压力便是成本压力，每年存储采购预算高达数千万元。同时，为了保障部分业务系统的高可用性，需在 A/B 两个机房部署完全对等的 MySQL 双活架构集群（如各100 台服务器），导致硬件与运维成本成倍增长。

同时在双活架构下，业务层仅关注“订单不丢、实时写入”，但不关心数据最终落在哪个机房、哪个分库。这给数据团队带来巨大挑战：无法准确追踪数据源，难以构建统一的数据视图，ETL 与实时同步逻辑异常复杂。

在业务种类多样的情况下，长期使用MySQL还会导致架构越来越复杂，使运维压力极大。集团内部运行着十余套大数据集群和超过 1000 个 MySQL 实例，分别服务于支付、风控、征信、BI 等不同场景，对数据库有不同的需求。

• 支付交易系统：要求高并发、低延迟的事务处理能力。
• 风控系统：依赖实时数据分析与毫秒级决策。

• 征信 用户画像业务：需要高性能 KV 存储与快速点查。

• BI 系统：依赖大规模离线分析计算。

多套异构系统并行，导致开发、监控、备份、扩容等运维工作极其繁重。

除MySQL外，我们使用 #HBase 存储海量日志与宽表，其虽具备高吞吐写入能力，但在事务支持、复杂查询、实时分析、KV 混合负载等方面存在明显短板，已无法满足新一代业务需求。

基于上述挑战，我们开始评估新一代分布式数据库方案。文章开头提到现代金融行业的业务对数据库提出了多种要求。宝付支付作为金融行业的一员也不例外，根据对TP、AP、KV、AI方向的需求，我们首先想到了 #OceanBase，核心原因在于其原生支持 HTAP（混合事务/分析处理） + KV + AI 的一体化架构。

• TP 能力：满足支付交易系统的高并发、强一致性要求。
• AP 能力：支撑风控与 BI 的实时分析需求。
• KV 接口：为征信等场景提供低延迟点查。
• AI 能力：内置向量化引擎与 AI 原生能力，为后续智能风控、实时推荐等 AI 应用奠定基础。

为控制风险，我们采取“由边缘到核心”的渐进式改造路径：先在非关键系统验证 OceanBase 稳定性，逐步迁移风控、征信等中台系统；最终目标是将核心支付交易系统平滑切换至 OceanBase，用一套数据库承载全场景需求。

从边缘到核心：OBKV-HBase替换HBase

在启动 OceanBase 引入计划后，我们先在离线与分析业务进行试点，后将多个MySQL业务迁移至OceanBase。当OBKV功能较为完善时，又完成了从HBase到#OBKV-HBase的升级，实现了一套引擎支持多场景业务的目标。

HBase 难以应对业务复杂度与实时性要求

尽管 HBase 在海量数据存储场景中曾发挥重要作用，但随着业务复杂度提升与实时性要求增强，其在架构、运维及成本等方面的问题日益凸显。主要体现在以下六个方面。

• 离线链路冗长：当前数据流转路径为从 MySQL 流转至 Hive，再导入 HBase，流程环节多，数据延迟显著，且 Hive 层的数据修正不够灵活。
• 实时链路依赖过重：直接读写 HBase 严重依赖 Zookeeper 与 HDFS，中间件耦合度高，链路稳定性风险集中。
• 运维问题：跨机房场景下，集群切换与数据同步操作繁琐，故障时难快速隔离或切换。
• 成本控制：为满足高可用要求，需部署完整的 HBase 主备集群，硬件与存储资源近乎翻倍，成本太大。
• 多机房网络问题：机网络切割的时候，专线网络异常的时候，对业务都有影响。
• SQL 查询依赖 phoenix：原生不支持标准 SQL，需借助 Phoenix 等组件实现查询，引入额外维护负担，且使用体验与性能往往不及直接 SQL 友好。

使用OBKV替换HBase，为统一技术栈奠定基础

OBKV 是构建在 OceanBase 分布式存储引擎之上的NoSQL 产品系列，目前支持 OBKV-Table、OBKV-HBase、OBKV-Redis 三种产品形态，其原生继承了 OceanBase 的高性能、事务、分布式、多租户、高可靠的基础能力。此外，OceanBase 的工具体系（比如OCP、OMS、CDC等）也原生支持 OBKV，运维 OBKV 的各个产品形态和运维 OceanBase 的 SQL 集群完全一样。OBKV 可以帮助企业统一技术栈，在满足业务对多模 NoSQL 数据库诉求的同时，降低企业在数据库运维上的复杂度。

基于我们目前正在使用的OBKV- HBase，总结其与HBase 的使用区别如下。

• 完全集成 OceanBase 分布式存储能力：OBKV 不仅有 OceanBase 强大的内核能力，也继承了 OceanBase 丰富的生态工具能力。
• 极简运维：DBA 如果同时有 SQL 以及 NoSQL 数据库的诉求，可以只运维一个数据库。
• 统一查询：可以用 OBKV 做简单快速的 DML，同时可以用 SQL 对同一份数据做并发的复杂查询。
• 成本更低：HBase 独用资源，OceanBase 是复用现有资源。
• 监控更方便：方便对应用现有运行环境添加监控。

OBKV-HBase 不仅解决了传统 HBase 在运维复杂、资源孤岛、工具缺失等方面的痛点，更通过与 OceanBase 深度融合，可以实现“一套引擎、多模服务、统一运维、资源共享”的现代化数据基础设施目标。

引入 OceanBase 的三个阶段，确保技术转型平稳可控

在数据库架构升级过程中，我们分三个阶段逐步引入 OceanBase，确保技术转型平稳可控。

第一阶段：初步探索与能力评估（2023 年）

2023 年底，团队开始接触 OceanBase 及其 OBKV-HBase 产品。当时 OBKV 文档尚不完善，关键功能缺失，尤其缺乏 bulkload（批量导入）能力，无法高效导入离线数据 ，初期判断暂不具备支撑核心业务的能力。因此，该阶段以技术调研为主，未投入生产使用。

第二阶段：归档与分析场景试点（2024 年）

2024 年，团队转向更匹配当前能力的场景，启动 OceanBase 在离线与分析业务的试点，将数据归档、BI 聚合宽表、AP 分析类业务迁移至 OceanBase。我们不仅验证了OceanBase在高吞吐写入、复杂查询、资源隔离等方面的稳定性与性能表现，还积累了集群部署、SQL 优化、运维监控等关键经验，为后续全面推广奠定基础。

第三阶段：逐步替换与扩展（2025 年起）

随着 OceanBase 功能持续完善（特别是 OBKV-HBase 的成熟），团队启动规模化替换计划。

• 关系型业务：逐步将业务管理系统、商户管理系统、BI 系统等原 MySQL 应用迁移至 OceanBase SQL 模式；
• NoSQL 业务：使用 OBKV-HBase 替代原有 HBase，例如将“绑卡/解卡操作日志”等高频 KV 场景迁移至 OBKV-HBase；
• 实现 TP、AP、KV 多负载统一承载，推动技术栈收敛与运维简化。

五步平滑迁移：工具使用、方案设计与注意事项

在从 HBase 到 OBKV-HBase 的数据迁移过程中，我们在实践中总结出五个关键步骤。

Step1: 目标端准备

在正式启动从 HBase 到 OBKV-HBase 的数据迁移前，需在 OceanBase 端完成充分的环境与配置准备。

• 硬件配置：为避免因磁盘性能不足导致集群不稳定，建议使用高性能磁盘，但建议初期不要过度分配资源，以便预留弹性空间，用于后续扩缩容及负载均衡调整。
• 存储规划：单个 OBServer 节点的磁盘容量应大于单个日志流的数据量。若单表数据量极大，而节点磁盘不足，可能在扩容或副本迁移时触发空间不足错误。
• 租户规划：建议为 OBKV 创建独立租户，隔离资源。
• 建好分区表。

注意事项

• 实测表明，自动 Range 分区优于手工预设 Hash 分区。自动分区支持分区裁剪，对范围扫描类查询性能更优；手工 Hash 分区在范围查询时需扫描所有分区，显著增加延迟与资源消耗。
• 需正确创建 Table Group：HBase 表名对应 OBKV-HBase 的 tablegroup 名字。
• 注意命名规范：HBase 列簇 family 在 OBKV-HBase 形式对应表 tablegroup$family。
• 注意 K 大小写：使用 DBeaver 等工具导出建表语句时，关键字（如 K）可能被转为小写（如 k），导致语法错误。同时需显式设置最大版本数（Max Versions）和数据过期时间（TTL）（多个版本多行）。

Step2: 数据迁移

在完成目标端环境准备后，我们分阶段实施历史数据迁移与增量数据同步，确保业务平滑切换至 OBKV-HBase。

历史数据迁移

为高效迁移海量历史数据（单表达数十 TB），我们同时使用了 DataX 与 OMS ，但需特别注意两者在数据格式上的关键差异：

• DataX 导入的数据 Q 值是带列簇，T 值是正数。
• 用 OMS 导入的 Q 值是不带列簇，T 值是负数。

增量数据同步

为确保切换期间数据零丢失，我们采用 “OMS 增量同步 + 业务双写” 双保险机制：

• HBase 开启复制，通过 OMS 增量同步。
• 通过业务程序双写保证数据实时同步。
• 逐步将流量从 HBase 切换到 OceanBase。

Step3: 数据校验

由于 OBKV-HBase 属于 NoSQL 场景，OMS 在当前版本中尚未提供 KV 类型数据的全量一致性校验功能，我们结合业务实际，设计了一套多维度、可落地的数据校验方案，确保迁移后数据准确无误。

1. 行数校验：精确统计表行数。

HBase 端：使用 HBase 的 RowCounter 工具统计原表行数。 命令: org.apache.hadoop.hbase.mapreduce.RowCounter 'table'。

OceanBase 端：使用 count 统计，获取行数并与 HBase 结果比对。

2. 三方数据对比：借助 Doris 实现内容级校验。

由于 OMS 暂时不支持进行 KV 场景下的全量校验，我们引入 Doris 作为临时比对中间层：

• 通过 DataX 将 HBase 数据同步至 OceanBase 和 Doris。
• 对比 HBase、OceanBase、Doris 三方的数据一致性。

3. 对关键业务字段进行抽样对比。

Step4:数据访问支持

在完成数据迁移与校验后，业务系统需通过标准接口访问 OBKV-HBase。我们发现 OBKV-HBase 不仅兼容 HBase 协议，还扩展了多项高级查询与操作能力，显著提升了开发效率与系统灵活性。

查询操作（Select）

• Filter：支持定义基于 AND 及 OR 构建的复杂的过滤条件，下压给 OBKV 服务端来做过滤。
• Limit：限制返回满足条件数据的条数。
• IN 等语法糖：IN 本质上是一种 Filter，提供对应接口方便业务编码。
• 简单聚合能力：提供 Sum/Min/Max/Avg/Count的聚合语义接口，下压给 OBKV 服务端来做简单聚合。
• OrderBy：只支持基于主键以及索引序。
• 迭代器访问方式：提供类似迭代器的流式 Query 接口，适用于大批量结果集的流式获取以及处理场景，比如翻页场景。

数据操作

• Insert：支持单行/多行数据插入。
• Update：支持单行/多行数据更新，支持带 Filter 的条件更新。
• Delete：提供基于主键做数据的删除，支持单行/多行数据删除。
• Upset（insertOrUpdate）：此接口的语义是，如果有对应记录存在，执行 Update 操作，如果不存在，执行 Insert 操作，此接口也支持单行/多行操作。

Step5：业务压测

为确保 OBKV-HBase 能够满足高并发生产环境要求，我们使用真实业务压测 OBKV 性能，达到 42w QPS，延迟仅为 1ms 左右，超出预期。

压测方法：

• 业务直接连接 OBServer 压测 OBKV 性能。
• 对比前期通过 ODP 压测的性能差异。
• 详细测试数据

我们部署 10 个 Pod 模拟业务客户端，分别通过 OCP 统一调度和通过 ODP 的方式进行多轮压测任务。如下分别是 OceanBase 数据库、OCP 模式、ODP 模式压测的数据记录。

OceanBase 数据库压测数据如下图所示

OCP 模式压测数据如下图所示

ODP 模式压测数据如下图所示

需要说明的是，前期通过 ODP 压测，性能不佳，QPS 不到 2k，具体原因分析见后续问题总结。经过优化，直连 OBServer 压测 OBKV，QPS 达到 42W，延迟 1ms 左右，完全满足业务需求。

直连 OBServer 的测试结果让我们对 OceanBase 的性能有了充分的信心，为后续业务的正式切换奠定了基础。

OBKV上线经验与问题总结：运维配置、数据校验

在 OBKV-HBase 的测试与上线过程中，我们积累了一系列关于监控集成、硬件配置、租户隔离及 CDC 同步等方面的实践经验，总结如下，供大家参考。

运维配置相关

1.监控配置

为避免重复建设监控平台，我们将 OBKV 相关指标接入公司统一的自研监控系统：

• ODP 的 Prometheus 参数可直接使用默认配置，无需额外调整；
• 如需修改 ODP 监控参数，可通过 sys 租户登录集群，执行以下命令：

show proxyconfig like "%prometheus%"以及alter proxyconfig set xxx = xxx;

2.硬件配置

• 建议使用高性能磁盘，以保障高吞吐写入需求。
• 初期资源不要划太多，避免将单台服务器的全部 CPU/内存资源划给租户，以便预留弹性空间用于后续扩缩容及负载均衡。
• 单个节点的磁盘要大于日志流的大小，当单表很大时且未合理分区，其对应的日志流可能超过单节点磁盘容量，同时在集群扩容（如从 3-3-3 架构扩展至 6-6-6 ）时，副本迁移会因日志流到节点磁盘迁移失败而失败。

3.租户配置

建议为 OBKV 创建独立租户，避免与 TP/AP 类 SQL 业务共享资源。

4.CDC 配置

在使用 OMS 或 CDC 进行数据同步时，需特别注意 HBase 动态列模型与 CDC 日志格式的兼容性问题。HBase 表的列是动态的（不同 Row 可含不同列），而 OceanBase 的 clog（提交日志）在记录变更时有两种模式。

• 全列模式（full）：记录整行所有列的值。
• 非全列模式：仅记录被更新的字段。

若源端写入为非全列，而目标端 CDC 期望全列日志，可能导致同步解析失败或数据不一致。

解决方法是启用 CDC 的脏数据跳过开关skip_dirty_data=1，允许跳过全列校验，修改后重启实例生效：ALTER BINLOG INSTANCE y6op8d9rk1 SET EXTRA_OBCDC_CFG ='skip_dirty_data=1'。

5.前缀检索用 setRowPrefixFilter

在早期调研阶段，我们比较担忧 OBKV-HBase 是否支持基于 RowKey 前缀的高效查询。经过深入查阅文档与测试验证，确认 OBKV-HBase 完全兼容 HBase 1.2+ 的原生 API，其中包括关键的前缀检索功能。可通过 Scan.setRowPrefixFilter(byte[] prefix) 方法实现高效的前缀扫描（Prefix Scan），具体如下图所示。

该接口会自动构造起始键（startRow）和终止键（stopRow），仅扫描匹配指定前缀的 RowKey 范围，避免全表扫描，显著提升查询效率。

数据校验问题

在从 HBase 迁移至 OBKV-HBase 的过程中，我们在数据校验过程中也遇到了3个关键问题。

问题1：上下游数据条数校对问题

问题描述

使用 DataX 和 OMS 两种工具分别迁移同一张 HBase 表后，OBKV 中的数据行数均少于 HBase 源端，初步校验无法对齐。

原因分析

HBase 的数据模型特性导致 count 结果存在歧义。

• Region 分裂重叠：分裂过程中可能短暂产生重复 RowKey。
• 未提交数据/写入失败残留：部分写入未完成但日志已落盘。
• 多版本（Multi-Version）：同一 RowKey 多次写入生成多个时间戳版本，默认全部保留。
• TTL（Time-To-Live）未生效：过期数据尚未被清理，仍计入统计。

在上述场景下，HBase 的 RowCounter 统计的是所有版本 + 所有可见记录，而 OBKV 默认仅保留最新版本（若未显式配置），导致数量差异。

解决办法

• 统一迁移工具：避免混合使用 DataX 与 OMS，防止因时间戳、列格式处理逻辑不同引入偏差。
• 放弃基于快照（Snapshot）或 HFile 的 BulkLoad 方式，改用 queryType=scan 的流式读取，确保仅同步当前可见、已提交的最新版本数据。
• 开发专门的数据校验工具，对比源端和目标端的数据。

结果验证

通过调整迁移工具和校验方法，最终实现了 HBase 和 OBKV 数据的完全一致。

注意事项

• 建表语句大小写敏感：通过 DBeaver 等工具导出的建表语句中，K 关键字可能为小写（如 k = 'value'），需手动修正为大写，否则解析失败。
• 注意设置最大版本号和过期属性（多个版本多行）。

问题 2: 20002 错误码

问题描述

• 客户端等待服务端一直没有回包，超时报错 20002 ，默认超时设置为 1.5 秒。
• 每次应用重启后，第一笔查询耗时比较高，后面查询耗时基本正常。

原因分析

根本原因是 scan.setCaching 参数配置不合理。

• scan.setCaching 参数用于限制每次 RPC 请求返回数据的行数。在 nextO 迭代的过程中，底层通过多次 RPC 来拉取剩余数据。
• 不设置 scan.setCaching 参数时，默认一次 RPC 拉完一整个分区的数据，在等数据返回的过程中卡住，导致 RT 较高。

解决办法

将 scan.setCaching 参数的值设置为 100，控制每次 RPC 请求返回的最大行数。scan.setCaching(100);设置后，第一次查询耗时降到了 300ms 左右，后续查询性能也得到显著提升。

问题 3：代理压测性能不佳

问题描述

通过 ODP 压测 OBKV-HBase，发现性能瓶颈明显，QPS 不到 2k。

原因分析

根本原因是ODP 元数据缓存机制与数据库大小写敏感配置不匹配。

• OceanBase 集群启用了 表名大小写敏感模式（lower_case_table_names = 0）。
• 而 ODP 默认行为在处理元数据请求时，未正确识别大小写敏感上下文，导致其无法有效缓存表结构信息。

每次查询均触发完整的元数据解析流程（包括向 sys 租户查询表定义），无法命中本地缓存。高频元数据查询成为性能瓶颈，严重拖累整体吞吐能力。

优化方案

• 通过设置 ODP 参数开启 ODP 表名小写兼容模式，在 sys 租户下执行：alter proxyconfig set pc_enable_lower_case_table_names=True。
• 再次压测结果：QPS 稳定在 1.2w 左右，性能提升 6 倍。

“一库多模、统一平台”，将大规模引入OceanBase

通过近两年对 OceanBase 及其 OBKV-HBase 能力的深入实践，宝付支付成功完成了从传统 HBase 架构向新一代分布式数据库平台的平滑演进，取得了显著的技术与业务成效。

• 实现降本：HBase 独用资源转为 OceanBase 复用资源，不仅释放了数台服务器资源，还实现了 NoSQL 与 SQL 负载的统一承载，使硬件投入与运维成本大幅降低。
• 提升效率：QPS 提升到 42W，延迟降低到 1ms 左右，完全满足高并发支付场景的严苛 SLA 要求。
• 增强可用性：告别 MySQL 主从 + 异地备库等复杂架构，统一为 OceanBase 多副本强一致架构。系统具备自动故障切换（RTO < 8s）、数据零丢失（RPO = 0）能力，整体健壮性显著提升。
• 统一监控：方便对应用现有运行环境添加监控，大幅提升可观测性和监控易用性。

不仅如此，对于集团架构而言，也具有重大意义和价值。

其一，完成数据库架构全面升级。从 HBase 到 OceanBase，从“多套异构数据库”走向“一库多模、统一平台”，我们实现了数据库架构的全面升级，技术栈大幅收敛。

其二，夯实业务创新底座。高性能、高可用的数据服务为实时风控、智能 BI 等新场景的业务创新提供了更强大的数据支撑能力。

其三，奠定智能数据架构基础。为未来 AI 原生计算、HTAP 融合分析、跨地域多活等演进方向预留充分扩展空间。

其四，沉淀宝贵实践经验。形成涵盖迁移方案、数据校验、性能调优、故障排查的完整方法论，可复用于后续系统改造。

本次 OBKV-HBase 成功落地，离不开 OceanBase 团队在过去两年中提供的专业、及时、深度的技术支持，特别是老纪及其研发、技术支持团队。无论是早期功能定制、性能瓶颈攻关，还是生产上线保障，OceanBase 团队始终与我们并肩作战，为项目顺利推进提供了坚实保障。在此，谨代表宝付支付技术团队，向 OceanBase 团队在迁移过程中提供的技术支持致以诚挚感谢！

另外，基于当前 OceanBase 在宝付支付的成功落地经验，我们已将 OceanBase 纳入集团未来数据架构的核心，聚焦 AI 项目赋能、汇聚库建设、多活架构尝试、零售支付场景四大业务方向大规模引入。

1. Al 项目赋能：实现一体化SQL+AI。

为响应公司对智能化转型的战略要求，我们将 AI 能力深度集成至数据库引擎层，推动从“被动查询”向“主动智能服务”升级。

• 原生支持 AI 混合计算：利用 OceanBase 内置的向量化执行引擎与 AI 函数能力，实现“SQL + AI”的混合计算。
• 探索智能化查询优化和数据处理。
• 提升数据分析和決策支持能力。

2. 汇聚库建设：实现一体化TP+AP。

当前集团存在 1000+ MySQL 实例及多套异构数据系统，导致跨库分析、实时统计、经营报表等场景面临巨大挑战，OceanBase 的 HTAP 一体化架构为此提供了根本性解决方案。我们将逐步把核心业务库、汇聚库、宽表等迁移至 OceanBase 并扩大线上使用规模，使用一套集群同时承载 TP 写入与 AP 分析，构建统一的数据平台，简化数据链路，提升数据治理和数据服务能力。

3.多活架构尝试，实现系统稳定。

苦于MySQL双活架构带来的问题，我们将尝试业务多活要求，满足高可用业务需求。依托 OceanBase 原生分布式多副本与 Paxos 协议能力，构建轻量级、高可用、跨机房、跨地域的多活架构，提升系统容灾能力和业务连续性。

4.零售支付场景深化。

随着内部零售支付业务越来越多，我们将在其他零售支付业务场景推广使用 OceanBase。并持续优化 OceanBase 压测记录，完善性能基线。我们计划基于真实业务负载开展常态化压测，建立 QPS、延迟、资源消耗等关键指标的基准模型。

此外，探索更多 OceanBase 在支付行业的应用场景，充分发挥 OceanBase 的 HTAP 与多模能力。

数据库的升级不仅是技术的迭代，更是业务持续创新与稳健运行的基石。

欢迎关注，将为您持续更新与#数据库、#AI、#开发、#降本增效 相关的技术内容。

摘要：

OceanBase 凭借原生分布式、零停机、全栈多云兼容三大核心技术优势，精准破解 TNG Digital 在高并发支撑、业务连续性等方面的痛点，助力其实现从“宕机危机”到“99.99%高可用”的跨越式升级,成为其规模化盈利的技术基石，打造了分布式数据库以硬核技术赋能东南亚头部金融科技企业核心支付场景的标杆范例，为分布式数据库基础软件出海提供“技术适配+低成本落地”的全新实践路径。

作为马来西亚金融科技领域的领军者，TNG Digital 凭借 TNG eWallet 深度融入民众支付生活，全面覆盖交通出行、餐饮消费、资金转账等高频场景。

自 2018 年起，其用户规模实现超 10倍爆发式增长，截至 2025 年，已服务马来西亚 3300 万人口中的 2500 万验证用户，成为支撑区域数字经济运转、贯穿民生服务的关键信息基础设施。

然而，高速增长背后暗藏技术“生死考验”，OceanBase 凭借原生分布式、零停机、全栈多云兼容三大核心技术优势，精准破解 TNG Digital 在高并发支撑、业务连续性等方面的痛点，助力其实现从“宕机危机”到“99.99%高可用”的跨越式升级。

本次合作不仅成为 TNG Digital 规模化盈利的技术基石，更打造了分布式数据库以硬核技术赋能东南亚头部金融科技企业核心支付场景的标杆范例，为分布式数据库基础软件出海提供“技术适配+低成本落地”的全新实践路径。

增长阵痛：金融科技高并发场景下的核心数据底座短板

作为承载马来西亚数千万用户日常支付的核心平台，TNG Digital 的系统稳定性直接关系到民生服务体验与金融市场秩序。

Leslie Lip（TNG Digital CTO）坦言，业务年增长率达 2-3 倍的背后，是技术团队不断与“规模陷阱”博弈的过程。

核心痛点集中于数据底座的四大短板：

· 突发流量峰值应对失效

午间支付高峰时段，全钱包系统需承载巨大的交易压力，而原有数据库难以支撑政府补贴发放等非常规突发流量。TNG Digital 曾在 6 年前发生的数据异常，正是因为原有数据库架构缺陷导致服务器资源未充分利用从而陷入瓶颈，暴露了核心数据底座的“抗冲击”能力不足。

· 业务迭代中的停机风险

金融科技平台需通过高频表结构更新，适配支付场景创新，但原有数据库的 DDL 变更常导致生产环境停机，直接影响用户支付、转账等核心操作的连续性，成为业务快速迭代的“绊脚石”。

· 多云扩展的兼容性壁垒

业务初期依托阿里云，随规模扩张延伸至 Azure、AWS 等多平台，但不同云厂商的数据库服务存在适配鸿沟，既无法实现跨云协同运维，又面临被单一厂商绑定的“vendor lock-in”风险，制约 TNG Digital 的全球化布局步伐。

· 性能与成本的失衡困境

用户增长带来数据量爆发式累积，原有数据库存储效率低下，导致 IDC 运维与存储成本持续攀升；同时在相同硬件规格下，吞吐量难以匹配业务增长需求，形成“成本涨、性能滞”的恶性循环。

OceanBase 破局之道：以“支付级”能力适配金融科技核心需求

Leslie Lip 强调，选择 OceanBase 的核心逻辑是“解决真实业务痛点，而非单纯追求技术参数升级”。

针对 TNG Digital 在支付场景高并发、业务连续性、多云扩展等方面的核心诉求，OceanBase 提供了贴合金融科技特性的全链路解决方案：

01零停机解决核心技术破解迭代难题

依托原生分布式架构设计，OceanBase 实现核心表 DDL 操作零停机执行的关键技术突破——在 POC 阶段即完成 4 万 TPS CRUD 并发场景下的表结构更新测试，全程无业务中断、无性能衰减。

这一技术特性彻底解决了 TNG Digital 高频迭代中的停机隐患，为支付场景快速创新扫清核心技术障碍。

02原生分布式架构扛住峰值压力

OceanBase 采用“share-nothing”原生分布式架构，具备线性弹性扩展能力，可按需扩容支撑业务增长。

该技术特性使其既能轻松承接午间的常规高峰流量，更能应对政府补贴发放等非常规突发流量的冲击，从底层架构层面杜绝宕机风险，完美匹配支付场景对高可用的极致要求。

03全栈多云一致性体验能力

OceanBase 内置全栈多云兼容技术模块，通过统一的技术接口与适配层，完美兼容阿里云、Azure、AWS 三大云平台的底层环境，实现不同云平台下的部署架构、运维操作、性能表现及合规审计的全链路一致性体验。

这一核心技术特性，不仅为 TNG 搭建了 “以私有化部署为核心、多云协同为延伸” 的弹性 IT 架构，保障了征信数据跨云流转与管理的稳定性、安全性，更从技术层面帮助 TNG Digital 彻底摆脱 “vendor lock-in” 制约，为其后续拓展东南亚其他区域征信服务、接入更多全球云服务提供商奠定了核心基础，让 TNG Digital 在全球化业务布局中具备更强的技术灵活性与成本可控性。

04高压缩比+高性能优化技术提升效益

OceanBase 基于高压缩的数据引擎，实现 5 倍数据体积缩减的技术效果，大幅降低存储与运维成本。

同时凭借分布式执行引擎优化技术，在相同硬件规格下实现 40% 的吞吐量提升，精准破解 TNG Digital “成本涨、性能滞”的核心困境，为金融科技企业盈利化发展提供技术支撑。

05全量 MySQL 兼容技术加速落地见效

OceanBase 深度打磨 MySQL 兼容层技术，实现语法、应用行为、驱动的全量兼容。

这一技术特性使 TNG Digital 技术团队无需额外学习成本即可快速上手，大幅缩短项目升级与落地周期，实现技术升级的“平滑过渡”。正如 Leslie Lip 所言，OceanBase 不仅是数据库，更是“能伴随企业野心共同成长的技术平台”。

实现从“生存线”到“增长线”的价值跃升

基于 OceanBase 完成核心数据底座升级后，TNG Digital 在业务稳定性、运营效率、创新能力三大维度实现质的飞跃，关键成效完全匹配金融科技支付场景的核心诉求：

01支付连续性达行业顶尖水平

核心系统实现 99.99% 的高可用，与 OceanBase 合作至今，未发生任何数据库事故，成功支撑多轮政府补贴发放等重大场景的平稳运行，彻底摆脱过往宕机阴影，筑牢支付业务“生存线”。

02性能与成本效益双突破

相同硬件规格下，业务吞吐量提升 40%，高效承接高峰期高并发交易；5 倍数据压缩比大幅降低存储成本，为企业盈利化发展提供有力支撑，将数据底座从“成本中心”转化为“效益中心”。

03创新与拓展能力全面释放

零停机 DDL 与多云协同能力，为 TNG Digital 的场景迭代与跨平台拓展扫清障碍。

目前双方已启动键值数据库模型搭建、跨云双活架构合作等计划，将基于 OceanBase 构建更具弹性的时间敏感型支付应用，进一步拓宽业务增长边界。

从服务本土支付场景的分布式数据库，到支撑海外支付场景的分布式数据库

金融科技的规模化增长，本质是数据底座“抗冲击能力、迭代能力、扩展能力”的综合较量。

TNG Digital 作为东南亚支付领域的龙头企业，其面临的“高并发、零中断、多云扩展”痛点，是全球金融科技企业规模化过程中的共性难题。OceanBase 的成功落地，不仅解决了单一企业的技术困境，更提供了适配支付场景核心需求的可复制技术方案。

OceanBase 与 TNG Digital 的合作，标志着分布式数据库凭借“原生分布式+零停机+全栈多云兼容”等硬核技术特性，已具备支撑海外头部金融科技核心支付场景的成熟能力，实现从“国内核心场景验证”到“海外高频支付场景落地”的关键跨越。

区别于其他出海案例，此次合作的核心亮点在于以技术特性精准匹配支付场景需求——零停机保障业务迭代连续性，原生分布式支撑高并发峰值，多云兼容打破拓展壁垒，这些技术优势共同重塑了海外市场对分布式数据库基础软件在支付场景下的技术认知。

未来，OceanBase 将持续深化与 TNG Digital 的协同创新，助力其实现云服务提供商拓展、跨云韧性升级等战略目标，同时进一步完善东南亚市场的本地化服务体系，聚焦金融科技支付、数字钱包等核心场景，为更多海外企业提供“支付级”稳定、高效、经济的数据底座支撑，推动分布式数据库基础软件全球化布局向“场景化深度赋能”新阶段迈进。

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

作者：张红霞，青岛雨诺网络信息股份有限公司新零售产品部总监

综述

当前，医药零售企业已不再满足于“卖药”，而是致力于成为“健康管理伙伴”。通过构建以 CRM 会员系统为核心、线上与线下深度融合的全渠道服务架构，企业实现了服务时间与空间的无限延展、会员数据的集中管理与智能应用、营销活动的精准触达与高效转化。

作为医药零售的头部企业，重庆医药（集团）股份有限公司（简称“重药集团”）前身是成立于1950年的中国医药公司西南区公司，服务于医药全产业链，同时从事医药研发（MAH）、医疗器械生产，并投资参与医药工业。重药集团拥有全级次分、子公司200余家，正在从传统的配送商业企业向“互联网+医药”融合型现代医药企业转型。

随着CRM会员系统的使用时间拉长，其底层的传统数据库逐渐难以满足复杂数据的高效处理需求。面对海量交易和多维度行为数据的汇聚，重药集团CRM会员系统亟需采用具备高可用、强一致、可扩展特性的数据库。经过对比三款国产分布式数据库，重药集团选择OceanBase，最终实现系统稳定运行、复杂场景实时分析、查询效率提升25倍、存储空间节约60%。

此次重药集团CRM系统的数据库升级不仅提升了用户体验与品牌忠诚度，也为后续集团构建高性能、高可用的“集团级数字化运营中枢”提供了明确的业务需求与数据基础，构建可扩展、可复制、可监管的集团化运营体系。

医药零售商业模式变革，CRM系统实现全渠道协同

随着消费者行为的数字化转型和健康需求的持续升级，医药零售行业正经历深刻的商业模式变革。传统药店“有啥卖啥”的经营逻辑，逐步向“顾客需要什么”的逻辑转变，除了提供到店服务外，还支持线上服务，比如通过企业微信、公众号等渠道建立长期沟通机制。微商城代客下单、在线解答疑问等。

为构建以专业化服务为基础的顾客信任体系，医药企业建立了完整的会员服务体系——CRM 会员系统，以实现绑定多重会员信息、建立精准的会员标签画像，为会员提供更多的服务和营销。通过数据驱动决策的专业化服务能力提升来提高企业在行业内的竞争力，实现增收。

如图1 所示，CRM 会员系统可以实现线上、线下全渠道协同，支持会员档案统一、标签体系完善、自动触发机制、店员触达赋能、社群营销等关键功能。完成顾客到店/线上购药 → 完成交易 → 数据沉淀至 CRM → 触发服务与营销 → 二次消费 → 再次触达，实现“交易—服务—再交易”的正向循环。

图1 CRM会员系统实现线上、线下全渠道协同

为实现一体化管理需求，构建CRM会员系统

重药集团CRM会员系统的搭建背景，源自于其各子公司会员管理分散，系统缺乏统一规划，导致数据难沉淀、服务差异大、运营难复制，且缺乏实时监控，难以支撑决策。

为实现一体化管理，重药集团CRM会员系统分阶段建设。第一阶段完成会员营销平台的底座建设，打造集团化、标准化、数据化运营基础，核心目标如下。

• 搭建集团化会员运营平台。现集团—子公司—门店的一体化管理，打通组织架构与业务链路，确保会员在不同层级和渠道中都能获得一致的服务体验。
• 统一的会员运营服务体系。构建覆盖会员管理、营销活动、服务交付的标准化流程，减少分散运作带来的效率损耗，提升整体运营协同能力。
• 可快速复制标准化服务能力。形成可落地的服务模板和运营机制，帮助新业务和子公司快速复制成熟经验，缩短建设周期，提升推广效率。
• 实现经营数据统一分析。沉淀完整的数据资产，打破信息孤岛，实现对会员、门店、区域的多维度统一分析，为企业战略决策与合规审计提供有力支撑。

在上述目标指导下，我们做了三个核心举措：

• 联合集团会员中心，推进一体化进程。覆盖集团全品牌及线上会员，实现线上和线下会员统一运营和全域价值管理（见图2）。
• 构建多层级组织架构视角报表。支持集团、品牌、门店的权限管理，权限灵活配置，便于集团总部进行跨品牌的数据报表分析。
• 集团统一下达任务。集团可向各品牌下发销售任务、患者教育活动任务及拉新任务，实现集团任务统一管理与执行监督。

图2 集团会员同意运营架构

我们计划以集团内个别区域公司为试点，试行以上举措，若成功，则进行全面推广。推广成功后，重药集团会员运营平台将实现从“单一业务系统”向“集团级数字化运营中枢”演进。依托统一的技术底座与标准化流程，平台不仅实现对多家子公司、多个品牌的全面接入，更构建起可扩展、可复制、可监管的集团化运营体系。

此外，为实现全渠道会员统一运营，平台通过整合分散在各系统中的数据，构建统一、动态、多维度的会员标签画像体系（见图3），支撑精细化运营决策。

图3 多维度会员标签画像体系

通过会员系统精准化的服务来反哺我们的线上和线下的会员营销和服务，实现线上精准营销、个性化推荐、好物推送、会员关怀，线下关联用药建议、慢病管理提醒、店员主动触达等，提升营销转化率，增强客户粘性，实现“数据驱动服务”的闭环。

精细化会员服务，带来海量数据的查询、存储难题

然而，随着集团化会员运营平台的推进，精细化服务模式持续深化，导致用户数据规模呈指数级增长，显著提升了系统的查询与存储复杂性。

• 会员量：突破千万级，覆盖多个品牌及区域公司。
• 交易数据量：达到亿级，涵盖线上线下购药、用券、复购等行为。
• 用户行为类数据：包括商品浏览、搜索、加购等，总量亦达千万级以上。

这些数据来源于线上商城、私域平台、公众号等多个渠道，经标签体系整合后，用于构建立体化的会员画像，支撑精准营销与双向引流。

但数据体量大、类型多样、实时性要求高，对数据库的高并发读写能力、存储扩展性与查询性能提出严峻考验。面对千万级会员、亿级交易和多维度行为数据的汇聚，传统数据库难以满足高效处理需求，亟需采用具备高可用、强一致、可扩展特性的分布式数据库系统进行支撑。

CRM会员系统数据库升级，应对千万级数据处理难题

传统数据库的技术瓶颈制约业务发展

重药集团会员服务平台的规模化发展，使系统数据总量迅速增长至千万级、数十 TB 存储规模，传统关系型数据库在支撑精细化会员运营场景时，暴露出四大核心挑战。

• 性能：百万大表 InnoDB 在高并发读写及复杂查询场景下，性能显著下降，无法满足业务需求，且有事务访问，无法通过拆分提升性能。同时，业务强依赖事务一致性，无法通过拆分提升性能。
• 效率：核心归档由于业务需求，需要保留大量数据（数十 TB），会造成 DDL 周期长，延迟业务上线时间。
• 成本：随着企业数量增多、历年数据累积，存储成本将越来越高。
• 及时性：在各种场景下，对应数据处理的及时性需求越来越强。

上述技术挑战不乏真实业务案例。

例 1：某大型连锁店，以满足信创要求为前提进行性能保障

如今国家对信息技术应用创新（简称“信创”）的要求日益严格，特别是在国有企业中，系统必须符合相关标准才能上线。为了响应这一趋势，我们严格按照信创目录选择数据库产品，并对其进行了全面的业务场景适配与性能验证。

• 数据准备：会员卡 9950万+、订单 1 亿 9980万+。
• 验证数据库：OceanBase 数据库、某数据库1、某数据库2。
• 验证功能：报表 14 项内容、高级筛选 8 项内容。
• 参考标准：报表查询小于 20s、静态化数据小于 60s、高级筛选小于 15s。

测试结果如图4所示。OceanBase 在所有测试项中均显著优于其他两个国产数据库，在报表查询、高级筛选、静态化数据三个场景的性能表现都远超预期：

• 报表查询小于 7s，平均提速 78 倍以上。
• 高级筛选响应高级筛选小于 1s，速度提升 200–700 倍。
• 静态化数据静态化数据小于 46s，效率提升 6.7 倍以上。

图4 OceanBase 数据库、某数据库1、某数据库2的测试结果

在严格遵循国家信创要求的前提下，OceanBase 不仅完全满足合规性准入条件，更在百亿级数据规模下的复杂查询与批量处理场景中展现出卓越性能，远超同类国产数据库产品。基于此，我们总结了三个数据库的性能数据，向客户提交了一份详细的分析报告。

例 2：连锁会员、订单交易数据量增长迅速，实时性查询瓶颈

除了信创需求外，客户对业务的实时性、及时性要求也越来越高。过去，企业主要依赖 BI 工具进行周期性报表生成，可容忍数小时甚至数天的数据延迟。然而，随着营销策略向精准触达和即时响应演进，业务人员需要在高价值客户识别、复购提醒触发、定向营销投放、健康知识推荐等场景中获取近实时数据支持。为实现精准服务，运营人员经常需要基于会员信息、会员属性、历史消费、会员标签、商品集合等多个维度进行多维组合筛选，由于关联维度过多，可能会出现查询失败、查询时间过长、范围跨度受限、复杂查询无法支持等问题，显然，这些问题是我们服务的客户无法接受的。

例 3：海量业务数据，系统可用性与存储成本难平衡

连锁医药企业会员体系的不断扩展和数字化运营的深入，必然会带来业务数据量的指数级增长，海量数据带来的高存储成本成为制约系统可持续发展的关键瓶颈之一。

• 用户数据：累计会员数量突破千万级（>1000万）。
• 交易流水：日均订单量达百万级，历史累计超过亿级（>1亿条）。
• 用户行为数据：包括浏览、搜索、加购、收藏等行为记录，总量亦达千万级以上。

单个业务数据库实例空间占用已达到 N 个 TB 级别，且随时间推移呈线性增长。随着客户数量增加和业务持续扩张，业务数据库实例的空间占用迅速攀升至数十TB甚至上百TB级别，这些数据不仅用于支撑日常业务运行，还需长期保留以满足合规审计、精准营销、客户画像构建等需求。企业面临保障性能与可用性的前提下降低存储成本的难题。

因此，引入具备高效数据压缩、自动冷热分层、弹性扩展能力的新一代分布式数据库，是实现“数据价值最大化、存储成本最小化”的必然选择。

数据库技术引入，支撑海量交易数据的高效处理

综合业务需求与传统数据库的技术瓶颈考虑，我们需要替换传统数据库，升级为高性能、稳定性强、成本低、 HTAP 一体化的分布式数据库。

自 2023 年起，我们开始系统性地评估并引入 OceanBase，历经技术认知、多轮测试、工具链验证、SaaS 级试点上线等关键阶段（见图5），最终成功应用于重药集团会员管理平台。

图5 上线OceanBase的关键阶段

1.技术引入与评估阶段（2023年）

测试重点包括三部分。

其一，日常抖动测试。在对 OceanBase 初期测试时，我们首先进行了业务压力测试。低峰期业务配合100%模拟线上流量直接发压，高达4轮的压力测试，每次持续 3 小时以上。

其二，扩容/缩容测试。在业务流量低时进行相关操作验证。为了验证是否存在小概率事件，进行了为期一周的脚本自动扩、缩容操作以观察其稳定性。

其三，Add Index 测试。与扩容、缩容相仿，基于业务流量对1T大表进行多达几十次的add index操作，观察延迟情况。

2.SaaS 产品试点上线（2023 年 12 月）

在完成全面技术验证后，我司将 OceanBase 应用于内部 SaaS 类产品中，作为首个生产级试点场景。该阶段实现了：

• 数据库稳定运行于真实业务环境中。
• 验证了迁移、运维、监控等全生命周期管理能力。
• 积累了宝贵的实战经验，为后续客户项目打下坚实基础。

3.重药集团项目正式上线（2025 年 4 月）

基于前期充分验证与试点成果，我们于 2025 年 4 月正式启动重药集团会员管理平台项目，OceanBase 正式投入生产使用，支撑海量交易数据的高效处理。

会员服务平台“新面貌”：稳定、高性能、低成本

构建标准化数据链路，稳定、高效处理海量数据

目前，OceanBase 主要支撑重药集团会员服务平台的分析型业务场景，支撑高并发、多维度的会员数据查询、标签计算、报表生成及精准营销决策。其核心价值体现在：高效处理海量历史数据、支持复杂实时分析、保障查询性能与系统稳定性。

整个数据链路遵循“源系统 → CRM 中转清洗 → OceanBase 分析库”的三层架构，如图6所示。

图6 会员服务平台的数据分析链路

数据来源（源系统）包括POS 订单数据、各渠道会员信息、组织人员数据、会员标签数据、档案测量数据、全部商品主数据。

• 中转与清洗层（CRM 系统）：所有原始数据通过定时抽取或实时接入方式进入 CRM 系统，进行统一的数据清洗、去重、合并与标准化处理。关键处理策略包括历史数据清洗、订单数据合并、积分逻辑处理、会员标签动态更新、消费行为计算、活跃度模型计算。
• 目标存储与分析层（OceanBase 分析库）：清洗后的数据通过同步机制实时或定时写入 OceanBase 分析库；并分为原始数据表、静态化处理表、日表/月表、报表中间表。

通过构建“源数据 → CRM 清洗 → OceanBase 分析库”的标准化数据链路，实现了多源异构数据的统一整合、复杂分析场景的高性能响应、业务数据的长期留存与高效利用。

会员精准筛选复杂场景，查询效率提升 25.7 倍

在重药集团会员服务平台的实际运营中，多维度组合筛选（见图7）是支撑精细化营销与客户管理的核心功能。对于数据库而言，该功能是典型的复杂查询场景，用户需同时基于多个维度进行精确匹配，查询通常涉及多表关联、大量过滤条件和聚合计算，非常考验数据库的执行效率。我们通过开启 OceanBase 的列存模式（Columnar Storage），将原本传统数据库MySQL 的响应时间从 18 秒缩短至 0.7 秒，性能提升达 25.7 倍，满足业务对“实时圈选、即时触达”的严苛需求，显著提升了系统整体吞吐量与用户体验。

图7 会员服务平台多维度组合筛选

数据存储空间省 60%，有效降低存储成本压力

OceanBase 将全量数据划分为两个部分进行管理：一是增量数据（Memtable），即实时写入内存中的热数据，支持快速读写；二是基线数据（静态数据），即经过合并与持久化后的冷数据，存储于磁盘。

对于静态数据，OceanBase 采用高效的压缩算法，对列式存储的数据进行深度压缩，显著减少磁盘 I/O 和存储开销。例如，当原始数据总量为 4TB 时，MySQL 需要完整保留所有数据，存储空间占用为 4TB；而 OceanBase 通过对静态数据进行高压缩处理，仅需 1.5TB 即可承载相同规模的数据。

在重药集团会员服务平台的实际部署中，OceanBase 通过其先进的列式存储引擎与高效压缩算法，显著降低了数据存储空间占用，在同等业务数据规模下实现了 60% 以上的存储空间节约，有效缓解了海量数据带来的存储成本压力。

面向未来，持续推进 OceanBase 的深度集成与价值释放

随着 OceanBase 在重药集团会员服务平台的成功落地，我们对其在更广泛业务领域和客户群体中的应用充满信心。面向 2026 年及未来，我们将围绕场景拓展、客户推广、技术融合与产品适配四大方向，持续推进 OceanBase 的深度集成与价值释放。

应用于更多业务场景与产品

当前，OceanBase 已稳定支撑重药集团会员管理平台的复杂分析型业务（如精准筛选、标签计算、报表生成）。订单处理中心和运营诊断产品也在生产环境开始使用OceanBase，下一步，我们将推动其全面融入日常运营服务场景，包括：实时会员服务、营销活动执行、AI 智能推荐等业务场景。

另外，我们将逐步将 OceanBase 适配至更多内部产品，包括商品主数据管理、患者健康管理平台、智能补货与供应链协同系统，构建以 OceanBase 为核心的统一、弹性、智能的企业级数据基础设施。

向业内客户推荐

在国家信创政策与企业降本增效双重驱动下，我们已将 OceanBase 作为高并发、大数据量、强一致性要求场景下的首选数据库，并向行业客户积极推广。截至目前，已在以下大型医药企业成功落地：扬子江药业集团、鹭燕医学、重药集团、上海医药、国大药房。未来，我们将继续优先推荐 OceanBase 作为会员服务、订单中心等关键系统的数据库底座，助力更多企业完成安全、高效、低成本的国产化替代。

交流开发，沉淀运维经验

为持续提升团队与客户的 OceanBase 应用能力，我们计划定期组织专题培训、参与社区技术沙龙、共建问题解决机制、定期组织数据库培训及实战分享会议，探讨并解决遇到的问题，争取打造一支“懂业务、精技术、能落地”的复合型数据库应用团队。

未来，我们将携手更多合作伙伴，共同探索“数据库 + AI + 行业场景”的创新路径，为医药健康行业的高质量发展注入新动能。