得物OceanBase数据库落地实践技术解析与经验总结

一、背景

得物平台在潮流圈的地位早已深入人心。作为集正品潮流电商与潮流生活社区于一体的新一代生活方式平台，其业务场景的复杂程度以及对用户体验的极致追求，对底层数据库的运维与选型提出了极高的要求。

先来看整体情况。目前得物在线的数据库服务品类非常丰富：从我们熟悉的MySQL、TiDB，到MongoDB、HBase、DuckDB，再到ClickHouse/StarRocks、向量数据库，可谓“十八般武艺”样样齐全。这些数据库分别支撑着核心交易、运营分析、AI算法、社区等多元化的业务场景。

然而，多品类数据库虽然功能强大，但带来的运维复杂度与研发选型难度也成正比。架构复杂、资源成本高，是绕不开的痛点。同时，业务对数据库的性能、可用性和成本的要求，一个比一个高。在持续的调研与选型中，OceanBase这款多模数据库逐渐进入我们的视野，特别是其4.x版本，引起了DBA团队和研发团队的极大兴趣。

二、多模数据库 OceanBase 选型

OceanBase基于Paxos协议实现多副本强同步，支持从单机房到三地五中心等多种部署模式。这意味着任意副本都能秒级完成故障接管，实现RPO=0、RTO小于8秒。更关键的是，它原生支持多活与单元化部署，可实现跨地域同时写入、跨云灵活扩展，且毫秒级的同步延迟能保障数据一致性。在当前业务对所有可用区级高可用需求日益迫切的大背景下，OceanBase的多活架构，确实为我们从容灾到合规提供了一套全方位的高可用保障方案。

总体来看，OceanBase的能力与公司业务场景和痛点高度匹配，主要体现在以下几个方面：

灵活架构： 单机分布式一体化能力，让零散的MySQL小业务可以从最小规模起步，随业务增长无缝扩展至分布式集群。同时，通过多租户机制按需分配资源，正好解决了过去小业务整合难、扩展需迁移切换的痛点，实现了成本与弹性的最优平衡。

降低成本： 通过分层转储、增量合并和两层压缩技术，在保障高性能写入的同时，能大幅压缩存储成本（降幅可达40%以上），针对性解决了MySQL类业务存储成本高、写放大严重的痛点。具体来说：

• 分层转储： 内存数据经过L0→L1→L2三级SSTable逐层下沉，有效避免内存阻塞，保障写入的持续性。
• 增量合并： 只合并被修改的热点宏块，未修改的数据直接复用，有效减少合并开销，降低写放大。
• 两层压缩： 先以行列混存编码对结构化数据做字典压缩，再用通用算法进行二次压缩。这种方式在性能与压缩率之间做到了灵活平衡，大幅削减了存储成本。

高可用： 原生多活架构基于Paxos协议，支持任意副本秒级故障接管（RPO=0，RTO<8s）及跨地域多活写入，完美满足业务对可用区级高可用的严苛要求，解决了容灾切换慢、异地数据一致性弱、合规部署复杂等痛点。

为了满足业务AP要求，我们专门增加了DuckDB、HBase等品类进行对比验证。 在主要以TP/AP场景进行落地、承接MySQL、StarRocks等组件业务的同时，我们在某业务的生产环境高频聚合SQL场景下进行了测试。结果令人印象深刻：OceanBase综合性能优于DuckDB（4:2胜出），其中JOIN聚合查询领先81.5倍，这充分体现了其行列混存架构的优势。当然，DuckDB在纯列存大列表过滤场景下略有优势（1.3x）。除了DuckDB，我们还初步进行了与HBase的性能对比，但结果不如预期（主要是因为磁盘类型导致IO能力存在差距——OceanBase部署时使用同盘环境，空跑时磁盘IO延迟在2~3ms。如果使用SSD磁盘进行分盘部署，性能会有明显提升）。后续我们会跟进新版本优化，并和社区共建，持续进行调研及方案优化。详细测试验证数据如下：

三、落地实践

得物在数据库选型上向来慎重，对稳定性的要求极高。最近随着多云、AI、向量等多种战略目标的制定，OceanBase在稳定性、性能、成本等方面的优势逐步凸显，基于它的验证和推广落地工作也随之展开。

DBA 验证评估

在实际业务推广之前，DBA团队先进行了详细的压测验证。基于不同的并发度和行列存储场景，OceanBase都表现出了不错的性能水平。

