怎么避免无意义劳动？奇富科技摈弃分库分表后，代码改造成本节省90%

作者：贾建龙，奇富科技数据库负责人
奇富科技原名#360数科，成立于2016年，并于2018年在纳斯达克上市（QFIN）、2022年在香港挂牌上市{S(03660)}，2023年2月正式更名为“奇富科技”。公司业务规模庞大，服务金融机构165家，注册用户数2.76亿，授信用户数6020万，2024年营业净利润60多亿。在AI浪潮的席卷下，公司在2025年启动了围绕 AI 的全新战略，致力于打造 AI 驱动的金融科技平台。
奇富科技的数据库种类繁多，包含MySQL、Redis、Pika、Elasticsearch、MongoDB、InfluxDB、PostgreSQL、Oracle、TiDB等。为了简化技术栈，以及解决现有数据库使用痛点，奇富科技数据库团队在2024年引入OceanBase替代部分MySQL与TiDB，实现了代码改造成本、存储与硬件成本的大幅缩减，以及性能、稳定性、扩展性等多方面的技术升级。本文分享奇富科技在多个场景的数据库痛点，以及OceanBase落地实践。
传统数据库 VS 分布式数据库

随着业务的不断扩展和数据的快速增长，奇富科技使用的传统的数据库在数据存储、数据处理、数据分析方面逐渐遇到诸多挑战，其扩展性和性能也很难满足业务需求。
首先，传统数据库受限于单节点存储和扩容的一些时效性，在业务数据量较大时难以满足存储需求。当前主流的传统数据库容量一般在 3TB 左右，当数据量超过数据库容量，通常会采用一拆多、多拆多的方式，导致架构变得复杂。如果是初始拆分，业务可能面临较大的改造。相较之下，分布式数据库的容量没有限制，理论上可以做到无限扩展，且扩展时无需改造业务。
其次，传统数据库受限于单机资源，单表大量写入也会存在一定的瓶颈，并且超过一定阈值后，会出现严重的延迟问题。分布式数据库可以通过分区的形式，将写压力打散到不同节点，扩展写能力，解决了单机写入的瓶颈问题。
此外，使用传统的开源数据库进行扩展时，往往需要适配中间件，需要DBA投入较多精力，包括事前的方案评审、验证，以及事中具体操作和事后观察。分布式数据库在扩容时，人工投入少，可以自动实现数据的重分布。
目前，奇富科技部分核心系统依然依赖 #MySQL 作为主要存储，但传统单库架构逐渐暴露出一系列瓶颈和隐患。在实践中遇到的典型问题如下。

• MySQL 单库写入压力：个别消费行为业务场景的库，写入压力日益增大，MySQL 无法承担压力，负载居高不下。
  
• 分库分表：当业务 MySQL 库需拆库分表时，代码改造成本高。
  
• 接口限流：某些后端场景需要调用大量接口。
  
• 主从同步延迟：业务写入量大时，主从同步延迟较高。
  
• 数据归档需求：针对一些合规要求，需要长期存放归档数据，且偶有人为查询的需求。
  
• 报表业务查询性能：针对某些报表业务查询的性能无法满足业务需求。
  
• 存储成本：数据存储成本高。
  

落地实践：从小场景验证到上线6个集群

为了突破现有瓶颈，提升系统的整体性能与稳定性，同时简化技术栈，降低 DBA 的学习和运维成本，奇富科技数据库团队决定选型一款功能较为完善的数据库，替换其他数据库。
对于分布式数据库的技术选型，主要考虑如下几点：稳定性、性能、兼容性、扩展性、生态、社区活跃度、国产化支持、成本。经过深入调研和评估，奇富科技决定引入 #OceanBase。
落地历程

如图1 所示，2023年，奇富科技开始接触 OceanBase，经过考察后，在2024年启动 OceanBase 的应用落地。在测试OceanBase 的架构设计、功能特性、性能指标等均符合需求后，先在公司内部的两个场景中开始真实环境的验证：一个场景是使用 OceanBase 替换 #TiDB，解决 TiDB 对业务监控的抖动和误告警问题，另一个场景是归档业务，实践证明 OceanBase 最高能达到80%左右的压缩率。

