标签 OceanBase 下的文章

本文整理自《深入解读 VSAG——OceanBase 自研开源向量索引库》系列文章
作者 | 金加宝、李昊天、王翔宇、杨鸣宇、钟萧遥(按姓名首字母排序)

摘要:
OceanBase向量索引库VSAG通过引入SIMD、内存分配优化、量化等方法提升向量检索性能。其核心算法包括:BSA在保证检索精度的前提下加速向量距离计算;EnhanceGraph利用搜索日志和构造日志动态增强图索引,提升查询准确性;DFSANN适配存算分离架构,实现低成本混合存储检索;HGraph则通过组件化分层架构支持多场景平滑切换。

向量搜索技术,被认为是海量非结构化数据检索的关键技术之一,这会涉及到高维空间的搜索问题,通常会通过近似最近邻搜索(Approximate Nearest Neighbor Search, ANNS)的方式来在高维空间中进行检索,以此来找到满足要求的数据。

随着 AI 应用场景的发展,半结构与非结构化数据的涌现,向量数据库成为 AI 时代重要的数据基座。在 VectorDBBench 基准测试中,OceanBase 在同等环境下向量性能已达到业界主流开源向量数据库的最优水平。这一出色表现很大程度上得益于 OceanBase 向量背后的向量索引库 —— VSAG。

向量索引,作为影响向量检索准确率、查询性能的重要因素,是决定向量数据库性能的关键基础。当前,开源社区已经涌现许多算法库,每个算法库有不同的特点,适用于不同的向量检索场景,包括在相似性搜索领域最有名、维护时间最长的 FAISS 算法库 (facebookresearch/faiss);由于高效、易于集成、单线程读写等特性广泛应用于搜索推荐系统的 hnswlib 算法库(nmslib/hnswlib);以及本文将深入介绍的 OceanBase 开源向量索引库 VSAG。

VSAG 库通过引入了许多 SIMD、内存分配和布局、量化等方法,获得了卓越的近似 K 近邻图的搜索性能表现。受益于其资源管理模块,在系统中能够提供租户级细粒度的计算和存储资源管理,提供了超大规模下混合内存与磁盘的快速检索方案。VSAG 在 960 维的 GIST 数据集上表现出色,在 ANN-Benchmarks 测试中远超其他算法。

今天,让我们从最基础的概念讲起,一起走进 OceanBase 向量背后的向量索引库 VSAG,并揭秘其中各项硬核算法。

向量是什么

向量(Vector / Embedding)是一个数据结构,其中包含一个浮点数的数组。这是一个向量的示例:

向量在检索相似的图片、音频和文本等方面发挥着关键作用,这源于其数据属性和特征表示能力。在机器学习和数据科学领域,向量被广泛用于描述数据特征。以图片数据为例,我们可以将其表示为向量。在计算机中,图片本质上是由像素构成的二维矩阵。每个像素的亮度值可视为图片的一个特征,因此,我们可以将这些亮度值串联成一个高维向量,从而实现图片的向量化表示。

这种向量化表示使我们能够利用向量空间中的距离和相似度度量方法来比较不同图片之间的相似程度。例如,欧氏距离可用于衡量两个图片向量间的像素差异,而余弦相似度则可测量它们的方向差异。通过计算向量间的距离或相似度,我们可以量化评估不同图片之间的相似程度。

在实际应用中,图片除了像素亮度以外还有轮廓等更复杂的特征可以用于比对相似度,所以一般会使用神经网络来进行特征向量的提取,然后通过距离函数来衡量不同图片之间的相似度。这就是为什么向量可以被用来衡量非结构化数据的相似度。

当可搜索内容表示为向量时,查询可以在相似内容中找到接近的匹配项。用于向量生成的嵌入模型知道哪些单词和概念相似,并将生成的向量放置在嵌入空间中。例如,关于 “clouds” 和 “fog” 的向量化源文档更有可能显示在关于 “mist” 的查询中,因为它们在语义上相似,即使它们在词法上不匹配。

如何衡量向量相似度

向量相似度有几种不同的度量方法,其中最常见的是欧式距离、点积距离和余弦距离。这些度量方法各有特点和适用场景。欧式距离直观地反映了向量在空间中的绝对距离,适用于需要考虑向量大小的情况。点积距离反映了向量的方向和大小,常用于机器学习中的权重计算。余弦距离则专注于向量间的角度,忽略大小差异,特别适合文本相似度等归一化场景。选择合适的度量方法对于提高相似度计算的准确性和效率至关重要,并且往往需要根据具体的应用场景和数据特征进行权衡。

相似度搜索的一种方法:近似最近邻搜索(ANNS)

在大规模数据集中,传统的精确最近邻搜索算法可能需要花费大量时间和计算资源。因此,近似最近邻检索(Approximate Nearest Neighbor Search,ANNS)技术的出现满足了对相似度搜索更快速和高效的需求。近似最近邻检索通过牺牲一定的搜索准确度,来换取更快的搜索速度。这种特性使得 ANNS 技术在需要快速检索大规模数据集中的相似对象时极具优势,特别是在诸如推荐系统、图像识别、自然语言处理和数据挖掘等领域。近似最近邻检索技术的应用范围非常广泛,它在提高效率的同时保持了对搜索结果准确度的要求,因此在大数据量情况下更能展现出其价值。

一般来说,近似最近邻搜索依赖对数据集提前构建好一个索引,搜索在索引上进行。通过使用索引,近似最近邻搜索一般能将耗时降低几个量级。常见的向量索引类型:基于树的索引结构、基于哈希的索引结构、基于图的索引结构、基于倒排的索引结构等。这些索引对于构建时间、批量查询、异构计算等场景分别有不同的优势,一般在业务场景中会根据实际需要来选用索引。

本文开头提到的 faiss,hnswlib,包括 vsag 都属于 ANNS 算法库。

向量搜索的挑战在哪里

虽然现在我们已经有了很多成熟的开源算法,但随着非结构化数据量的持续增长,以及更多 AI 应用的诞生,向量搜索技术被提出了更多的挑战。

更快的搜索速度是第一个挑战。对于更好性能的追求在业务中是一直存在的,更快的搜索速度意味着单位实例能够服务更多的用户请求,同时更快的搜索速度能够降低访问延迟提升体验。

更高的搜索精度是第二个挑战。向量召回作为搜索推荐链路的上游环节,搜索精度很大程度上影响到整条搜索链路的召回精度上界。通过提高向量召回的精度,能够给后续的排序环节提供更加高质量的输入。在 RAG 应用中同理,向量的召回率越高,能够输入给语言大模型的内容就越好,语言大模型的回答就越准确。

更低成本的搜索是第三个挑战。更低成本更多是企业从降本增效出发,希望在技术上获得收益。向量检索因为数据结构本身的特点,查询服务的成本本来就高于标量数据。而当前音视图文数据量的增长给系统带来的服务成本来增长迅速。近几年对于低成本的向量索引的探索更多被关注到,比较有名的是微软提出的 DiskANN 算法,而后续在学术界和工业界也涌现出更多相关的后续工作。

VSAG 硬核算法详解

1.BSA(Bridging Speed and Accuracy):在保证检索精度的前提下加速向量距离计算

背景与设计目的

现有向量检索算法(如 HNSW、IVF)经过多年优化,对索引结构的改进只能带来小幅度性能提升。向量检索算法的性能瓶颈在于“距离计算”这一操作:在 HNSW 中距离计算约占 80% 的总时间开销,在 IVF 中更是接近 90%。使用计算代价更低的近似距离代替精确的距离计算,例如乘积量化(product quantization),虽然可以大幅提高距离计算的效率,然而会导致检索精度的大幅下降,使其很难应用于高精度的向量检索场景。

因此,如何既利用近似距离的实现快速计算、又能够保持高检索精度,成为了 BSA 算法试图解决的关键问题。

核心技术与实现方案

BSA 算法将向量检索中的距离计算分为两类,其中第一类为需要精确距离计算(Label 0),第二类为不需要精确距离计算(Label 1),并利用近似距离、当前搜索过程中的队列阈值作为特征,训练一个线性二分类器,通过调整模型截距来保证分类器的分类精度达到检索要求。

在搜索过程中,如果线性分类器将当前距离计算分为第一类,则需计算当前点的精确距离并更新结果队列;如果线性分类器的分类结果为第二类,该次的距离计算则可以避免。

该算法不仅可以加速内存向量检索的距离计算,同时还可以避免磁盘方案的冗余 IO。

性能表现

以下展示了几种加速距离计算的方法在 GIST 和 DEEP 两个数据集上的性能表现。结果可见,BSA+OPQ 框架实现了原始 HNSW 最高 1.7 倍的检索性能提升,以及相对原始 IVF 最高 2.2 倍的提升,远超索引结构优化带来的性能提升。同时 BSA 方法不受索引结构的限制,可以应用于任意向量检索算法。

实战应用

当前,BSA 方法在内部的数据和实际应用场景均已进行验证和应用:

在 100w 数据集上,在召回率不降低的前提下,搜索耗时从 7.53ms 下降到4.85ms,降低 35.59% 。这意味着吞吐能够增加 55.25% 。
在 1000w 数据集上,在召回率不降低的前提下,搜索耗时从 10.09ms 下降到7.33ms,降低 27.35% 。这意味着吞吐能够增加 37.64% 。

2. EnhanceGraph:动态增强的图索引构建,提升查询准确性

背景与设计目的

以 k-NNs Graph 为例,基于图的近似最近邻搜索(ANNS)算法以其优越的搜索性能和精确性成为主流。为了对其进行进一步优化,当前许多研究正在探索通过边的剪枝策略,减少索引的空间占用和提高搜索效率,然而此类策略往往会导致检索精度大幅下降。此外,由于传统基于图的索引在构建后将保持静态,所以在人脸识别等服务中经常会出现反复识别失败的情况。

面对上述挑战,EnhanceGraph 将搜索日志和构建日志用于辅助图索引的构建,从而有效利用历史查询数据和被丢弃的信息完善图索引,从而在保障查询性能的同时提升准确性。

核心技术与实现方案

EnhanceGraph 利用搜索日志和构造日志对图进行动态增强,前者可用于检测图结构中的缺陷,后者可用于补充近似图中缺失的 k-NNs,从而在可接受的空间成本增加的情况下显著提高查询的准确性。

与现有的索引在构建完成后即保持静态不同,EnhanceGraph 允许在搜索过程中实时进行反馈,基于用户的实时反馈或历史查询生成共轭图,用于维护所有反馈的召回信息。在线搜索时,第一阶段首先在近邻图进行搜索,第二阶段使用共轭图对搜索结果进行补充以增强召回表现。

具体来说,在构建图索引时,首先将近似图中被裁掉的边(构造日志)添加到共轭图中。在历史查询中,将失败查询时收敛到的局部最优解,与离线计算或者用户反馈的全局最优解结合,构成搜索日志。基于搜索日志,可以在共轭图中添加缺失的从局部最优解到全局最优解的边。这些边将在搜索的第二阶段补充搜索结果,以提高召回率,确保历史中失败的查询不会再次收敛到局部最优。

性能表现

如图所示为 EnhanceGraph 在若干主流数据集(GIST1M;SIFT1M;GloVe-100)和蚂蚁数据集上对召回率增强的表现。

结果显示,在部分数据集上,EnhanceGraph 能显著提高 Recall@1 的召回率,最高从 41.74% 提升到 93.42%。得益于从生成的查询和历史的查询得到的搜索信息,大幅度降低了未来的查询对 TOP1 最近邻的召回失败情况。对于OceanBase 数据集,即使是 Recall@1 非常高的情况下也能无损 QPS 提高召回率(从 99.8% 提升到 99.9%)。另外,使用构建信息对二阶段搜索进行补充也显著提升了 Recall@10。

实战应用

当前,EnhanceGraph 已在实际业务场景中进行了测试验证:

在 100w 数据集上,使用生成式方法,在几乎不降低 QPS 和使用少量额外存储空间(少于 7%),提升 HNSW 的 TOP-1 召回率从 99.8% 到 99.96% 。保证召回失败的人群有 80% 以上的概率不会再失败。
在 100w 数据集上,使用历史查询进行反馈,在几乎不降低 QPS 和使用少量额外存储空间(少于 3%),提升 HNSW 的 TOP-1 召回率从 99.8% 到 99.97% 。保证召回失败的人群有 85% 以上的概率不会再失败。

3. DFSANN:适配存算分离架构的低成本检索方案

背景与设计目的

当下的向量检索的研究主要关注纯内存向量索引的性能,较少关注海量数据的存储性能。然而,随着非结构化数据的快速膨胀,内存开销增加,数据的存储成本飙升,只使用压缩方法会显著降低精度;同时,存算分离架构中的共享存储相比起本地 SSD 会有更高的 IO 成本,这导致现有的基于 IO 的检索方案(例如DiskANN、SPANN等)不一定有比较高的性能。

因此,业界迫切地需要一种能够适配在存算分离架构系统上的低成本的检索方案。

核心技术与实现方案

现有磁盘方案中,搜索过程会产生频繁 IO,且重排阶段有较多不必要的精确距离计算,从而造成资源浪费。为此,DFSANN 先将搜索过程与 IO 过程进行解耦,再通过优化 IO 方案实现有效降本。一方面,通过减少 IO 次数和 IO 后的重排数据量来优化检索时间,另一方面,通过异步下放 IO 来减少总的 IO 时间:

缓存 Graph 与部分 IO:

将 Graph 缓存至内存,原始数据仍在底层存储中,在搜索过程中使用压缩向量进行快速检索,对近似距离进行排序,仅在结果重排阶段对最有可能的部分后续集进行 IO,从而降低少对磁盘的依赖。

优化 IO 方案:

边搜边 IO: 搜索中异步下发 IO 请求,获取全部候选集对应的精确向量,搜完后只计算部分候选集合的精确距离。该方法虽然需要全量 IO,但只计算部分集合,此外由于 IO 在搜索过程中下发,重排时无需等待,IO 的耗时开销几近于无。

搜完再 IO: 在搜索过程中积累 IO 请求,搜索完成后,根据近似距离排序结果将部分更有可能是最终结果的候选集对应的 IO 请求一次性异步下发,并计算精确距离。该方案可减少 IO 量,但搜索耗时会稍高一些。

进一步的成本优化:当前方案能够在较短的时间内实现较高召回率的检索。然而,受限于本地 SSD 的 IO 并发与图索引的构建成本,单机一般不会只构建一个大规模索引,导致单次检索产生巨大的 IO 开销。后续将采用预聚合(即,预先将部分点聚类成簇)的方式进一步降低存储成本和 IO 成本。

性能表现

在随机数据上的实验结果显示,DFSANN 的两套搜索模式都显著优于原始 DiskANN,特别当存储介质是 DFS 时,DFSANN 的吞吐显著优于 DiskANN。

4. HGraph:适配通用场景,支持平滑切换的六边形战士

背景与设计目的

现有的向量算法往往针对特定的需求,只能做到部分场景的适配。如果伴随业务需求调整,需要切换算法,则算法之间的异构特性会导致切换难度大,同时切换后存在各种不确定性的隐患。HGraph 致力于实现一套支持多种场景并且可以平滑切换的索引。

核心技术与实现方案

HGraph 基于组件化的分层架构,弹性化各个向量检索组件(量化器,IO 模块,图结构模块等),部分组件支持可插拔能力,通过不同组件的配置支持广泛的业务场景,且几乎保持同等性能。

HGraph的分层架构包括:
基础的算子层:包括量化器算子,IO访问算子等,支持新型的量化算法变更,支持多种数据访问方式;
数据组织层:提供算法核心能力,支持多种算法角度的数据结构管理、访问与计算能力;
接口抽象层:屏蔽底层的数据结构细节,提供统一的访问接口;
基础索引层:支持具体的索引算法结构,包含了构建、训练、检索的工作流,以及标签过滤、范围查询等特定功能。

适配不同场景,HGraph 提供多种组装方案。例如纯内存场景、混合存储场景等,用户在使用上只需要修改配置参数即可实现不同索引类型,支持快速迭代落地。

此外,HGraph 还在算法兼容和工程层面实现了多项优化。算法兼容方面已实现对 BSA、EnhanceGraph、DFSANN 等算法的兼容;工程层面,通过优化算子调用开销、SIMD 混合加速、预取优化等方案,实现了性能对标专业领域索引,甚至有所超越。

典型场景配置

HGraph支持大部分应用场景,覆盖不同数据规格,不同精度诉求,尤其是希望一套索引支持多个场景和具备平滑切换能力的场景。

高性能,高精度场景(数据规模 1M-100M,内存资源充足,精度 99%+,性能要求高):带重排和共轭图的纯内存方案;或单层 FP32 图,配合共轭图提升精度。

低内存,高性能场景(数据规模 100M-10B,内存资源紧张,精度 96%-98%,性能要求高)。

低成本,混合存储场景(数据规模 10B-1000B,内存资源十分紧张,精度和性能要求放宽)

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

摘要:
OceanBase联合河南师范大学软件学院与华东师范大学数据科学与工程学院撰写的ESTune论文被数据库领域顶级会议 SIGMOD 2026录用。通过对性能不佳的配置引入早停机制,ESTune 成功打破了迭代式数据库调优中的效率瓶颈。具体而言,ESTune 结合贝叶斯网络,利用部分执行数据(即分段性能指标)对低效配置的最终性能进行可靠预测。

日前,由河南师范大学软件学院,华东师范大学数据科学与工程学院与OceanBase团队联合撰写的论文《ESTune: Bayesian Uncertainty-Guided Early Stopping for Database Configuration Tuning》被数据库领域顶级会议 SIGMOD 2026(Proceedings of the ACM on Management of Data)录用。

SIGMOD 是 ACM 旗下的年度会议,是数据库领域公认的权威会议。本论文针对现有数据库旋钮调优方法效率低下的痛点,提出了一种基于贝叶斯不确定性引导的早停(即 Early Stopping)框架——ESTune 。

该论文的录用,标志着数据库参数自动调优领域在效率提升上取得了突破性进展。该方法通过解决利用部分工作负载数据可靠预测低效配置性能的技术难题,成功在不牺牲调优有效性的前提下,显著加速了现有方法的调优效率。

以下为论文介绍:

问题

尽管现有的自动化调优方法(如 OtterTune、HUNTER 等)能够实现数据库性能的显著提升,但它们普遍面临一个致命瓶颈:调优效率低下。这些方法在每轮参数性能评估时都需要完整运行整个工作负载,导致评估成本高昂且固定。而获取一个满意的参数配置通常需要数百次迭代,因此造成整体调优周期极为冗长,这样严重制约了自动化调优技术的实际应用和推广。

目前的自动化参数通常采用全量评估模式(即为每个配置都完整运行整个工作负载)。然而这种评估模式存在固有的局限性与显著的改进潜力。

该观点主要基于以下两个关键观察:

1.探索与利用的权衡导致性能波动。调优过程中会产生大量性能不佳的配置,这些配置往往占据了大量的评估时间。

2.对差配置的评估无需极其精确。对于表现极差的配置,即使评估存在一定误差(例如在 85%-115% 范围内波动),也不会影响最终调优结果的有效性。

基于此,该论文提出了 ESTune,其核心理念是:对性能不佳的参数配置实施早停策略,即无需完整运行整个工作负载;随后,ESTune 利用可靠的预测性能替代这些早停配置的最终性能。

通过这种方式,ESTune 不仅保证了调优的有效性,而且减少了不佳配置的评估时间,从而提升了调优效率。

核心技术一:分段式性能监控与最优粒度切分

工作负载通常被划分为基于时间和基于数量两种类型。

基于时间的工作负载常见于具有大量短查询的 OLTP 场景。对于此类工作负载,ESTune 将其执行过程划分为固定数量的时间段,并记录每个段的性能指标。例如,对于一个总执行时长为 500 秒的工作负载 TPC-C,若其执行过程被划分为 10 个时间段,则收集器将在每 50 秒的时间间隔内记录一次吞吐量。

基于数量的工作负载常见于查询数量较少但耗时较长的 OLAP 场景。对于此类工作负载,ESTune 会按预设的查询语句数量进行分段,并记录每个分段的性能指标。例如,对于一个由 22 个查询语句组成的工作负载 TPC-H,若其被分段为 22 个部分,则 ESTune 将记录针对每个查询语句的性能。

核心技术二:基于混合贝叶斯神经网络的性能预测

为了准确预测早停配置的数据库性能,ESTune 设计了混合贝叶斯神经网络(即HBNN),其整体架构如图 1 所示。

具体来说,GRU 处理由段性能数据组成的数据序列。S1,S2,…,Sl。

FNN 用来处理n个参数的取值 V1,V2, …,Vn。

BNN 则结合了 GRU 和 FNN 的输出,并预测该配置性能的均值和方差。

图1:HBNN的整体架构

核心技术三:基于 MAML 的少样本快速适应技术

