当前位置：首页 > news >正文

Milvus（16）：索引解释

news 来源：原创 2025/8/15 11:55:17

索引是建立在数据之上的附加结构。其内部结构取决于所使用的近似近邻搜索算法。索引可以加快搜索速度，但在搜索过程中会产生额外的预处理时间、空间和 RAM。此外，使用索引通常会降低召回率（虽然影响可以忽略不计，但仍然很重要）。因此，本文将解释如何最大限度地减少使用索引的成本，同时最大限度地提高索引的效益。

1 概述

在 Milvus 中，索引是特定于字段的，适用的索引类型因目标字段的数据类型而异。作为专业的向量数据库，Milvus 注重提高向量搜索和标量过滤的性能，因此提供了多种索引类型。下表列出了字段数据类型与适用索引类型之间的映射关系。

字段数据类型	适用索引类型
FLOAT_VECTOR FLOAT16_VECTOR bfloat16_vector	平面 IVF_FLAT IVF_SQ8 IVF_PQ GPU_IVF_FLAT GPU_IVF_PQ HNSW DISKANN
二进制向量	BIN_FLAT BIN_IVF_FLAT
稀疏浮点矢量	稀疏反转索引
变量	反转（推荐） BITMAP Trie
BOOL	BITMAP（推荐）反转
INT8 INT16 INT32 INT64	反转 STL_SORT
FLOAT DOUBLE	反转
数组（BOOL、INT8/16/32/64 和 VARCHAR 类型的元素）	BITMAP（推荐）
ARRAY（BOOL、INT8/16/32/64、FLOAT、DOUBLE 和 VARCHAR 类型的元素）	反转
JSON	反转

本文重点介绍如何选择合适的向量索引。对于标量字段，可以始终使用推荐的索引类型。为向量搜索选择适当的索引类型会极大地影响性能和资源使用情况。在为向量字段选择索引类型时，必须考虑各种因素，包括底层数据结构、内存使用情况和性能要求。

2 向量索引解剖图

如下图所示，Milvus 中的索引类型由三个核心部分组成，即数据结构、量化和细化器。量化和精炼器是可选的，但由于收益大于成本的显著平衡而被广泛使用。

在创建索引时，Milvus 会结合所选的数据结构和量化方法来确定最佳扩展率。在查询时，系统会检索topK × expansion rate 候选向量，应用精炼器以更高的精度重新计算距离，最后返回最精确的topK 结果。这种混合方法通过将资源密集型细化限制在候选矢量的过滤子集上，在速度和精确度之间取得了平衡。

2.1 数据结构

数据结构是索引的基础层。常见类型包括

反转文件（IVF）

IVF 系列索引类型允许 Milvus 通过基于中心点的分区将向量聚类到桶中。一般可以安全地假设，如果桶的中心点接近查询向量，那么桶中的所有向量都有可能接近查询向量。基于这个前提，Milvus 只扫描那些中心点靠近查询向量的桶中的向量 Embeddings，而不是检查整个数据集。这种策略既能降低计算成本，又能保持可接受的精确度。这种索引数据结构非常适合需要快速吞吐量的大规模数据集。
基于图的结构