• 高并发支持: 在不同的读写模式下，OceanBase都展现了优异的吞吐量（TPS和QPS）。比如在200并发下，行列混存模式的TPS值高达13076.91，显示出其优秀的处理能力，非常适合高并发的在线事务处理（OLTP）场景。
• 高效的读写性能: 在只读和只写模式下，行存表和列存表的性能表现都相当突出。在100 QPS情况下，OceanBase的TPS值能达到7230左右，表明它能够高效处理大量查询请求，适合大规模数据的分析需求（OLAP）。
• 资源利用率: CPU使用率在不同负载下表现合理。例如在200并发下，行存表的CPU使用率为63.73%，显示出高负荷下良好的资源分配能力，确保了系统的稳定性和可靠性。
• 灵活的存储引擎: OceanBase支持行存、列存及混合存储，能够根据不同的业务需求和数据特性选择最优的存储模式，从而提升处理效率。

压测和结论可以参考下图。

复杂查询一直是数据库的验证重点。验证过程中，DBA团队还深度对比了MySQL和OceanBase在复杂查询场景下的表现，比如聚合查询、分页排序查询等。以下面的SQL1和SQL2为例，它们分别用于获取某一周期内SQL审核的执行情况统计，以及分页排序查询的明细情况：

SQL1

select count(distinct(a.field_A)) as count, SUM(CASE WHEN b.field_BIN (0,1,3,7) THEN 1 ELSE 0 END) AStotal_cnt, SUM(CASE WHEN b.field_BIN (0) THEN 1 ELSE 0 END) AStodo, SUM(CASE WHEN b.field_BIN (1,7) THEN 1 ELSE 0 END) ASdone, SUM(CASE WHEN b.field_BIN (3) THEN 1 ELSE 0 END) ASauto from table_A a join table_B b on a.field_A = b.field_C and b.field_B IN (0,1,3,7) and b.create_time >= {START_TS} and b.create_time < {END_TS} where a.is_deleted in (0)

SQL2

select a.*, SUM(CASE WHEN b.field_BIN (0,1,3,7) THEN 1 ELSE 0 END) AS totalCount , SUM(CASE WHEN b.field_BIN (0) THEN 1 ELSE 0 END) ASamount, SUM(CASE WHEN b.field_BIN (1,7) THEN 1 ELSE 0 END) ASdone, SUM(CASE WHEN b.field_BIN (3) THEN 1 ELSE 0 END) ASauto, sum(IF( b.create_time >= {START_TS} and b.field_B = 0, 1, 0)) as amount_current from table_A a join table_B b on a.field_A = b.field_C and b.field_B IN (0,1,3,7) and b.create_time >= {START_TS} and b.create_time < {END_TS} where a.is_deleted in (0) group by field_A order by amount desc limit 0, 10

这两条是典型的复杂查询SQL。在MySQL中，即使执行计划调到了最优，耗时也需要1.3秒和3.9秒。而在OceanBase中，我们用相同的SQL进行测试，并通过逐步优化进行对比，性能提升效果非常明显： 通过5个维度的渐进式优化，SQL2的执行时间从4秒降至0.02秒，整体性能提升约200倍；SQL1从1.3秒降至0.01秒，提升约130倍。 下图详细介绍了这几项优化的思路：

OceanBase通过计划缓存复用、分区裁剪减少扫描、列存索引破最左前缀瓶颈、多核并行执行提速、Hint指定算法这五大特性，从“计划生成→数据扫描→索引选择→执行调度→算法决策”全链路压缩了复杂SQL的执行开销。

值得一提的是，OceanBase提供了非常丰富的执行计划Hint，让DBA可以在SQL中直接指定算法，精准干预执行计划的生成。 这个Hint功能不是日常调优的工具，而是优化器出现偏差时的兜底干预能力——当生产SQL突发劣化、统计信息失准，或者关联条件复杂导致优化器选错算法时，DBA可以直接在SQL中指定算法来纠正执行计划，无需改写SQL本身。这个能力是MySQL不具备的。

下图是团队基于OceanBase SQL查询计划和Hint功能的详细拆解和分析。

业务 POC

在正式推广业务之前，OceanBase先在DBA团队内部进行了试点，主要针对DBA内部的AP报表业务。结果相当喜人：SQL执行速度平均提升了10~30倍。要知道，DBA的报表业务之前一直基于MySQL，存在复杂查询耗时过长的问题，大部分查询超过1秒，甚至有些超过30秒才能执行成功，同时还伴随着资源互斥、锁等待等运维问题。