由于数据库参数调优通常期望在短时间内获得满意的结果,因此只能进行有限次的迭代。然而,神经网络又通常需要依赖大量的训练数据来微调参数,以防止过拟合并实现良好的学习与泛化能力。

为了应对这一挑战,ESTune集成了MAML(Model-Agnostic Meta-Learning)算法。

该算法通过在历史调优任务上进行元训练,学习出一组优秀的初始化超参数。这使得 HBNN 能够快速适应新的调优任务,即使在“冷启动”场景下,也能通过少量迭代迅速收敛。

性能成果

论文在 MySQL 8.0 和 PostgreSQL 12.12 两个主流数据库系统上进行了广泛评估,使用了包括 TPC-C 和 TPC-H 在内的多种工作负载。实验对象涵盖了 BestConfig, OtterTune, HUNTER, LlamaTune (SMAC), OpAdviser, OBTune 和 GPTuner 等多种最先进的参数调优方法。

实验对比了这些现有方法及其集成 ESTune 后的增强版本(即ES_*)的性能。图2、图 3 和图 4 分别展示了不同场景下的调优结果,实验数据一致显示:ESTune 大幅增强了这些基线方法的调优效率。

图 2:MYSQL 在 TPC-C 工作负载上的调优结果

图 3:MYSQL 在 TPC-H 工作负载上的调优结果

图 4:PostgreSQL 在 TPC-C 工作负载上的调优结果

小结与展望

通过对性能不佳的配置引入早停机制,ESTune 成功打破了迭代式数据库调优中的效率瓶颈。具体而言,ESTune 结合贝叶斯网络,利用部分执行数据(即分段性能指标)对低效配置的最终性能进行可靠预测。

未来的工作将围绕 ESTune 在复杂动态环境下的应用展开:一是探索框架负载漂移场景下的泛化能力;二是将其扩展至云原生数据库,以支持同时优化性能、成本和稳定性的多目标调优。

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

摘要:
本文介绍如何为开源个人AI助手 Moltbot(原 ClawdBot)集成基于 OceanBase 技术栈的长期记忆插件 PowerMem。通过 HTTP API 对接,PowerMem 为 Moltbot 提供智能信息抽取、艾宾浩斯遗忘曲线调度及多智能体隔离的记忆能力,显著增强其上下文持久化与自主决策水平,实现更类人的“数字员工”体验。 

Moltbot 是什么?


Clawdbot(后更名为 Moltbot,又更名为 OpenClaw)是一款开源、以通讯为核心的AI智能体项目,运行在你自己的设备上,通过你已有的渠道(WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、Teams、WebChat 等)和你对话,支持语音、Canvas、多代理路由等。 简单点说:Moltbot 最大的特点是不仅能回答问题,更能真正“动手”操作你的电脑系统,执行命令、控制浏览器、管理文件,就像一个 7 x 24 小时在线的 “数字员工”。 

官网 :https://www.molt.bot/
github 地址:https://github.com/moltbot/moltbot
 

Moltbot 部署

方式一:NPM 全局安装

方式二:源代码安装

上面两种安装方式二选一,因为我是走的源代码安装:
1.     pnpm moltbot onboard --install-daemon 初始化

2.     同意风险
提示这里会让你确认风险。Moltbot 功能强大,能执行系统命令、读写文件、控制浏览器,但这也意味着如果配置不当或被滥用,可能会带来安全风险,请谨慎使用。

3.     选择快速开始
4.     配置 AI 模型授权,我手里头有qwen的

5.     启动web问个小问题:“查一下我的电脑型号”,很快 moltbot 回复了我机器的具体型号,虽然任务非常简单,但是还是挺惊喜的,距离“贾维斯”又进了一步了。

Moltbot 的原生记忆解读

Moltbot 的持久记忆可以概括为:「Markdown 文件为单一事实来源 + 可选向量/混合检索」。 

存储形态:纯 Markdown 文件 事实来源:模型「记得」的内容 = 写入磁盘的 Markdown;不依赖模型内部状态。默认布局(在 workspace 下,如 ~/clawd):memory/YYYY-MM-DD.md:按日期的日志,仅追加;会话开始时读「今天 + 昨天」。MEMORY.md(可选):长期、人工可维护的记忆;只在 main 私聊 session 加载,群聊不加载。 也就是说:短期、按天的记录 → memory/YYYY-MM-DD.md长期、精选事实 → MEMORY.md持久化完全靠「写进这些文件」,而不是靠对话历史本身。 

写入时机与「记忆冲刷」(Memory Flush) 平时:模型通过 工具(如 write、edit)或技能,把要记住的内容写到 MEMORY.md 或 memory/YYYY-MM-DD.md。自动冲刷:当 session 快触发自动 compaction 前,Moltbot 会跑一轮 静默的 agent 回合,专门提醒模型「把该持久化的东西写进记忆文件」,并鼓励用 NO_REPLY 不回复用户,避免用户看到这次内部回合。触发条件由 agents.defaults.compaction.memoryFlush 控制,例如在「剩余 token ≈ softThresholdTokens」时触发;每轮 compaction 只做一次 flush,并在 sessions.json 里记 memoryFlushCompactionCount 等,避免重复。 

相关代码在 src/auto-reply/reply/memory-flush.ts:shouldRunMemoryFlush():根据当前 token、context 上限、reserve、softThreshold 判断是否该 flush。

若 workspace 只读(如 sandbox workspaceAccess: "ro"),则不做 flush。 

检索层:向量 + 可选 BM25 混合检索 
数据流

实现方式 

插件控制:默认使用 memory-core 插件(可设 plugins.slots.memory = "none" 关掉)。工具:memory_search:对 MEMORY.md 和 memory/.md 做语义检索(按 ~400 token 分块、80 token 重叠),返回片段 + 文件路径 + 行号;可选开启 BM25 + 向量 的混合检索。memory_get:按路径(及可选 from/lines)读取 MEMORY 或 memory 下的文件片段,供在检索后精确拉取,控制上下文长度。向量索引:对MEMORY.md 和 memory/.md 建索引;索引按 agent 存于 ~/.clawdbot/memory/.sqlite(路径可配)。支持远程 embedding(OpenAI、Gemini 等)或本地模型(如 GGUF);可选 sqlite-vec 做向量加速。文件变更有 watcher(debounce),索引异步更新;若 embedding 模型/端点等变化,会整库重建索引。 

混搜权重分配

最终分数的计算公式非常简单(src/memory/hybrid.ts):

这意味着:向量搜索和文本三七开:最终得分 = 0.7×向量分 + 0.3×文本分(归一化后),偏重语义。候选池放大 4 倍:先取 maxResults × 4 的候选再合并、排序、截到 maxResults,提高最终 Top‑N 质量。 

Moltbot + powermem 方案


有 PowerMem VS 没有 PowerMem

集成 powermem 方案集成方式:已插件的方式进行集成

集成方式:新增插件 extensions/memory-powermem,通过 HTTP 调用 PowerMem 已启动的 API 服务;不把 PowerMem 作为库嵌入 Moltbot 进程。部署:用户需单独启动 PowerMem(如 powermem-server --host 0.0.0.0 --port 8000 或 Docker),并在 Moltbot 配置中填写 baseUrl(及可选 apiKey)。 代码结构代码地址:https://github.com/ob-labs/moltbot-extension-powermem

在 Moltbot Agent 里会暴露这些能力:memory_recall — 按查询搜索长期记忆memory_store — 写入一条记忆(可选是否智能抽取)memory_forget — 按记忆 ID 或按搜索条件删除 使用 powermem 插件 Step1: 前置条件 已安装 Moltbot(CLI + gateway 能正常用)PowerMem 服务:需要单独安装并启动(见下文两种方式,任选其一)若用 PowerMem 的「智能抽取」:需在 PowerMem 的 .env 里配置好 LLM + Embedding 的 API Key(如通义千问 / OpenAI) Step2:把本插件装进 Moltbot 在你本机执行(路径改成你实际克隆的目录):

安装成功后,可用 moltbot plugins list 确认能看到 memory-powermem。 Step3:配置 Moltbot 使用本插件 编辑 Moltbot 的配置文件(常见位置:~/.clawdbot/config.json 或项目里的 moltbot.json),在 根级 增加或合并 plugins 段,并把记忆槽指向本插件,并写上 PowerMem 的地址。 示例(JSON):

说明:baseUrl:PowerMem 的 HTTP 地址,不要加 /api/v1,就写 http://localhost:8000 或你的实际主机/端口。若 PowerMem 开了 API Key 鉴权,在 config 里增加 "apiKey": "你的key"。改完配置后重启 Moltbot gateway(或重启 Mac 菜单栏应用),配置才会生效。 Step4:验证插件与 PowerMem 连通 在终端执行:

若输出里没有报错、能看到健康状态,说明插件已连上 PowerMem。 Step5: 测试手动写入 + 搜索 我们来简单测试一下,用手动写入验证数据库是否有数据

 若搜索能返回刚写的那条(或类似内容),说明「安装 PowerMem → 安装插件 → 配置 Moltbot」全流程已打通。 下面是执行结果:

看一眼数据库,妥妥的已经写入了

 欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/  

摘要:
浙大与 OceanBase 联合提出 DeepK 调试引擎,为 LLM-based 自动程序修复提供了一种全新的思路。通过将隐含在大规模 bug-fix 数据中的调试经验显式化、结构化并系统复用,有效弥补了现有方法过度依赖隐式推理的不足,引导大语言模型从“隐式猜修复”转向“基于经验的知识驱动调试”,显著提升了自动程序修复的准确性与稳定性。

日前,由浙江大学与 OceanBase 团队联合撰写的论文:《Debugging Engine Enhanced by Prior Knowledge: Can We Teach LLM How to Debug?》被软件工程领域顶级会议 The ACM International Conference on the Foundations of Software Engineering (FSE) 2026 录用。

FSE 是软件工程领域最具影响力的国际顶级会议之一,是中国计算机学会 CCF 推荐的 A 类国际会议。本论文通过系统化提取和复用结构化调试知识,引导大语言模型从“隐式猜修复”转向“基于经验的知识驱动调试”,显著提升了自动程序修复的准确性与稳定性。

简介

随着大语言模型在代码理解与生成领域能力的不断增强,自动程序修复(Automated Program Repair,APR)逐渐成为软件工程研究的重要方向。

近年来,大量工作尝试通过提示工程、多智能体协作、示例检索或执行反馈等方式提升修复效果,并在多个基准数据集上取得了可观进展。然而,这些方法大多仍然依赖模型的隐式推理能力:模型需要从原始示例、上下文或运行结果中自行推断调试思路,而调试过程中真正稳定、可复用的知识却并未被显式建模和系统利用。

论文 DeepK(Debugging Engine Enhanced by Prior Knowledge)正是针对这一核心缺陷提出了解决方案。

作者指出,大规模 bug-fix 数据集中蕴含着丰富的调试经验,但现有方法通常只将其作为上下文示例或推理演示使用,而没有将其中的调试逻辑提炼为结构化知识。

DeepK 通过系统性地提取、验证并复用调试知识,为大语言模型提供明确的调试指导,使程序修复从“依赖模型临场发挥”转向“基于经验的知识驱动推理”。

核心理念:让调试从隐式推断走向显式知识引导

传统的 LLM-based APR 方法在设计上存在一个根本矛盾:一方面希望模型具备类似人类的调试能力,另一方面却很少向模型明确提供“人类是如何调试的”。模型虽然可以在大量示例中隐式学习模式,但这种方式缺乏稳定性、可解释性,也难以在分布外场景中保持鲁棒。
DeepK 的核心理念在于,将调试视为一种可总结、可验证、可复用的知识过程。它不再把修复行为简单等同于补丁生成,而是将调试拆解为两个紧密协同的部分:对错误根因的理解,以及围绕该根因展开的修复策略。通过显式建模这两类调试知识,DeepK 试图为大语言模型提供类似“资深程序员经验”的指导,使其在面对新 bug 时能够遵循已有的成功调试路径进行推理,而非从零开始试探。

图 1. DeepK 的 4 阶段架构

核心技术一:基于 AST 的编辑描述生成与调试语义对齐

在从历史 bug-fix 数据中提取调试知识时,一个关键挑战在于如何避免被低层次的代码差异所干扰。直接对比 buggy 与 fixed 代码往往会产生大量琐碎、语义不明确的修改信息,难以反映真实的调试逻辑。

为此,DeepK 引入了一种基于抽象语法树的编辑描述生成机制,将代码层面的差异转化为人类可读、具有步骤感的自然语言编辑描述。

该机制通过分析两版代码的 AST 结构,定位真正与错误修复相关的修改位置,并过滤掉不合理或无关的编辑操作,从而生成更符合人类调试习惯的修改描述。这一过程有效弥合了“代码补丁”与“调试思维”之间的鸿沟,为后续调试知识的抽取提供了清晰、语义化的输入。

图 2. 代码编辑描述生成工具

核心技术二:结构化调试知识的抽取、验证与知识库构建

在获得编辑描述后,DeepK 进一步引导大语言模型围绕“如何定位并修复该 bug”生成结构化调试知识。模型需要明确指出错误的根因,并给出一步步的调试与修复策略。与以往方法不同的是,DeepK 并不直接接受模型生成的结果,而是引入了验证机制:模型必须仅基于自己生成的调试知识重新修复程序,并通过测试用例验证其正确性。只有能够稳定指导修复成功的知识,才会被纳入最终的调试知识库。

在知识组织层面,DeepK 采用多视角索引策略,从任务描述、程序结构以及执行轨迹等多个维度刻画每一条调试知识,使其能够在面对不同类型的新 bug 时被准确检索。这种多维度设计避免了单一相似度度量带来的偏差,使知识检索既具备语义相关性,又保留结构与运行层面的信息。

图 3. 结构化调试知识抽取

核心技术三:先验调试知识增强的程序修复流程

在实际修复新 bug 时,DeepK 并不替代现有 APR 系统,而是以“调试知识增强模块”的形式融入其中。当系统接收到新的 buggy 代码后,会从知识库中检索出最相关的调试知识,并将其注入模型的推理阶段,引导模型围绕已验证的调试思路展开修复。

这种设计使 DeepK 能够自然地与不同类型的 APR 系统集成,无论是基于提示与检索的非智能体方法,还是基于脚本化流程的修复框架,都可以从中受益。

通过这种方式,程序修复过程不再依赖单次推理的偶然成功,而是建立在大量历史调试经验的积累之上,使模型的行为更加稳定、可解释。

性能成果

在 ACPR 与 AtCoder 等多个基准数据集上的实验结果表明,DeepK 在不同模型后端(GPT-4o与 DeepSeek-v3)下均能显著提升现有方法的修复准确率。在分布内场景中,DeepK 相较最强基线方法取得了稳定的绝对提升;在更具挑战性的分布外竞赛编程任务中,其相对提升尤为显著,显示出结构化调试知识在应对分布偏移时的独特价值。

图 4. DeepK 与其他基准方法的对比

进一步的消融实验验证了各个设计组件的重要性。结果显示,对调试策略的显式建模对性能提升贡献最大,多维度检索机制显著增强了系统的鲁棒性,而基于 AST 的编辑描述在复杂程序修复中发挥了关键作用。同时,实验还揭示了调试知识数量与性能之间的权衡关系,表明适量、精准的知识注入比简单堆叠上下文更加有效。

图 5.知识库索引构建的消融实验

图 6. 结构化调试知识的消融实验

图 7. 代码编辑描述工具的消融实验

图 8. 调试知识数量与调试性能的关系

结语

DeepK 的工作为 LLM-based 自动程序修复提供了一种全新的思路。通过将隐含在大规模 bug-fix 数据中的调试经验显式化、结构化并系统复用,该框架有效弥补了现有方法过度依赖隐式推理的不足。

在实践中,DeepK 在多种数据分布与模型设置下均展现出稳定的性能提升,并显著增强了修复过程的可解释性与鲁棒性。

这项研究表明,相比不断扩展模型规模或复杂化推理流程,让模型掌握可复用的调试知识可能是一条更加稳健、可持续的路径,也为未来构建更可靠的软件智能系统奠定了坚实基础。

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

摘要:
中国联通使用的传统集中式数据库面临高并发、扩展难、运维复杂等痛点,于是其与 OceanBase 构建“企业版核心承载 + 社区版自主创新” 双轨体系,现已全面覆盖联通 B 域(业务支撑)、O 域(运营支撑)、M 域(管理支撑)全场景。其中,OceanBase 企业版攻克运营商最核心的B域40% 生产系统,支撑全球最大规模 “全国大集中” 核心业务。

当超 4 亿用户的通信消费、5G 服务、政企业务全部汇聚于 “全国一套系统”,当传统数据库的性能瓶颈,遭遇数字时代的 “数据海啸”,自研数据库如何扛起全球最复杂的电信核心业务?

近日,中国联通软件研究院(简称 “联通软研院”)与 OceanBase 的四年深度合作交出了震撼行业的答卷:

双方打造的 “企业版核心承载 + 社区版自主创新” 双轨体系,已全面覆盖联通 B 域(业务支撑)、O 域(运营支撑)、M 域(管理支撑)全场景,累计部署节点超 1000个。其中,OceanBase 企业版攻克运营商最核心的 B 域 40% 生产系统,支撑全球最大规模 “全国大集中” 核心业务;基于OceanBase 社区版自研的 CUDB 数据库规模化上线数百套系统,更以 AI 向量数据库创新应用 ChatDBA,为运营商智能化转型提供了可复用的创新方案。

这场合作见证了自研数据库技术从 “入局” 到 “破局” 再到 “引领” 的华丽转身。

破局 “全国大集中”:超 4 亿用户核心系统的分布式升级革命

在电信行业 “省集中” 为主流的格局下,中国联通率先推行 “全国大集中” 战略,以一套 cBSS 系统承载 31 省全业务、全客户、全渠道服务,支撑超 4 亿用户的 CRM、计费、结算等核心场景 —— 这是全球电信行业单体承载用户最多、集中化程度最高的业务支撑系统,其技术升级难度堪称 “在飞行的飞机上换引擎”。

此前,该系统长期依赖传统集中式数据库,即便后续升级为 “中间件 + 数据库” 架构,仍面临高并发性能瓶颈、扩展性不足、运维复杂等致命痛点:月初缴费高峰时 “一省慢、全国卡”,5000 万用户基数就触达集中式数据库性能上限;31 省业务 “共性收敛与个性保留” 难以平衡;复杂存储过程与多数据库类型导致升级改造难如登天。

OceanBase 的分布式架构成为破解困局的关键。作为 “全国电信唯一大集中核心业务支撑系统国产升级” 案例,OceanBase 企业版通过三大核心能力实现突破:

一是 “两地三中心” 部署模式,以Paxos 协议分布式一致性机制,实现 RPO=0(数据零丢失)、RTO<30秒的金融级容灾,相比传统集中式数据库的主备架构,容灾建设成本降低 50% 以上,支撑核心业务全年 7×24小时无间断运行;

二是多租户弹性扩缩容技术,将全国上千个节点物理资源池化,按业务需求动态分配 CPU、内存、IO,彻底解决资源争抢问题,计费中心查询性能提升 60%,政企中台并发处理能力翻倍,资源利用率从不足 40% 跃升至 80% 以上,硬件成本降低 60%;

三是深度兼容特性,完美适配 MySQL 与 Oracle 语法,让复杂存储过程、冷僻 SQL 语句无需大幅改写,实现 ERP 系统零改造平滑升级,B 域核心系统整体升级改造成本降低 70%。

更具创新性的是,基于 OceanBase 多租户能力构建的 “一库多服” 架构:通过镜像库将 10 余个业务中心的高负载查询请求从生产库剥离,既保障 “全国一套账” 的统一管理,又能灵活响应各省 5G 用户增长分析、政企客户关联图谱等个性化需求,仅用 1 周就完成所有数据库升级同步,成为支撑业务运营的数据枢纽。

自主创新加码:CUDB 引领开源生态规模化落地

在核心业务升级的同时,联通软研院并未止步于 “使用者” 角色,而是向 “开发者”“创新者” 转型。

2021 年 OceanBase 开源后,联通软研院仅用 13 个月就完成社区版深度优化,打造出分布式 HTAP 数据库产品分布式 CUDB,成为基于 OceanBase 社区版的最大规模应用案例。截至 2025 年 6 月,分布式 CUDB 已承载数百个业务应用,部署节点超 200 个,管理原始数据量近 300TB,广泛覆盖 O 域、M 域各类场景。

为解决传统 MySQL 多版本分散、升级低效的痛点,自研 MySQL 与分布式 CUDB 双向数据迁移工具,实现 10 万条 / 秒的升级速度 —— 这是社区版 OMS 的 3 倍、同类产品 DataX 的 5 倍,已累计完成 25TB + 数据升级,兼容性与效率均处于行业领先水平。

