Milvus（16）：索引解释

        索引是建立在数据之上的附加结构。其内部结构取决于所使用的近似近邻搜索算法。索引可以加快搜索速度，但在搜索过程中会产生额外的预处理时间、空间和 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 的容量。