DBA内部报表业务整体迁移到OceanBase后，利用其物化视图、行列混存等特性，SQL执行速度平均提升了10~30倍。同时，通过混沌工程，我们验证了OceanBase在各异常场景下的止血手段，并形成了运维SOP，积累了宝贵的OceanBase运维经验，极大地提振了DBA团队将OceanBase面向业务落地的信心。

第一个“吃螃蟹”的业务

在DBA内部尝试积累了实践经验后，我们对某业务团队的系统进行了综合评估。该团队共管理多套MySQL集群，总规模达百核CPU、存储量TB级，面临着以下业务痛点：

• TP & AP 混查，CPU 等告警频发： 普遍没有只读实例，同时存在大量复杂聚合查询，长期对TP业务查询造成较大资源挤占，CPU经常告警。
• 磁盘容量问题凸显： 部分AI相关的MySQL磁盘增长迅速，B+Tree架构下碎片化明显；大表较多，执行DDL所需预留的额外空间较大，磁盘成本压力显著。
• 资源分配不合理： QPS较低的实例较多，即使配置最低也存在资源浪费。
• 运维处理复杂： 存在大量空长事务及异常DML，常规管控平台无法快速排查。

基于这些切实痛点，DBA团队构建了全面的迁移计划，涵盖平台接入、资源规划、架构设计、集群配置、迁移变更等各个环节。整体的迁移流程图如下：

业务整体迁移完成后，数据库架构完成了升级，SQL平均耗时下降了88.3%，业务超时接口清零，总体成本降低了43%。

架构变得清晰简洁：从多套MySQL集群整合为一套OB集群，通过多租户实现隔离；仅仅三台主机就承载了整个团队的业务，同时兼顾了高可用和TP/AP业务的资源隔离。集群底层宿主机为云ECS实例，共三个Zone，分别部署在两个可用区。可用区A的两个Zone用于读写业务，可用区B的一个Zone用于只读业务。每个zone由若干计算节点组成。集群中还会预留出部分冗余CPU资源，当租户出现CPU告警时，这些冗余CPU可以秒级完成扩容。整体架构如下：

具体数据上，SQL平均耗时下降了88.3%，业务超时接口清零，性能提升8.6倍。聚合和范围查询的响应时间较MySQL降至1%以内。以某研发效能平台为例，AP相关SQL的平均耗时从6.87秒降至0.8秒，性能提升约8.6倍，耗时下降88%。详细数据如下：

成本收益也相当明显，相比MySQL总体下降43%，主要体现在存储方面。MySQL迁移到OceanBase后，压缩率达到了80%以上，简单字段场景下压缩比甚至可达10:1以上。在资源利用上，基于OceanBase特有的多租户PrimaryZone打散加CPU超卖技术，我们将集群ECS CPU利用率提高到了100%，远超MySQL主备架构50%的利用率。

第一个“大换血”的业务

在有了第一次业务经验后，数据库团队开始寻找新的“战机”。了解到另一个业务团队当前存在更切身的痛点：

• 传统 MySQL 架构： 业务库会在MySQL下游接入异构从库，用于业务B端的运营数据聚合查询。
• 多套异构数据库支撑业务： 运营B端原先完全走StarRocks；商家B端的大活动查询走StarRocks，小活动查询走MySQL，通过数据同步工具从MySQL异构同步到其他品类数据库。
• 业务分流痛点： 需要业务手动分流点查和聚合查询，但这种分流时常不准确，导致聚合查询走到MySQL影响业务的情况时有发生。
• 存储数据量大： StarRocks加MySQL占用了大量的存储空间，后续数据的一致性完全依赖同步工具保障。
• AP 查询性能急需优化： 虽然业务对部分组件进行了拆分以提升查询效率，但查询仍然存在提升空间。

经过全面的POC验证和测试后，OceanBase很好地解决了当前问题，特别是架构痛点。在承载MySQL业务的同时，它的压缩率和性能上都优于StarRocks。在与研发业务高效协作后，我们对当前架构进行了一次“大换血”，目前已经将StarRocks的部分流量切到OceanBase进行POC，运营B端已全部走OceanBase。整体效果超出了预期。

• 架构升级： 从原先的“MySQL + StarRocks”双链路+应用层手动分流，升级为OceanBase行列混存一体化架构。