同时,分布式 CUDB 全面接入联通云,实现 “一点开通、一点交付、一点监控、一点运维、一点操作” 的一站式服务,大幅提升云租户使用体验与运营效率。更值得关注的是,联通软研院在合作中累计向 OceanBase 开源社区贡献代码超万行,输出数据库事务日志精准恢复、云存储备份对接等核心能力,实现 “使用开源、贡献开源” 的良性循环,推动数据库生态协同进化。

AI + 数据库融合:ChatDBA 树立智能化转型新范式

2025 年,AI 成为数字化转型的核心驱动力,中国联通软研院聚焦 AI 向量数据库等前沿领域,基于 OceanBase 完成数据库智能专家 ChatDBA 的底层架构升级,破解了大模型落地的关键痛点。作为基于 RAG(检索增强生成)技术构建的 AI 应用,ChatDBA需整合海量数据库专业知识与运维经验,传统架构存在扩展性不足、运维复杂、资源利用率低等问题。

经过对主流向量数据库的全面测评,OceanBase 的一体化能力脱颖而出:其支持关系型数据、向量数据等多类型数据混合存储查询,可处理最高 16000 维稠密向量,在 768 维 100 万数据集下检索性能是主流向量数据库的 3-6 倍;分布式架构保障高并发与故障自动恢复,多租户技术实现资源隔离,搭配完善的管控与迁移工具,大幅降低运维成本。

依托这些优势,ChatDBA 仅用两周就完成适配改造,硬件资源成本直降 30%,运维人力成本同步降低,问题解决效率显著提升,成为运营商领域 “AI + 数据库” 深度融合的标杆范例。

从核心业务分布式升级的 “破冰”,到开源生态自主创新的 “深耕”,再到 AI 一体化架构的 “引领”,中国联通软研院与 OceanBase 的合作不仅实现了量化的降本增效,更构建了 “自主创新、安全稳定、智能高效” 的数字基建新范式。

联通软研院相关负责人表示,未来将持续扩大合作范围,深化向量数据库、多模数据融合等领域创新。OceanBase 也将以此次合作为基础,持续迭代升级,适配电信行业核心需求。

这场跨越四年的深度合作,不仅为中国联通 “数字服务使能者” 转型筑牢技术底座,更向全行业证明:自研数据库已具备支撑全球最复杂核心业务的能力。

这一点在 OceanBase 过去五年的实践中得以充分验证:自 2020 年商业化以来,OceanBase 已在运营商领域实现从“点上突破”到“面上开花”的转变,深度服务中国联通、中国移动、中国电信三大运营商,覆盖 B/O/M 全业务域。在今年 9 月举行的中国通信展上,凭借在通信行业扎根沉淀的实践优势和技术创新能力,OceanBase 联合运营商打造的五个标杆案例获得由中国通信企业协会评选的“一等案例”荣誉。这些成绩的背后,是 OceanBase 作为运营商“可信赖基石”地位的奠定。

当每一通电话、每一笔交易、每一次 AI 交互都运行在自主研发的数据库上,我们看到的不仅是技术自立自强的硬核实力,更是数字化的坚实底气 —— 自研数据库正在从幕后走向台前,重新定义数字时代的数据库核心标准。

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

摘要:
爱奇艺卡券业务原采用 “MySQL 分库分表 + ES 异步同步” 架构,面临 TP/AP 分离导致的架构复杂、AP 查询分钟级延迟、数据一致性隐患等问题。如今借助 OceanBase 的 HTAP 能力,将 AP、TP 业务融合到一个数据库,在架构简化、成本控制与效率提升方面均取得了突破。

爱奇艺是国内知名的在线视频平台,每年都会推出上百部优质长视频内容,其中不乏如 2023 年现象级爆款《狂飙》这样的佳作。近两年,随着短视频、微剧的兴起,平台年处理视频内容数量级从上百部直接跃升至上万部。

每一部内容从立项、拍摄、生产、制作到上线播出,均需经过复杂流程,并依赖上百个业务模块协同支持。卡券业务是出于整个业务生态里面的中台位置,对上提供中台能力,如为创新型业务会员、云影院提供商业化变现和用户转化营销工具。

过去,卡券业务系统将 AP(分析处理)与 TP(事务处理)业务分开处理,架构复杂,需要较高的维护成本;如今,借助 OceanBase 的 HTAP 能力,将 AP、TP 业务融合到一个数据库,在架构简化、成本控制与效率提升方面均取得了突破。

解构卡券业务的数据架构困境

卡券是爱奇艺核心的营销与促销工具,贯穿爱奇艺的会员购买、云影院观影等商业化变现全链路。其底层数据库的性能直接关乎用户体验与业务敏捷性。

例如,促销发券、会员领券等场景均需要业务系统提供高并发事务处理(TP)能力。而在运营侧,则需要实时统计和分析发券数量、会员领券等指标,以便评估活动效果、优化营销策略,这依赖于高效的数据分析(AP)能力。

过去,卡券业务系统采用的是“MySQL 分库分表+ES 异步同步”的复杂架构:分库分表的 MySQL 来承载 TP 业务,以应对高并发海量请求;Elasticsearch(ES)来完成统计分析等 AP 类业务。

“这个卡券业务的架构基本上能为业务需求提供足够的支撑。不过,我们并不满意,一直在寻找新的解决方案。”爱奇艺高级总监张冲表示。

其最重要的原因就在于系统架构过于复杂,虽能满足业务需求,但每一个节点都需要研发投入大量精力维护,顶峰的时候研发资源占比近 80%,严重挤占了业务创新资源。

具体而言,在 TP 业务方面,通过分库分表的 MySQL 集群支撑高并发交易,但实际日常资源利用率仅约 10%,资源冗余明显。在 AP 业务方面,ES 进行运营统计分析时的数据源自订阅多个 MySQL 实例的 binlog,经消息队列 RMQ 异步同步至 ES,链路冗长,存在分钟级延迟。并且 ES 的清理归档代价较高,Reindex 开销也比较大。

此外,数据的一致性与准确性面临挑战,在异步同步过程中,甚至出现过 UV(访客数量)超过页面点击的异常,统计准确率难以保障。

张冲坦言,对现有架构进行升级更深层的原因,源于对技术进步的持续追求。“我们希望技术上再往前走一走,要和互联网行业最先进的技术保持对齐。”

从“分库分表+ES”到“单库双擎”,爱奇艺 HTAP 架构升级实践

随着新技术趋势的出现,爱奇艺也开始寻找能够简化架构、支撑业务更好发展的新发展。数据库的升级是这次架构升级的关键。

对于新一代数据库,爱奇艺提出了明确的要求:

第一,必须是一款兼顾 TP、AP,具备 HTAP 能力的数据库产品,无需管 MQ,无需处理异构的数据,尽量减少对数据平台的依赖,以简化数据底座;

第二,总体成本可控,和现有架构相比成本不能上升,符合公司降本增效的目标;

第三,云中立,在遇到故障的时候可以实现云逃逸,且在不同的云上均可提供一致性的服务。

根据上述三个基本要求,经过对多款主流数据库产品的调研与测试,OB Cloud 一体化云数据库凭借其卓越的性能与高度契合的需求满足度,赢得了爱奇艺的青睐,并且在高并发、高可用、安全、数据治理、低成本等方面的技术积累,都被浓缩到 OB Cloud 一体化云数据库的产品中。

张冲表示:“OceanBase 不仅提供了真正的 HTAP 融合能力,其原生分布式架构还与我们的云原生战略高度契合。同时,OB Cloud 在百度云上开服也是一个重要契机,因为爱奇艺的系统平台就部署在百度云上。”

完成数据库选型之后,爱奇艺迅速开始了数据和架构升级的准备工作。

升级工作分为两个阶段:

AP 升级:将 ES 集群中的百亿文档升级至 OB Cloud 集群。通过双写、迁移历史数据、切读、停双写等步骤,不仅完成数据升级,还从业务层面进行了逻辑去冗余和简化。最终,资源成本下降 60%,运营查询类 SQL 基本在 1 秒内返回。

TP 升级:将 16 个物理机数据库从原生 MySQL 分库分表形态升级至 OB Cloud 集群。借助 OceanBase 的 OMS 同步工具,顺利完成海量数据同步与校验工作。最终,存储成本下降 80%,且系统具备弹性伸缩能力,无需为大促提前预备资源。

张冲表示,为了尽量减少对业务的干扰,保持业务稳定性,升级过程尽可能少地修改代码,他们采取了一些措施:

  1. 汇聚到 OceanBase 的分区表、分区键与原来的分片逻辑一致,使得业务系统零改造切换;
  2. 保持 AP 业务不变,仅修改数据源订阅,通过全兼容的 binlog 直接订阅到同租户的 AP 表。此时还是多份存储,但依靠高压缩比,整体存储成本没有上升;
  3. 将 TP 业务的表异步修改为行列混存,不影响业务稳定性,同时运营统计只需简单修改库和表名即可快速上线。通过多副本读写分离,最终实现了单库双擎、支撑实时在线业务与数据分析的简洁架构。

化繁为简,打造卡券业务的现代化数据库底座

经过升级改造后,卡券业务系统架构变得非常简洁,只有基本的业务服务和数据中台的数据交互,不再需要维护额外的数据流服务,也无需担心存储不足等问题,归档清理的周期也相应延长,研发人员得以更加聚焦于业务需求的开发。

张冲表示,卡券业务系统架构升级带来了如下好处:

首先,链路极大简化。 去除了 MySQL 到 ES 的异步同步链路,消除了 ES 集群的运维与成本;张冲特别感慨此次架构的升级带来的简化,他表示“简单到只有计算、只有存储,简单到有点像互联网刚开始发展的那个阶段。”

其次,分析效率提升。 常规 AP 查询可直接在 OB Cloud 中完成,时间也从原来的准实时变成了实时,所有统计 SQL 的响应时间(RT)均小于 1 秒,性能大幅提升。而 BI 类需求以前需要数据中台部门支持,属于跨部门协作,最快也需数天;现在本部门内部就能完成,时间缩短为 2-3 天;

第三,存储成本显著节省。 借助 OceanBase 的高压缩能力,相比 MySQL 的存储成本下降了 80%,并且它可以弹性伸缩,不再需要提前为大促预备过量资源。

“相对于之前的架构,现在的架构非常简洁。这要得益于 OceanBase 把高并发、高可用、安全、数据治理、低成本等各种技术积累都浓缩到了这个数据库产品中。”张冲这样评价。

小结

张冲表示,未来爱奇艺计划将 OceanBase 的实践推广至更多在线交易型业务,如订单支付、会员中心等,并逐步探索其在 KV 存储、向量检索等场景的应用。

面对 AI 浪潮,张冲也提出了对未来数据库的期待:“知识图谱、AI 工作流等复杂场景,需要更智能的底层数据支撑。希望 OceanBase 能在这些方向持续演进,成为企业智能化转型的数据基石。借助 OceanBase 技术的不断完善和应用场景的拓展,爱奇艺将在科技创新的道路上走得更远。”

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

摘要:
OceanBase联合中国人民大学数据库团队的数据库缺陷实证研究,被软件工程顶刊IEEE TSE录用。该研究首次构建了面向开源关系型数据库的细粒度缺陷分类体系,共获得12 项发现,为RDBMS系统的开发维护和测试提供了重要启示。研究发现,涉及SQL数据类型及数据库触发器、存储过程、参数设置等复杂功能的缺陷现有测试工作无法有效触发,这一发现为提升RDBMS缺陷检测能力提供了显著改进空间。

日前,由 OceanBase 联合中国人民大学数据库系统研究团队(刘爽副教授)对主流关系型数据库系统缺陷开展的实证研究《A Comprehensive Study of Bugs in Relational DBMS》被软件工程领域顶级期刊 IEEE Transactions on Software Engineering(TSE) 正式录用。

IEEE TSE 是 IEEE 旗下软件工程方向的权威期刊。在数据库缺陷实证研究方面,本论文首次系统分析了 MySQL 等三个开源数据库中 777 个真实缺陷,揭示了 RDBMS 的缺陷在根因、表症等方面的特点,以及现有测试工具在深层语义缺陷检测上的局限性。

以下为论文介绍。

简 介

本研究通过“系统性实证分析”揭示主流关系型数据库在真实场景中的缺陷规律。研究覆盖 MySQL、SQLite 和 openGauss 三大系统中 777 个高质量修复缺陷,深入剖析其根本原因、症状表现、分布特征及其关联性。

其核心贡献在于:首次构建了面向开源关系型数据库的细粒度缺陷分类体系,研究共获得 12 项发现,为 RDBMS 系统的开发维护和测试提供了重要启示。研究发现,涉及 SQL 数据类型及数据库触发器、存储过程、参数设置等复杂功能的缺陷现有测试工作无法有效触发,这一发现为提升 RDBMS 缺陷检测能力提供了显著改进空间。

方法与分类体系


表1:采集 bug 的统计信息

本研究通过一套严谨的实证方法对关系型数据库中的真实缺陷进行系统性分类与归因。围绕三个核心维度展开:根因、症状和修复模块。研究团队从 MySQL、SQLite 和 openGauss 的官方仓库中收集了 2018 至 2023 年间报告的 2495 个缺陷,经过严格筛选后构建了一个高质量的 777 个缺陷数据集。

在此基础上,作者提出了一套四维分析框架:

根因维度识别出 12 类根本问题(如错误逻辑、API 误用、类型处理缺陷等);
症状维度归纳了包括错误结果、崩溃、死锁、性能退化等行为;
模块维度定位缺陷修复位置(如解析器、优化器、执行引擎、存储层等);
关联性进一步探索三者之间的关联规律,例如“类型相关根因多导致错误结果,且集中于表达式求值模块”。

为确保标注一致性,两名研究人员独立完成全部标签分配,并通过 Cohen’s Kappa 系数评估达成共识。该方法不仅保证了分析的客观性,也为后续数据库测试工具的设计提供了可操作的指导依据。

结果与分析

研究揭示了多项关键发现。首先,在根因分布上,“不正确的代码逻辑”占比最高达 32.3%,“类型处理缺陷”和“API 误用”分别以 9.0% 和 8.4% 的比例成为第二、第三大类根因。其次,在症状表现方面,“结果不一致”是最普遍的症状,占全部缺陷的 42.99%,且往往无崩溃、无报错,具有极强的隐蔽性。


图1:按根本原因划分的缺陷分布

进一步的跨系统对比显示:MySQL 与 SQLite 在缺陷模式上高度相似,而 openGauss 因架构差异与活跃开发状态,表现出显著不同的缺陷谱系。这些结果不仅刻画了数据库内核的脆弱面,也为未来高可靠数据库的设计与质量保障工作指明了方向。


图2:症状与根因的关系

概念验证工具 SQLT

研究中观察到类型相关缺陷在数据库 bug 中占比显著,团队开发了一个概念验证工具 SQLT,用于针对性挖掘此类问题。SQLT 强化了对跨数据类型表达式、隐式类型转换以及非标准类型(如 BIT、JSON)组合的查询生成能力。

该工具通过比对语义等价查询的执行结果,能够有效识别那些不触发崩溃但返回错误结果的静默逻辑缺陷。在实验中,SQLT 不仅成功复现了多个已知类型 bug,还新发现 8 个此前未被报告的问题,其 5 个已被 MySQL、SQLite 和 openGauss 官方确认并修复。


表2:SQLT检测到的缺陷

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

摘要:
OceanBase联合成都信息工程大学的数据库缺陷实证研究,被软件工程顶刊IEEE TKDE录用。研究聚焦复杂工作负载下数据库参数自动调优的效率与泛化能力问题,提出一种分层协作的多智能体框架,通过创新的训练机制与协同策略,有效破解传统调优方法的瓶颈,为数据库性能优化和预测提供了兼具理论创新性与工程实用性的技术方案。

近日,成都信息工程大学与 OceanBase 研发团队合作完成的研究《CMA+DB: How to Automatically Tune Database Parameters through Collaborative Multi-Agents》,被《IEEE Transactions on Knowledge and Data Engineering》(TKDE,CCF A 类、SCI 一区)录用。

研究聚焦复杂工作负载下数据库参数自动调优的效率与泛化能力问题,提出一种分层协作的多智能体框架,通过创新的训练机制与协同策略,有效破解传统调优方法的瓶颈,为数据库性能优化和预测提供了兼具理论创新性与工程实用性的技术方案。

以下为论文介绍:

研究背景与挑战

随着分布式与云计算技术的发展,数据库工作负载日趋多样化、复杂化。从高并发的在线交易场景(TPC-C),到随机读写的云服务场景(YCSB),再到高实时性的社交互动场景(Twitter),不同场景对参数配置的需求差异显著。

传统调优方式逐渐难以适配这些实际需求:人工调优高度依赖 DBA 的专业经验,不仅需要耗费大量时间梳理参数关系,而且无法应对动态变化的工作负载,往往出现 “调优即过时” 的问题;搜索式调优方法依赖启发式规则,在简单场景下表现尚可,但面对多参数交互的复杂场景时,搜索空间急剧扩大,调优效率大幅下降;贝叶斯优化方法需要手动筛选关键参数,若参数定义不全面,难以找到最优配置;现有强化学习调优方法多采用单智能体设计,仅能对参数进行粗粒度调优,无法充分挖掘不同类型参数间的深层交互影响,调优精度和泛化能力受限。

如何实现参数调优的自动化、精准化与高效化,成为数据库领域亟待解决的关键问题。


图1 数据库参数调优主要步骤

核心理论创新:CMA+DB 多智能体协作框架

CMA+DB 框架以 “分类协作、分层训练” 为核心设计理念,构建了三级递进式训练机制,整合单智能体预训练模型 SAPM、多智能体联合训练模型 MATM 与基于概率选择的联合训练模型 PJTM,既保障了单个参数类别内的调优深度,又实现了跨类别参数的协同优化。

三个子模型并非孤立存在,而是以级联方式递进工作,前一阶段的训练成果直接作为后一阶段的输入,形成 “基础专精—交互探索—精准强化” 的完整调优链路,确保框架在参数交互捕捉、调优效率与泛化能力之间实现最优平衡。


图2 CMA+DB 模型工作原理

在技术实现上,CMA+DB 基于深度确定性策略梯度(DDPG)与多智能体深度确定性策略梯度(MADDPG)构建核心算法架构,采用 Actor-Critic 网络结构实现智能体的决策与优化。每个智能体都具备独立的观测空间与动作空间,通过与数据库环境的持续交互获取反馈,不断优化参数调优策略。


图3 多智能体 Actor 和 Critic 网络结构

在第一阶段,提出单智能体预训练模型 SAPM。训练初期,每个 Agent 负责调优一类功能或参数级别相似的参数,目的是探究单个 Agent 对数据库性能的影响,进而优化其网络,使得其神经网络偏向于调节重要参数。该过程 Agent 之间相互不影响。与传统的单智能体模型相比,SAPM 模型的优点在于更深入地探究相似参数之间的关系,也更容易识别出一些重要参数。

这一阶段对于识别关键参数和实现快速收敛至关重要。通过使智能体能够初步掌握参数调整策略,SAPM 为后续更复杂的多智能体训练奠定了坚实的基础,并减少后续阶段的耦合干扰,从而提高了整体效率和效果。

在第二阶段,提出多智能体联合训练模型 MATM,在 MATM 模型训练阶段,使用组合算法将多个 Agent 的预测动作组合并映射为一组数据库的推荐配置,要求 Agent 之间不能存在相同的数据库参数。

这种协作方法不仅增加了可调参数的数量,还显著增强了模型的表现力和调整能力。此阶段虽然存在耦合,但通过联合训练,能够让智能体逐步适应彼此的行为模式,实现协同优化。

在第三阶段,提出了联合动作概选模型 PJTM,在 SAPM 和 MATM 模型训练之后进行训练,算法为每个 Agent 设置了一个概选因子 Pi, Agent 根据 Pi,随机地参与联合动作推荐。当一个 Agent 控制的数据库参数对数据库性能的提升微乎其微时,就可以根据 Pi 减小该 Agent 的动作参与,进而降低其对其它 Agent 所做动作的负面影响。这一机制有效减少了低影响智能体对整体调优过程的干扰,缓解了耦合带来的负面影响。

基于上述三种方式,提出协作型多智能体模型 CMA+DB,其整合 SAPM、MATM 和 PJTM 模型进行分阶段训练,实现分功能、分级别地对数据库参数进行调优。探究了相同类型参数之间的相互影响以及不同类型参数之间的协作关系。有效地解决了离散环境和异步反馈的挑战,确保多个智能体的动作是协调的,并针对数据库性能进行了优化,提高了数据库参数的调优数量,提升了数据库参数调优的效率。

关键验证成果

相关研究成果已在 PostgreSQL 数据库环境下,在 TPC-C、YCSB、Twitter 三种典型工作负载上,与主流调优方法进行全面对比验证,核心性能指标表现突出且稳定。