图1 奇富科技落地OceanBase历程
在内部推广阶段取得显著成效后，公司非核心业务率先上线OceanBase，运维工作同步完成内部适配，虽尚未实现完全平台化，但必须先将原有人工操作全部脚本化、自动化，工单化亦以脚本形式提供对接能力。同时，下游数仓也需要调整同步链路，原先仅需拉取 MySQL Binlog，现在需要新增对 OceanBase 的增量数据抽取。
八月，数据库团队选取了一批与实时业务相关、重要性较高却非订单核心的场景，如外购平台、行为日志等，作为第二批迁移与推广对象。迁移工作完成后，随即启动与OceanBase运维平台的对接：针对用户频繁申请实例与数据库、工单量大的情况，为避免影响其他运维工作，数据库团队已将此类需求全部转入工单化流程，实现自动化处理。
压测数据

奇富科技内部对接各个业务使用的 MySQL 有几百多套，提供不同规格的套餐，供各业务线按需申请。为确保 OceanBase 上线后沿用同一管理模式，数据库团队预先制定了标准化租户套餐，业务侧仅需在工单系统内勾选所需套餐，即可自动完成租户创建，无需沟通租户的资源详情，若套餐外有特殊需求，可另行提交申请。
数据库团队针对每一种租户套餐的资源规格进行了性能压测，详细数据见图2，当然该数据仅用于内部选型与容量规划，并非 OceanBase 的极限性能。

图2 不同租户套餐的性能压测数据
技术架构

奇富科技的数据库架构整体分为五层（见图3）。

• 业务服务层：所有业务服务（含 App、Web 及各接口服务）均通过统一访问层接入数据库。
  
• MySQL 服务层：业务流量先抵达 LVS 集群，由 LVS 提供虚拟 VIP，再转发至 MySQL 。MySQL 采用主从架构，用 Orchestrator 实现高可用。一套 Orchestrator 可同时监控几十套 MySQL 以实现故障自动切换。
  
• DTS 服务层：数据归档同步工具使用mysqldump或其他数据迁移工具，数据实时同步工具使用 OMS。
  
• OceanBase 集群层：为兼容现有访问模式并预防 OBProxy 单点故障，OceanBase 集群层同样前置了一套 IVS 集群。
  
• 数仓层：数仓通过全量拉取数据和 Binlog 订阅方式获取数据，原来通过 Binlog 从 MySQL 抽取数据；切换到 OceanBase 后，部署了 OceanBase Binlog 集群，确保下游数仓链路的正常运行。
  

图3 奇富科技的数据库架构
在该架构中，OceanBase 集群层的机型（内部使用）都以物理机为主，存储为 NVME SSD。截至2025年8月，内部共计6个 OceanBase 集群，50+节点数，总存储容量已达到 30TB+。按照业务重要性，我们规划了小集群和大集群两种 OceanBase 集群规模。

• 小集群：以业务部门为集群粒度，如产品、风控、运营、催收等业务各自独立部署一套小集群，确保部门间数据与资源隔离。
  
• 大集群：报表、业务监控、归档业务等对时效性要求不高、且无强业务耦合的场景，统一归入一套大集群集中部署，该集群规模可按需扩展至上百节点。
  

使用场景：四类典型技术场景与迁移经验

在 OceanBase 的落地过程中，数据库团队按照以下四类典型场景分批执行，现阶段均已完成上线。
1.数据归档。
基于 OceanBase 的高压缩能力，将 MySQL 中的冷数据，通过 OMS 或其他导入工具，定期归档到 OceanBase 中，释放存储空间，降低存储成本。
2.HTAP 场景。
采购平台的后端业务数据存储既有实时业务的读写操作、也有分析统计类的场景需求。该平台原本使用 TiDB，但因其稳定性与资源隔离无法满足业务月结高峰要求，采购平台整体迁移到了 OceanBase。
3.离线数据处理。
报表业务的离线数据来自 Excel、上游 MySQL 等多种数据源，大量数据滞留不好清理。并且有跑批需求，需要调用多个业务部门的数据接口，业务逻辑比较复杂，影响处理性能。
4.纯写场景。
用户行为数据写入 MySQL，写入量很大，业务侧无查询操作，少量人为查询。
下文将分享奇富客户在上几类场景中的迁移经验。
1.HTAP 场景——外采平台迁移

改造目的

• 性能和扩展性：TiDB 迁移至 OceanBase，以实现更好的性能和扩展性。
  
• 稳定性：TiDB 4.x版本经常出现性能抖动，无法满足外采平台对 HTAP 混合负载的稳定性要求。
  
• 统一技术栈：内部在逐步大面积使用 OceanBase，需要统一技术栈。
  
• 完善机房容灾架构：OceanBase 的金融级无损容灾及跨机房切换能力可补齐现有机房级容灾缺口。
  

改造方案

