• 时间:
  • 分类:

在数据基础设施领域，向量检索正在经历从“单一功能组件”向“核心生产系统”的跨越。

随着LLM应用、搜广推系统进入深水区，企业对向量数据库的需求早已超越了简单的“TopK 召回”。在生产环境中，如何在大规模数据下保持极低的延迟？如何在复杂的标量过滤条件下依然维持高吞吐？如何在数据频繁更新时保证索引的鲜度与性能？这些是决定业务成败的关键。

近日，阿里云多模数据库 Lindorm 发布了新版向量检索服务，并基于业界通用的 VectorDBBench 基准测试工具，发布了最新版本的性能报告。测试结果显示，通过引入 CBO/RBO 混合优化器 与 自适应混合索引 架构，Lindorm 在大规模数据与复杂过滤场景下展现出了显著的性能优。这不仅是一次跑分上的突破，更验证了国产云原生数据库在处理大规模、高并发、复杂混合检索场景下的硬核实力。

01 Benchmark实测分析

我们选取了业界公认的 Cohere 标准数据集，在真实云环境下与主流向量数据库进行了严苛的对比测试。

场景一：高并发 KNN 检索性能

我们分别在千万级 (Cohere-10M) 和百万级 (Cohere-1M) 规模下进行了测试。值得一提的是，这种极速体验并非以牺牲精度为代价——在两个数据集的测试中，Lindorm 始终保持了 99% 以上的超高召回率。

1. Cohere-10M：

在 1,000 万量级的数据规模下，我们将 Lindorm (32C 单节点) 与 VectorDBBench 榜单上的顶级云服务进行了横向对比：
QPS 遥遥领先：Lindorm 跑出了 2.4万+ 的极高 QPS，大幅超越了榜单前列的 Zilliz Cloud (3,957) 以及此前的 SOTA 记录（18,000）。
延迟极致丝滑：在同等高吞吐下，Lindorm 的 P99 延迟表现稳定在 2.5ms。相比之下，竞品的延迟普遍在 10ms 甚至 100ms 以上。
图片

  1. Cohere-1M：在 100 万量级下，Lindorm 展现了碾压级的性能优势：Lindorm QPS 突破 5.6万，同时将延迟控制在 2ms；相比之下，主流开源产品如 Milvus、OpenSearch 的 QPS 普遍在 3,000 左右。
    图片

    场景二：融合检索 (Hybrid Search)

    融合检索是生产环境的真实考验——业务中 80% 的查询带有复杂的标量过滤条件。而传统的“先过滤再检索”或“先检索再过滤”模式，往往在特定过滤比例下出现严重的性能坍塌。

得益于 CBO/RBO 混合优化器 与 自适应混合索引 架构，Lindorm 在全过滤区间内实现了智能的执行计划路由，不仅保持了极高的性能水位，更确保了全链路分支的召回率均在 90% 以上：

  • 低过滤比例 (Vector-Driven)：当过滤出的结果集较大时，优化器选择向量导航优先策略。利用交叉流水线技术，在图遍历的同时并行执行标量过滤，保持了与纯向量检索相当的 5万+ QPS。

  • 高过滤比例 (Scalar-Driven)：当过滤条件极严苛时，CBO 自动切换为标量驱动模式。利用 Bitmap / 倒排索引 快速圈定目标集，彻底规避了无效的向量计算，QPS 更是飙升至 26万+，完美解决了传统方案在稀疏结果集下的“深坑”问题。
    图片

    注：

    • 数据来源：Lindorm 数据基于 32C128G 规格单节点实测；Hologres 数据引用自 阿里云开发者社区；其他竞品数据直接引用自 VectorDBBench Leaderboard 及公开评测报告。
    • 真实业务模拟：Lindorm 上述成绩均为 无 Query Cache 模式下的实测值。我们测的不是缓存，是实打实的性能。

02 测试方式

为了确保测试结果的公正性与可复现性，本次测试采用了业界通用的标准硬件规格与开源测试框架。

  • 测试环境规格：Lindorm 实例规格为 32核 128GB (32C128G)，这是云上生产环境的典型配置。
  • 软件版本：Lindorm 向量引擎版本为 3.10.16 及以上。

  • 测试工具：使用业界权威的 VectorDBBench 进行压测。为了支持 Lindorm 的特定协议，我们已将适配代码提交至 VectorDBBench 官方仓库。

    开源共建：相关适配代码详见 PR #718: zilliztech/VectorDBBench。开发者可直接基于此 PR 复现上述测试结果。

03 技术解密：如何做到极致性能？

Lindorm 向量检索性能的突破，并非依赖单一算法的优化，而是源于对数据库系统架构的深度重构。我们将向量检索从“外挂索引”进化为了“原生数据库系统”。
图片

