存算分离架构下向量检索I/O优化方案深度对比

存算分离架构下向量检索I/O优化方案深度对比

在云计算与云原生架构全面普及的背景下，大规模向量检索系统普遍采用“存算分离”架构。该架构将计算节点与基于对象存储的海量底层数据分离，具备了近乎无限的扩展潜力和极高的存储性价比。然而，这种架构在带来红利的同时，也引入了新的技术挑战。本文将聚焦对象存储I/O效率这一核心痛点，深度对比分析现有的两类主流I/O优化方案：固定阈值启发式合并方案与在线全局请求规划方案，帮助技术团队在系统设计与选型时做出更合理的决策。

一、 对比背景与问题定义

在主流的聚类型向量索引（如IVF、IVFPQ等）部署模式中，通常采用“本地存紧凑路由索引 + 对象存储存全量向量payload”的模式。查询时，系统先在本地内存中快速计算出待探测的簇，然后再向底层的对象存储发起数据拉取请求进行精排。

这里的核心矛盾在于对象存储的I/O特性与检索请求模式的不匹配：

1. 固定开销主导：对象存储的Range-GET请求存在极高的固定首字节延迟。例如，读取1KB数据的延迟可能约为25ms，而读取1MB数据的延迟可能仅约30ms。这意味着碎片化的小请求会严重拖慢系统响应。
2. 按请求次数计费：云上对象存储通常按API请求次数计费，海量碎片化请求不仅推高延迟，更会直接导致成本失控。

为了解决这一问题，业界衍生出了不同的I/O优化方案。本文主要对比以下两类对象：

• 方案A（传统启发式合并方案）：采用固定间隙或跨度阈值的贪心合并策略（当前诸多开源向量数据库与数据系统所采用的基线方案）。
• 方案B（在线全局请求规划方案）：以WaRP（Workload-Aware Request Planner）为代表的，将请求规划建模为全局优化问题并搭配离线重排序的系统性方案。

二、 两类方案的相同点分析

尽管两类方案在实现逻辑上存在显著差异，但它们的设计初衷与基础能力具有高度的一致性：

1. 优化目标一致：两者的根本目的都在于减少针对对象存储的碎片化API请求数量，降低首字节延迟带来的开销，从而在不改变向量召回率的前提下，提升系统的查询吞吐量并降低响应延迟与存储成本。
2. 工作层级相同：两者均工作在“探测之后、精排之前”的I/O拉取层。它们都是对已选出的待读取字节区间进行后置处理，与上层的具体ANN索引结构（无论是树索引、图索引还是IVF系列）保持解耦，具备一定程度的通用性。
3. 底层依赖一致：两者都依赖对象存储标准的Range-GET能力，不要求底层存储系统提供特殊的定制化接口，符合云原生架构的通用规范。

三、 核心差异分析

两类方案在架构设计、功能能力与适用场景上存在本质差异，具体表现在以下几个维度：

1. 技术架构与合并逻辑

• 方案A（启发式合并）：采用静态的贪心策略。当系统计算出多个待读取的簇区间后，如果相邻两个簇之间的字节间隙小于某个预设的固定阈值，系统就会将它们合并为一个大请求连续读取，否则各自独立发请求。这是一种局部、贪心的决策过程。
• 方案B（全局规划）：将探测得到的有序字节区间分组问题，抽象为一个全局优化问题。它不仅考虑间隙大小，还综合引入了单查询最大请求预算（K_max，直接约束GET请求成本）和系统单查询请求并行度估计（P）。通过在线算法全局寻找请求数量、过度读取字节量、查询延迟三者间的最优平衡。

2. 参数调优与自适应性

• 方案A：固定阈值参数严重依赖人工经验调优。由于不同数据集的簇分布、不同查询工作负载的探测模式差异巨大，一套固定参数无法跨场景通用，常常出现“调好A数据集，B数据集崩盘”的现象。
• 方案B：通过感知工作负载（Workload-Aware）和系统并发能力，动态调整规划策略。离线阶段通过对IVF簇粒度的payload进行重排序，提升物理数据布局的局部性；在线阶段根据实时输入的区间集合进行自适应规划，免去了繁琐的手工调参。

3. 计算与I/O的资源博弈

在面对请求数过多的困境时，传统思路中还有一种变种：单纯调粗聚类粒度（减少簇总数）。

