本部分回答有关 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搜索索引中定义存储源字段。 - 考虑高性能内存功能
- Be aware that synonym collections and deeply nested embeddedDocuments create significant memory artifacts. If you use these features heavily, you must allocate more Java heap space to the
mongotprocess.
索引工作负载
写入（插入、更新、删除）的速率和类型决定了保持搜索索引与数据库同步所需的 CPU 和 磁盘 IOPS。
要预配写入吞吐量和维护：
1
2
最大限度地复制延迟
- 合并索引
- 避免在单个集合上定义多个单独的搜索索引。每个索引都会增加开销。相反，应创建单个综合索引定义。
- 物化复杂视图
- If you are indexing a complex view, the change stream performance can be a constraint. Consider creating a materialized view to provide a simple, pre-aggregated data source for
mongotto index.
3
查询工作负载
查询性能主要取决于用于处理的 CPU 和用于缓存的RAM 。查询的复杂性和数量决定了实现延迟目标所需的资源。
要估计查询性能所需的部署大小，请执行以下操作：
1
2
分配RAM以实现延迟
RAM是快速查询的最重要因素。
- 全文搜索
- 目标是将尽可能多的索引放入操作系统的文件系统缓存中。为获得最佳性能，请在
mongot节点上预配足够的RAM ，以与磁盘上索引的总大小相匹配。这样可以最大限度地减少磁盘读取速度慢的情况。 - Vector Search
- 对于低延迟向量搜索，HNSW图表索引必须存在于内存中。要计算所需的最小RAM，请使用索引大小估算过程中的步骤，并添加 20-25% 的缓冲区以开销。如果RAM不适合向量索引，查询延迟会增加。
注意
要降低RAM要求，请考虑使用矢量量化。矢量量化可以压缩矢量嵌入，从而降低内存占用（以及保存它们所需的RAM ），同时对召回率或精度的影响最小。