MongoDB Search 和 Vector Search with MongoDB Community处于预览状态。在预览期间，功能和相应的文档可能随时更改。要学习；了解详情，请参阅 预览功能。
本部分回答有关 mongot部署的关键规划问题，并提供设计搜索架构的可行步骤。要获得全面的概述，请线性阅读本节。或者，您可以使用本部分作为参考，根据需要跳到相关部分。本节的目标是帮助准确估计资源需求并构建稳健的部署。
数据特征和索引
数据结构和索引定义是 磁盘使用 和 RAM 要求 的主节点 (primary node in the replica set) 驱动因素。使用此部分来估计最终索引大小以及有效管理索引所需的内存。
1
计算基线索引大小
使用以下公式作为磁盘空间估算的点：
Estimated Index Size = (Number of Documents) x (Avg. Size of Indexed Text per Doc) x (Expansion Factor)
扩展因子至关重要，在很大程度上取决于您的分词策略。使用这些乘数作为指南：
用例(Use Case) | 乘数 |
|---|---|
标准/语言分词 |
|
关键字/简单标记化 |
|
edgeGram（自动完成） |
|
nGram（部分匹配） |
|
注意
前面的扩展因子乘数代表一般化示例，可能不适应用所有基于文本的内容。请务必使用自己的数据进行测试，以确定适合您部署的索引计算方式。
2
3
管理内存消耗以防止不稳定
- 使用静态映射
- 如果文档结构不可预测，请禁用动态映射。动态映射可能会导致“映射爆炸”，从而创建数千个意外字段，消耗过多RAM并导致不稳定。使用
dynamic: false显式定义索引。要学习；了解更多信息，请参阅静态和动态映射。 - 限制存储的源字段
- 仅在
mongot索引本身中存储搜索结果所需的最少字段设立。从主节点 (primary node in the replica set)MongoDB集合中获取字段通常效率更高，并且可以减少索引使用的磁盘空间。要学习；了解更多信息，请参阅在MongoDB搜索索引中定义存储源字段。 - 考虑高性能内存功能
- 请注意，同义词集合 和深度嵌套的 embeddedDocuments 会产生严重的内存问题。如果大量使用这些功能，则必须为
mongot进程分配更多Java堆空间。
索引工作负载
写入（插入、更新、删除）的速率和类型决定了保持搜索索引与数据库同步所需的 CPU 和 磁盘 IOPS。
要预配写入吞吐量和维护：
1
2
最大限度地复制延迟
- 合并索引
- 避免在单个集合上定义多个单独的搜索索引。每个索引都会增加开销。相反，应创建单个综合索引定义。
- 物化复杂视图
- 如果您正在为复杂视图索引，变更流性能可能会成为一个限制。考虑创建 物化视图，为
mongot索引提供简单的预聚合数据源。
3
查询工作负载
查询性能主要取决于用于处理的 CPU 和用于缓存的RAM 。查询的复杂性和数量决定了实现延迟目标所需的资源。
要估计查询性能所需的部署大小，请执行以下操作：
1
2
分配RAM以实现延迟
RAM是快速查询的最重要因素。
- 全文搜索
- 目标是将尽可能多的索引放入操作系统的文件系统缓存中。为获得最佳性能，请在
mongot节点上预配足够的RAM ，以与磁盘上索引的总大小相匹配。这样可以最大限度地减少磁盘读取速度慢的情况。 - Vector Search
- 对于低延迟向量搜索，HNSW图表索引必须存在于内存中。要计算所需的最小RAM，请使用索引大小估算过程中的步骤，并添加 20-25% 的缓冲区以开销。如果RAM不适合向量索引，查询延迟会增加。
注意
要降低RAM要求，请考虑使用矢量量化。矢量量化可以压缩矢量嵌入，从而降低内存占用（以及保存它们所需的RAM ），同时对召回率或精度的影响最小。