• 超过1000万行的大表进行分区改造。
  
• 对大表按月进行分区改造。
  
• 通过OMS 实现 TiDB 到 OceanBase 的数据迁移。
  
• 逐步切换业务读写流量至 OceanBase。
  
• 下游大数据团队平台适配。
  

成效

迁移完成后，整体存储成本降低25%、稳定性表现超预期，实现零抖动、统计类执行时间缩短30%。
不过在迁移过程中，也遇到一些小问题。

• 数据一致性问题。
  

问题分析： 唯一键约束导致部分数据在 OceanBase 中缺失（字段前后空格判定和 TiDB 不一致造成的）。
解决方案： 通过 SQL 验证确认问题，结合业务场景，变更唯一索引字段为联合字段；业务筛选可接受丢失的数据行。

• 字段默认值差异。
  

问题分析： decimal 类型字段在 OceanBase 中默认为 NULL，而在 TiDB 中默认为0.00。
解决方案： 对于业务无影响的话，可以忽略，有影响时可修改默认值为0.00。

• 性能调优问题。
  

问题分析： 并行度参数设置不当影响查询性能。
解决方案： 调整 parallel_min_scan_time_threshold参数(ms)，在业务实时查询与 AP 查询上得到最优。

• 参数配置问题。
  

问题分析：  OLTP 和 OLAP 场景参数需求不同。
解决方案：  针对不同业务场景分别设置相应的参数配置，如分析类查询和 TP 类查询采用不同的参数组合。
2.纯写场景——用户行为数据的迁移

原 MySQL 环境

用户行为数据场景为纯写入型场景，1.6 TB 数据空间，QPS 峰值达到 2w+。原本使用的 MySQL 是一主多从架构，跨机房部署，写入量大时，I/O 压力大，主从延迟高，且由于分库分表需要做大量的代码改造，投入成本过高。正好遇到 OceanBase 在内部推广的契机，于是用户行为数据的迁移便成为前期推广的用例。
迁移方案

前期使用 OMS 进行全量 + 增量同步，以及数据一致性校验。完成一致性校验后，业务停写，业务添加 OceanBase 写入，完成和 MySQL 的双写。持续双写一个月无异常后，业务确认 OceanBase 满足需求，于是下线 MySQL，只写入 OceanBase。OceanBase 运行至今，业务侧从未反馈存在抖动问题。
需要注意的是，原 MySQL 表结构未考虑分布式特性，迁往 OceanBase 后需要对大表增加分区，尽量结合业务场景选择分区字段或根据时间进行分区。另外，时间字段分区可能存在热点节点，严重情况下可考虑使用二级分区字段来平衡热点。
3.SQL 遇到的问题

数据库团队曾遇到两个SQL问题，一是DDL 添加字段，可能会导致 SQL 执行计划失效，全表扫描。二是查询 SQL 的原绑定执行计划失效，性能急剧下降，原本只需要3秒, 失效后变为300秒。对此，一种临时方案是在进行 DDL 增加字段操作之前，若出现 SQL 执行计划失效问题，可以先手动全量合并空间。但从长期来看，需要将 OceanBase 集群从 4.3.2 版本升级到 4.3.5 版本，可以彻底解决。
究其根本，导致SQL性能急剧下降的原因在于：userType 表被 OceanBase 的查询优化器进行了连接消除（join elimination），由于 outer join 主键连接的特性，优化器认为该表是冗余的并将其消除，所有包含 userType 表的 Hint 都因此失效，以至于查询执行计划发生了非预期的改变，导致性能大幅下降。
针对连接消除导致的性能问题，我们采用了三种优化方案。
优化方案一：控制核心表连接顺序使用。

• 使用 hint: /+LEADING(a e) use_hash/
  
• 效果：查询时间从300+秒降至48秒。
  

优化方案二：指定连接方式和索引。

• 使用 hint：/+leading(a e) use_nl(e) index(e idx_appl_no)/
  
• 效果：查询时间进一步降至8秒。
  

优化方案三：防止连接消除（最优方案）。

• 使用 hint：/+LEADING((a userType) e) index(e idx_appl_no) index(userType PRIMARY) NO_ELIMINATE_JOIN/
  
• 关键点：使用 NO_ELIMINATE_JOIN 阻止优化器消除 userType 表的连接。
  
• 效果：查询时间降至4秒，是所有方案中效果最好的。
  

在优化方案中，解决 SQL 性能问题的核心思路是：通过 NO_ELIMINATE_JOIN hint 强制保留原有的表连接关系，防止优化器过度优化导致的性能退化，最终将查询时间从300秒降低到了4秒。
4.OMS 工具遇到的问题