1. 突破内存墙的多技术融合架构

向量检索的本质是大量的随机内存访问。Lindorm 引入了聚类、图与两层量化深度融合的设计，将内存带宽的使用效率推向极致：

  • 聚类索引：提供稳定的空间划分，快速定位目标区域，大幅减少无效搜索。
  • 图索引：在聚类的基础上构建导航图，提供极速的近邻收敛能力。
  • 两层量化：
    Layer 1 粗排层：通过高压缩比的量化技术，使索引数据能最大程度驻留在 CPU L3 Cache 中，极大缓解了内存总线压力。
    Layer 2 精排层：仅对筛选出的少量关键候选集，加载原始精度向量进行重排。

这种先快后精的策略，让 Lindorm 在召回率不打折的前提下，检索吞吐实现了质的飞跃。

2. 融合检索：从“外挂”转向“原生数据库系统”

这是 Lindorm 向量引擎最核心的革命。在此之前，业界的融合检索方案往往陷入两难：

  • 产品化方案的“缝合怪”困境：大多数向量数据库仅是将向量索引与标量索引简单拼接。两者在底层存储与执行逻辑上完全割裂，导致查询时需要在不同引擎间大量搬运数据，性能损耗巨大。
  • 学术界方案的“僵化”难题：学术界的融合索引虽然在特定数据集上表现优异，但往往要求预先定义固定的过滤字段与数据结构，无法适应真实业务中频繁变更 Schema 的动态需求。

Lindorm 选择了一条全新的道路：将向量与标量视为统一的抽象实体。

  • 以向量为锚的统一抽象：Lindorm 彻底摒弃了“外挂”思维，而是以向量数据为锚点，重新设计了整个系统的存储结构、优化器与执行器。在这种架构下，标量属性不再是向量的附属品，而是与向量特征紧密交织的原生一等公民。
  • 自适应混合索引：为了应对多样化的标量数据分布，系统内置了自适应混合索引引擎。对于高基数数据，自动采用 Hash 或 B-Tree 结构；对于低基数数据，自适应启用 Bitmap 或 Roaring Bitmap，利用 SIMD 位运算优势实现极速集合操作。
  • 智能执行计划路由：系统实时维护高维直方图统计信息。当查询到来时，优化器会根据过滤条件的选择率（Selectivity），智能判断是应该“先查向量再过滤”，还是“先查标量再计算距离”，亦或是采用“交叉流水线”并行执行。这种智能决策机制，确保了无论数据分布如何倾斜，系统始终能选择最优的执行路径。

3. 全架构自适应加速

不同于依赖固定写死的优化路径，Lindorm 向量引擎支持跨平台自适应，根据运行环境自动选择更合适的执行策略，让性能在不同硬件上都能“开到最优档”：

  • x86 环境：自动探测并激活 AVX512 / AVX2 指令集，利用硬件级指令实现距离计算的极致加速。
  • ARM 环境：深度适配 NEON 指令集，确保在国产化算力底座上依然表现强劲。

4. 图结构的自我进化

索引在增量写入后，往往会因为数据分布的漂移导致图结构的“局部最优”陷阱，造成检索路径变长。Lindorm 向量引擎引入后台重整机制：在不影响在线服务的情况下，持续观察结构质量并做温和修复与优化，让导航结构逐步回到更理想的状态，让引擎始终处于稳定的运行状态。

5. 面向生产的动态能力

在快速迭代的业务中，数据结构绝不能是死板的。Lindorm 赋予了索引强大的动态修改能力：

  • 实时更新：无论是向量还是标量数据，都支持实时的增删改操作。标量修改仅涉及倒排索引的微小变动，向量修改则支持原地实时更新，确保每一次写入都能即刻被检索到。
  • Schema 演进：支持在线 Schema 演进，业务可以随时添加或删除标量列，无需漫长的索引重建周期。

结语

Lindorm 向量服务不仅仅是一个更快的检索索引，它是对向量数据库底层逻辑的一次重构。通过将高性能检索加速、全架构适配以及数据库级的查询优化深度融合，Lindorm 为大规模 AI 应用提供了最坚实的性能护城河。

无论是万亿级参数的大模型检索增强，还是面对超高 QPS 压力、实时变动的商品推荐，Lindorm 已准备好为你的业务披挂上阵。

关于 Lindorm

云原生多模数据库 Lindorm 是阿里巴巴自主研发的面向 AI 时代的云原生数据库，支持向量、宽表、搜索、列存、时序等多种数据模型，为企业提供一站式的数据存储与处理能力。了解更多请访问产品官网：https://www.aliyun.com/product/apsaradb/lindorm

标签: none

添加新评论