在调优效率方面,CMA+DB 的收敛速度优势显著。在 TPC-C 高并发交易场景中,这一优势尤为明显,CMA+DB 的平均收敛速度(达到最大吞吐量时)优于其他三种算法。能帮助数据库更快脱离性能波动期,进入最优稳定状态,大幅缩短调优耗时,降低系统上线或扩容后的性能适配成本。

在性能提升方面,CMA+DB 展现出持续优化的能力。经过 SAPM 预训练后,框架的吞吐量已优于现有部分主流方法;后续经 MATM 的跨类别参数协同优化,以及 PJTM 的精准强化,在 TPC-C 场景下,其延迟显著低于 OtterTune、CDBTune+ 等方法,有效保障了系统在峰值压力下的响应稳定性,避免了因参数配置不当导致的延迟突增问题。

在泛化能力方面,CMA+DB 表现出极强的适应性。实验结果表明,不同参数规模与智能体数量的组合测试显示,CMA+DB 能够根据实际场景灵活调整,无需人工干预即可适配不同规模的数据库参数调优需求,解决了传统方法在参数规模变化时泛化能力下降的问题。

总结与展望

作为一种兼具理论深度与工程价值的数据库参数自动调优方案,CMA+DB 框架通过多智能体分类协作与分层训练的创新设计,有效解决了传统方法在参数交互探索、调优效率与泛化能力上的短板,为 AI 赋能数据库优化领域提供了新的技术思路。

该框架的核心优势在于,不但实现了参数调优的自动化与精准化,而且无需依赖大量人工干预与领域知识,降低了数据库性能优化的门槛,具备较强的应用价值。

未来研究将进一步优化框架结构,通过算法改进降低计算复杂度,提升框架在超大规模参数场景下的运行效率;同时,将尝试适配 MySQL、OceanBase 等更多主流 DBMS,针对不同数据库的内核特性调整智能体的参数分类与协作策略,推动相关技术在金融、电商、社交等实际生产环境中的广泛应用,为数据库系统的性能优化提供更高效、更通用的解决方案。

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

墨天轮社区举办的 【文档悬赏令】系列活动,每次聚焦一个主题,征集真实、可操作的第一手文档,希望能扩充社区文档资源、为更多人提供有用的参考资料,让技术学习少走弯路!

第2号悬赏令活动主题:数据库巡检方案实践

数据库巡检是保障业务稳定运行的核心运维环节,更是DBA日常工作的重中之重。当前数据库类型、场景十分丰富,多数从业者需耗费大量时间整理巡检清单、调试巡检流程。墨天轮社区第二期【文档悬赏令】活动特围绕这一主题发起有奖征集活动,诚邀您上传实用、可落地的数据库巡检文档,和社区众位DBA们互帮互助,让巡检工作更高效、更标准!

一、活动时间

2026 年 1 月 26 日 - 3 月 28 日

二、文档要求

1、主题范围

本次征集聚焦 “数据库巡检” 核心主题,覆盖国内外主流数据库,基础巡检、专项巡检、自动化巡检等多类实用方案等均可,具体范围如下:

巡检主题细分(包含但不限于):

  • 基础巡检:日常运维巡检表/巡检清单/巡检手册
  • 专项巡检:性能监控与优化巡检/灾备状态巡检/单机or集群巡检
  • 方式:手动巡检标准化文档/自动化巡检/脚本命令/巡检工具

数据库不限

  • 商业数据库:Oracle、SQL Server等
  • 国产数据库:达梦DM8、人大金仓KingbaseES、OceanBase等国产库
  • 开源数据库:MySQL、PostgreSQL、Redis等开源库

2、合格要求与格式

文档内容需明确巡检目的、适用场景、巡检流程等,包含巡检相关代码(部分敏感信息可隐去)。

  • 页数要求:≥5 页
  • 必加标签:上传时需在 “标签” 栏填写 “数据库巡检” + 数据库种类(如 Oracle、OceanBase) 两个标签
  • 支持格式:优先推荐 .doc、.pdf、.ppt、.md、.txt 格式(可支持前 5 页预览,下载率更高);也可上传 .zip (需附内容说明);
以下文档将被判为不合格:
1)主题无关:非“数据库巡检”相关主题
2)内容搬运:直接上传电子书或产品官方文档、他人演讲PPT,或直接复制抄袭、全文搬运网站其他文章/文档内容(已发布的文章内容不可以同时上传成文档参与活动,但如果是您曾发在其他网站的内容则可以上传参与)
3)流水账或凑字数:文档页数需≥5页,但不可通过凑字数、使用大量无关图片占篇幅等
4)作者刷量:不可刷数据-我们鼓励作者自发宣传自己的文档,但不可使用人工刷量、注册小号刷量等方式提高下载量;不可将文档拆分多份上传,导致单份内容无实际意义、缺乏完整性
5)重复文档:重新上传以前发布的文档系统会自动识别判定为重复仅自己可见,也不可删除旧文档后重新上传

三、上传步骤

  1. 登录上传:登录墨天轮账号后,点击链接直达上传页:https://www.modb.pro/docUpload,或在首页下拉框点击 “传文档”;

  1. 填写信息

    • 标题:建议明确标注 “数据库种类 + 巡检场景”(如《MySQL数据库巡检手册》《Oracle数据库常规巡检项目和命令》),帮助他人快速判断主题
    • 标签:上传时需在 “标签” 栏填写 “数据库巡检” + 数据库种类(如 Oracle、OceanBase) 两个标签
    • 墨值设置:支持免墨值 / 5 墨值 / 10 墨值 / 25 墨值 / 50 墨值 / 100 墨值,设置墨值后,他人下载时支付的墨值将实时计入您的账户(ps:一般来说墨值越低下载门槛越低,被下载可能更高)

  1. 提交:确认信息无误后点击 “提交文档”即可。于 “控制台-内容管理-我的文档” 处可查看您所有文档明细,若您遇到“仅自己可见”“转换失败”等状态可询问墨天轮小助手(VX:modb666)询问具体原因。

四、奖励设置

本次活动奖励分为 “合格奖”“有效助人奖”“巡检先锋奖” 三类

1、合格奖

每位用户每日首次上传≥5 页的合格文档,可自动触发 “每日任务” 获 5 墨值。此外,本次活动奖励额外可叠加,根据用户合格文档数量发放不同等级的墨值奖励,具体如下:

合格数量墨值
0-3个10墨值/份
3个以上15墨值/份

2、有效助人奖

根据单个文档下载数发放不同等级的墨值奖励,每个用户最多可有5个文档获得本项奖励:

被下载数墨值
30<被下载数 ≤ 5050墨值
50<被下载数 ≤ 100100墨值
100<下载数 ≤ 150200墨值
150<下载数 ≤ 200300墨值
下载数>200500墨值

3、巡检先锋奖

将综合评估用户上传的合格文档的内容质量及总下载量,评选出 “既多产、又优质” 的核心贡献者,发予相应奖励:

奖项等级奖励内容
第 1 名1000 墨值 + 100元内数据库实体书一本
第 2 名500墨值 + 爱国者U盘(128GB 双接口)
第 3-5 名笔记本电脑支架(可旋转)

说明:三类奖项单独评奖、每位用户可重复获得。其中新版本先锋奖数量将根据实际参与情况灵活调整,若参与情况佳则可能增设、反之亦然。

五、奖励公布与发放

  1. 进度公示:为了让大家更加了解自己的参与进度,将在活动期间不定期在活动原文评论区公布最新合格情况。若发现违规行为也欢迎向工作人员反馈,一经核实将取消其参与资格。
  2. 结果公布:活动结束后 3 个工作日内公布所有获奖名单;
  3. 奖励发放:墨值将在结果公布后 1-2 个工作日内发放至账户;实物奖励将通过私信收集地址,10 个工作日内寄出。

常见问题(Q&A)

Q1:如何让我的安装文档下载率更高?
A:建议在标题、简介中写明 “适用版本 + 核心亮点”,若上传的是.zip 等无法预览的格式,可在评论区附关键步骤截图或内容大纲,帮助他人判断价值。

Q2:墨值可以干什么?
A:墨值是墨天轮社区的“通用货币”,可以用来下载付费文档、赞赏他人文章或进行提问赞赏、直播打赏、兑换商品、参与墨值拍卖等。具体可查看使用说明:https://www.modb.pro/db/446902

Q3:我的文档会被展示在哪里?
A:文档上传成功后可在您的控制台、个人主页找到相应链接。管理员也会择优推荐到网站首页及文档页面,为您的文档增加更多曝光。若您觉得您的文档优秀,欢迎您转发分享或自荐给工作人员,我们将为您争取首页推荐、转发等更多曝光。


无论是你是初学者还是资深开发者,欢迎你加入本次文档悬赏活动,分享你的优质文档,与更多朋友一起学习进步!未来我们也将针对更多技术主题推出悬赏活动,如果你有推荐的主题也不妨告诉我们!乐知乐享、共同成长!

往期活动导航
【文档悬赏令】第1号:数据库新版本的安装实操


欲了解更多可浏览墨天轮社区,围绕数据人的学习成长提供一站式的全面服务,打造集新闻资讯、在线问答、活动直播、在线课程、文档阅览、资源下载、知识分享及在线运维为一体的统一平台,持续促进数据领域的知识传播和技术创新。

关注官方公众号: 墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯

新元启幕,万象更新;榜单出炉,洞察先机。2026 年首期中国数据库排行榜正式发布,本期榜单整体格局延续此前态势,排名变化不大。回顾 2025 年,国产数据库厂商整体表现稳健,技术路线与产品定位进一步清晰。

在这一背景下,1 月榜单的表现也为观察当前国产数据库市场的竞争格局与发展趋势提供了一个清晰窗口。接下来,和小编一同盘点本月榜单部分产品的亮眼表现。

一、PolarDB 升榜眼,达梦守前三

最新数据库榜单前十揭晓,OceanBase 毫无悬念卫冕榜首,PolarDB 实力突围跃升榜眼,达梦数据库稳坐前三之位。值得关注的是,本月前十排名中,仅 PolarDB 与达梦两家的位次发生调整,其余产品座次保持不变。


图1:中国数据库流行度排行榜前十得分情况

新年伊始,OceanBase 以737.24分稳居榜首,这份领先地位的背后,是其在技术研发、工程实践与战略布局上的全方位深耕。在数据库核心问题研究上,OceanBase始终深耕不辍,联合华东师范大学发表的论文《APQO:自适应参数化查询优化框架》成功入选数据库顶级会议SIGMOD 2026;与中国人民大学合作完成的关系型数据库缺陷实证研究成果,也顺利被IEEE TSE正式录用,通过系统分析777个真实缺陷,足见其在工程质量与底层机制打磨上的持续深耕。

工程与产品打磨上,2025全年OceanBase完成460次投产稳定支撑1500余个关键业务系统运行,在高复杂度生产环境中沉淀出成熟的交付与运维体系;全年累计推进16次版本迭代,新增489项功能与158项数据库相关专利,工程体系化能力进一步夯实。面向AI时代浪潮,OceanBase持续推进一体化战略,不仅发布兼容TP、AP与AI负载的融合版本OceanBase 4.4,还推出AI原生混合搜索数据库SeekDB助力Data × AI战略落地,其在AI就绪数据库方向的探索,更首次获得IDC面向生成式AI的数据基础设施“领导者”评价。

本月 PolarDB以654.49分排名较上月上升一位,跻身榜眼之位,整体表现稳中有进。行业认可方面,Gartner 2025年全球云数据库管理系统魔力象限给出了有力佐证——阿里云连续第六年入选“领导者”象限,且是亚太区唯一入选厂商。这一成绩的背后,作为阿里云核心云原生关系型数据库的PolarDB提供了重要技术支撑,充分印证自身产品成熟度、技术完整性与全球竞争力。


图2:Gartner 2025年全球云数据库管理系统魔力象限

IDC最新报告披露的市场数据同样可观,2025年上半年中国关系型数据库软件市场规模达22.1亿美元,公有云关系型数据库同比增长16.3%,增速优于整体市场;阿里云位列市场前三,在云数据库规模化交付与行业覆盖上的优势,为PolarDB的持续落地与增长筑牢市场基础。


图3:2025 年上半年中国关系型数据库软件市场规模前三名分别为:阿里云、腾讯、华为

达梦数据库本月以614.76分稳居榜单第三名,核心竞争力集中在多关键行业的国产化落地成效,以及技术与生态的双重突破。国产化实践推进中,达梦不断拓宽覆盖边界、提升项目复杂度,在医疗、通信、交通等领域均交出亮眼答卷:助力武汉大学人民医院完成病案管理系统底层数据库升级重构;与福建移动深化国产化替代合作,还助力其斩获“数字中国创新大赛”奖项;参与建设的西镇高速全路段国产化收费系统已实现稳定运行。

底层能力打磨与生态建设同步推进,凭借扎实的生态建设成果,达梦荣获2025 IDC中国生态奖;资本市场上,达梦数据(688692)成功入选“科创板上市公司价值30强”。综合来看,达梦数据库本月稳居前列,正是其在重点行业落地、技术自主可控及生态体系建设上持续发力的必然结果。

金篆信科GoldenDB 本月表现亮眼,以577.06分位居行业排行榜第四位,核心竞争力在权威认可与关键行业落地中充分彰显,成为国产数据库领域的核心标杆。权威评选中,2025数据智能“星河(Galaxy)”案例评选给出有力背书,GoldenDB成为入选案例数量最多的数据库厂商,充分印证其技术落地能力与行业实践深度。

关键行业布局中,运营商领域GoldenDB稳居领先地位,在中国移动、中国联通核心系统数据库市场占比分别超80%、60%,每日支撑9亿+移动用户、12亿+物联网用户计费,与多家移动公司合作的核心业务改造、智能运维等案例均获权威认可,转型成效显著。金融领域更是实现突破,作为业界首家覆盖全类型金融机构核心系统的国产数据库,其服务超100家金融机构,每日承载超100亿笔、10万亿元交易,获头部机构战略投资,连续稳居市场占有率第一。

本月,金仓数据库以568.20分位列行业排行榜第五位,核心优势集中在关键行业持续落地与产品能力的迭代完善上。能源领域始终是其重点实践方向,截至目前,已累计支撑1000余个发电厂项目,部署3000多套数据库,覆盖全国31个省(区),形成扎实的规模化应用基础。

产品能力打磨上,金仓数据库聚焦部署、安全与性能三大核心维度持续优化;行业认可持续加码,金仓数据库与辽宁移动、新疆移动等合作的多项实践成功入选2025数据资产管理大会“星河案例”榜单。

排名第六位的腾讯云TDSQL表现尤为亮眼,核心竞争力集中在金融核心系统领域的规模化落地能力与高可靠运行水平。2025年年终决算作为银行IT体系最具挑战性的关键节点,TDSQL成功护航70余家金融机构实现“零失误”完成决算,覆盖国内超过半数Top 100银行,服务对象涵盖国有大行、头部股份制银行、城商行及支付清算机构,行业覆盖的深度与广度持续提升。

YashanDB稳居行业排行榜前十,回顾2025年,其在行业影响力与技术能力两方面均取得实质进展,不仅跻身墨天轮中国数据库流行度排行榜前十,核心技术能力更获得中国电子学会“国际领先水平”认证,技术成熟度与专业认可度同步提升。

产品与技术演进上,YashanDB V23.5版本以“TP+”为核心理念,面向企业混合工作负载场景进行系统性优化,多个关键模块能力实现跃升。综合来看,崖山数据库在保持榜单稳定位置的同时,通过持续的产品迭代与技术深化,进一步夯实了其在混合负载数据库方向的竞争力。

二、细分产品实力出圈,多元特色创新破局


图4:本月亮点数据库得分情况

在月度中国数据库排行榜的头部阵营之外,一批各具技术特色与落地实力的数据库产品同样表现亮眼。它们或是凭借长期技术积淀夯实竞争力,或是依托行业标杆项目实现排名跃升,或是在细分赛道突破创新,共同勾勒出国产数据库多元化发展的活力图景。

本期榜单中,排名第十一位的 openGauss 的稳定表现源于长期技术积累,核心支撑落在持续的内核演进、软硬协同优化与工程能力沉淀上。去年11月发布的7.0.0创新版,基于鲲鹏920平台在权威HTAP基准测试HyBench中斩获H-Score 2831.89的优异成绩,再度刷新性能纪录。

openGauss Summit 2025的召开,进一步释放出持续演进的明确信号。大会不仅开源业界首个多写数据库架构oGRAC,更发布“1+2”技术战略,敲定多读多写、超节点数据库及AI原生多模态数据库底座的建设方向。

Apache IoTDB 位次稳定保持在第20位,商业场景与航天领域的双重落地突破,成为榜单排名的核心支撑,充分验证其技术成熟度与市场适配能力。依托高吞吐读写能力、高压缩比及端 — 边 — 云协同架构的核心优势,Apache IoTDB 在关键场景中持续彰显硬核实力。航天领域更是斩获亮眼成果,12 月 3 日朱雀三号遥一运载火箭成功首飞入轨,这款国产时序数据库为此次试验提供高效数据管理支撑。

本月,万里数据库排名稳步提升至第34名,重点行业项目的持续落地成为核心增长动力。作为国家级专精特新“小巨人”企业,万里数据库深耕国产自主可控数据库研发,核心产品GreatDB在金融与运营商领域的实践成效持续凸显。在运营商“O域系统国产替代”项目中,GreatDB凭借对MySQL协议与生态的高度兼容,实现应用平滑迁移与业务连续运行,迁移效率与运维友好性得到充分验证。深厚的技术积淀叠加丰富的行业实践,让万里数据库已构建起成熟的自主可控数据库解决方案。

同方数科自主研发的KBase多模数据库成为本月榜单最大“黑马”。独特的搜索/NXD/RDF/向量四模一体架构是KBase的核心竞争力,集成98%精准度中文处理算法与400万概念词典,全文检索性能达2TB/s,十亿级向量检索可实现毫秒响应,在大规模知识管理与复杂数据处理场景优势显著。目前产品已通过信通院搜索型数据库与向量数据库双评测,斩获35项信创认证,全面适配鲲鹏/飞腾芯片及统信/麒麟系统,核心能力获得权威背书。

近期,一款数据库新品凭借亮眼动作引发行业关注 —— 数翊科技自主研发的海纳数据库(HexaDB)于 12 月完成近亿元融资,这款定位于库仓一体型的产品,精准覆盖高并发交易与实时分析并存的复杂业务场景,成长势头强劲。

成立于 2022 年的数翊科技,已凭借 HexaDB 在金融、智能制造、车联网、物联网等领域服务多家头部客户,产品逐步切入企业关键业务系统。技术架构上,数翊科技构建起自主创新的 H-T-A-I-P 全栈技术体系,实现交易型、分析型与智能型业务的一体化融合。研发布局层面,华中研发总部已落地武汉光谷,聚焦核心技术持续攻坚,强化区域服务与产业协同。随着技术能力、行业实践与研发布局的持续完善,HexaDB 正在实时库仓一体化与 “DB for AI” 方向上,逐步释放工程化与商业化潜力。

三、见证荣耀时刻,2025年度数据库奖项揭晓

在全球数字化转型持续深入与国家信创战略全面落地的双重推动下,数据库作为支撑数字经济运转的核心基础设施,正经历着从技术跟跑到自主引领的关键跨越。2025 年,云原生与人工智能的深度融合,不仅重构了数据库的技术架构,更催生出多元化的行业应用场景,国产数据库厂商也在核心技术突破与关键系统替代中交出亮眼答卷。

为梳理年度发展成果、树立行业标杆,墨天轮社区依托近 50 个权威评估指标启动 2025 年数据库奖项评选。接下来,就让我们一同揭晓本年度脱颖而出的行业璀璨亮点。

点击查看年度获奖名单


图5:2025年度数据库获奖名单

本次评选落下帷幕,上榜的每一款产品都以独特的技术优势与应用价值,勾勒出数据库领域的年度发展图景。我们期待,未来能见证更多产品在自主研发的道路上稳步迈进,在关键场景中持续释放价值,书写国产数据库的崭新篇章。


相关阅读

原文链接https://www.modb.pro/db/2010657961249693696

欲了解更多可浏览墨天轮社区,围绕数据人的学习成长提供一站式的全面服务,打造集新闻资讯、在线问答、活动直播、在线课程、文档阅览、资源下载、知识分享及在线运维为一体的统一平台,持续促进数据领域的知识传播和技术创新。

关注官方公众号: 墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯

本次版本 新增函数对象转换能力,扩展了达梦等多数据库迁移适配范围,并提升了批量转换的处理效率,进一步降低企业级数据库迁移的复杂度与成本。

一、核心特性

支持函数对象迁移

函数对象可随存储过程的迁移任务一键同步转换​。该能力的加入,让 SQLShift[1] 从一款“​存储过程迁移工具​”升级为“​核心业务逻辑对象全量迁移工具​”。随之也带来三重提升:

  1. 降低迁移风险与人工成本

    避免 函数对象 需人工逐个改写与反复校验,大幅减少因语法差异、返回值不一致引发的运行期错误。

  2. 提升非表对象整体迁移效率

    函数对象与存储过程 可在同一时间中完成迁移与校验,缩短整体迁移周期。

  3. 保障业务逻辑完整性与可用性