目前内部 OMS 集群节点共15+，涉及300+ 同步任务、4000+ 库表同步，不可避免地出现了一些问题。比如：

• 离线场景需要从上游 MySQL 同步数据，涉及到 100+ 库，库表数量众多、任务部署繁琐。
  
• OMS 元信息原本存储在 MySQL 中，随着任务数据量越来越大，MySQL 的存储面临很大压力。
  
• 涉及分库分表 DDL 操作，可能会引起表结构的不一致问题。
  

解决方案也比较简单：

• 通过工单化+接口+脚本，自动创建数据源，自动迁移，并记录原数据信息。
  
• OMS 数据源从 MySQL 改为到 OceanBase 存储。
  
• 后经与业务沟通，采用分库分表+视图的形式。
  

价值收益：降本增效零抖动

在应用OceanBase后，奇富科技在成本和技术方面均获得了超出预期的收益。
成本收益——多方面缩减成本

存储成本：OceanBase 的高压缩率可以直接降低存储成本，在归档业务引入 OceanBase 后，集群的数据量从 10TB 减少到 5TB，存储成本降低一半。
硬件成本：使用OceanBase替换 TiDB 后，也缩减了一些机器数量，整体缩减服务器超30台。
运维成本：OceanBase 的在线扩缩容相比其他数据库更加方便、快捷，极大节省了运维的人力成本。同时，OceanBase 提供了多种工具，如白屏管理工具 OCP、安装部署工具 OBD、数据迁移服务 OMS、诊断工具 obdiag 等，自动化程度高、人工介入少。值得一提的是，单节点引发的 RTO 时间极短，极大地降低了DBA 运维难度。
代码改造成本：得益于OceanBase独有的原生分布式数据库特性，此前业务因分库分表引起的代码改造成本降低90%。
技术收益——支撑业务更加给力

性能提升：OceanBase 作为原生分布式数据库，可以多节点并行处理复杂 SQL，大幅缩短了响应时间，显著提升性能。因此，相较于之前：

• 单机所能承载的流量也更大。
  
• 业务流量的骤增不会引发较大的性能波动，能够很好地承载突发流量。
  
• 对于离线查询的跑批任务，整体任务执行时间缩减40%。
  
• 用户行为记录业务的流量提升 30%，且抖动消除。
  

稳定性改进：OceanBase 具备金融级高可用能力，铸就了稳定性这一产品优势。OceanBase拥有较多核心技术用于故障判断，对比我们原来使用的 Orchestrator + MySQL 主从架构，不仅容灾能力更强，降低了故障率，提升了系统可用性，而且运维操作对业务几乎没有影响。上线 OceanBase 后，业务稳定性显著提高，能够承载更多的业务流量且不抖动，有效缩减了业务任务的执行时间。
扩展能力：OceanBase 支持在线扩缩容，且有 OCP 等白屏管理工具可实现白屏扩缩容操作。对于需要管理容量的场景，弹性伸缩非常便捷、有效增强了并发处理能力。
未来规划：广泛应用，统一技术栈

未来，奇富科技将从技术演进、业务支撑、团队建设、工具平台四个方面更深入、可持续地使用 OceanBase。
业务支撑：后续奇富科技将在更多场景接入 OceanBase 作为存储方案。在业务侧使用 OceanBase 的过程中，数据库团队将协助解决业务侧遇到的问题，持续提升使用体验。
技术演进：数据库团队会调研OceanBase的向量、KV 特性，满足越来越多的向量数据库的需求。目前，OceanBase在奇富科技内部的应用范围渐广，从运维角度而言，在满足技术要求的情况下，使用统一技术栈是最好的方案。
团队建设：奇富科技将进行OceanBase运维人才培养，并建设相关知识体系。一方面内部分组学习OceanBase，定期在公司内部进行围绕 OceanBase 的技术分享。另一方面，在学习过程中，做好内部针对 OceanBase 相关内容的知识沉淀，技术推广，累积运维经验。
工具平台：奇富科技计划将OceanBase运维工具与与内部管控平台打通，提升 OceanBase 应用生命周期管理的自动化程度。同时，完善运维事项，提升运维效率，比如 OMS 同步任务的固定巡检及任务合并。

最后为大家推荐这个 OceanBase 开源负责人老纪的公众号「老纪的技术唠嗑局」，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！
「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星✨吧！你的每一个Star，都是我们努力的动力。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！