## **说明**

本文描述问题及解决方法同样适用于 [腾讯云 Elasticsearch Service（ES）](https://cloud.tencent.com/document/product/845?from=20421&%3Bfrom_column=20421&%3Bfrom_column=20421&%3Bfrom_column=20421&%3Bfrom_column=20421&from_column=20421)。

---

## 一、痛点：以图搜图 1 亿条向量，得多少台机器

假设你要给一个电商站的商品图库做以图搜图，规模 1 亿张图、1024 维 embedding。

算一笔账：

- 每个向量：`1024 维 × 4 字节 (float32) = 4 KB`
- 1 亿条向量：`1 亿 × 4 KB ≈ 380 GB` 原始向量数据
- HNSW 索引还要额外的图结构开销

这 400 多 GB 的东西，得用多少台机器才能跑得动？

一个真实的成本问题：ES 集群里向量索引会切成多个分片分布到不同节点。**每个分片的 HNSW 图在被查询的时候，都要装进它所在节点的 page cache**，否则那个节点就会性能雪崩（后面讲原因）。所以你切多少分片、机器怎么加，最终每台机器上落下来的那部分索引，都得能塞进这台机器的空闲内存。

按一台 64GB 机器实际能给 HNSW 用的 30-40GB 堆外内存算，380 GB 索引至少 10 台起步，副本一开翻倍到 20 台。

有人说：那就用大内存机器少几台。这就要问了：**HNSW 装不下节点内存到底为什么会雪崩？**

### 雪崩

HNSW 索引文件本身当然可以放在磁盘上。Elasticsearch/Lucene 底层用 mmap 映射索引文件，操作系统按需把磁盘页加载到 page cache。索引 500 GB、单节点内存 128 GB，机器照样能启动、能查询。

卡点在**查询时**。[HNSW（Hierarchical Navigable Small World）](https://arxiv.org/abs/1603.09320) 是一个分层图结构，查询从入口点出发，跳到邻居节点、比较距离、再跳下一个邻居。这种跳转是完全随机的——今天访问 100 号节点，下一步可能就跳到 5000 万号。

节点内存能装下这个分片的图时，所有图节点都在 page cache 里，随机跳转就是内存随机访问，纳秒级延迟。

节点内存装不下这个分片时：

- 每次跳转都可能触发一次 page fault（要访问的页不在内存，得从磁盘读）
- 跳转是随机的，"下一步该访问哪页"无法预测，预读（readahead）帮不上忙
- 操作系统不断淘汰旧页，HNSW 又立刻要访问那些刚被淘汰的页，page cache 反复抖动（thrashing）
- 磁盘随机 I/O 比内存随机访问慢几个数量级（毫秒 vs 纳秒）

[Elasticsearch 9.2.0 Release Notes](https://github.com/elastic/elasticsearch/blob/9.4/docs/release-notes/index.md) 的 "Allow direct IO for BBQ rescoring" 段落给了一个量化数字：这种低内存场景下 BBQ rescoring 的延迟可能被放大**多达 5000 倍**（`can be affected by as much as 5000x`）。

所以"向量检索要全内存"的真实含义不是物理上做不到，是**性能上不可用**。而 Elasticsearch 9.2 的 DiskBBQ 就是冲着这个约束来的。

---

## 二、DiskBBQ 是什么

DiskBBQ 是 Elasticsearch 9.2 引入的一个 `dense_vector` 索引类型，索引数据主体放在磁盘上，且不会像 HNSW 那样在内存不足时性能崩塌。

开启只需要在 mapping 里加一行 `index_options`：

```console
PUT bbq_disk-index
{
  "mappings": {
    "properties": {
      "my_vector": {
        "type": "dense_vector",
        "dims": 3,
        "similarity": "l2_norm",
        "index": true,
        "index_options": {
          "type": "bbq_disk"
        }
      }
    }
  }
}
```

关于版本和可用性：

- Elasticsearch 9.2 首发，开启 `bbq_disk` 需要 Enterprise 订阅
- Elasticsearch 9.4 起，`bbq_disk` 直接成了 `dense_vector` 的默认索引类型
- **腾讯云 ES 9.4.2 已经跟进到这个版本，创建 `dense_vector` 字段时默认就走 DiskBBQ，不用再单独申请 license**

Elastic 官方给出的三个关键结论：

1. 建索引比 HNSW 更快、更便宜（`faster and cheaper indexing than HNSW`）
2. 低内存环境下性能线性下降（`degrades linearly, not exponentially`）
3. 内存充足时 QPS 接近 HNSW（`Is near HNSW for QPS when the index is in memory`）

---

## 三、为什么叫 DiskBBQ

拆开看：

| 部分 | 含义 |
|------|------|
| Disk | 索引数据主体放磁盘 |
| B | Better，Better Binary Quantization 的第一个 B |
| BQ | Binary Quantization，二值量化 |

### BBQ 是什么

Better Binary Quantization（BBQ）是 Elastic 在 8.x 引入的向量量化算法（[Search Labs: Better Binary Quantization](https://www.elastic.co/search-labs/blog/better-binary-quantization-lucene-elasticsearch)）：

- 输入：一个 `float32` 数组（1024 维，占 4 KB）
- 输出：一个 bit 数组（同样 1024 维，占 128 字节）
- 压缩率 32:1

思路是把每一维压成 1 bit 保留符号信息，查询时通过后续的 rescore 环节找回精度。

### Disk 是怎么加上去的

只做 BBQ 量化、配合 HNSW，只是把图节点里存的向量压小，图结构本身还是要驻留内存。DiskBBQ 的关键改动是**换掉 HNSW 的图结构，改用磁盘友好的新架构**。

[Elastic 官方 BBQ 参考文档](https://github.com/elastic/elasticsearch/blob/9.4/docs/reference/elasticsearch/mapping-reference/bbq.md) 里描述得很直接：

> DiskBBQ groups similar vectors into small clusters using **hierarchical K-means**. When processing a query, it finds the centroids closest to the query vector and only compares the vectors within those clusters.

代码里对应的类叫 [`IVFVectorsReader` / `IVFVectorsWriter`](https://github.com/elastic/elasticsearch/blob/9.4/server/src/main/java/org/elasticsearch/index/codec/vectors/diskbbq/IVFVectorsReader.java)。IVF 全称 Inverted File index，是 FAISS、Milvus 里的经典向量索引结构。所以更准确的说法是：

> DiskBBQ = IVF 架构 + BBQ 量化 + 磁盘优化。

---

## 四、原理：怎么做到上磁盘也不慢

先看架构对比：
![Clipboard_Screenshot_1788186547.png](https://developer.qcloudimg.com/http-save/yehe-7348459/2411ea102c6788ad37330d85f7caa383.png)

DiskBBQ 的三步：聚类、量化、分级查询。

### 第一步：聚类，把向量分组

建索引时用 hierarchical K-means 聚类把所有向量分成若干个簇（cluster），每个簇选一个代表点，叫 centroid（质心）。

举个数：1 亿个向量分成 10 万个簇，每个 centroid 是一个 float32 向量（1024 维 × 4B ≈ 4 KB），10 万个 centroid 大概 400 MB。塞得进任何一台机器。

只有 centroid 需要放在内存里，明细向量都在磁盘上。

### 第二步：量化，每维只留 1 bit

对每个原始向量做 BBQ 量化：`float32[1024]` → `bit[1024]`，存储砍到 1/32。量化后的向量按所属簇分组，写到磁盘上的 posting list 里。

翻 [`ES920DiskBBQVectorsFormat.java`](https://github.com/elastic/elasticsearch/blob/9.4/server/src/main/java/org/elasticsearch/index/codec/vectors/diskbbq/ES920DiskBBQVectorsFormat.java#L54-L59) 源码，能看到索引数据被拆成三个文件（下方三行 Java 语句为源码原文，`//` 注释为本文补充说明）：

```java
// centroid ordinals -> centroid values, offsets（源码原注释）
public static final String CENTROID_EXTENSION = "cenivf";
// 每个 cluster 的量化向量 + 该向量的 docId（本文补充）
public static final String CLUSTER_EXTENSION = "clivf";
// centroid 数量、在 clivf 中的偏移量（本文补充）
public static final String IVF_META_EXTENSION = "mivf";
```

三个文件各司其职，类注释里写得很清楚：

- `.cenivf` 存 centroid 数据（`Which stores the raw and quantized centroid vectors`），数据量小，可以留在 page cache
- `.clivf` 存每个 cluster 的量化向量和 docId（`Stores the quantized vectors for each cluster, inline and stored in blocks. Additionally, the docIds of each vector is stored`），是磁盘上的大头
- `.mivf` 存元数据，指明每个 cluster 在 `.clivf` 里的偏移（`Stores metadata including the number of centroids and their offsets in the clivf file`）

### 第三步：查询，先粗筛再精排
![Clipboard_Screenshot_1788186599.png](https://developer.qcloudimg.com/http-save/yehe-7348459/ab1b35f624407fa0dc555f33729b53a8.png)

四步：

1. 粗筛簇（内存）：算查询向量到所有 centroid 的距离，只挑最近的 top-N 个簇
2. 读 posting list（磁盘顺序读）：只从这 N 个簇里取量化向量
3. BBQ 打分：用 1-bit 量化向量快速算距离，得到候选集
4. Rescore：用原始向量（float32 或 bfloat16）精确排序，返回最终 top-K

### 为什么就能磁盘友好

对比两种方案的磁盘访问模式：

| 维度 | HNSW | DiskBBQ |
|------|------|---------|
| 访问模式 | 随机跳转 | 顺序读几个块 |
| 磁盘表现 | 灾难 | 完美适配 |
| 内存需求 | 整个图 | 只要 centroid |

关键不在"把 HNSW 硬塞进磁盘"，而在"换一种天然适合磁盘顺序读的架构"。

### 从代码看查询入口

查询策略入口在 [`IVFKnnSearchStrategy.java`](https://github.com/elastic/elasticsearch/blob/9.4/server/src/main/java/org/elasticsearch/search/vectors/IVFKnnSearchStrategy.java#L18-L22)，只带三个核心字段（Java 声明为源码原文，`//` 注释为本文补充）：

```java
public class IVFKnnSearchStrategy extends KnnSearchStrategy {
    private final float visitRatio;   // 要访问多少比例的簇
    private final int numCands;       // BBQ 打分后保留的候选数
    private final int k;              // 最终返回的 top-K
    // ...
}
```

三个字段对应查询的三个阶段：

- `visitRatio` 决定第 1 步看多少比例的簇，对外的 mapping 参数是 `visit_percentage`
- `numCands` 决定第 3 步 BBQ 打分后保留多少候选
- `k` 决定第 4 步 rescore 后返回多少条

遍历 centroid 的接口只有三行，[`CentroidIterator.java`](https://github.com/elastic/elasticsearch/blob/9.4/server/src/main/java/org/elasticsearch/index/codec/vectors/diskbbq/CentroidIterator.java#L17-L21) 原样：

```java
public interface CentroidIterator {
    boolean hasNext();

    PostingMetadata nextPosting() throws IOException;
}
```

签名一眼看穿意图：拿出下一个要访问的簇的元信息，然后去磁盘读。没有随机跳转，没有图导航。

---

## 五、性能：实测数据

数据全部来自 Elastic 官方 [DiskBBQ introduction: An alternative to HNSW](https://www.elastic.co/search-labs/blog/diskbbq-elasticsearch-introduction)。

### 内存充足场景（1M 向量全部装进 RAM）

| 索引类型 | 建索引耗时 | 查询延迟 | Recall |
|---------|-----------|---------|--------|
| HNSW BBQ | 1,054,319 ms | ~3.4 ms | 92% |
| DiskBBQ | **94,075 ms** | ~4.0 ms | 91% |

一手结论：

- **建索引快约 11 倍**（1,054,319 / 94,075 ≈ 11.2），官方原话是 "DiskBBQ can be a whopping 10x faster at indexing speed"
- 查询延迟只慢 0.6 ms，recall 差 1 个百分点
- 换句话说：**内存充足时它几乎追平 HNSW BBQ，但建索引成本只有 1/10**

我们看一组关键的核心数据：
![Index time in milliseconds vs. RAM / JVM Heap](https://developer.qcloudimg.com/http-save/yehe-7348459/311701cd644f06d89ea1304316341f17.png)
随着整体内存减少，DiskBBQ 索引会平稳降级。然而，一旦内存受到极大限制，HNSW 就会彻底失效。
![image](https://developer.qcloudimg.com/http-save/yehe-7348459/155c96245ce786271411c9d2a54f25bd.png)
DiskBBQ 在搜索延迟方面表现出平稳的降级特性。当然，速度确实开始变慢，但随着内存限制日益严格，HNSW 的延迟开始呈指数级增长。


### 内存不足场景

官方博客里的原话：

> Again, we see DiskBBQ degrading gracefully in search latency. Indeed, it starts to slow down, but HNSW latency begins to increase **exponentially** as memory becomes increasingly restricted.

HNSW 是指数级恶化，DiskBBQ 是"gracefully"下降。这也是文章开头 5000x 那个数字要解决的场景。

### 适用边界

官方 BBQ 参考文档给了明确的 recall 边界：

> DiskBBQ typically performs well for recall levels up to around **95%**. For use cases requiring exceptionally high recall (99% or higher), many vector clusters may need to be visited, which can negatively impact performance.

以及两个使用限制：`not recommended for low dimensionality vectors`、`only floating point values are allowed currently`。

落到选型：

| 场景 | 推荐 |
|------|------|
| 亿级向量、成本敏感、内存吃紧 | DiskBBQ |
| 目标 recall ≤ 95% | DiskBBQ |
| 目标 recall ≥ 99% | `bbq_hnsw` 或其他 HNSW 变体 |
| 向量维度很低（几十维） | 不适合 |
| byte 类型向量 | 不适合 |

---

## 六、结语

回到开头的问题：向量检索一定要把索引全塞进内存吗？

Elasticsearch 9.2 之后不必了；到了 9.4，DiskBBQ 直接成了 `dense_vector` 的默认索引类型。

对使用者的实际影响：

- 亿级向量的集群不再必须按"索引 = 总内存"来配机器，机器数和成本可以按业务能容忍的 recall 与延迟来重新算。以文中的 1M 向量为例，建索引耗时从 1054 秒降到 94 秒，业务的重建索引窗口可以显著收窄
- 老的 HNSW 索引不用急着改。`bbq_hnsw` 依然存在，recall 99% 以上仍然走 HNSW 更划算
- 迁移路径也简单，把 `index_options.type` 改成 `bbq_disk` 后 reindex 一次就好

本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service（ES）。

向量检索一定要把索引全塞进内存吗？—— Elasticsearch 9.x 的救命稻草 DiskBBQ

Elasticsearch 9.2 推出 DiskBBQ：向量索引主体放磁盘、内存不足不再雪崩。腾讯云 ES 9.4.2 已默认开启，建索引比 HNSW 快 10 倍。

官方产研

云计算

大数据

人工智能

腾讯云ES 9.4.2默认支持DiskBBQ向量索引，无需单独license。DiskBBQ采用IVF+BBQ量化架构，以1亿条1024维向量为例，对比HNSW，建索引快约11倍，内存不足时延迟平稳降级而非指数级雪崩，recall约91-92%。适用于亿级向量、成本敏感场景，目标recall≤95%时优先选择。

代码解释

Java

ES特惠专场，新客首购5.5折起！


2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

向量检索一定要把索引全塞进内存吗？—— Elasticsearch 9.x 的救命稻草 DiskBBQ-腾讯云开发者社区-腾讯云

向量检索一定要把索引全塞进内存吗？—— Elasticsearch 9.x 的救命稻草 DiskBBQ

向量检索一定要把索引全塞进内存吗？—— Elasticsearch 9.x 的救命稻草 DiskBBQ

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