避免 函数对象 缺失导致上层存储过程等对象无法编译或运行的问题,有效降低迁移后集中调试与返工压力,提升割接与上线的稳定性。

函数对象迁移任务

<iframe src="//player.bilibili.com/player.html?isOutside=true&aid=115970207123078&bvid=BV1Gg6LBAEf3&cid=35655845383&p=1" scrolling="no" border="0" frameborder="no" framespacing="0" allowfullscreen="true"></iframe>

新增数据库迁移组合

本次升级,SQLShift 扩展了多项数据库迁移组合。

SQLShift 支持迁移链路

  • 新增 Oracle / OceanBase → 达梦

    降低了迁移至达梦数据库的复杂度和人工成本,帮助企业快速完成数据库替换或国产化改造。

  • 新增 PostgreSQL → OceanBase(Oracle 模式)

    减少了跨数据库迁移中的人工调整工作量,加快了从 PostgreSQL 向 OceanBase 的迁移进程。

二、其他更新

批量处理能力提升

支持同时上传多个 SQL 文件进行转换,提升大规模迁移场景下的处理效率。

免费试用限时开放!

👉 点击领取 你的转换额度,立即体验 SQLShift 智能化迁移带来的飞跃效率!

🧩 SQL 方言再多,转换也能一步到位,SQLShift 为你搞定!

SQLShift介绍

模力工场新鲜事

  • 想用一个下午快速摸清一个领域,并产出一份条理清晰、信息量丰富的深度内容?本周模力工场带你体验 “AI 增效流水线:从信息到作品的智能生产工作流”。从智能阅读提炼(语鲸)、一键生成研报(AI 快研侠),到跨平台记忆管理(MemOS-MindDock),再到自动视觉设计,这条流水线覆盖“读、写、研、记、设计”全流程,助你将碎片信息快速整合为结构化的知识作品。例如,若你对近期热议的 Clawdbot 等 AI 助手产品感兴趣,不妨以此为主题,用这套工作流实践一番。点击进入模力工场首页,查看顶部专题横幅,扫码添加模力小 A,获取完整工具链与实操指引。

030 周上榜应用精选(附用户热评)

模力工场第 030 周 AI 应用榜来袭!本周共有 32 款应用上架,榜单完全由用户真实使用、测评与讨论热度驱动。我们从社区声量最高的应用中精选出十款,并透过用户真实评论,为你解读榜单背后的产品逻辑与行业风向。

创作平民化:人人都能成为内容创作者

  • 随变:潮人必备 AI 创作神器,让灵感瞬间变潮流短片!

”玩了几天随变,感觉有点像简洁版抖音…但 AI 创作出来的视频,如‘创作一条刀马刀马的舞蹈片段’它会理解为元素中有刀有马,BGM 也毫不相干…这显然是开盲盒,会消耗创作者热情。希望引入更多‘悦己’的功能。”【用户热评|@MATTHEW】

  • PixVerse:秒出电影感视频,视觉叙事交给 AI。

  • 小云雀:一句话生成爆款,创作门槛降至零。

  • WHEE:一站式视觉工坊,生图改图扩图,创意无限延伸。

  • 唱鸭:零基础玩音乐,AI 帮你谱写生活旋律。

学习力升级:AI 正在重塑教辅软件

  • 千问智学:全科 AI 辅导,教材全覆盖,答疑效率翻倍。

”千问智学高度契合我心中对答疑辅导类学习软件的期待。功能清晰划分为学习智能体、提分助手、宝藏资料、职业考试几大板块,每个分类还结合适用年龄、所学专业、所在地区等不同维度,打造了针对性的内容与服务…综合体验可以给到 9 分的高分。”【用户热评|@Abin】

  • 豆包爱学: 随身 AI 家教,拍题秒出思路,学习难题不再怕。

智能自动化:从被动回答到主动执行

  • Atoms:多 AI 团队协作,想法闪电变产品原型。

”用 Atoms 搭了一个族谱显示的网站...最戳我的是它的层级数据可视化功能,族谱的家族分支、辈分脉络展示得一目了然,不用自己折腾结构设计。而且全程打字输入需求就行,不用写一行代码,平台会自动匹配开发需求,内置多个角色也比较好用,做出来的族谱网站的展示效果整体合预期(有一些样式生成的没处理好,显示会重叠)。整体来说对新手很友好,搭建网站的核心需求都能完美满足,小细节的不足完全不影响基础使用,作为零代码工具来说很靠谱了。“【用户热评|@墨鱼罐头】

  • offer快 📍北京:AI 求职分身,智能匹配+自动投递,轻松拿下好工作。

心理疗愈:不仅是应用,更是思考伴侣

  • MetaSight 元见 📍杭州:命运 AI 投射仪,换个视角看清人生路径。

”我其实很好奇这个领域的 AI 应用能发展到什么程度。之前试用时,我只是输入了自己当前的工作状态、心情和年龄,系统就帮我推算出了未来的发展方向和行动建议…如果这类应用未来能结合 IoT 硬件,可能会真正引爆市场。目前应用面向的用户群中包含不少中老年人,他们对这类能根据现状推理出下一步计划与发展方向的功能,需求其实非常迫切。”【用户热评|@.】

榜单之外但有趣的应用

应用名称:扣子(2.0版本)

关键词:AI 职场助手|流程自动化|智能办公

模力小 A 推荐:专为职场人打造的智能效率伙伴,能帮你自动处理会议纪要、邮件撰写、日程安排等重复工作,让 AI 真正成为你的“数字同事”。

应用名称:Vidu AI MV

关键词:一键成片|AI MV 生成|影音创作

模力小 A 推荐:只需上传图片和音乐,即可自动生成拥有专业转场、节奏卡点和电影级质感的音乐短片,让普通人也能轻松打造专属 MV。

本周上榜应用趋势解读

本周上榜的一批 AI 应用呈现出几个非常鲜明的趋势:创作力提升、学习力强化、智能自动化与心理疗愈并行发展。

在创意生产与多媒体内容创作方向,我们看到像随变、PixVerse、小云雀、WHEE、唱鸭这样的应用迅速聚焦 AI 驱动的视觉与音频内容生成,从“一句话生成爆款内容”、秒级视频产出,到图像改图、一站式创作体验,AI 正在让个人创作者从繁琐操作中解放出来,把灵感瞬间转为可传播的成果。这与行业趋势一致:AI 正在大规模重塑创意产业和内容生产流程,创作者不再受制于传统软件约束,而能借助 AI 助力快速迭代与表达创意。

在教育与知识服务方向,豆包爱学、千问智学等产品体现了 AI 在学习辅导领域的深化应用,它们通过拍题讲解、教材覆盖的智能辅导模式,正在将 AI 从“工具助手”升级到“学习伴侣”,这与全球教育领域推动 AI 个性化辅导、提升学习效率的大趋势不谋而合。

此外,AI Agent 与自动化服务型工具(如 Atoms、offer 快、MetaSight)正在形成一股新潮流。Atoms 体现了多智能体协作快速将想法变成可用产品的能力;offer 快则将 AI 直接介入求职流程中,实现岗位筛选、沟通跟进与自动申请;MetaSight 则尝试把 AI 带入命理解读与人生洞察场景,让智能体具备不仅执行任务、还促发用户自我思考的能力。

综合来看,本周上榜的 AI 应用不仅覆盖了内容创作、学习辅导、个性化洞察和流程自动化等核心领域,还共同凸显了一个核心趋势:AI 正在从“简单生成”向“深度交互与高效执行”转变,让用户的生产力、学习效率和生活智能都进入一个新阶段。

One more thing,

模力工场将亮相 OceanBase 社区嘉年华!诚邀您加入我们的上海现场展位。作为 OceanBase 合作的创新社区,模力工场将于 1 月 31 日 登陆上海社区嘉年华,并拥有专属展位。这不仅是一次技术交流——我们更希望和你一起,在现场用 AI Coding 展现创造力、在开放麦分享你的项目故事、与行业先锋面对面切磋、在开源市集交换灵感。我们为你预留了专属席位,期待与你共同呈现:当开源精神遇上 AI 创造力,能碰撞出多少令人惊艳的可能。立即报名,锁定与数百位技术同行深度连接的一天!

本文作者:OceanBase 资深技术专家 张易

摘要:
在 AI 时代,OceanBase 以混合搜索为核心的多模能力,从 AI Agent 的视角出发,为大模型提供高质量的上下文信息,在提升 AI 应用效果的同时显著降低运行成本,真正实现了技术与业务价值的统一。

在 AI 与数字化转型驱动的时代,企业正面临数据形态、处理速度与复杂性的剧增。近日,全球知名咨询机构 Forrester 在其最新报告《Multi-Model Data Platforms Landscape, Q4 2025》中指出,多模数据平台(MMDP)已成为应对现代应用复杂数据需求的关键趋势。报告将 MMDP 定义为“在一个数据库管理系统中支持多种数据模型”的统一平台,其核心价值在于简化技术栈、降低数据冗余并加速开发周期。

OceanBase作为“Notable Vendor”出现在该报告中,这不仅是对 OceanBase 多模一体化产品的认可,更预示着化繁为简、现代架构的数据时代即将来临。

在报告中,OceanBase 被认为是聚焦以下扩展用例的代表性厂商:

Agentic AI
Forrester 认为 MMDP 是 Agentic AI 的大脑与记忆。AI Agent 需要推理,它需要知道事实、拥有记忆并理解逻辑关系。MMDP 提供了向量检索(找相似)、图谱(找逻辑)、结构化数据(找事实)的统一平台,防止 AI 幻觉。

多模数据统一检索
Forrester 认为 MMDP 能为开发者提供一键“原子操作”。比如,用户修改资料,既要改结构化数据里的名字,又要改全文搜索里的索引,还要改图数据里的节点,过去这需要写很复杂的分布式事务代码,而 MMDP 允许用统一查询语言在一个步骤内完成跨模态的增删改查,保证数据一致性,极大简化开发。

推荐引擎
Forrester 认为 MMDP 能够提供比“猜你喜欢”更懂你的推荐。传统的推荐只看买了什么,现在的推荐要看用户的实时点击流(行为)、朋友买了什么(关系)、用户搜索的关键词(文本语义),结合了图计算(社交推荐)和多模态搜索(语义推荐),提供更精准的上下文感知推荐。

本文将深度解读 OceanBase 多模一体化能力,探讨其如何以原生一体化的架构,帮助企业架构师与 IT 决策者厘清正在面临的“架构之问”:是继续采用“烟囱式”的数据库组合,还是转向真正的一体化平台?

从“多”到“一”:终结架构碎片化,多模是 AI 时代的必然选择

长期以来,业界普遍采用“为专业场景选择专业工具”的理念,构建了所谓的“多语言持久化”(Polyglot Persistence)架构,即为不同数据模型部署独立的数据库系统。然而,这种模式在业务复杂性指数级增长的今天,其弊端日益凸显,逐渐演变为创新的沉重枷锁。

这种“数据库联邦”模式的困境,在许多积极拥抱 AI 的企业中表现得尤为突出。它们为了实现语义搜索、精确匹配与关系查询,被迫引入由关系数据库、搜索引擎与多种向量数据库构成的复杂技术栈。这不仅导致架构臃肿、运维成本高昂,更在稳定性、数据一致性与开发效率上带来了巨大挑战,形成了沉重的技术债务。

货拉拉在转型过程中的早期探索,便是一个深刻的例证,其面临的动态 Schema 变更、混合检索与多系统运维难题,正是这种碎片化架构的典型缩影。

这些痛点深刻揭示了“烟囱式”架构的本质缺陷——它将数据管理的复杂性转嫁给了应用和运维团队。正如 Forrester 报告所指出的,MMDP 的核心价值正是通过在一个数据库内部实现统一的数据存储、事务处理和治理,从根本上解决数据孤岛问题,降低总拥有成本(TCO)并提升业务敏捷性。


Forrester: MMDPs Enable Simpler Cross-Model Querying

解构 OceanBase:为 AI Agent 打造的混合搜索“大脑”

在 AI Agent 与大语言模型(LLM)引领技术浪潮的今天,数据库的角色正在被重新定义。它不再仅仅是数据的存储仓库,更是决定 AI 应用智能水平与运行成本的“上下文引擎”(Context Engine)。

正如 OceanBase CTO 杨传辉所言,“向量搜索只是 AI 数据库的初级阶段,最终所有向量搜索都会演进为混合搜索——能否支持混合搜索,正是衡量 AI 数据库核心实力的关键分水岭”。


OceanBase 的多模一体化实现混合搜索

OceanBase 的多模能力并非简单的“功能叠加”,而是根植于其原生一体化的分布式架构。这种架构将关系、向量、全文、JSON 等多种数据模型统一在单一引擎下,共享同一套存储、事务和查询优化器。其核心价值主张,正是从 AI Agent 的视角出发,通过强大的混合搜索能力,为大模型提供更高质量、更精准的上下文信息,从而在提升 AI 应用效果的同时,显著降低因 Token 消耗而产生的计算成本。

混合搜索:AI 时代的“上下文工程”基石

AI 应用,尤其是 RAG(检索增强生成)应用,其效果的优劣极大程度上依赖于提供给大模型的上下文质量。大模型虽然具备强大的计算能力,但缺乏长期记忆,这就需要数据库为其存储并管理上下文信息,同时精准输出大模型所需的上下文——这一过程被称为“上下文工程”(Context Engineering)。

一个典型的复杂查询,如“推荐附近 500 米内,人均消费低于 25 元,评价超过 4.5 分,且环境安静的咖啡厅”,单纯的向量或文本搜索都难以胜任。这需要一个能同时理解并处理多种数据维度的“大脑”。

OceanBase 的混合搜索能力,正是为解决这类多维度信息综合检索的难题而生。它将四种关键的搜索能力无缝融合在一个查询引擎中:

这种“多路召回,统一排序”的模式,让 OceanBase 能够先通过关系、标量数据进行高效过滤,大幅缩小检索范围,再在小范围内进行精准的向量或全文搜索。每一路检索都会产出部分结果,最终将各路结果融合,并经过全局重排序(Rerank),才能为大模型输出其真正需要的精准结果。


OceanBase 混合搜索机制

这种机制不仅极大地提升了查询的准确性(Recall)和精确率(Precision),更重要的是,它将最相关、最精炼的信息作为上下文喂给大模型,有效避免了无关信息对模型推理的干扰,并从根本上减少了昂贵的Token消耗,直接降低了AI应用的运行成本。

技术利器一:高性能向量搜索是混合搜索的基础

高性能且功能完备的向量搜索,是混合搜索的核心基础。目前,OceanBase 向量搜索性能已达到业界开源向量数据库的先进水平——无论是稠密向量还是稀疏向量,在向量数据库领域主流 Benchmark 测试中均表现突出。

在 VectorDBBench 的测试中,OceanBase 在不同过滤率下的性能全面占优。同时,OceanBase 的磁盘向量索引,在构建时间与存储占用两方面,也实现了业界领先。


OceanBase 向量性能测评

更重要的是,OceanBase 实现了向量搜索与全文搜索的深度融合,通过多路搜索显著提升召回效果。测试数据清晰呈现了不同搜索方式的召回表现:仅采用单一搜索路径(无论全文搜索、稠密向量还是稀疏向量),都难以达到最优召回效果;唯有将稀疏向量、稠密向量与全文搜索相结合,才能实现更优的召回表现,达成 1+1 > 2的协同效应。


OceanBase 多路召回评测

值得一提的是,这两大能力均构建于 OceanBase 数据库原生架构之上,天然继承了分布式架构的弹性扩展特性与对象存储的高效适配能力。

技术利器二:半结构化数据的高效处理(JSON)

在 AI 场景中,企业在处理海量 JSON 数据(如用户行为日志、订单轨迹、动态特征字段)时,普遍面临 Schema 重复存储导致空间浪费、按行存储导致压缩率低、查询性能低下等痛点。

OceanBase 针对性地设计了创新的存储方案。它采用 JSON 二进制存储,并创造性地实现了“列化拆分”。通过智能识别“高频列(Frequent Col)”与“稀疏列(Spare Col)”,将频繁访问的字段独立成列存储,稀疏字段则聚合存储。


OceanBase JSON 列化拆分机制

这种设计带来了显著的技术收益。首先是极致的压缩效率,拆分后的独立列可利用 OceanBase 成熟的列存编码能力进行高效压缩。在 TPCH-10G 数据集上的测试显示,其压缩比是传统文档数据库的 3 倍,直接降低了存储成本。

其次是查询性能的加速,查询特定字段时,只需读取对应列,极大减少了 I/O 开销。此外,用 JSON 格式动态扩展特征字段,还可帮助企业减少 30%-50% 的数据清洗成本。这一能力对于 AI 应用中频繁变化的特征工程尤为重要,使得企业无需频繁修改 Schema 即可灵活应对业务需求。

技术利器三:HTAP 能力支撑 AI 场景的元数据管理

在 AI 场景中,除了要开展多路搜索,还需妥善管理 AI 场景下的元数据。要做好 AI 数据库的元数据管理,不仅需要支持元数据的实时写入与事务一致性,还需实现元数据检索结果与多路搜索结果的 SQL 级联动。

在这方面,支持 HTAP 的关系型数据库是更优选择。通过将关系模型与向量、全文、JSON 能力深度融合,OceanBase 最终形成了全面的混合搜索能力。


OceanBase 如何解决 AI 场景元数据管理问题

例如,在知识库场景中,需要管理用户权限、文档分类、访问日志等大量元数据,同时还要进行文档的语义检索。传统方案需要在应用层协调关系数据库与向量数据库的查询结果,而 OceanBase 则可以通过一条 SQL 完成“先通过关系过滤确定用户可访问的文档范围,再在该范围内进行向量语义搜索”的复杂操作,极大地简化了开发逻辑并提升了查询效率。

一体化架构:从“数据库联邦”到“统一数据底座”

过去,企业为了实现类似的多模态处理能力,不得不拼凑一个由关系数据库、向量数据库、全文搜索引擎等多种产品组成的“数据库联邦”。这种“烟囱式”架构不仅运维复杂、成本高昂,更在数据一致性、开发效率和系统稳定性上带来了巨大挑战。

OceanBase 的一体化架构则试图改变这一局面,为企业 AI 应用提供坚实的统一数据底座。多个客户的成功实践,生动地诠释了这一价值。

蚂蚁集团“百宝箱”的智能体在线搜索就是一个典型案例。其复杂的地理位置、用户评分、消费水平和语义偏好混合查询需求,在 OceanBase 中通过一条 SQL 即可实现,完美替代了原先 Milvus + Zsearch + OceanBase 的复杂组合。这种将多路检索逻辑从业务层下沉到数据库内核的做法,极大地简化了业务实现,实现了在线高性能混合搜索。


蚂蚁集团百宝箱 Agent 在线搜索示例

货拉拉则基于 OceanBase 的混合搜索能力,构建了一站式的企业 AI 数据底座,支撑起包括知识库平台、AI Coding、Agent 平台、ChatBI、智能客服等多种 AI 应用。这不仅用单一技术栈取代了原有的 vsearch + Weaviate + Milvus 等多个开源组件,解决了系统的稳定性难题,还复用了 OceanBase 成熟的高可用能力,实现了 RPO=0、RTO<8 秒的金融级标准。

在具体应用中,货拉拉通过“资损代码识别”场景,利用历史案例向量化与实时代码相似度检索,有效规避了潜在的财务风险;在“数仓AI答疑助手”项目中,更是融合了向量、标量、全文关键字等多种检索方案,并结合重排序模型,显著降低了内部数据查询门槛和人力成本,提升了数据开发人员的效率。


货拉拉 AI 应用架构

中国联通利用 OceanBase 构建了拥有 10 亿级向量规模的公司级统一知识库平台。原先采用“关系数据库+Elasticsearch”的架构,在切换到 OceanBase 后,查询执行效率提升到原 Elasticsearch 方案的 2 倍,同时解决了复杂的用户-文档权限管理问题。通过融合关系查找与多路搜索,联通成功实现了知识库的精细化权限管控及灵活的用户间权限共享需求,支持公共文档与私有文档的统一管理。


中国联通 AI 应用架构图

飞猪也通过 OceanBase 统一了其智能体数据平台的后端,用一套系统替代了原先的分布式 KV + 分布式 Table + 搜索 + 向量的复杂架构。这不仅统一了技术栈,还实现了对知识库、Memory 等多种数据的统一支持,SQL 的简单易用性与稳定低延迟的特性,让开发团队能够更专注于业务创新。


飞猪 AI Agent 架构

