一、背景
得物是全球领先的集正品潮流电商和潮流生活社区于一体的新一代潮流生活方式平台。复杂的业务场景和极致的用户体验追求，对数据库运维和选型提出了更高要求。
目前得物在线的数据库服务涵盖 MySQL、TiDB、MongoDB、HBase、DuckDB、ClickHouse / StarRocks、向量数据库等多品类，支撑核心交易、运营分析、AI 算法、社区等多业务场景。
多品类数据库面临运维复杂度高、研发选型难、架构复杂、资源成本高等运维问题。同时业务对数据库性能、可用性、成本要求逐步增高。在持续的数据库调研和选型中，OceanBase 作为多模数据库，逐步进入视野，特别是 4.x 版本引起了 DBA 团队和研发团队的极大兴趣。
二、多模数据库 OceanBase 选型
OceanBase 基于 Paxos 协议实现多副本强同步，支持单机房到三地五中心多种部署模式，任意副本秒级故障接管，RPO = 0，RTO < 8s。同时支持多活与单元化部署，实现跨地域同时写入、跨云灵活扩展，毫秒级同步延迟保障数据一致。在当前业务对可用区级高可用日益迫切的需求下，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 在稳定性、性能、成本等方面优势逐步凸显，基于 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.3s 和 3.9s。在 OceanBase 中对相同的 SQL 进行测试，并进行优化对比，性能提升效果明显： 通过 5 个维度的渐进式优化，将 SQL2 执行时间从 4s 降至 0.02s，整体性能提升约 200 倍；SQL1 从 1.3s 降至 0.01s，提升约 130 倍。 下图详细介绍这几项优化的思路：
OceanBase 通过计划缓存复用、分区裁剪减少扫描、列存索引破最左前缀瓶颈、多核并行执行提速、Hint 指定算法五大特性，从 “计划生成→数据扫描→索引选择→执行调度→算法决策” 全链路压缩复杂 SQL 的执行开销。
需要指出的是，OceanBase 提供了丰富的执行计划 Hint，让 DBA 可以在 SQL 中直接指定算法，精准干预执行计划的生成。 OceanBase 的执行计划 Hint 不是日常调优工具，而是优化器偏差时的兜底干预能力——当生产 SQL 突发劣化、统计信息失准或关联条件复杂导致选错算法时，DBA 可直接在 SQL 中指定算法纠正执行计划，无需改写 SQL，这份能力是 MySQL 所不具备的。
下图是团队基于 OceanBase SQL 查询计划和 OceanBase SQL Hint 的详细拆解和分析。
业务 POC
在正式推广业务之前，OceanBase 在 DBA 团队内部尝试，DBA 内部 AP 报表业务试点，SQL 执行速度平均提升 10~30 倍。DBA 报表业务一直基于 MySQL，存在复杂查询耗时长的问题，大部分超过 1 秒，甚至有超过 30s 才能执行成功，同时复杂查询带来的资源互斥、锁等待等运维问题。
DBA 内部报表业务整体迁移到 OceanBase，使用 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 到 1 套 OB 集群，多租户隔离；三个主机便承载团队整体业务，并同时兼顾高可用和 TP / AP 业务资源隔离。集群底层宿主机为云 ECS 实例，共三个 Zone，分别部署在两个可用区，可用区 A 两个 Zone 用于读写业务，可用区 B 一个 Zone 用于只读业务，每个 zone 由若干计算节点组成。集群中也会留出部分冗余 CPU 资源，当租户出现 CPU 告警时，冗余 CPU 可以秒级完成租户的 CPU 扩容。整体架构如下：
SQL 平均耗时下降 88.3%，业务超时接口清零，性能提升 8.6 倍，聚合 / 范围查询响应时间较 MySQL 降至 1% 以内，以某研发效能平台为例，AP 相关 SQL 平均耗时从 6.87s 降至 0.8s，性能提升约 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 行列混存一体化。
- 消除异构： 消除数据同步工具链路，数据从异步滞后到实时可见转变。业务分流风险消除：消除应用层手动分流，OB 内部自动路由点查 / 聚合，彻底杜绝分流错误影响业务的风险。
- 存储降本： 存储从数 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 的多模多态数据基础设施，解决业务当前痛点，为业务创新提供坚实数据底座支撑。
往期回顾
1.AI UITester：AI Native 的 UI 自动化测试新范式｜得物技术
2.从狂野代码到按目标生产：得物推荐 AI Harness 的工程化实践｜AICon 演讲整理
3.从表单到 Agent：得物社区活动搭建的 AI 实践之路
4.从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流
5.让 Claude Code 拥有自我进化和记忆系统｜得物技术
文 / 菲利斯、未文
关注得物技术，每周四更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。