• 消除异构： 消除了数据同步工具链路，数据从异步滞后变为实时可见。业务分流风险也被消除：消除了应用层手动分流，OceanBase内部自动路由点查和聚合查询，彻底杜绝了分流错误影响业务的风险。
• 存储降本： 存储从数TB级降至百GB级，较MySQL压缩率达94%，较StarRocks压缩率达30%。
• SQL 提效显著： OceanBase的聚合和范围查询响应时间，较StarRocks平均降低65%（10%-90%），较MySQL降至1%以内；高QPS点查与MySQL互有优势，且显著优于StarRocks。在实时性方面，OceanBase查询完全实时无延迟，而StarRocks存在秒级的写入到读取延迟。

更多迁移收益和对比数据可以参考下图。

四、落地遇到的问题及解决方案

目前，报表业务及部分TP业务已经完成了OceanBase迁移。虽然带来了性能和成本的双重好处，但迁移过程也遇到了不少问题和挑战，除了性能问题，还包括兼容性等问题。

迁移挑战

在OceanBase最新的LTS版本4.4.2实践中，需要特别注意它与MySQL在SQL语法、事务隔离级别、自增列实现等方面的差异。我们需要通过业务适配或参数调整来解决这些兼容性问题。在性能方面，通过绑定执行计划、错峰刷新物化视图等手段，我们有效解决了AP查询走偏、物化视图卡住等瓶颈。

更重要的一点是，从传统数据库（如MySQL）迁移到OceanBase时，引入新特性需要特别谨慎。新特性新功能仍在完善中，不可避免会有些场景限制甚至功能互斥。比如我们遇到的实时物化视图与DDL冲突问题。在引入新功能时，必须建立严格的准入审核、监控告警和故障演练机制。上线前应全面评估，避免对业务造成不必要的影响。

在保障业务稳定性、可用性的前提下，通过迁移OceanBase来获得性能和成本的双重提升，是值得的。但在接下来进入深水区、推广到核心业务时，还会有不少切实需要解决的问题，需要持续沉淀和总结经验。

以下是迁移过程中遇到的问题和总结，比如实时物化视图和DDL相冲突、SQL语法不兼容、用户连接字符串被转义等：

运维体系转型

运维模式从原来的实例级转向了租户级加集群级，在监控、备份和容量规划上，全面适配OceanBase的分布式特性。工具链也相应升级，从云MySQL的“控制台+数据同步工具+数据库诊断工具+自研DBA管控平台”，切换为OceanBase的“OCP+OMS+diag+ODC/自研DBA管控平台”体系，实现了管控、迁移、诊断与开发的全链路覆盖。

DBA团队还对OceanBase的知识框架进行了系统梳理：

团队能力建设

通过“基础培训—深度实践—认证培养”三层路径，DBA团队系统地提升了从OceanBase架构原理到性能调优的实战能力。通过达成OBCP认证目标，我们已经建立了OceanBase系统化知识体系框架，训练出了OceanBase专项运维人员。同时，基于技术分享、项目实战带教和内部知识库等途径，形成了“分享—实战—沉淀”的知识转移闭环，持续提升团队能力。

五、未来规划与架构演进

未来，OceanBase在团队中的规划将逐步进入核心区和深水区。同时，我们将从成本、性能、效率、AI智能、AI Agent底座等多维度为业务赋能提效。

大致分三个阶段推进：短期（0.5-1年）夯实基础，建立技术支撑、标准SOP和应急演练体系；中期（1-2年）引入OBKV落地业务场景、上线向量检索，完成多云多可用区建设并引流核心新增业务；长期（2-3年）建成统一多模数据平台，覆盖90%的数据场景。

围绕AIOps方向，我们将从异常检测、根因分析、容量预测到自动调参，构建智能运维全链路能力，实现性能预警、故障自愈和资源规划的自动化与智能化。以OceanBase迁移为契机，实现成本、敏捷性、创新与风险四大收益：3年内TCO降低50%，业务上线准备缩短至1天内，覆盖实时分析与个性化推荐等新场景，并达成秒级故障恢复与数据零丢失。我们将持续推动OceanBase的全面落地，关注并调研OceanBase LakeBase等面向AI底座的数据库产品。团队将致力于构建面向未来、面向AI Agent的多模多态数据基础设施，解决业务当前痛点，为业务创新提供坚实的数据底座支撑。