这些案例共同证明,OceanBase 的一体化架构并非简单的功能聚合,而是通过在内核层面实现多模数据的统一管理与查询,从根本上解决了数据孤岛问题,降低了技术栈的复杂性,最终加速了AI应用的创新与落地。

从技术到业务:OceanBase 多模一体化的实践价值

技术的先进性最终需要通过业务价值来体现。从上述案例中,我们可以清晰地看到 OceanBase 多模一体化架构在 AI 时代所带来的三大核心价值:

第一,显著降低 AI 应用的运行成本。 通过混合搜索提供的精准过滤与排序机制,OceanBase 能够为大模型提供更高质量、更相关的上下文信息,从而大幅减少无效 Token 的消耗。在当前大模型推理成本居高不下的背景下,这种成本优化对企业而言具有直接的经济价值。

第二,简化技术栈,提升开发与运维效率。 一体化架构让企业无需在应用层协调多个异构数据库系统,开发者可以用熟悉的 SQL 语言完成复杂的多模查询,极大地降低了学习成本与开发复杂度。同时,统一的运维管理也减轻了 DBA 团队的负担,提升了系统的整体稳定性。

第三,加速 AI 应用的创新周期。 当数据基础设施变得简单、高效且可靠时,业务团队可以将更多精力投入到 AI 应用本身的创新上,而非陷入复杂的数据管道搭建与维护中。这种“基础设施即服务”的理念,正是 OceanBase 一体化架构的核心价值所在。

选择下一代数据基石,拥抱智能未来

Forrester 的报告揭示了多模一体化不仅是技术趋势,更是企业在 AI 时代保持竞争力的战略选择。面对日益复杂的数据环境,传统“烟囱式”的架构已难以为继。

OceanBase 提供的不仅是一个功能丰富的数据库,更是一个稳定、高效、面向未来的一体化数据基石。它通过在存储、查询、事务等层面的原生一体化设计,让企业能够更从容地应对数据融合的挑战,将宝贵的精力聚焦于业务创新本身。

特别是在 AI 时代,OceanBase 以混合搜索为核心的多模能力,从 AI Agent 的视角出发,为大模型提供高质量的上下文信息,在提升 AI 应用效果的同时显著降低运行成本,真正实现了技术与业务价值的统一。

对于正在寻求下一代数据架构的架构师和 IT 掌舵者而言,可以重新审视自身的技术栈,考虑 Forrester 倡导的多模数据处理平台,为企业的下一个十年发展奠定坚实基础。

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

摘要

随着数据密集型应用的快速发展,哈希索引已成为内存数据库、键值存储和重复数据删除系统的核心组件。传统哈希索引在面对持久内存(PMem)时,由于存储流量放大和内存效率低下,难以充分利用其大容量和持久性优势。为此,OceanBase研究人员联合厦门大学、昆士兰大学学生及教授提出了一种新型哈希索引设计MetoHash,通过层次化设计、批量持久、指纹过滤和重复合并等技术,有效解决了传统方案在存储 I/O 放大和内存效率方面的问题。

简介

随着数据密集型应用的快速增长,能够实现常数级查找复杂度的哈希索引已成为构建内存数据库、键值存储和重复数据删除系统的核心组件。传统哈希索引在面对新兴的持久内存时,虽然利用了其大容量和数据持久性优势,却在存储流量放大和内存效率方面面临严峻挑战。

持久内存以其大容量、数据持久性、近 DRAM 性能等特性,为内存架构带来革命性变革。然而,PMem 的固定访问粒度和持久化 CPU 缓存特性,使得传统哈希索引设计难以充分发挥其硬件潜力,其原因在于现有方案极易放大存储 I/O 或降低内存效率。

日前,一篇题为《MetoHash: A Memory-Efficient and Traffic-Optimized Hashing Index on Hybrid PMem-DRAM Memories》的论文被高性能计算顶级会议SC 2025录用,并荣获最佳学生论文提名(该会议录用的 136 篇论文中选择 6 篇)。该论文由厦门大学、昆士兰大学与 OceanBase 的研究人员联合完成。其中,厦门大学硕士生余子祥、邓光阳为共同第一作者,沈志荣教授为通讯作者;昆士兰大学鲍芝峰教授,以及 OceanBase 的徐泉清、杨传辉研究员共同参与了此项研究。

SC 由美国计算机协会(ACM)与美国电气电子工程师学会(IEEE)于 1988 年共同创办,是全球高性能计算领域公认的年度顶级盛会,是中国计算机学会 CCF 推荐的 A 类国际会议。SC 2025 会议共收到 643 篇投稿,接收 136 篇,录用率 21.2%。

本论文的核心思想是构建一个跨越 CPU 缓存、DRAM 和 PMem 的三层索引架构,让数据在层次化存储中高效流动。

本文提出的 MetoHash 通过层次化设计、批量持久、指纹过滤、重复合并等关键技术,系统性地解决了现有方案在流量放大与内存效率上的痛点,为高性能键值存储、内存数据库、实时分析等应用提供了强大的底层支撑。

核心理念:三层协同,让数据在混合内存中“各得其所”

传统哈希索引在面对由持久内存(PMem)和动态随机存取内存(DRAM)构成的混合内存系统时,面临一个根本性矛盾:若为追求 PMem 的持久性而将索引完全置于其中,则会因 PMem 较高的访问延迟和固定的写入粒度导致严重的性能下降和 I/O 放大;若为追求速度而将索引完全置于 DRAM,则又无法利用 PMem 的大容量和持久化优势。

MetoHash 的创新核心理念在于“解耦与协同”。它不再将哈希索引视为一个单一的整体,而是将其功能拆解,并根据 CPU 缓存、DRAM 和 PMem 的不同硬件特性进行重新部署,构建了一个三层的高效数据管理流水线。其目标是让热数据、元数据和海量持久化数据分别在最适合的存储层级上被处理,从而在整体上实现高吞吐、低延迟、低流量和高内存效率的统一。


图1 MetoHash 的三层索引结构

核心技术一:缓存辅助的批量收集写入

此技术旨在根治向 PMem 进行小粒度插入时引发的“写放大”(Write Amplification)与频繁桶探测问题。其方案是在持久性 CPU 缓存中预分配多个与 PMem 访问粒度对齐的“收集表”(Collecting Table)。新到达的键值对根据哈希值被直接路由到相应收集表,并通过原子操作实现无锁快速插入,从而充分利用缓存的高速与持久化特性。当一个收集表被填满时,其包含的多个键值对将作为一个完整的、与 PMem 最佳写入粒度匹配的数据单元,被一次性顺序刷写到 PMem 的备份日志中。这种方法彻底消除了因写入粒度不匹配带来的额外 I/O 流量,充分利用 PMem 的写入带宽,同时将零散插入转化为高效批量操作。


图2 持久缓存刷入 DRAM 和 PMem 中

核心技术二:基于 DRAM 指纹的反向精准查找

该技术致力于解决在混合多层索引中查询时在 PMem 层进行盲目、耗时的桶探测的瓶颈。其核心是在 DRAM 中维护一个紧凑的“指纹”目录,其本质为 PMem 主哈希表中的每个键哈希值的一个简短片段。

在进行查询时,系统首先计算查询键的指纹,并利用 SIMD 指令等在 DRAM 指纹目录中进行高速并行比对,迅速筛选出 PMem 中少数几个可能匹配的位置。只有这些候选位置,才需要访问 PMem 进行精确的键值比较。整个查询遵循 PMem 主表 → DRAM 表 → CPU 缓存收集表的反向路径,确保定位到有效值。这一设计将耗时的海量比对操作从慢速的 PMem 转移至高速的 DRAM,极大减少了查询延迟与 PMem 访问压力。


图3 DRAM 结构刷入 PMem 中,并在 DRAM 中保留指纹

核心技术三:段分裂驱动的重复项消除与空间回收

为解决“先插入后检查”模式可能产生的键重复问题以及删除操作导致的空间碎片化问题,MetoHash 在数据结构段分裂中引入合并与清理机制。

首先,DRAM 桶与 PMem 桶在逻辑布局上严格对齐,使得 DRAM 桶满时其内容能高效批量刷写至 PMem 对应位置。当 PMem 中某个段需要分裂以扩容时,系统将旧段所有数据读入 DRAM,在此过程中主动识别并消除同一键的多个版本的无效值,仅保留其最新的有效项,并将合并、去重后的结果写入新分配的段。此过程自然跳过了已标记删除的项,从而在完成容量扩展的同时,一举实现了存储空间的即时回收与整理,保持了 PMem 存储的紧凑性与查询效率。

性能成果

在实际搭载英特尔傲腾持久内存的测试平台上,MetoHash 与八种前沿方案进行了全面对比。

①吞吐量提升:在 YCSB 等各类负载下,其吞吐量平均超越以往方案 86.1% 至 257.6%,并呈现近线性扩展能力。


图4 MetoHash 相较其他基线索引在不同负载下均有明显优势

②变长数据支持:在处理 16B 至 256B 的变长键值时,其吞吐量平均仍领先对比方案 190.8%,尤其在小值主导的负载中优势显著。


图5 MetoHash 相较于其他基线索引在不同键值对大小下均有明显优势

③内存效率权衡:相比将全部索引存于 DRAM 的方案(如 VIPER),MetoHash 的 DRAM 占用减少 86.7%;相比 PMem 利用率低的方案 (如 Plush),MetoHash 的 PMem 占用减少 86.5%。


图6 MetoHash 相较于其他基线索引能够取得较好的 DRAM/PMem 效率权衡

小结

这项工作提出的 MetoHash 混合内存哈希索引,为持久内存时代的高性能、高内存效率数据管理提供了系统的解决方案。在理论上,MetoHash 首次通过缓存、DRAM、PMem 三层协同的架构,解决了由 PMem 固定访问粒度引发的 I/O 放大与内存效率低下这一对核心矛盾。在实践中,其在多种负载下的吞吐量相较当前方案平均提升 86.1% 至 257.6%,存储流量大幅降低,内存占用显著优化,在多种负载中验证了其卓越性能。

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

作者:杨泽,宝付支付数据团队负责人

随着#数字化转型 升级进入关键期,数据库已从被动的存储仓库,转变为主动赋能业务的智能数据中枢。以现代金融行业为例,业务对数据库提出了更高要求:既要满足事务,又要实时分析,同时安全、高效、弹性、智能地处理多模数据,并支撑实时决策与业务创新。这意味着,符合要求的数据库需在TP、AP、KV、AI方向均具备出色的数据处理能力。

作为在银行、消费金融、零售、跨境等行业深耕多年的一站式综合支付解决方案商,宝付支付产品种类丰富,且深谙技术创新与业务稳健的关系,不断引进先进技术维护和保障公司业务稳步运行,全方位为商户资金安全和交易安全保驾护航。

近年来,宝付支付的原数据库方案已不能满足业务需求,故而寻求技术升级。本文分享宝付支付在KV场景使用OBKV替换HBase的技术实践。

出于架构痛点,寻求支持 TP+AP + KV + AI 的数据库

宝付支付所属集团——漫道集团采用基于MySQL的集中式架构,由于近年来业务高速增长(2023 年初交易量约 3000万笔/日,2024 年 12月 已突破 9000 万笔/日)带来的海量数据(TB级),系统压力陡增。

最直观的压力便是成本压力,每年存储采购预算高达数千万元。同时,为了保障部分业务系统的高可用性,需在 A/B 两个机房部署完全对等的 MySQL 双活架构集群(如各100 台服务器),导致硬件与运维成本成倍增长。

同时在双活架构下,业务层仅关注“订单不丢、实时写入”,但不关心数据最终落在哪个机房、哪个分库。这给数据团队带来巨大挑战:无法准确追踪数据源,难以构建统一的数据视图,ETL 与实时同步逻辑异常复杂。

在业务种类多样的情况下,长期使用MySQL还会导致架构越来越复杂,使运维压力极大。集团内部运行着十余套大数据集群和超过 1000 个 MySQL 实例,分别服务于支付、风控、征信、BI 等不同场景,对数据库有不同的需求。

  • 支付交易系统:要求高并发、低延迟的事务处理能力。
  • 风控系统:依赖实时数据分析与毫秒级决策。
  • 征信 用户画像业务:需要高性能 KV 存储与快速点查。

  • BI 系统:依赖大规模离线分析计算。

多套异构系统并行,导致开发、监控、备份、扩容等运维工作极其繁重。

除MySQL外,我们使用 #HBase 存储海量日志与宽表,其虽具备高吞吐写入能力,但在事务支持、复杂查询、实时分析、KV 混合负载等方面存在明显短板,已无法满足新一代业务需求。

基于上述挑战,我们开始评估新一代分布式数据库方案。文章开头提到现代金融行业的业务对数据库提出了多种要求。宝付支付作为金融行业的一员也不例外,根据对TP、AP、KV、AI方向的需求,我们首先想到了 #OceanBase,核心原因在于其原生支持 HTAP(混合事务/分析处理) + KV + AI 的一体化架构。

  • TP 能力:满足支付交易系统的高并发、强一致性要求。
  • AP 能力:支撑风控与 BI 的实时分析需求。
  • KV 接口:为征信等场景提供低延迟点查。
  • AI 能力:内置向量化引擎与 AI 原生能力,为后续智能风控、实时推荐等 AI 应用奠定基础。

为控制风险,我们采取“由边缘到核心”的渐进式改造路径:先在非关键系统验证 OceanBase 稳定性,逐步迁移风控、征信等中台系统;最终目标是将核心支付交易系统平滑切换至 OceanBase,用一套数据库承载全场景需求。

从边缘到核心:OBKV-HBase替换HBase

在启动 OceanBase 引入计划后,我们先在离线与分析业务进行试点,后将多个MySQL业务迁移至OceanBase。当OBKV功能较为完善时,又完成了从HBase到#OBKV-HBase的升级,实现了一套引擎支持多场景业务的目标。

HBase 难以应对业务复杂度与实时性要求

尽管 HBase 在海量数据存储场景中曾发挥重要作用,但随着业务复杂度提升与实时性要求增强,其在架构、运维及成本等方面的问题日益凸显。主要体现在以下六个方面。

  • 离线链路冗长:当前数据流转路径为从 MySQL 流转至 Hive,再导入 HBase,流程环节多,数据延迟显著,且 Hive 层的数据修正不够灵活。
  • 实时链路依赖过重:直接读写 HBase 严重依赖 Zookeeper 与 HDFS,中间件耦合度高,链路稳定性风险集中。
  • 运维问题:跨机房场景下,集群切换与数据同步操作繁琐,故障时难快速隔离或切换。
  • 成本控制:为满足高可用要求,需部署完整的 HBase 主备集群,硬件与存储资源近乎翻倍,成本太大。
  • 多机房网络问题:机网络切割的时候,专线网络异常的时候,对业务都有影响。
  • SQL 查询依赖 phoenix:原生不支持标准 SQL,需借助 Phoenix 等组件实现查询,引入额外维护负担,且使用体验与性能往往不及直接 SQL 友好。

使用OBKV替换HBase,为统一技术栈奠定基础

OBKV 是构建在 OceanBase 分布式存储引擎之上的NoSQL 产品系列,目前支持 OBKV-Table、OBKV-HBase、OBKV-Redis 三种产品形态,其原生继承了 OceanBase 的高性能、事务、分布式、多租户、高可靠的基础能力。此外,OceanBase 的工具体系(比如OCP、OMS、CDC等)也原生支持 OBKV,运维 OBKV 的各个产品形态和运维 OceanBase 的 SQL 集群完全一样。OBKV 可以帮助企业统一技术栈,在满足业务对多模 NoSQL 数据库诉求的同时,降低企业在数据库运维上的复杂度。

基于我们目前正在使用的OBKV- HBase,总结其与HBase 的使用区别如下。

  • 完全集成 OceanBase 分布式存储能力:OBKV 不仅有 OceanBase 强大的内核能力,也继承了 OceanBase 丰富的生态工具能力。
  • 极简运维:DBA 如果同时有 SQL 以及 NoSQL 数据库的诉求,可以只运维一个数据库。
  • 统一查询:可以用 OBKV 做简单快速的 DML,同时可以用 SQL 对同一份数据做并发的复杂查询。
  • 成本更低:HBase 独用资源,OceanBase 是复用现有资源。
  • 监控更方便:方便对应用现有运行环境添加监控。

OBKV-HBase 不仅解决了传统 HBase 在运维复杂、资源孤岛、工具缺失等方面的痛点,更通过与 OceanBase 深度融合,可以实现“一套引擎、多模服务、统一运维、资源共享”的现代化数据基础设施目标。

引入 OceanBase 的三个阶段,确保技术转型平稳可控

在数据库架构升级过程中,我们分三个阶段逐步引入 OceanBase,确保技术转型平稳可控。

第一阶段:初步探索与能力评估(2023 年)

2023 年底,团队开始接触 OceanBase 及其 OBKV-HBase 产品。当时 OBKV 文档尚不完善,关键功能缺失,尤其缺乏 bulkload(批量导入)能力,无法高效导入离线数据 ,初期判断暂不具备支撑核心业务的能力。因此,该阶段以技术调研为主,未投入生产使用。

第二阶段:归档与分析场景试点(2024 年)

2024 年,团队转向更匹配当前能力的场景,启动 OceanBase 在离线与分析业务的试点,将数据归档、BI 聚合宽表、AP 分析类业务迁移至 OceanBase。我们不仅验证了OceanBase在高吞吐写入、复杂查询、资源隔离等方面的稳定性与性能表现,还积累了集群部署、SQL 优化、运维监控等关键经验,为后续全面推广奠定基础。

第三阶段:逐步替换与扩展(2025 年起)

随着 OceanBase 功能持续完善(特别是 OBKV-HBase 的成熟),团队启动规模化替换计划。

  • 关系型业务:逐步将业务管理系统、商户管理系统、BI 系统等原 MySQL 应用迁移至 OceanBase SQL 模式;
  • NoSQL 业务:使用 OBKV-HBase 替代原有 HBase,例如将“绑卡/解卡操作日志”等高频 KV 场景迁移至 OBKV-HBase;
  • 实现 TP、AP、KV 多负载统一承载,推动技术栈收敛与运维简化。

五步平滑迁移:工具使用、方案设计与注意事项

在从 HBase 到 OBKV-HBase 的数据迁移过程中,我们在实践中总结出五个关键步骤。

Step1: 目标端准备

在正式启动从 HBase 到 OBKV-HBase 的数据迁移前,需在 OceanBase 端完成充分的环境与配置准备。

  • 硬件配置:为避免因磁盘性能不足导致集群不稳定,建议使用高性能磁盘,但建议初期不要过度分配资源,以便预留弹性空间,用于后续扩缩容及负载均衡调整。
  • 存储规划:单个 OBServer 节点的磁盘容量应大于单个日志流的数据量。若单表数据量极大,而节点磁盘不足,可能在扩容或副本迁移时触发空间不足错误。
  • 租户规划:建议为 OBKV 创建独立租户,隔离资源。
  • 建好分区表。

注意事项

  • 实测表明,自动 Range 分区优于手工预设 Hash 分区。自动分区支持分区裁剪,对范围扫描类查询性能更优;手工 Hash 分区在范围查询时需扫描所有分区,显著增加延迟与资源消耗。
  • 需正确创建 Table Group:HBase 表名对应 OBKV-HBase 的 tablegroup 名字。
  • 注意命名规范:HBase 列簇 family 在 OBKV-HBase 形式对应表 tablegroup$family。
  • 注意 K 大小写:使用 DBeaver 等工具导出建表语句时,关键字(如 K)可能被转为小写(如 k),导致语法错误。同时需显式设置最大版本数(Max Versions)和数据过期时间(TTL)(多个版本多行)。

Step2: 数据迁移

在完成目标端环境准备后,我们分阶段实施历史数据迁移与增量数据同步,确保业务平滑切换至 OBKV-HBase。

历史数据迁移

为高效迁移海量历史数据(单表达数十 TB),我们同时使用了 DataX 与 OMS ,但需特别注意两者在数据格式上的关键差异:

  • DataX 导入的数据 Q 值是带列簇,T 值是正数。
  • 用 OMS 导入的 Q 值是不带列簇,T 值是负数。
增量数据同步

为确保切换期间数据零丢失,我们采用 “OMS 增量同步 + 业务双写” 双保险机制:

  • HBase 开启复制,通过 OMS 增量同步。
  • 通过业务程序双写保证数据实时同步。
  • 逐步将流量从 HBase 切换到 OceanBase。

Step3: 数据校验

由于 OBKV-HBase 属于 NoSQL 场景,OMS 在当前版本中尚未提供 KV 类型数据的全量一致性校验功能,我们结合业务实际,设计了一套多维度、可落地的数据校验方案,确保迁移后数据准确无误。

1. 行数校验:精确统计表行数。

HBase 端:使用 HBase 的 RowCounter 工具统计原表行数。 命令: org.apache.hadoop.hbase.mapreduce.RowCounter 'table'

