向量索引内存配置
Neo4j 向量索引的最佳内存配置
要评估向量索引对操作系统文件系统缓存的需求,有两个量是重要的:
-
逻辑向量数据大小 — 被索引的向量数据的字节数,与存储和索引开销无关。
-
物理向量索引大小 — 已填充的向量索引在磁盘上的大小。
两者均可用作估算向量搜索内存需求时的起点。
逻辑向量数据大小的计算公式为:
维度精度 x 维度数量 x 向量数量
对于 Lucene 支持的向量索引,维度精度为 4 字节。例如,1,000,000 个 768 维的向量,其逻辑向量数据大小为 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 页缓存和其他操作系统内存仍取决于图的其余部分和查询负载。
| 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 |
| Component (组件) | 估算 | 说明 |
|---|---|---|
Neo4j 堆 |
取决于工作负载 |
使用 |
Neo4j 页缓存 |
取决于工作负载 |
使用页缓存容量规划和 |
索引的操作系统文件系统缓存 |
物理向量索引大小的 40% |
17.46GB |
其他 OS 内存 |
取决于工作负载 |
为操作系统和其他进程预留内存 |
AuraDB 实例大小调整
有关 AuraDB 特定的向量大小调整和向量优化实例指南,请参阅 Aura → 向量优化。
预热向量索引
向量索引在被查询时会加载到操作系统的文件系统缓存中。最初的查询可能需要从磁盘读取更多的 Lucene 索引。随着越来越多的索引驻留在文件系统缓存中,后续查询将减少磁盘读取次数,性能也会变得更加稳定。
因此,可以通过在处理生产流量之前对索引执行随机查询来完成预热。所需的查询数量取决于索引的大小、可用 RAM 的量以及预热查询的代表性。作为起点:
-
对于较小的索引(最多 1M 个条目),测试表明约 5 次随机查询效果良好
-
对于较大的索引,建议从约 100 次随机查询开始,并根据目标系统上观察到的磁盘 I/O 和延迟进行调整
使用具有代表性的查询,并在预热期间监控磁盘读取活动。使用 iotop 等工具或类似的 Linux I/O 监控工具,可以查看操作系统是否仍在大量从磁盘读取数据。
|
由于 Lucene 支持的向量索引文件依赖于操作系统的文件系统缓存,因此服务器重启会清除该缓存。在重启、滚动重启、打补丁或升级后,可能需要再次预热索引。 |