首先为大家推荐这个 OceanBase 开源负责人老纪的公众号 "老纪的技术唠嗑局"，会持续更新和 #数据库 、#AI 、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！
本文整理自6月21日"OceanBase 城市交流会 · SQL 遇上 AI "《度小满 × OceanBase 实践：统一架构驱动效率与成本双突破》，点击链接可观看视频回顾。
作者：赵辉，度小满技术委员会负责人
度小满，原百度金融。2018年4月，百度宣布旗下金融服务事业群组正式完成拆分融资协议签署，实现独立运营。作为一家金融科技公司，度小满充分发挥百度的AI优势和技术实力，携手金融机构合作伙伴，用科技更好地提供金融服务。本文介绍度小满业务高速增长背后，面临的存储挑战与数据库解决方案。
四大成本优势决定数据库选型结果
度小满金融业务规模的高速扩张，使存储需求呈指数级增长。那时，底层的数据库方案面临数亿用户的高并发交易、毫秒级实时风控决策、高吞吐变量数据写入，以及报表分析的极低延迟的挑战。经大数据部门的深入分析，存储架构存在五个方面的问题，导致其很难面对上述挑战，持续支撑业务需求。
其一，度小满自研技术栈多，比如关系存储类DDBS、KV存储类的CKV、稀疏海量存储类的Eggroll、等等。对于一线开发人员来说学习成本较高，需要对接并学习多种用法，开发和对接效率有待提高。
其二，资源成本高，主机规模大，主从备架构部署冗余，存在多个小集群，导致存储成本高、CPU利用率低、资源难复用。
其三，一些业务操作如流量切换与屏蔽、数据均衡操作、扩缩容操作复杂，且对业务不透明，需要多方配合，执行周期较长，部分场景更是需要方案定制。
其四，存在可用性风险，所有类型的存储引擎在全场景下，比如进程挂起、硬件故障、机房故障、地域灾难等场景，难以达到9999的SLA。
其五，工具生态欠缺，工具自动化，尤其是产品化程度较低，运维效率有提升空间。
针对业务需求及原本数据库方案面临的困境，我们决定重新选择一款既满足业务需求又可以统一当前所有技术栈的产品。那么，为什么最终选择OceanBase呢？
经过前期对多款数据库在迁移成本、资源成本、学习成本、运维成本等方面的调研，我们发现 OceanBase 非常符合我们的选型需求。
1.迁移成本低：兼容 MySQL 和 Redis 协议，迁移过程平滑无感。
为了实现底层架构栈的统一，我们替换数据库方案面临的第一个要求就是迁移成本不能过高，否则将会面临较大的业务阻力。由于 OceanBase 兼容 MySQL 和 Redis 协议，整个迁移过程非常平滑，几乎没有改造，我们投入的人力、时间都较少，对业务有正向收益，因此，间接降低了整体的迁移成本。
2.资源成本低：引擎执行高效，TPCC 刷榜世界纪录，超高压缩比。
OceanBase 有世界领先的计算执行引擎，曾打破 TPCC 世界纪录。而且，极致的数据压缩比在业内闻名，相比传统数据库 MySQL，能够实现几倍的存储空间节约，极大地降低了企业的存储成本，带来显著的资源利用率提升。
3.学习成本低：支持关系/KV /向量等技术栈统一，多种部署架构的运维方式统一。
如上文提到的，我们的多种技术栈及组件给一线的开发人员和运维人员带来了极大的学习成本，OceanBase 用一套引擎就可以解决关系型数据、KV、向量等多种数据类型的存储及计算，满足所有业务场景的需求，极大降低了学习成本，提升了运维效率。
4.运维成本低：支持机房地域级的容灾，RTO<8s，RPO=0。原生支持分布式，扩缩容对用户透明。
OceanBase 具备完善的周边工具生态，包括 OCP（云平台）、OMS（数据迁移服务）和 ODC（开发者中心）、OBD（安装部署工具）等，为用户提供了全方位的支持，从安装部署、迁移数据、开发工具到运维管理、监控告警，一应俱全。在支持在线扩缩容的基础上，通过云管理平台 OCP，可以白屏化实现非常便捷的扩缩容能力，极大地提升了我们目前的运营能力、使用体验和工作效率。此外，OceanBase 原生具备高可用能力、经过我们的实际测试，发现在故障发生时，业务完成切换的时间在 8s 之内，且数据零丢失，证明OceanBase确实达到了 RPO=0，RTO< 8s。
五个场景探索OceanBase在业务落地的可行性
到底OceanBase在实际场景中的表现如何，能否解决我们此前面临的数据延迟、查询性能问题？下文通过五个技术场景的实践举例说明。
场景1：海量数据的低延迟查
在单表月数据量 10亿，占用内存约 30GB 的查询场景中，通常仅查询月内数据且查询语句复杂。使用原本的MySQL方案时，需要将一张表拆分为多张表才能实现较好的性能。但这样的操作会使业务逻辑和使用逻辑变得更加复杂，无法满足业务需求，同时，存储成本很高，不符合整体业务诉求。
在切入 OceanBase 后，2025年5月单表存储数据近 10 亿，内存占用 29.5GB，在响应耗时最大的update 场景中耗时8毫秒，符合我们的预期，而在其他场景如 select、insert 场景的耗时更低。对于业务操作整体耗时，OceanBase方案可以控制在10毫秒内，完全满足业务要求。
该场景中，我们的经验是：由于 OceanBase 为原生分布式架构，建议大家针对需要手动分表的场景使用分区能力，降低一线人员的改造成本和业务逻辑设计成本。另外对于复杂查询语句，例如 in 值太多的情况，需绑定执行计划，避免全表扫描导致执行时间过长。
场景2：数仓加工高性能读写
实时数仓的高性能读写是另一个需要优化的业务场景，涉及 10w 写 + 36w 读，其中查询涉及 TP 点查 + AP 聚合关联查询，并且存量数据和增量数据分别是两种存储系统。原本我们使用 MySQL 的 DDBS 分布式存储进行增量数据的实时读写，这是因为在存储数据量较多时，访问存量数据带来的性能压力较大。而对于存量数据，则使用 Eggroll 存储，但由于 Eggroll 是磁盘型存储，即一个简易的基于 RocksDB 的分布式架构，扩缩容周期相对较长。
下图显示了我们的数仓加工链路，在改造前，业务数据源通过 Kafka、Flink，在 ODS 层读写MySQL，然后读 Eggroll，再经过 Kafka 多轮的写，链路从 ODS 层到 DWD 层再到 DWS 层。开发该数据链路的人员既要熟悉 DDBS 架构、Eggroll 架构，还要清楚从 Kafka 到 Flink 再到 Hive 的整条链路，涉及多个引擎和链路加工，交付周期非常长。
经过改造后，我们将 DDBS 和 Eggroll 切换为 OceanBase ，在整体架构、交付效率、扩缩容、成本等方面都取得了巨大收益。
- 架构精简：原本维护两套存储引擎变成了维护一套交互链路，撰写这部分代码的同学只需要熟悉一套逻辑和接口就可以完成整个链路工作。
- 交付效率翻倍：除了撰写代码的效率提升外，学习成本也大幅降低，开发周期从6天缩短到3天左右，交付效率翻倍。
- 扩缩容效率提升：原来一个扩容可能是要天级别甚至周级别才能完成，切换到支持在线扩缩容的 OceanBase 后，可以实现小时级扩容。
- 成本收益3倍以上：DDBS 及 Eggroll 的压缩比并不高，切换到 OceanBase 后，压缩比可以做到 4:1，带来的成本收益非常大，加上性能收益，整体成本收益达到3倍以上。
当然，在本次改造过程中，我们也积累了一些技术实践经验，供大家参考。
一是在使用 OceanBase 的过程中应尽量避免跨分区的 RPC 通信问题，如果 RPC 通信次数较高，查询性能下降会比较明显，需要对业务模型做尽量合理的设计，例如 SQL 中要带分区信息，尽量命中本地节点以便取得更极致的性能表现。
二是热点数据的写冲突。由于 Flink 的数据是实时同步的，如果我们更新一个变量，变量也会实时读写，导致热点数据的写冲突及性能下降，因此建议开启 Early Lock Release 特性，整个性能表现会更加优秀。
三是存量数据高压力写对结果点查的影响，由于批量存量数据需要每天更新入库，会和正常的业务请求发生资源争抢，导致业务请求的时间变长。我们的解决方案是，对存量写任务进行资源隔离与管控，进一步解决问题。
后续我们计划使用 obbinlog 代替现有 Kafka 的数据传输链路，与OceanBase社区合作优化obbinlog的性能，实现基于 Flink和OceanBase 及其工具的监控链路，降低实时数仓加工链路的架构复杂度，进一步提升查询效率和交付效率。
此外，我们也期望 AP 聚合关联查的延迟问题能被解决，所以未来会探索OceanBase 的行列混存。目前，我们关注到 OceanBase已经发布面向AP的第一个 LTS 版本------V4.3.5，后续将持续关注该版本的完善情况。
场景3：变量数据高吞吐写入
度小满存在很多变量有 T+1 加工的场景，加工完成后需要进行变量入库，供在线业务查询。我们的原方案是使用 HBase 的 Bulkload 能力更新到存储引擎 Eggroll 上，当 Eggroll 切换到 OceanBase 后，开始使用 OceanBase 的 Obloader 脚本。
目前，在使用Obloader 方案时也遇到一些问题。由于 DGS 是我们内部自研的对象存储，协议独特，不能完全兼容 Obloader 脚本，需要我们先将其下载到本地再用脚本入库，效率较低。但由于我们在更新 T+1 数据时，需要把一天之内完成所有数据的全量写入，单个脚本入库数据量太大，时效性要求很高。当效率不足以支撑时，会导致一天内需要写入的数据写不进去，因此当前的方案无法满足实际业务需求。
对此， OceanBase 官方为我们推荐了旁路 SDK 方式，直接对接自研 DGS 协议，远程读取直接入库，避免了一次落盘操作。同时针对超大数据量场景，利用 K8S 弹性能力，动态启动多进程分片入库，提升了整个吞吐量，确保了该场景下业务的适配性。
场景4：标量过滤+向量检索的混合查询
在AI大潮下，标量过滤+向量检索的混合查询将成为常态。对于该场景，我们当前使用 Elasticsearch 支撑，而我们将积极探索切换为 OceanBase 方案的可能性，并开启了性能测试。
在性能测试中，我们使用了两种业界常用的测试集：
- 数据集：cohere 768 1M（768维，100W向量），在 Limit 10、召回率 0.9、索引类型为 HNSW、并发 50 的情况下进行基础性能对比，OceanBase 性能是 Elasticsearch 的1.24倍。
- 数据集：cohere 1536 500K（1536维，50W向量），在 Limit 10、召回率 0.9、索引类型为 HNSW、并发 50 的情况下进行基础性能对比，OceanBase 性能是 Elasticsearch 的1.04倍。
从测试结果来看，OceanBase 在 AI 场景中会有 10%～20% 的性能提升。我们已联合业务方进行试点，后续会进一步完成OceanBase在 AI 场景的落地。
场景5：极致的 KV 读写性能
在我们的 KV 场景中，前端面临 120w QPS 的查询压力，并且会映射到底层存储。我们搭建了 OceanBase 三节点，经过测试，OceanBase能够做到 60w QPS 的性能支持，平均延迟 1 毫秒左右，且可以持久化存储，完全满足我们的业务需求。同时 OceanBase 存量数据在磁盘中也能够持久化存储，提升了系统的稳定性和可用性，相较于原本的 CKV 方案，优势明显。因此，我们计划近期在KV场景正式上线OceanBase。
总结与展望
引入 OceanBase 对度小满来说，不仅是替换传统关系型数据库解决性能和成本问题，更大的意义在于：将关系型/KV 型/ AI 向量型等众多在线存储技术栈进行统一，实现开发与运维的双重提效。
进一步展望，我们对 OceanBase 的内部测试表明其性能优于其他主流向量数据库，但这些结果尚未获得独立的第三方验证，如 VectorDBBench 第三方基准测试项目。我们希望 OceanBase 做进一步的验证，同时也期待和 OceanBase 的专家做更深入的探讨，并最终应用到真实的业务中。
「老纪的技术唠嗑局」不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献一份力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星 ✨ 吧！你的每一个Star，都是我们努力的动力。