Docs 菜单
Docs 主页
/ /

额外性能建议

本页提供了有关提高MongoDB Vector Search 查询性能的其他建议。

当矢量数据保存在内存中时,分层可导航小世界 可以高效运行。您必须确保数据节点有足够的RAM来保存向量数据和索引。我们建议部署单独的 搜索节点以实现工作负载隔离性,而不进行数据隔离性,这样可以更有效地利用向量搜索使用案例的内存。

嵌入模型
向量维度
空间要求

Voyage AI voyage_3_large

2048

8kb (for float)
2.14kb (for int8)
0.334kb (for int1)

OpenAI text-embedding-ada-002

1536

6 kb

Google text-embedding-gecko

768

3 kb

Cohere embed-english-v3.0

1024

4kb (for float)
1.07kb (for int8)
0.167kb (for int1)

BinData 量化向量。要了解更多信息,请参阅 引入量化向量 。

MongoDB Vector Search 消耗的 CPU、内存和磁盘资源量取决于多个因素,包括索引大小和查询条件。请务必监控您的环境,以了解向量搜索的运行状况和性能,并确认有足够的基础架构容量并识别任何异常情况。

使用以下指标观察并提高MongoDB Vector Search 索引和查询的性能:

监控MongoDB Vector Search 索引使用的RAM总量。足够的RAM对于MongoDB Vector Search查询性能至关重要,因为进入磁盘的查询性能要低得多。确保整个索引能够容纳在内存中。

System Memory确保可用 始终大于已用System Memory 。如果不经常查询索引,则并非所有索引都可能位于内存中。因此,请结合使用System Memory 指标和Index Size 指标来优化预配。

如果向量索引大小超过3 GB,我们建议进行向量量化,即仅在内存中存储索引的 4%,而不是完整索引。

监控磁盘上所有索引的总大小(以字节为单位)。这是确保您准确确定RAM要求的必要条件。

Index Size验证磁盘上的搜索 100指标,查看如果向量的 % 存储在内存中,完整索引的大小,并确保它小于可用的系统内存。

监控所选示例周期内进程每秒的平均页面错误率。 Page Faults 指标表示搜索查询写入磁盘的频率,这表明内存不适合完整索引。

该指标必须尽可能接近于零。如果始终出现页面错误,请考虑扩展集群层以预配足够的RAM。

当您在不使用专用搜索节点的情况下执行向量搜索时,您的查询最初会在遍历 Hierarchical Navigable Small Worlds图表时在磁盘上执行随机查找,并将向量值读入内存。使用搜索节点时,这种缓存预热通常仅在索引重建事件发生,通常是在计划的维护窗口期间。

向量嵌入在索引中会消耗计算资源。 大型数据集上的 ENN 查询会消耗 CPU 资源。因此,同时索引和查询可能会导致资源瓶颈。为防止出现 CPU 瓶颈,请避免在查询运行时对向量索引。执行初始同步时,在发出测试查询之前,请确保搜索节点 CPU 使用率返回接近0 %,这表明段已合并并刷新到磁盘。

在索引操作期间监控 Search Normalized Process CPU 指标,因为大量索引会显示 CPU 使用率升高。该指标将 CPU 使用率显示为相对于可用 CPU 核心数规范化的百分比,使您能够评估相对于集群容量的资源饱和度。对向量嵌入进行索引后,等待 CPU 占用率返回接近 0%,因为段合并和刷新已完成。

后退

基准测试结果

在此页面上