OceanBase 端:使用 count 统计,获取行数并与 HBase 结果比对。

2. 三方数据对比:借助 Doris 实现内容级校验。

由于 OMS 暂时不支持进行 KV 场景下的全量校验,我们引入 Doris 作为临时比对中间层:

  • 通过 DataX 将 HBase 数据同步至 OceanBase 和 Doris。
  • 对比 HBase、OceanBase、Doris 三方的数据一致性。

3. 对关键业务字段进行抽样对比。

Step4:数据访问支持

在完成数据迁移与校验后,业务系统需通过标准接口访问 OBKV-HBase。我们发现 OBKV-HBase 不仅兼容 HBase 协议,还扩展了多项高级查询与操作能力,显著提升了开发效率与系统灵活性。

查询操作(Select)
  • Filter:支持定义基于 AND 及 OR 构建的复杂的过滤条件,下压给 OBKV 服务端来做过滤。
  • Limit:限制返回满足条件数据的条数。
  • IN 等语法糖:IN 本质上是一种 Filter,提供对应接口方便业务编码。
  • 简单聚合能力:提供 Sum/Min/Max/Avg/Count的聚合语义接口,下压给 OBKV 服务端来做简单聚合。
  • OrderBy:只支持基于主键以及索引序。
  • 迭代器访问方式:提供类似迭代器的流式 Query 接口,适用于大批量结果集的流式获取以及处理场景,比如翻页场景。
数据操作
  • Insert:支持单行/多行数据插入。
  • Update:支持单行/多行数据更新,支持带 Filter 的条件更新。
  • Delete:提供基于主键做数据的删除,支持单行/多行数据删除。
  • Upset(insertOrUpdate):此接口的语义是,如果有对应记录存在,执行 Update 操作,如果不存在,执行 Insert 操作,此接口也支持单行/多行操作。

Step5:业务压测

为确保 OBKV-HBase 能够满足高并发生产环境要求,我们使用真实业务压测 OBKV 性能,达到 42w QPS,延迟仅为 1ms 左右,超出预期。

压测方法:

  • 业务直接连接 OBServer 压测 OBKV 性能。
  • 对比前期通过 ODP 压测的性能差异。
  • 详细测试数据

我们部署 10 个 Pod 模拟业务客户端,分别通过 OCP 统一调度和通过 ODP 的方式进行多轮压测任务。如下分别是 OceanBase 数据库、OCP 模式、ODP 模式压测的数据记录。

OceanBase 数据库压测数据如下图所示

OCP 模式压测数据如下图所示

ODP 模式压测数据如下图所示

需要说明的是,前期通过 ODP 压测,性能不佳,QPS 不到 2k,具体原因分析见后续问题总结。经过优化,直连 OBServer 压测 OBKV,QPS 达到 42W,延迟 1ms 左右,完全满足业务需求。

直连 OBServer 的测试结果让我们对 OceanBase 的性能有了充分的信心,为后续业务的正式切换奠定了基础。

OBKV上线经验与问题总结:运维配置、数据校验

在 OBKV-HBase 的测试与上线过程中,我们积累了一系列关于监控集成、硬件配置、租户隔离及 CDC 同步等方面的实践经验,总结如下,供大家参考。

运维配置相关

1.监控配置

为避免重复建设监控平台,我们将 OBKV 相关指标接入公司统一的自研监控系统:

  • ODP 的 Prometheus 参数可直接使用默认配置,无需额外调整;
  • 如需修改 ODP 监控参数,可通过 sys 租户登录集群,执行以下命令:
show proxyconfig like "%prometheus%"以及alter proxyconfig set xxx = xxx;
2.硬件配置
  • 建议使用高性能磁盘,以保障高吞吐写入需求。
  • 初期资源不要划太多,避免将单台服务器的全部 CPU/内存资源划给租户,以便预留弹性空间用于后续扩缩容及负载均衡。
  • 单个节点的磁盘要大于日志流的大小,当单表很大时且未合理分区,其对应的日志流可能超过单节点磁盘容量,同时在集群扩容(如从 3-3-3 架构扩展至 6-6-6 )时,副本迁移会因日志流到节点磁盘迁移失败而失败。
3.租户配置

建议为 OBKV 创建独立租户,避免与 TP/AP 类 SQL 业务共享资源。

4.CDC 配置

在使用 OMS 或 CDC 进行数据同步时,需特别注意 HBase 动态列模型与 CDC 日志格式的兼容性问题。HBase 表的列是动态的(不同 Row 可含不同列),而 OceanBase 的 clog(提交日志)在记录变更时有两种模式。

  • 全列模式(full):记录整行所有列的值。
  • 非全列模式:仅记录被更新的字段。

若源端写入为非全列,而目标端 CDC 期望全列日志,可能导致同步解析失败或数据不一致。

解决方法是启用 CDC 的脏数据跳过开关skip_dirty_data=1,允许跳过全列校验,修改后重启实例生效:ALTER BINLOG INSTANCE y6op8d9rk1 SET EXTRA_OBCDC_CFG ='skip_dirty_data=1'

5.前缀检索用 setRowPrefixFilter

在早期调研阶段,我们比较担忧 OBKV-HBase 是否支持基于 RowKey 前缀的高效查询。经过深入查阅文档与测试验证,确认 OBKV-HBase 完全兼容 HBase 1.2+ 的原生 API,其中包括关键的前缀检索功能。可通过 Scan.setRowPrefixFilter(byte[] prefix) 方法实现高效的前缀扫描(Prefix Scan),具体如下图所示。

该接口会自动构造起始键(startRow)和终止键(stopRow),仅扫描匹配指定前缀的 RowKey 范围,避免全表扫描,显著提升查询效率。

数据校验问题

在从 HBase 迁移至 OBKV-HBase 的过程中,我们在数据校验过程中也遇到了3个关键问题。

问题1:上下游数据条数校对问题

问题描述

使用 DataX 和 OMS 两种工具分别迁移同一张 HBase 表后,OBKV 中的数据行数均少于 HBase 源端,初步校验无法对齐。

原因分析

HBase 的数据模型特性导致 count 结果存在歧义。

  • Region 分裂重叠:分裂过程中可能短暂产生重复 RowKey。
  • 未提交数据/写入失败残留:部分写入未完成但日志已落盘。
  • 多版本(Multi-Version):同一 RowKey 多次写入生成多个时间戳版本,默认全部保留。
  • TTL(Time-To-Live)未生效:过期数据尚未被清理,仍计入统计。

在上述场景下,HBase 的 RowCounter 统计的是所有版本 + 所有可见记录,而 OBKV 默认仅保留最新版本(若未显式配置),导致数量差异。

解决办法

  • 统一迁移工具:避免混合使用 DataX 与 OMS,防止因时间戳、列格式处理逻辑不同引入偏差。
  • 放弃基于快照(Snapshot)或 HFile 的 BulkLoad 方式,改用 queryType=scan 的流式读取,确保仅同步当前可见、已提交的最新版本数据。
  • 开发专门的数据校验工具,对比源端和目标端的数据。

结果验证

通过调整迁移工具和校验方法,最终实现了 HBase 和 OBKV 数据的完全一致。

注意事项

  • 建表语句大小写敏感:通过 DBeaver 等工具导出的建表语句中,K 关键字可能为小写(如 k = 'value'),需手动修正为大写,否则解析失败。
  • 注意设置最大版本号和过期属性(多个版本多行)。

问题 2: 20002 错误码

问题描述

  • 客户端等待服务端一直没有回包,超时报错 20002 ,默认超时设置为 1.5 秒。
  • 每次应用重启后,第一笔查询耗时比较高,后面查询耗时基本正常。

原因分析

根本原因是 scan.setCaching 参数配置不合理。

  • scan.setCaching 参数用于限制每次 RPC 请求返回数据的行数。在 nextO 迭代的过程中,底层通过多次 RPC 来拉取剩余数据。
  • 不设置 scan.setCaching 参数时,默认一次 RPC 拉完一整个分区的数据,在等数据返回的过程中卡住,导致 RT 较高。

解决办法

将 scan.setCaching 参数的值设置为 100,控制每次 RPC 请求返回的最大行数。scan.setCaching(100);设置后,第一次查询耗时降到了 300ms 左右,后续查询性能也得到显著提升。

问题 3:代理压测性能不佳

问题描述

通过 ODP 压测 OBKV-HBase,发现性能瓶颈明显,QPS 不到 2k。

原因分析

根本原因是ODP 元数据缓存机制与数据库大小写敏感配置不匹配。

  • OceanBase 集群启用了 表名大小写敏感模式(lower_case_table_names = 0)。
  • 而 ODP 默认行为在处理元数据请求时,未正确识别大小写敏感上下文,导致其无法有效缓存表结构信息。

每次查询均触发完整的元数据解析流程(包括向 sys 租户查询表定义),无法命中本地缓存。高频元数据查询成为性能瓶颈,严重拖累整体吞吐能力。

优化方案

  • 通过设置 ODP 参数开启 ODP 表名小写兼容模式,在 sys 租户下执行:alter proxyconfig set pc_enable_lower_case_table_names=True
  • 再次压测结果:QPS 稳定在 1.2w 左右,性能提升 6 倍

“一库多模、统一平台”,将大规模引入OceanBase

通过近两年对 OceanBase 及其 OBKV-HBase 能力的深入实践,宝付支付成功完成了从传统 HBase 架构向新一代分布式数据库平台的平滑演进,取得了显著的技术与业务成效。

  • 实现降本:HBase 独用资源转为 OceanBase 复用资源,不仅释放了数台服务器资源,还实现了 NoSQL 与 SQL 负载的统一承载,使硬件投入与运维成本大幅降低。
  • 提升效率:QPS 提升到 42W,延迟降低到 1ms 左右,完全满足高并发支付场景的严苛 SLA 要求。
  • 增强可用性:告别 MySQL 主从 + 异地备库等复杂架构,统一为 OceanBase 多副本强一致架构。系统具备自动故障切换(RTO < 8s)、数据零丢失(RPO = 0)能力,整体健壮性显著提升。
  • 统一监控:方便对应用现有运行环境添加监控,大幅提升可观测性和监控易用性。

不仅如此,对于集团架构而言,也具有重大意义和价值。

其一,完成数据库架构全面升级。从 HBase 到 OceanBase,从“多套异构数据库”走向“一库多模、统一平台”,我们实现了数据库架构的全面升级,技术栈大幅收敛。

其二,夯实业务创新底座。高性能、高可用的数据服务为实时风控、智能 BI 等新场景的业务创新提供了更强大的数据支撑能力。

其三,奠定智能数据架构基础。为未来 AI 原生计算、HTAP 融合分析、跨地域多活等演进方向预留充分扩展空间。

其四,沉淀宝贵实践经验。形成涵盖迁移方案、数据校验、性能调优、故障排查的完整方法论,可复用于后续系统改造。

本次 OBKV-HBase 成功落地,离不开 OceanBase 团队在过去两年中提供的专业、及时、深度的技术支持,特别是老纪及其研发、技术支持团队。无论是早期功能定制、性能瓶颈攻关,还是生产上线保障,OceanBase 团队始终与我们并肩作战,为项目顺利推进提供了坚实保障。在此,谨代表宝付支付技术团队,向 OceanBase 团队在迁移过程中提供的技术支持致以诚挚感谢!

另外,基于当前 OceanBase 在宝付支付的成功落地经验,我们已将 OceanBase 纳入集团未来数据架构的核心,聚焦 AI 项目赋能、汇聚库建设、多活架构尝试、零售支付场景四大业务方向大规模引入。

1. Al 项目赋能:实现一体化SQL+AI。

为响应公司对智能化转型的战略要求,我们将 AI 能力深度集成至数据库引擎层,推动从“被动查询”向“主动智能服务”升级。

  • 原生支持 AI 混合计算:利用 OceanBase 内置的向量化执行引擎与 AI 函数能力,实现“SQL + AI”的混合计算。
  • 探索智能化查询优化和数据处理。
  • 提升数据分析和決策支持能力。

2. 汇聚库建设:实现一体化TP+AP。

当前集团存在 1000+ MySQL 实例及多套异构数据系统,导致跨库分析、实时统计、经营报表等场景面临巨大挑战,OceanBase 的 HTAP 一体化架构为此提供了根本性解决方案。我们将逐步把核心业务库、汇聚库、宽表等迁移至 OceanBase 并扩大线上使用规模,使用一套集群同时承载 TP 写入与 AP 分析,构建统一的数据平台,简化数据链路,提升数据治理和数据服务能力。

3.多活架构尝试,实现系统稳定。

苦于MySQL双活架构带来的问题,我们将尝试业务多活要求,满足高可用业务需求。依托 OceanBase 原生分布式多副本与 Paxos 协议能力,构建轻量级、高可用、跨机房、跨地域的多活架构,提升系统容灾能力和业务连续性。

4.零售支付场景深化。

随着内部零售支付业务越来越多,我们将在其他零售支付业务场景推广使用 OceanBase。并持续优化 OceanBase 压测记录,完善性能基线。我们计划基于真实业务负载开展常态化压测,建立 QPS、延迟、资源消耗等关键指标的基准模型。

此外,探索更多 OceanBase 在支付行业的应用场景,充分发挥 OceanBase 的 HTAP 与多模能力。

数据库的升级不仅是技术的迭代,更是业务持续创新与稳健运行的基石。

欢迎关注,将为您持续更新与#数据库、#AI、#开发、#降本增效 相关的技术内容。

摘要:

OceanBase 凭借原生分布式、零停机、全栈多云兼容三大核心技术优势,精准破解 TNG Digital 在高并发支撑、业务连续性等方面的痛点,助力其实现从“宕机危机”到“99.99%高可用”的跨越式升级,成为其规模化盈利的技术基石,打造了分布式数据库以硬核技术赋能东南亚头部金融科技企业核心支付场景的标杆范例,为分布式数据库基础软件出海提供“技术适配+低成本落地”的全新实践路径。

作为马来西亚金融科技领域的领军者,TNG Digital 凭借 TNG eWallet 深度融入民众支付生活,全面覆盖交通出行、餐饮消费、资金转账等高频场景。

自 2018 年起,其用户规模实现超 10倍爆发式增长,截至 2025 年,已服务马来西亚 3300 万人口中的 2500 万验证用户,成为支撑区域数字经济运转、贯穿民生服务的关键信息基础设施。

然而,高速增长背后暗藏技术“生死考验”,OceanBase 凭借原生分布式、零停机、全栈多云兼容三大核心技术优势,精准破解 TNG Digital 在高并发支撑、业务连续性等方面的痛点,助力其实现从“宕机危机”到“99.99%高可用”的跨越式升级。

本次合作不仅成为 TNG Digital 规模化盈利的技术基石,更打造了分布式数据库以硬核技术赋能东南亚头部金融科技企业核心支付场景的标杆范例,为分布式数据库基础软件出海提供“技术适配+低成本落地”的全新实践路径。

增长阵痛:金融科技高并发场景下的核心数据底座短板

作为承载马来西亚数千万用户日常支付的核心平台,TNG Digital 的系统稳定性直接关系到民生服务体验与金融市场秩序。

Leslie Lip(TNG Digital CTO)坦言,业务年增长率达 2-3 倍的背后,是技术团队不断与“规模陷阱”博弈的过程。

核心痛点集中于数据底座的四大短板:

· 突发流量峰值应对失效

午间支付高峰时段,全钱包系统需承载巨大的交易压力,而原有数据库难以支撑政府补贴发放等非常规突发流量。TNG Digital 曾在 6 年前发生的数据异常,正是因为原有数据库架构缺陷导致服务器资源未充分利用从而陷入瓶颈,暴露了核心数据底座的“抗冲击”能力不足。

· 业务迭代中的停机风险

金融科技平台需通过高频表结构更新,适配支付场景创新,但原有数据库的 DDL 变更常导致生产环境停机,直接影响用户支付、转账等核心操作的连续性,成为业务快速迭代的“绊脚石”。

· 多云扩展的兼容性壁垒

业务初期依托阿里云,随规模扩张延伸至 Azure、AWS 等多平台,但不同云厂商的数据库服务存在适配鸿沟,既无法实现跨云协同运维,又面临被单一厂商绑定的“vendor lock-in”风险,制约 TNG Digital 的全球化布局步伐。

· 性能与成本的失衡困境

用户增长带来数据量爆发式累积,原有数据库存储效率低下,导致 IDC 运维与存储成本持续攀升;同时在相同硬件规格下,吞吐量难以匹配业务增长需求,形成“成本涨、性能滞”的恶性循环。

OceanBase 破局之道:以“支付级”能力适配金融科技核心需求

Leslie Lip 强调,选择 OceanBase 的核心逻辑是“解决真实业务痛点,而非单纯追求技术参数升级”。

针对 TNG Digital 在支付场景高并发、业务连续性、多云扩展等方面的核心诉求,OceanBase 提供了贴合金融科技特性的全链路解决方案:

01零停机解决核心技术破解迭代难题

依托原生分布式架构设计,OceanBase 实现核心表 DDL 操作零停机执行的关键技术突破——在 POC 阶段即完成 4 万 TPS CRUD 并发场景下的表结构更新测试,全程无业务中断、无性能衰减。

这一技术特性彻底解决了 TNG Digital 高频迭代中的停机隐患,为支付场景快速创新扫清核心技术障碍。

02原生分布式架构扛住峰值压力

OceanBase 采用“share-nothing”原生分布式架构,具备线性弹性扩展能力,可按需扩容支撑业务增长。

该技术特性使其既能轻松承接午间的常规高峰流量,更能应对政府补贴发放等非常规突发流量的冲击,从底层架构层面杜绝宕机风险,完美匹配支付场景对高可用的极致要求。

03全栈多云一致性体验能力

OceanBase 内置全栈多云兼容技术模块,通过统一的技术接口与适配层,完美兼容阿里云、Azure、AWS 三大云平台的底层环境,实现不同云平台下的部署架构、运维操作、性能表现及合规审计的全链路一致性体验。

这一核心技术特性,不仅为 TNG 搭建了 “以私有化部署为核心、多云协同为延伸” 的弹性 IT 架构,保障了征信数据跨云流转与管理的稳定性、安全性,更从技术层面帮助 TNG Digital 彻底摆脱 “vendor lock-in” 制约,为其后续拓展东南亚其他区域征信服务、接入更多全球云服务提供商奠定了核心基础,让 TNG Digital 在全球化业务布局中具备更强的技术灵活性与成本可控性。

04高压缩比+高性能优化技术提升效益

OceanBase 基于高压缩的数据引擎,实现 5 倍数据体积缩减的技术效果,大幅降低存储与运维成本。

同时凭借分布式执行引擎优化技术,在相同硬件规格下实现 40% 的吞吐量提升,精准破解 TNG Digital “成本涨、性能滞”的核心困境,为金融科技企业盈利化发展提供技术支撑。

05全量 MySQL 兼容技术加速落地见效

OceanBase 深度打磨 MySQL 兼容层技术,实现语法、应用行为、驱动的全量兼容。

这一技术特性使 TNG Digital 技术团队无需额外学习成本即可快速上手,大幅缩短项目升级与落地周期,实现技术升级的“平滑过渡”。正如 Leslie Lip 所言,OceanBase 不仅是数据库,更是“能伴随企业野心共同成长的技术平台”。

实现从“生存线”到“增长线”的价值跃升

基于 OceanBase 完成核心数据底座升级后,TNG Digital 在业务稳定性、运营效率、创新能力三大维度实现质的飞跃,关键成效完全匹配金融科技支付场景的核心诉求:

01支付连续性达行业顶尖水平

核心系统实现 99.99% 的高可用,与 OceanBase 合作至今,未发生任何数据库事故,成功支撑多轮政府补贴发放等重大场景的平稳运行,彻底摆脱过往宕机阴影,筑牢支付业务“生存线”。

02性能与成本效益双突破

相同硬件规格下,业务吞吐量提升 40%,高效承接高峰期高并发交易;5 倍数据压缩比大幅降低存储成本,为企业盈利化发展提供有力支撑,将数据底座从“成本中心”转化为“效益中心”。

03创新与拓展能力全面释放

零停机 DDL 与多云协同能力,为 TNG Digital 的场景迭代与跨平台拓展扫清障碍。

目前双方已启动键值数据库模型搭建、跨云双活架构合作等计划,将基于 OceanBase 构建更具弹性的时间敏感型支付应用,进一步拓宽业务增长边界。

从服务本土支付场景的分布式数据库,到支撑海外支付场景的分布式数据库

金融科技的规模化增长,本质是数据底座“抗冲击能力、迭代能力、扩展能力”的综合较量。

TNG Digital 作为东南亚支付领域的龙头企业,其面临的“高并发、零中断、多云扩展”痛点,是全球金融科技企业规模化过程中的共性难题。OceanBase 的成功落地,不仅解决了单一企业的技术困境,更提供了适配支付场景核心需求的可复制技术方案。

