本页提供了有关提高MongoDB Vector Search 查询性能的其他建议。
确保有足够的内存
当矢量数据保存在内存中时,分层可导航小世界 可以高效运行。您必须确保数据节点有足够的RAM来保存向量数据和索引。我们建议部署单独的 搜索节点以实现工作负载隔离性,而不进行数据隔离性,这样可以更有效地利用向量搜索使用案例的内存。
嵌入模型 | 向量维度 | 空间要求 |
---|---|---|
Voyage AI | 2048 | 8kb (for float )2.14kb (for int8 )0.334kb (for int1 ) |
OpenAI | 1536 | 6 kb |
Google | 768 | 3 kb |
Cohere | 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 指标来优化预配。
搜索索引大小
监控磁盘上所有索引的总大小(以字节为单位)。这是确保您准确确定RAM要求的必要条件。
Index Size验证磁盘上的搜索 100指标,查看如果向量的 % 存储在内存中,完整索引的大小,并确保它小于可用的系统内存。
搜索页面错误
监控所选示例周期内进程每秒的平均页面错误率。 Page Faults 指标表示搜索查询写入磁盘的频率,这表明内存不适合完整索引。
该指标必须尽可能接近于零。如果始终出现页面错误,请考虑扩展集群层以预配足够的RAM。
预热文件系统缓存
当您在不使用专用搜索节点的情况下执行向量搜索时,您的查询最初会在遍历 Hierarchical Navigable Small Worlds图表时在磁盘上执行随机查找,并将向量值读入内存。使用搜索节点时,这种缓存预热通常仅在索引重建事件发生,通常是在计划的维护窗口期间。
监控 CPU 瓶颈
向量嵌入在索引中会消耗计算资源。 大型数据集上的 ENN 查询会消耗 CPU 资源。因此,同时索引和查询可能会导致资源瓶颈。为防止出现 CPU 瓶颈,请避免在查询运行时对向量索引。执行初始同步时,在发出测试查询之前,请确保搜索节点 CPU 使用率返回接近0 %,这表明段已合并并刷新到磁盘。
在索引操作期间监控 Search Normalized Process CPU 指标,因为大量索引会显示 CPU 使用率升高。该指标将 CPU 使用率显示为相对于可用 CPU 核心数规范化的百分比,使您能够评估相对于集群容量的资源饱和度。对向量嵌入进行索引后,等待 CPU 占用率返回接近 0%,因为段合并和刷新已完成。