• 方案A及传统思路：在调粗粒度后，虽然请求数下降了，但会导致单个簇包含的候选集显著扩大，极大增加了后续精排阶段的CPU计算开销，同时削弱了索引的剪枝能力。这是一种“拆东墙补西墙”的非根本性妥协。
• 方案B：保持了上层索引的精细剪枝能力，仅在I/O层通过全局规划合并请求。即使存在一定程度的“过度读取字节量”（读取了部分不需要的簇数据），也比盲目扩大候选集的计算开销要小得多，实现了真正的存算效率解耦优化。

四、 关键差异对比表格

对比维度	方案A：固定阈值启发式合并	方案B：在线全局请求规划（如WaRP）
核心逻辑	局部贪心，基于固定间隙阈值合并	全局优化，结合请求预算与并发度动态规划
参数依赖	强依赖人工调优，需设定固定阈值	弱依赖，系统自适应输入区间与系统状态
数据布局优化	无（或依赖固定大小存储页的重排）	离线簇payload重排序，面向可变长度Range-GET
跨负载通用性	较差，需针对不同数据集重新调参	较好，设计目标即为适配多变工作负载
计算开销影响	可能迫使系统调粗聚类粒度，增加精排CPU开销	不改变召回率与候选集大小，仅优化I/O效率
迁移与接入成本	低，逻辑简单，几十行代码即可实现	中高，需引入离线重排序流程与在线规划器组件

五、 典型场景选择与选型建议

1. 适用方案A的场景

如果您的业务场景属于中小型数据规模，或者查询工作负载非常单一固定（例如总是探测固定数量的簇），且团队的开发资源有限，希望快速上线，那么采用方案A的固定阈值合并是合理的选择。在这些场景下，数据分布相对均匀，人工调优的参数能够覆盖大部分情况，引入复杂的全局规划器反而会增加系统不必要的复杂度。许多依托于百度智能云对象存储BOS构建的轻量级检索应用，在初期阶段采用此方案即可满足基本的延迟与成本平衡。

2. 适用方案B的场景

如果您的业务属于超大规模向量数据集（如十亿级以上），且底层完全构筑在对象存储之上；同时，您的查询工作负载存在显著的多样性（如不同召回率要求导致探测簇数量动态变化），且对查询长尾延迟和API调用成本极度敏感。在这种生产级大规模场景下，方案A的局限性会被无限放大。此时，引入类似WaRP的在线全局请求规划器，搭配离线的数据重排序，能够实现全局资源的最优调配，保障系统在高压下的稳定吞吐。

六、 迁移与使用注意事项

如果您计划将现有的向量检索系统从方案A迁移至方案B（在线全局规划架构），需要重点关注以下几个方面：

1. 离线重排序的兼容性：方案B通常需要配合离线的簇payload重排序。这意味着底层数据的物理布局需要重新组织。在迁移过程中，需要设计新旧数据并存的兼容策略，确保未重排序的历史数据仍能被正确查询。
2. 在线规划器的性能开销：全局规划器本身是一个在线算法，其运行需要消耗CPU资源。在单查询并发度极高的场景下，必须评估规划器自身的计算延迟，确保其带来的I/O收益远大于其自身的计算开销。通常需要将规划器的高度优化为常数级或对数级时间复杂度。
3. 系统参数的动态探测：在线规划依赖于对系统单查询请求并行度（P）的准确估计。在云原生环境下，计算节点的负载是动态变化的，系统需要具备实时探测或弹性反馈当前I/O并发能力的能力，否则规划器可能给出脱离实际物理资源限制的错误计划。
4. 计费模型的重新核算：迁移后，由于API请求数量大幅减少但单次请求读取的数据量可能增加（过度读取），需要重新评估云上对象存储的账单结构。虽然按请求次数计费的成本会下降，但如果存在按流量计费的部分，需确保总流量溢出在可控范围内。

七、 总结

大规模向量检索在存算分离架构下的I/O优化，正在从“打补丁式的经验调优”走向“系统化的全局规划”。固定阈值的启发式合并方案虽然实现简单，但在面对复杂多变的海量数据检索时显得力不从心；而将I/O请求规划建模为全局优化问题，结合离线数据布局调整与在线负载感知的方案，代表了该领域走向深水区的重要技术演进方向。架构师在选型时，不应盲目追求架构的先进性，而应结合自身的数据规模、负载特征与运维能力，在开发成本与长期I/O收益之间找到最适合当前业务阶段的平衡点。