向量索引内存配置

向量索引基于 Lucene。如内存配置章节所述,Lucene 支持的向量索引文件由操作系统的文件系统缓存而非 Neo4j 页缓存(page cache)进行缓存。对于向量索引,您必须确保 Neo4j 有足够的内存(JVM 堆和 Neo4j 页缓存),并确保有足够的剩余 RAM 可供操作系统的文件系统缓存使用。如果留给缓存的 RAM 不足,操作系统将更频繁地从磁盘读取数据,导致向量搜索性能下降。在内存压力较大的情况下,操作系统还可能开始使用交换空间(swapping)。使用 iotop 等工具或类似的 Linux I/O 监控工具,可以帮助您了解磁盘 I/O 的使用情况。

Neo4j 向量索引的最佳内存配置

要评估向量索引对操作系统文件系统缓存的需求,有两个量是重要的:

  • 逻辑向量数据大小 — 被索引的向量数据的字节数,与存储和索引开销无关。

  • 物理向量索引大小 — 已填充的向量索引在磁盘上的大小。

两者均可用作估算向量搜索内存需求时的起点。

逻辑向量数据大小的计算公式为:

维度精度 x 维度数量 x 向量数量

对于 Lucene 支持的向量索引,维度精度为 4 字节。例如,1,000,000768 维的向量,其逻辑向量数据大小为 3.072 GB

物理向量索引大小可以在索引构建后通过查看其磁盘占用量来测量,也可以提前估算。估算结果取决于是否启用了量化(默认值为 true,参见 vector.quantization.enabled)。

以下估算值按每个向量计算,其中 HNSW_M 是配置的 vector.hnsw.m 值(默认 16):

  • 启用量化 — 约 1.1 x (1.25 x 维度精度 x 维度数量 + 8 x HNSW_M) 字节

  • 未启用量化 — 约 1.1 x (维度精度 x 维度数量 + 8 x HNSW_M) 字节

要估算完整的物理向量索引大小,请将每个向量的估算值乘以向量总数。

作为起点,对于量化索引,请预留约 40% 的物理向量索引大小作为操作系统文件系统缓存。对于未量化索引,请预留约 100% 的物理向量索引大小。

整体内存配置需要兼顾 Neo4j 堆、Neo4j 页缓存、向量索引的操作系统文件系统缓存以及其他操作系统内存。

Neo4j 页缓存取决于向量访问模式

访问模式 页缓存建议

向量仅用于索引和搜索,不被返回或重用

Neo4j 页缓存主要根据图的其他部分和任何其他已访问的属性进行分配即可。如果查询不需要从图存储中读取向量属性值,则无需将其保持在 Neo4j 页缓存中。

向量在索引查找后会被返回、重新排序或重用

Neo4j 页缓存还必须考虑从图存储中读取向量属性值。请相应地调整页缓存的分配大小。

示例计算

以下示例展示了如何针对以下场景估算向量特定的存储和内存需求:

  • 1000 万个 768 维的 FLOAT32 类型向量

  • 使用默认向量索引设置,启用量化且 vector.hnsw.m = 16

  • 向量仅用于索引和搜索,索引查找后不被返回或重用。

此示例计算了向量特定的磁盘占用空间和索引的操作系统文件系统缓存。Neo4j 堆、Neo4j 页缓存和其他操作系统内存仍取决于图的其余部分和查询负载。

表 1. 磁盘存储需求
Component (组件) 公式

逻辑向量数据大小

10M 向量 x 每个维度 4 字节 x 768 维度 / 1,000,000,000

30.72GB

物理向量索引大小(单个索引)

(10M 向量 x 1.1 x (1.25 x 每个维度 4 字节 x 768 维度 + 8 字节 x 16)) / 1,000,000,000

43.648GB

向量相关总占用空间

逻辑向量数据大小 + 物理向量索引大小

74.368GB

表 2. 内存分配组件
Component (组件) 估算 说明

Neo4j 堆

取决于工作负载

使用 neo4j-admin server memory-recommendation 获取初步建议,然后根据查询并发性和应用行为进行调整。

Neo4j 页缓存

取决于工作负载

使用页缓存容量规划neo4j-admin server memory-recommendation 作为起点,然后考虑图的其余部分以及工作负载读取的任何非向量属性。

索引的操作系统文件系统缓存

物理向量索引大小的 40%

17.46GB

其他 OS 内存

取决于工作负载

为操作系统和其他进程预留内存

AuraDB 实例大小调整

有关 AuraDB 特定的向量大小调整和向量优化实例指南,请参阅 Aura → 向量优化

预热向量索引

向量索引在被查询时会加载到操作系统的文件系统缓存中。最初的查询可能需要从磁盘读取更多的 Lucene 索引。随着越来越多的索引驻留在文件系统缓存中,后续查询将减少磁盘读取次数,性能也会变得更加稳定。

因此,可以通过在处理生产流量之前对索引执行随机查询来完成预热。所需的查询数量取决于索引的大小、可用 RAM 的量以及预热查询的代表性。作为起点:

  • 对于较小的索引(最多 1M 个条目),测试表明约 5 次随机查询效果良好

  • 对于较大的索引,建议从约 100 次随机查询开始,并根据目标系统上观察到的磁盘 I/O 和延迟进行调整

使用具有代表性的查询,并在预热期间监控磁盘读取活动。使用 iotop 等工具或类似的 Linux I/O 监控工具,可以查看操作系统是否仍在大量从磁盘读取数据。

由于 Lucene 支持的向量索引文件依赖于操作系统的文件系统缓存,因此服务器重启会清除该缓存。在重启、滚动重启、打补丁或升级后,可能需要再次预热索引。