基于图的向量搜索数据结构，如分层导航小世界(HNSW），构建了一个分层图，其中每个向量都与其最近的邻居相连。查询可以浏览这个层次结构，从粗略的上层开始，然后切换到下层，从而实现高效的对数时间搜索复杂性。这种索引数据结构适用于高维空间和要求低延迟查询的场景。

2.2 量化

量化通过更粗略的表示来减少内存占用和计算成本：

标量量化（如SQ8）使 Milvus 能够将每个向量维度压缩为单字节（8 位），与 32 位浮点数相比，内存使用量减少了 75%，同时保持了合理的精度。
乘积量化（PQ）使 Milvus 能够将向量分割成子向量，并使用基于编码本的聚类进行编码。这可以实现更高的压缩率（例如 4-32 倍），但代价是召回率略有降低，因此适用于内存受限的环境。

2.3 精炼器

量化本身就是有损的。为了保持召回率，量化始终会产生比所需数量更多的前 K 个候选结果，这使得精炼器可以使用更高的精度从这些候选结果中进一步选择前 K 个结果，从而提高召回率。

例如，FP32 精炼器通过使用 FP32 精度而不是量化值重新计算距离，对量化返回的候选搜索结果进行操作符操作。

这对于需要在搜索效率和精度之间做出权衡的应用（如语义搜索或推荐系统）来说至关重要，因为在这些应用中，微小的距离变化都会对结果质量产生重大影响。

2.4 总结

这种分层架构--通过数据结构进行粗过滤、通过量化进行高效计算、通过细化进行精度调整--使 Milvus 能够自适应地优化精度-性能权衡。

3 性能权衡

在评估性能时，平衡构建时间、每秒查询次数（QPS）和召回率至关重要。一般规则如下：

就QPS 而言，基于图形的索引类型通常优于IVF 变体。
IVF 变体尤其适用于topK 较大的情况（例如，超过 2,000 个）。
与SQ相比，PQ通常能在相似的压缩率下提供更好的召回率，但后者的性能更快。
将硬盘用于部分索引（如DiskANN）有助于管理大型数据集，但也会带来潜在的 IOPS 瓶颈。

3.1 容量

容量通常涉及数据大小与可用 RAM 之间的关系。在处理容量问题时，请考虑以下几点：

如果有四分之一的原始数据适合存储在内存中，则应考虑使用延迟稳定的 DiskANN。
如果所有原始数据都适合在内存中存储，则应考虑基于内存的索引类型和 mmap。
您可以使用量化应用索引类型和 mmap 来换取最大容量的准确性。

mmap 并不总是解决方案。当大部分数据在磁盘上时，DiskANN 可以提供更好的延迟。

3.2 召回率

召回率通常涉及过滤率，即搜索前过滤掉的数据。在处理召回问题时，应考虑以下几点：

如果过滤率小于 85%，则基于图的索引类型优于 IVF 变体。
如果过滤比在 85% 到 95% 之间，则使用 IVF 变体。
如果过滤率超过 98%，则使用 "蛮力"（FLAT）来获得最准确的搜索结果。

上述项目并不总是正确的。建议使用不同的索引类型来调整召回，以确定哪种索引类型有效。

3.3 性能

搜索性能通常涉及 top-K，即搜索返回的记录数。在处理性能问题时，请考虑以下几点：

对于 Top-K 较小的搜索（如 2,000），需要较高的召回率，基于图的索引类型优于 IVF 变体。
对于 top-K 较大的搜索（与向量嵌入的总数相比），IVF 变体比基于图的索引类型是更好的选择。
对于 top-K 中等且过滤率较高的搜索，IVF 变体是更好的选择。

3.4 决策矩阵：选择最合适的索引类型

下表是一个决策矩阵，供您在选择合适的索引类型时参考。

方案	推荐索引	注释
原始数据适合内存	HNSW、IVF + 精炼	使用 HNSW 实现低`k`/ 高召回率。
磁盘、固态硬盘上的原始数据	磁盘ANN	最适合对延迟敏感的查询。
磁盘上的原始数据，有限的 RAM	IVFPQ/SQ + mmap	平衡内存和磁盘访问。
高过滤率（>95）	强制（FLAT）	避免微小候选集的索引开销。
大型`k` （≥ 数据集的 1）	IVF	簇剪枝减少了计算量。
极高的召回率（>99）	蛮力 (FLAT) + GPU	--

4 内存使用估算

索引的内存消耗受其数据结构、通过量化实现的压缩率以及所使用的精炼器的影响。一般来说，由于图的结构（如HNSW），基于图的索引通常会占用较多内存，这通常意味着每个向量的空间开销较大。相比之下，IVF 及其变体更节省内存，因为适用的每个向量空间开销更少。不过，DiskANN等先进技术允许索引的一部分（如图或细化器）驻留在磁盘上，从而在保持性能的同时减少了内存负荷。

4.1 IVF 索引内存使用量

IVF 索引通过将数据划分为数据集群，在内存效率和搜索性能之间取得平衡。以下是使用 IVF 变体索引的 100 万个 128 维向量所使用的内存明细。

4.1.1 计算中心点使用的内存

IVF 系列索引类型使 Milvus 能够使用基于中心点的分区将向量聚类到桶中。在原始向量 Embeddings 中，每个中心点都包含在索引中。当你将向量划分为 2,000 个簇时，内存使用量可按如下方式计算：

2,000 clusters × 128 dimensions × 4 bytes = 1.0 MB

4.1.2 计算簇分配使用的内存

每个向量嵌入都会分配给一个簇，并以整数 ID 的形式存储。对于 2 000 个簇来说，2 字节的整数就足够了。内存使用量的计算方法如下：

1,000,000 vectors × 2 bytes = 2.0 MB

4.1.3 计算量化带来的压缩

IVF 变体通常使用 PQ 和 SQ8，内存使用量可按下式估算：

使用带有 8 个子量化器的 PQ
```
1,000,000 vectors × 8 bytes = 8.0 MB
```

使用 SQ8

1,000,000 vectors × 128 dimensions × 1 byte = 128 MB

下表列出了不同配置下的内存用量估算：

配置	内存估算	总内存
IVF-PQ（无细化）	1.0 MB + 2.0 MB + 8.0 MB	11.0 MB
IVF-PQ + 10% 原始细化	1.0 MB + 2.0 MB + 8.0 MB + 51.2 MB	62.2 MB
IVF-SQ8 （无细化）	1.0 MB + 2.0 MB + 128 MB	131.0 MB
IVF-FLAT（全原始向量）	1.0 MB + 2.0 MB + 512 MB	515.0 MB

4.1.4 计算细化开销

IVF 变体通常会与细化器配对，对候选对象进行重新排序。对于检索前 10 个结果且扩展率为 5 的搜索，细化开销可估算如下：

10 (topK) x 5 (expansion rate) = 50 candidates
50 candidates x 128 dimensions x 4 bytes = 25.6 KB

4.2 基于图形的索引内存使用情况

基于图的索引类型（如 HNSW）需要大量内存来存储图结构和原始向量嵌入。下面是使用 HNSW 索引类型索引的 100 万个 128 维向量所消耗内存的详细明细。

4.2.1 计算图结构使用的内存

HNSW 中的每个向量都与其邻居保持连接。在图度（每个节点的边数）为 32 的情况下，所消耗的内存计算如下：

1,000,000 vectors × 32 links × 4 bytes (for 32-bit integer storage) = 128 MB

4.2.2 计算原始向量嵌入所消耗的内存

存储未压缩的 FP32 向量所消耗的内存可计算如下：

1,000,000 vectors × 128 dimensions × 4 bytes = 512 MB

当您使用 HNSW 对 100 万 128 维向量嵌入进行索引时，使用的总内存为128 MB（图形）+ 512 MB（向量）= 640 MB。

4.2.3 计算量化带来的压缩

量化可以减小向量大小。例如，使用带有 8 个子量化器（每个向量 8 字节）的 PQ 会导致大幅压缩。压缩后的向量 Embeddings 所消耗的内存可计算如下：

1,000,000 vectors × 8 bytes = 8 MB

与原始向量嵌入相比，这实现了 64 倍的压缩率，HNSWPQ索引类型使用的总内存将为128 MB（图）+ 8 MB（压缩向量）= 136 MB。

4.2.4 计算细化开销

细化（如使用原始向量重新排序）会将高精度数据临时加载到内存中。对于检索前 10 个结果且扩展率为 5 的搜索，细化开销可估算如下：

10 (topK) x 5 (expansion rate) = 50 candidates
50 candidates x 128 dimensions x 4 bytes = 25.6 KB

4.3 其他考虑因素

IVF 和基于图的索引可通过量化优化内存使用，而内存映射文件（mmap）和 DiskANN 则可解决数据集超出可用随机存取内存（RAM）的情况。

DiskANN 是一种基于 Vamana 图的索引，它将数据点连接起来，以便在搜索过程中高效导航，同时应用 PQ 来减小向量的大小，并能快速计算向量之间的近似距离。

Vamana 图存储在磁盘上，这使得 DiskANN 能够处理那些内存无法容纳的大型数据集。这对十亿点数据集尤其有用。

内存映射（Mmap）可实现对磁盘上大型文件的直接内存访问，从而允许 Milvus 在内存和硬盘中同时存储索引和数据。这种方法可根据访问频率减少 I/O 调用的开销，有助于优化 I/O 操作，从而在不对搜索性能造成重大影响的情况下扩大 Collections 的存储容量。

具体来说，你可以配置 Milvus 对某些字段中的原始数据进行内存映射，而不是将它们完全加载到内存中。这样，你就可以直接对字段进行内存访问，而不必担心内存问题，并扩展了 Collections 的容量。