OceanBase 与 TNG Digital 的合作,标志着分布式数据库凭借“原生分布式+零停机+全栈多云兼容”等硬核技术特性,已具备支撑海外头部金融科技核心支付场景的成熟能力,实现从“国内核心场景验证”到“海外高频支付场景落地”的关键跨越。

区别于其他出海案例,此次合作的核心亮点在于以技术特性精准匹配支付场景需求——零停机保障业务迭代连续性,原生分布式支撑高并发峰值,多云兼容打破拓展壁垒,这些技术优势共同重塑了海外市场对分布式数据库基础软件在支付场景下的技术认知。

未来,OceanBase 将持续深化与 TNG Digital 的协同创新,助力其实现云服务提供商拓展、跨云韧性升级等战略目标,同时进一步完善东南亚市场的本地化服务体系,聚焦金融科技支付、数字钱包等核心场景,为更多海外企业提供“支付级”稳定、高效、经济的数据底座支撑,推动分布式数据库基础软件全球化布局向“场景化深度赋能”新阶段迈进。

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

作者:张红霞,青岛雨诺网络信息股份有限公司新零售产品部总监

综述

当前,医药零售企业已不再满足于“卖药”,而是致力于成为“健康管理伙伴”。通过构建以 CRM 会员系统为核心、线上与线下深度融合的全渠道服务架构,企业实现了服务时间与空间的无限延展、会员数据的集中管理与智能应用、营销活动的精准触达与高效转化。

作为医药零售的头部企业,重庆医药(集团)股份有限公司(简称“重药集团”)前身是成立于1950年的中国医药公司西南区公司,服务于医药全产业链,同时从事医药研发(MAH)、医疗器械生产,并投资参与医药工业。重药集团拥有全级次分、子公司200余家,正在从传统的配送商业企业向“互联网+医药”融合型现代医药企业转型。

随着CRM会员系统的使用时间拉长,其底层的传统数据库逐渐难以满足复杂数据的高效处理需求。面对海量交易和多维度行为数据的汇聚,重药集团CRM会员系统亟需采用具备高可用、强一致、可扩展特性的数据库。经过对比三款国产分布式数据库,重药集团选择OceanBase,最终实现系统稳定运行、复杂场景实时分析、查询效率提升25倍、存储空间节约60%。

此次重药集团CRM系统的数据库升级不仅提升了用户体验与品牌忠诚度,也为后续集团构建高性能、高可用的“集团级数字化运营中枢”提供了明确的业务需求与数据基础,构建可扩展、可复制、可监管的集团化运营体系。

医药零售商业模式变革,CRM系统实现全渠道协同

随着消费者行为的数字化转型和健康需求的持续升级,医药零售行业正经历深刻的商业模式变革。传统药店“有啥卖啥”的经营逻辑,逐步向“顾客需要什么”的逻辑转变,除了提供到店服务外,还支持线上服务,比如通过企业微信、公众号等渠道建立长期沟通机制。微商城代客下单、在线解答疑问等。

为构建以专业化服务为基础的顾客信任体系,医药企业建立了完整的会员服务体系——CRM 会员系统,以实现绑定多重会员信息、建立精准的会员标签画像,为会员提供更多的服务和营销。通过数据驱动决策的专业化服务能力提升来提高企业在行业内的竞争力,实现增收。

如图1 所示,CRM 会员系统可以实现线上、线下全渠道协同,支持会员档案统一、标签体系完善、自动触发机制、店员触达赋能、社群营销等关键功能。完成顾客到店/线上购药 → 完成交易 → 数据沉淀至 CRM → 触发服务与营销 → 二次消费 → 再次触达,实现“交易—服务—再交易”的正向循环。

图1 CRM会员系统实现线上、线下全渠道协同

为实现一体化管理需求,构建CRM会员系统

重药集团CRM会员系统的搭建背景,源自于其各子公司会员管理分散,系统缺乏统一规划,导致数据难沉淀、服务差异大、运营难复制,且缺乏实时监控,难以支撑决策。

为实现一体化管理,重药集团CRM会员系统分阶段建设。第一阶段完成会员营销平台的底座建设,打造集团化、标准化、数据化运营基础,核心目标如下。

  • 搭建集团化会员运营平台。现集团—子公司—门店的一体化管理,打通组织架构与业务链路,确保会员在不同层级和渠道中都能获得一致的服务体验。
  • 统一的会员运营服务体系。构建覆盖会员管理、营销活动、服务交付的标准化流程,减少分散运作带来的效率损耗,提升整体运营协同能力。
  • 可快速复制标准化服务能力。形成可落地的服务模板和运营机制,帮助新业务和子公司快速复制成熟经验,缩短建设周期,提升推广效率。
  • 实现经营数据统一分析。沉淀完整的数据资产,打破信息孤岛,实现对会员、门店、区域的多维度统一分析,为企业战略决策与合规审计提供有力支撑。

在上述目标指导下,我们做了三个核心举措:

  • 联合集团会员中心,推进一体化进程。覆盖集团全品牌及线上会员,实现线上和线下会员统一运营和全域价值管理(见图2)。
  • 构建多层级组织架构视角报表。支持集团、品牌、门店的权限管理,权限灵活配置,便于集团总部进行跨品牌的数据报表分析。
  • 集团统一下达任务。集团可向各品牌下发销售任务、患者教育活动任务及拉新任务,实现集团任务统一管理与执行监督。

图2 集团会员同意运营架构

我们计划以集团内个别区域公司为试点,试行以上举措,若成功,则进行全面推广。推广成功后,重药集团会员运营平台将实现从“单一业务系统”向“集团级数字化运营中枢”演进。依托统一的技术底座与标准化流程,平台不仅实现对多家子公司、多个品牌的全面接入,更构建起可扩展、可复制、可监管的集团化运营体系。

此外,为实现全渠道会员统一运营,平台通过整合分散在各系统中的数据,构建统一、动态、多维度的会员标签画像体系(见图3),支撑精细化运营决策。

图3 多维度会员标签画像体系

通过会员系统精准化的服务来反哺我们的线上和线下的会员营销和服务,实现线上精准营销、个性化推荐、好物推送、会员关怀,线下关联用药建议、慢病管理提醒、店员主动触达等,提升营销转化率,增强客户粘性,实现“数据驱动服务”的闭环。

精细化会员服务,带来海量数据的查询、存储难题

然而,随着集团化会员运营平台的推进,精细化服务模式持续深化,导致用户数据规模呈指数级增长,显著提升了系统的查询与存储复杂性。

  • 会员量:突破千万级,覆盖多个品牌及区域公司。
  • 交易数据量:达到亿级,涵盖线上线下购药、用券、复购等行为。
  • 用户行为类数据:包括商品浏览、搜索、加购等,总量亦达千万级以上。

这些数据来源于线上商城、私域平台、公众号等多个渠道,经标签体系整合后,用于构建立体化的会员画像,支撑精准营销与双向引流。

但数据体量大、类型多样、实时性要求高,对数据库的高并发读写能力、存储扩展性与查询性能提出严峻考验。面对千万级会员、亿级交易和多维度行为数据的汇聚,传统数据库难以满足高效处理需求,亟需采用具备高可用、强一致、可扩展特性的分布式数据库系统进行支撑。

CRM会员系统数据库升级,应对千万级数据处理难题

传统数据库的技术瓶颈制约业务发展

重药集团会员服务平台的规模化发展,使系统数据总量迅速增长至千万级、数十 TB 存储规模,传统关系型数据库在支撑精细化会员运营场景时,暴露出四大核心挑战。

  • 性能:百万大表 InnoDB 在高并发读写及复杂查询场景下,性能显著下降,无法满足业务需求,且有事务访问,无法通过拆分提升性能。同时,业务强依赖事务一致性,无法通过拆分提升性能。
  • 效率:核心归档由于业务需求,需要保留大量数据(数十 TB),会造成 DDL 周期长,延迟业务上线时间。
  • 成本:随着企业数量增多、历年数据累积,存储成本将越来越高。
  • 及时性:在各种场景下,对应数据处理的及时性需求越来越强。

上述技术挑战不乏真实业务案例。

例 1:某大型连锁店,以满足信创要求为前提进行性能保障

如今国家对信息技术应用创新(简称“信创”)的要求日益严格,特别是在国有企业中,系统必须符合相关标准才能上线。为了响应这一趋势,我们严格按照信创目录选择数据库产品,并对其进行了全面的业务场景适配与性能验证。

  • 数据准备:会员卡 9950万+、订单 1 亿 9980万+。
  • 验证数据库:OceanBase 数据库、某数据库1、某数据库2。
  • 验证功能:报表 14 项内容、高级筛选 8 项内容。
  • 参考标准:报表查询小于 20s、静态化数据小于 60s、高级筛选小于 15s。

测试结果如图4所示。OceanBase 在所有测试项中均显著优于其他两个国产数据库,在报表查询、高级筛选、静态化数据三个场景的性能表现都远超预期:

  • 报表查询小于 7s,平均提速 78 倍以上。
  • 高级筛选响应高级筛选小于 1s,速度提升 200–700 倍。
  • 静态化数据静态化数据小于 46s,效率提升 6.7 倍以上。

图4 OceanBase 数据库、某数据库1、某数据库2的测试结果

在严格遵循国家信创要求的前提下,OceanBase 不仅完全满足合规性准入条件,更在百亿级数据规模下的复杂查询与批量处理场景中展现出卓越性能,远超同类国产数据库产品。基于此,我们总结了三个数据库的性能数据,向客户提交了一份详细的分析报告。

例 2:连锁会员、订单交易数据量增长迅速,实时性查询瓶颈

除了信创需求外,客户对业务的实时性、及时性要求也越来越高。过去,企业主要依赖 BI 工具进行周期性报表生成,可容忍数小时甚至数天的数据延迟。然而,随着营销策略向精准触达和即时响应演进,业务人员需要在高价值客户识别、复购提醒触发、定向营销投放、健康知识推荐等场景中获取近实时数据支持。为实现精准服务,运营人员经常需要基于会员信息、会员属性、历史消费、会员标签、商品集合等多个维度进行多维组合筛选,由于关联维度过多,可能会出现查询失败、查询时间过长、范围跨度受限、复杂查询无法支持等问题,显然,这些问题是我们服务的客户无法接受的。

例 3:海量业务数据,系统可用性与存储成本难平衡

连锁医药企业会员体系的不断扩展和数字化运营的深入,必然会带来业务数据量的指数级增长,海量数据带来的高存储成本成为制约系统可持续发展的关键瓶颈之一。

  • 用户数据:累计会员数量突破千万级(>1000万)。
  • 交易流水:日均订单量达百万级,历史累计超过亿级(>1亿条)。
  • 用户行为数据:包括浏览、搜索、加购、收藏等行为记录,总量亦达千万级以上。

单个业务数据库实例空间占用已达到 N 个 TB 级别,且随时间推移呈线性增长。随着客户数量增加和业务持续扩张,业务数据库实例的空间占用迅速攀升至数十TB甚至上百TB级别,这些数据不仅用于支撑日常业务运行,还需长期保留以满足合规审计、精准营销、客户画像构建等需求。企业面临保障性能与可用性的前提下降低存储成本的难题。

因此,引入具备高效数据压缩、自动冷热分层、弹性扩展能力的新一代分布式数据库,是实现“数据价值最大化、存储成本最小化”的必然选择。

数据库技术引入,支撑海量交易数据的高效处理

综合业务需求与传统数据库的技术瓶颈考虑,我们需要替换传统数据库,升级为高性能、稳定性强、成本低、 HTAP 一体化的分布式数据库。

自 2023 年起,我们开始系统性地评估并引入 OceanBase,历经技术认知、多轮测试、工具链验证、SaaS 级试点上线等关键阶段(见图5),最终成功应用于重药集团会员管理平台。

图5 上线OceanBase的关键阶段

1.技术引入与评估阶段(2023年)

测试重点包括三部分。

其一,日常抖动测试。在对 OceanBase 初期测试时,我们首先进行了业务压力测试。低峰期业务配合100%模拟线上流量直接发压,高达4轮的压力测试,每次持续 3 小时以上。

其二,扩容/缩容测试。在业务流量低时进行相关操作验证。为了验证是否存在小概率事件,进行了为期一周的脚本自动扩、缩容操作以观察其稳定性。

其三,Add Index 测试。与扩容、缩容相仿,基于业务流量对1T大表进行多达几十次的add index操作,观察延迟情况。

2.SaaS 产品试点上线(2023 年 12 月)

在完成全面技术验证后,我司将 OceanBase 应用于内部 SaaS 类产品中,作为首个生产级试点场景。该阶段实现了:

  • 数据库稳定运行于真实业务环境中。
  • 验证了迁移、运维、监控等全生命周期管理能力。
  • 积累了宝贵的实战经验,为后续客户项目打下坚实基础。

3.重药集团项目正式上线(2025 年 4 月)

基于前期充分验证与试点成果,我们于 2025 年 4 月正式启动重药集团会员管理平台项目,OceanBase 正式投入生产使用,支撑海量交易数据的高效处理。

会员服务平台“新面貌”:稳定、高性能、低成本

构建标准化数据链路,稳定、高效处理海量数据

目前,OceanBase 主要支撑重药集团会员服务平台的分析型业务场景,支撑高并发、多维度的会员数据查询、标签计算、报表生成及精准营销决策。其核心价值体现在:高效处理海量历史数据、支持复杂实时分析、保障查询性能与系统稳定性。

整个数据链路遵循“源系统 → CRM 中转清洗 → OceanBase 分析库”的三层架构,如图6所示。

图6 会员服务平台的数据分析链路

数据来源(源系统)包括POS 订单数据、各渠道会员信息、组织人员数据、会员标签数据、档案测量数据、全部商品主数据。

  • 中转与清洗层(CRM 系统):所有原始数据通过定时抽取或实时接入方式进入 CRM 系统,进行统一的数据清洗、去重、合并与标准化处理。关键处理策略包括历史数据清洗、订单数据合并、积分逻辑处理、会员标签动态更新、消费行为计算、活跃度模型计算。
  • 目标存储与分析层(OceanBase 分析库):清洗后的数据通过同步机制实时或定时写入 OceanBase 分析库;并分为原始数据表、静态化处理表、日表/月表、报表中间表。

通过构建“源数据 → CRM 清洗 → OceanBase 分析库”的标准化数据链路,实现了多源异构数据的统一整合、复杂分析场景的高性能响应、业务数据的长期留存与高效利用。

会员精准筛选复杂场景,查询效率提升 25.7 倍

在重药集团会员服务平台的实际运营中,多维度组合筛选(见图7)是支撑精细化营销与客户管理的核心功能。对于数据库而言,该功能是典型的复杂查询场景,用户需同时基于多个维度进行精确匹配,查询通常涉及多表关联、大量过滤条件和聚合计算,非常考验数据库的执行效率。我们通过开启 OceanBase 的列存模式(Columnar Storage),将原本传统数据库MySQL 的响应时间从 18 秒缩短至 0.7 秒,性能提升达 25.7 倍,满足业务对“实时圈选、即时触达”的严苛需求,显著提升了系统整体吞吐量与用户体验。

图7 会员服务平台多维度组合筛选

数据存储空间省 60%,有效降低存储成本压力

OceanBase 将全量数据划分为两个部分进行管理:一是增量数据(Memtable),即实时写入内存中的热数据,支持快速读写;二是基线数据(静态数据),即经过合并与持久化后的冷数据,存储于磁盘。

对于静态数据,OceanBase 采用高效的压缩算法,对列式存储的数据进行深度压缩,显著减少磁盘 I/O 和存储开销。例如,当原始数据总量为 4TB 时,MySQL 需要完整保留所有数据,存储空间占用为 4TB;而 OceanBase 通过对静态数据进行高压缩处理,仅需 1.5TB 即可承载相同规模的数据。

在重药集团会员服务平台的实际部署中,OceanBase 通过其先进的列式存储引擎与高效压缩算法,显著降低了数据存储空间占用,在同等业务数据规模下实现了 60% 以上的存储空间节约,有效缓解了海量数据带来的存储成本压力。

面向未来,持续推进 OceanBase 的深度集成与价值释放

随着 OceanBase 在重药集团会员服务平台的成功落地,我们对其在更广泛业务领域和客户群体中的应用充满信心。面向 2026 年及未来,我们将围绕场景拓展、客户推广、技术融合与产品适配四大方向,持续推进 OceanBase 的深度集成与价值释放。

应用于更多业务场景与产品

当前,OceanBase 已稳定支撑重药集团会员管理平台的复杂分析型业务(如精准筛选、标签计算、报表生成)。订单处理中心和运营诊断产品也在生产环境开始使用OceanBase,下一步,我们将推动其全面融入日常运营服务场景,包括:实时会员服务、营销活动执行、AI 智能推荐等业务场景。

另外,我们将逐步将 OceanBase 适配至更多内部产品,包括商品主数据管理、患者健康管理平台、智能补货与供应链协同系统,构建以 OceanBase 为核心的统一、弹性、智能的企业级数据基础设施。

向业内客户推荐

在国家信创政策与企业降本增效双重驱动下,我们已将 OceanBase 作为高并发、大数据量、强一致性要求场景下的首选数据库,并向行业客户积极推广。截至目前,已在以下大型医药企业成功落地:扬子江药业集团、鹭燕医学、重药集团、上海医药、国大药房。未来,我们将继续优先推荐 OceanBase 作为会员服务、订单中心等关键系统的数据库底座,助力更多企业完成安全、高效、低成本的国产化替代。

交流开发,沉淀运维经验

为持续提升团队与客户的 OceanBase 应用能力,我们计划定期组织专题培训、参与社区技术沙龙、共建问题解决机制、定期组织数据库培训及实战分享会议,探讨并解决遇到的问题,争取打造一支“懂业务、精技术、能落地”的复合型数据库应用团队。

未来,我们将携手更多合作伙伴,共同探索“数据库 + AI + 行业场景”的创新路径,为医药健康行业的高质量发展注入新动能。


近日,全球权威机构 IDC 发布的《IDC 中国分布式事务数据库市场追踪,2025H1》报告显示,2025 上半年,原生分布式数据库厂商 OceanBase 以 2810 万美元营收,居中国分布式事务数据库本地部署市场第一。这是继 2024 年下半年后,OceanBase 连续两次在该细分市场拔得头筹。

同时,在包含公有云的整体市场中,OceanBase 以 4060 万美元营收位列独立厂商第一、整体第四,持续领跑国产数据库阵营。

 

IDC 统计,2025 上半年,中国分布式事务数据库市场规模达 4.2 亿美元,同比增长 19.6%。其中,本地部署市场增速高达 24.9%,显著高于公有云部署模式,预计 2024-2029 年复合增长率将达 24.2%。分布式数据库正加速向金融、政务等核心系统渗透,在性能、稳定性与综合成本上比肩甚至超越国际产品。

 

IDC 同时认为,当前市场集中度持续提升,前五大厂商已占据 82.5%的市场份额。随着国家数据库测评名单的发布和政策深入推进,具备核心技术能力与成熟实践案例的厂商优势凸显。

 

据了解,OceanBase 是蚂蚁集团 100%自研的原生分布式数据库。IDC 在报告中指出,OceanBase 凭借原生分布式、原生多租户、HTAP、高级数据压缩等技术特性,成为分布式交易型数据库的代表厂商。其“单机分布式一体化”设计,可在同一产品体系下灵活支撑企业从初创到超大规模增长的全周期需求。

 

自 2020 年商业化以来,OceanBase 客户数突破 4000 家,连续 5 年年均增速超 100%,广泛应用于金融、政务、能源、通信、医疗等关键领域。面向 AI 时代,OceanBase 加速“Data xAI”融合,先后发布 4.4 一体化融合版本、AI 原生混合搜索数据库 seekdb 等产品,通过 AI 原生混合搜索、多模融合、TP/AP/AI 一体化等前沿能力,服务数十家头部企业智能化应用。

 

在金融领域,OceanBase 服务全部政策性银行、5/6 国有大行,覆盖超 100 家资产规模千亿级以上银行,支撑 190+核心系统、1000+关键业务,并成功落地汇丰、澳门大丰、老中银行、三井住友等国际金融机构。其中,老中银行在老挝上线基于 OceanBase 的新一代核心系统,性能提升 20 倍、批量处理缩至 30 分钟,成本仅为同类方案 20%,实现中国自研数据库海外银行核心系统的首单落地。

 

在政务与央国企领域,OceanBase 支撑全国约 1/3 省级人社系统、12123 交管平台、北上广深地铁票务系统及多家三甲医院 HIS 系统,并深度服务中国移动、中国联通、中国电信、国家电网、中国石化、中国航信、中国南方航空等大型央国企。

 

在海外支持方面,OceanBase 多云数据库 OB Cloud 已运行于阿里云、AWS、Azure 等七大主流云平台,支持“一套架构、全球运行”,服务 GCash、2C2P、PalmPay 等 50 余家海外客户。