本页提供了有关提高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 向量搜索消耗的 CPU、内存和磁盘资源量取决于多个因素，包括索引大小和查询条件。请务必监控您的环境，以了解向量搜索的运行状况和性能，并确认有足够的基础架构容量并识别任何异常情况。
使用以下指标观察并提高MongoDB Vector Search 搜索索引和查询的性能：
搜索系统内存
监控MongoDB Vector Search 搜索索引使用的RAM总量。足够的RAM对于MongoDB向量搜索查询性能至关重要，因为进入磁盘的查询性能要低得多。确保整个索引能够容纳在内存中。
确保可用 System Memory 始终大于已用 System Memory。如果不经常查询索引，则并非所有索引都可能位于内存中。因此，请结合使用 System Memory 指标和 Index Size 指标 来优化预配。
如果向量索引大小超过 3 GB，我们建议进行向量量化，即仅在内存中存储索引的 4%，而不是完整索引。
搜索索引大小
监控磁盘上所有索引的总大小（以字节为单位）。这是确保您准确确定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%。