17认证网目前得物在线的数据库服务涵盖多品类，支撑核心交易、运营分析、AI 算法、社区等多业务场景，但也面临运维复杂度高、研发选型难、架构复杂、资源成本高等运维问题。同时，业务对数据库性能、可用性、成本要求逐步增高。在持续的数据库调研和选型中，OceanBase 作为多模数据库，逐步进入视野，特别是 4.x 版本引起了 DBA 团队和研发团队的极大兴趣。
本文获授权转载自微信公众号“得物技术”，作者为菲利斯、未文，全文 5059 字，阅读约需 8 分钟。
OceanBase 基于 Paxos 协议实现多副本强同步，支持单机房到三地五中心多种部署模式，任意副本秒级故障接管，RPO = 0，RTO < 8s。同时支持多活与单元化部署，实现跨地域同时写入、跨云灵活扩展，毫秒级同步延迟保障数据一致。
在当前业务对可用区级高可用日益迫切的需求下，OceanBase 多活架构提供了从容灾到合规的全方位高可用保障。总体来看，OceanBase 能力与公司业务场景、痛点高度匹配：
灵活架构：单机分布式一体化能力，让零散 MySQL 小业务从最小规模起步，随增长无缝扩展至分布式集群，同时通过多租户机制按需分配资源，解决小业务整合难、扩展需迁移切换的痛点，实现成本与弹性的最优平衡。
降低成本：通过分层转储、增量合并和两层压缩，在保障高性能写入的同时大幅压缩存储成本（降幅可达 40%+），解决 MySQL 类业务存储成本高、写放大严重的痛点。
- 分层转储：内存数据经 L0 → L1 → L2 三级 SSTable 逐层下沉，避免内存阻塞，保障写入持续性。
- 增量合并：仅合并被修改的热点宏块，未修改数据直接复用，有效减少合并开销，降低写放大。
- 两层压缩：先以行列混存编码对结构化数据做字典压缩，再用通用算法二次压缩，在性能与压缩率之间灵活平衡，大幅削减存储成本。
高可用：原生多活架构基于 Paxos 协议，支持任意副本秒级故障接管、RPO = 0，RTO < 8s 及跨地域多活写入，满足业务对可用区级高可用的严苛要求，解决容灾切换慢、异地数据一致性弱、合规部署复杂的痛点。
在以 TP AP 为主要场景进行落地、承接 MySQL、StarRocks 等组件业务的同时，在某业务生产环境高频聚合 SQL 场景下，OceanBase 综合性能优于其它品类数据库，其中 JOIN 聚合查询领先 81.5 倍，充分体现行列混存架构优势。
测试验证数据如下：
在实际业务推广前，DBA 端进行了详细压测验证，基于不同并发度和行列存储场景，OceanBase 表现出较好的性能水平。
- 高并发支持: 在不同的读写模式下，OceanBase 展现出优异的吞吐量表现（TPS 和 QPS）。例如，在 200 并发下，行列混存模式的 TPS 值高达 13076.91，显示出其优秀的处理能力，适合高并发的在线事务处理（OLTP）场景。
- 高效的读写性能：在只读和只写模式下，行存表、列存表的性能表现均较为突出。在 100 QPS 情况下，OceanBase 的 TPS 值能够达到 7230 左右，表明它能够高效处理大量查询请求，适合大规模数据的分析需求（OLAP）。
- 资源利用率：CPU 使用率在不同负载下表现合理。例如，在 200 并发下，行存表的 CPU 使用率为 63.73%，显示出其在高负荷下的良好资源分配能力。这能够确保系统的稳定性和可靠性。
- 灵活的存储引擎：OceanBase 支持行存、列存及混合存储，能够根据不同的业务需求和数据特性选择最优的存储模式，从而提高处理效率。
压测和结论参考下图：
如下 SQL1 和 SQL2 分别用于获取某一周期内 SQL 审核的执行情况统计和分页排序查询明细情况：
SQL1：
select count(distinct(a.field_A)) as count,SUM(CASE WHEN b.`field_B` IN (0,1,3,7) THEN 1 ELSE 0 END) AS `total_cnt`,SUM(CASE WHEN b.`field_B` IN (0) THEN 1 ELSE 0 END) AS `todo`,SUM(CASE WHEN b.`field_B` IN (1,7) THEN 1 ELSE 0 END) AS `done`,SUM(CASE WHEN b.`field_B` IN (3) THEN 1 ELSE 0 END) AS `auto`from table_A a join table_B b on a.field_A = b.field_Cand 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)
select a.*, SUM(CASE WHEN b.`field_B` IN (0,1,3,7) THEN 1 ELSE 0 END) AS `totalCount` ,SUM(CASE WHEN b.`field_B` IN (0) THEN 1 ELSE 0 END) AS `amount`,SUM(CASE WHEN b.`field_B` IN (1,7) THEN 1 ELSE 0 END) AS `done`,SUM(CASE WHEN b.`field_B` IN (3) THEN 1 ELSE 0 END) AS `auto`,sum(IF( b.create_time >= {START_TS} and b.field_B = 0, 1, 0)) as amount_currentfrom table_A a join table_B b on a.field_A = b.field_Cand 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
在 OceanBase 中对相同的 SQL 进行测试，并进行优化对比，性能提升效果明显：通过 5 个维度的渐进式优化，将 SQL2 执行时间从 4s 降至 0.02s，整体性能提升约 200 倍；SQL1 从 1.3s 降至 0.01s，提升约 130 倍。
下图详细介绍这几项优化的思路：
OceanBase 的执行计划 Hint 不是日常调优工具，而是优化器偏差时的兜底干预能力——当生产 SQL 突发劣化、统计信息失准或关联条件复杂导致选错算法时，DBA 可直接在 SQL 中指定算法纠正执行计划，无需改写 SQL，这份能力是 MySQL 所不具备的。
下图是团队基于 OceanBase SQL 查询计划和 OceanBase SQL Hint 的详细拆解和分析。
在正式推广业务之前，OceanBase 在 DBA 团队内部尝试，DBA 内部 AP 报表业务试点，SQL 执行速度平均提升 10-30 倍。
DBA 报表业务一直基于 MySQL，存在复杂查询耗时长的问题，大部分超过 1 秒，甚至有超过 30s 才能执行成功，同时复杂查询带来的资源互斥、锁等待等运维问题。
DBA 内部报表业务整体切换到 OceanBase，使用 OceanBase 物化视图、行列混存等特性，SQL 执行速度平均提升 10-30 倍，同时通过混沌工程，验证 OceanBase 在各异常场景下的止血手段并形成运维 SOP，积累 OceanBase 运维经验，提振 DBA 团队把 OceanBase 面向业务落地的信心。
- TP & AP 混查，CPU 等告警频发：普遍没有只读实例，同时存在大量复杂聚合查询，长期对 TP 业务查询造成较大资源挤占，CPU 经常告警。
- 磁盘容量问题凸显：部分 AI 相关 MySQL 磁盘增长迅速，B+Tree 架构下碎片明显；大表较多，执行 DDL 所需预留额外空间较大，磁盘成本压力显著。
- 资源分配不合理：QPS 较低的实例较多，即使在最低配置下也存在资源浪费。
- 运维处理复杂：存在大量空长事务及异常 DML，常规管控平台无法快速排查。
基于业务团队目前遇到的切实痛点，DBA 团队构建了全面的切换计划，涵盖平台接入、资源规划、架构设计、集群配置、迁移变更等各个环节。
整体流程图如下：
架构清晰简洁，多套 MySQL 集中到 1 套 OB 集群，多租户隔离；三个主机便承载团队整体业务，并同时兼顾高可用和 TP AP 业务资源隔离。集群底层宿主机为云 ECS 实例，共三个 Zone，分别部署在两个可用区，可用区 A 两个 Zone 用于读写业务，可用区 B 一个 Zone 用于只读业务，每个 zone 由若干计算节点组成。集群中也会留出部分冗余 CPU 资源，当租户出现 CPU 告警时，冗余 CPU 可以秒级完成租户的 CPU 扩容。
整体架构如下：
详细数据如下：
资源利用上，基于 OceanBase 特有的多租户 PrimaryZone 打散 + CPU 超卖，将集群 ECS CPU 利用率提高到 100%，远超 MySQL 主备架构的 50%。
- 传统 MySQL 架构：业务库会在 MySQL 下游接入异构从库，用于业务 B 端运营数据聚合查询。
- 多套异构数据库支撑业务：运营 B 端原先全走另一家数据库，商家 B 端大活动查询也是，只有小活动查询走 MySQL，通过数据同步工具从 MySQL 异构同步到其他品类数据库。
- 业务分流痛点：需要业务手动分流点查 聚合查询，而这种分流时常不准确，出现聚合查询走到 MySQL 影响业务的情况。
- 存储数据量大：两个数据库的组合，占用了大量的存储空间，后续数据一致性依赖同步工具保障。
- AP 查询性能急需优化：虽然业务对部分组件进行了拆分以提升查询效率，查询仍然存在提升空间。
在经过全面的 POC 验证及测试后，OceanBase 很好地解决了当前问题，特别是架构痛点，在承载 MySQL 业务的同时，压缩率及性能上均较原数据库更优，在与研发业务高效协作后，对当前架构进行“大换血”，目前已将原数据库的部分流量切到 OceanBase 进行 POC，运营 B 端已全部走 OceanBase。并且整体效果超出预期。
- 架构升级：从双链路 + 应用层手动分流升级为 OceanBase 行列混存一体化。
- 消除异构：消除数据同步工具链路，数据从异步滞后到实时可见转变。
- 业务分流风险消除：消除应用层手动分流，OceanBase 内部自动路由点查 聚合，彻底杜绝分流错误影响业务的风险。
- 存储降本：存储从数 TB 级降至百 GB 级，较 MySQL 压缩率达 94%，较原数据库压缩率达 30%。
- SQL 提效显著：OceanBase 的聚合 范围查询响应时间较原数据库平均降低 65%（10%-90%），较 MySQL 降至 1% 以内；高 QPS 点查与 MySQL 互有优势，且显著优于原数据库。实时性方面，OceanBase 查询完全实时无延迟，而原数据库存在秒级写入-读取延迟。
在 OceanBase 最新的 LTS 版本 4.4.2 实践中，需注意与 MySQL 在 SQL 语法、事务隔离级别、自增列实现等方面的差异，通过业务适配或参数调整解决兼容性问题。性能方面，通过绑定执行计划、错峰刷新物化视图等手段，有效解决了 AP 查询走偏、物化视图卡住等瓶颈。
更重要的一点是，从传统数据库如 MySQL 等切换至 OceanBase 时，引入新特性需要特别小心，因为新特性新功能也仍在完善中，不可避免有场景限制甚至功能互斥，比如这里遇到的实时物化视图与 DDL 冲突问题，在引入新功能时须建立严格的准入审核、监控告警和故障演练机制。上线前应全面评估，避免对业务造成非必要影响。
在保障业务稳定性、可用性前提下，通过切换 OceanBase 来获得性能、成本双重提升，特别是在接下来进入深水区、核心业务推广时，还有不少切实需要解决的问题，需要沉淀总结的经验。
运维模式从实例级转为租户级 + 集群级，在监控、备份和容量规划上全面适配 OceanBase 的分布式特性。工具链也相应升级，从云 MySQL 的 “控制台 + 数据同步工具 + 数据库诊断工具 + 自研 DBA 管控平台” 切换为 OceanBase 的 “OCP + OMS + diag + ODC 自研 DBA 管控平台” 体系，实现管控、迁移、诊断与开发的全链路覆盖。
DBA 团队对 OceanBase 知识框架也进行了梳理：
通过 “基础培训 — 深度实践 — 认证培养” 三层路径，DBA 团队系统提升从 OceanBase 架构原理到性能调优的实战能力，并通过达成 OBCP 认证目标，已建立 OceanBase 系统化知识体系框架，训练出 OceanBase 专项运维人员。
同时，基于技术分享、项目实战带教和内部知识库等途径，形成 “分享 — 实战 — 沉淀” 的知识转移闭环，持续提升团队能力。
大致分三个阶段推进：
- 短期（0.5-1 年）夯实基础，建立技术支撑、标准 SOP 和应急演练体系；
- 中期（1-2 年）引入 OBKV 落地业务场景、上线向量检索，完成多云多可用区建设并引流核心新增业务；
- 长期（2-3 年）建成统一多模数据平台，覆盖 90% 数据场景。
以切换至 OceanBase 为契机，实现成本、敏捷性、创新与风险四大收益：
3 年内 TCO 降低 50%，业务上线准备缩短至 1 天内，覆盖实时分析与个性化推荐等新场景，并达成秒级故障恢复与数据零丢失；
持续推动 OceanBase 的全面落地，关注并调研 OceanBase Lakebase 等面向 AI 底座的数据库产品。
团队将致力于构建面向未来、面向 AI Agent 的多模多态数据基础设施，解决业务当前痛点，为业务创新提供坚实数据底座支撑。
版权申明：内容来源网络，版权归原创者所有，如有侵权请联系删除
想了解更多行业资讯
扫码关注👇
了解更多考试相关
扫码添加上智启元官方客服微信👇
