为了更好地了解和简化支出，尤其是随着使用量的增加， MongoDB Atlas提供了一些工具来管理和控制组织的数据库成本。
所有部署范式建议
以下建议适用于所有部署范式。
考虑这些优化Atlas成本的策略。
缩减未充分利用的集群
使用Performance Advisor和集群指标来识别超大集群。查找是否存在持续较低的 System Max: User CPU utilization（低于 45%）或从未充分利用的多余RAM 。然后缩减到更符合实际工作负载模式的层级。
许多团队从更大的集群开始，却忘记在学习；了解实际使用模式时进行调整。 Atlas提供低 CPU 选项以实现更轻的工作负载，还提供灵活的大小调整选项，让您能够根据实际情况匹配资源，而不是凭空猜测。规模优化通常是最大的费用控制手段。
要学习；了解详情，请参阅 响应式缩减集群。
在您的集群层上启用自动伸缩功能，以匹配使用量并防止过度预配。
缩减每六个小时进行一次，并且必须符合特定条件。要了解更多信息，请参阅缩减集群层。
您还可以通过定期监控集群的 CPU、WireTiger 缓存、内存和 IOPs，在正常使用的 30 天滚动期间手动降级到较低的集群层。一般来说，如果使用量持续低于已分配资源的 45%，我们建议您缩减。
对于专用集群，如果长时间不使用，请考虑扩展到较低层级或暂停集群。
我们建议您使用
M10或M30集群来进行开发和测试环境。要了解更多信息，请参阅 Atlas 集群大小指南。对于开发和测试环境，我们建议您：
启用 cron 作业，在夜间无人对集群进行主动开发时暂停开发和测试集群。在使用以下方法之一时，您可以通过将
paused字段设置为true来使用 Atlas Administration API 暂停集群：在第三方指标或警报系统中设置警报，如果开发或测试集群超过一周没有任何活动，则会触发该警报。
考虑在设定时间后终止未使用的开发和测试集群，并向集群所有者发送充分的电子邮件警报。您可以通过以下方法终止集群：
Terraform 集群资源，通过将
termination_protection_enabled字段设置为false。
避免分片分布不均
对于分片的集群，查看您的扩展策略以避免热分片。当集群中的一个分片接收的流量或数据比其他分片多得多时，就会出现热分片，迫使您在只有单个分片需要更多资源时扩展整个集群。
检查您的集合在分片上的分布情况，以发现这些不平衡的情况。查找尚未分片的的繁忙集合。正确分配它们，以便您可以扩展整个集群的大小。您还可以根据实际使用情况，为不同集合设立不同的分片方式。首先尝试重新平衡流量，使其跨分片均匀，但如果不可能，请利用独立分片功能。
当您不使用独立分片扩展，热分片的成本很高，因为您最终需要为扩展整个集群中实际上并不需要的资源付费。当您通过智能分片更均匀地分布负载时，您可以调整设置并避免不必要的成本。节省的成本取决于您的特定工作负载，但随着数据模式的变化，这些方法可帮助您以稳定、经济高效的方式实现增长。
要了解更多信息，请参阅 Atlas 可扩展性指导。
优化备份配置
连续备份的成本很高，但可以最安全地从备份窗口内的任何点恢复数据，以防发生灾难或代码逻辑错误。我们建议您仅对生产应用程序中最关键的数据层级启用连续备份。
降低存储不太关键数据的集群的备份频率。请考虑在开发环境中完全终止这些集群。
优化数据传输模式
尽可能选择同一提供商、同一地区的数据传输，以最大限度地降低成本。仅在必要时使用区域间或互联网传输，例如需要在不同地区恢复应用程序的灾难恢复场景。将集群放置在与大部分流量相同的地区（通常是托管应用程序的区域）可以大幅降低数据传输成本。
压缩网络流量
在客户端驱动程序中启用网络压缩，以压缩客户端与服务器之间的数据。例如，您可以为节点 Node.js 驱动程序配置网络压缩选项。Atlas 始终会压缩集群内通信。
要了解更多信息，请参阅如何降低数据传输成本。
优化连接池
查看应用程序的连接池设置并调整其大小，以匹配您的实际并发使用模式。大多数应用程序可以安全地从默认设置中减少最大池大小，同时添加适当的连接超时和重试逻辑。
每个数据库连接都会消耗应用程序和集群端的资源。过度预配的连接池会产生不必要的开销，并且实际上可能会因连接抖动而损害性能。
避免低效查询
检查访问数据的所有应用程序和进程是否效率低下。确保查询不会：
重新读取客户端已经存在的数据。
将现有数据重新写入集群。
要了解更多信息，请参阅如何降低数据传输成本。
优化查询
执行时间较长的查询会增加资源使用量，从而需要更高层级的集群。优化这些查询以减少资源消耗，从而降低成本。
与您的团队一起安排季度查询调整，以查看最慢的查询并Atlas 审核索引占用空间。使用Performance Advisor来识别缺失的索引，并使用查询分析器来发现成本高昂的操作。创建一个简单的电子表格来追踪成本最高的前10 个查询及其优化状态。
查询性能会随着数据的增长而降级。在 1 GB时表现良好的查询可以轻松超过 100 GB时的预算。同时，未使用的索引会消耗存储并减慢写入速度，并且无法提供价值。定期审核及早发现性能偏差，保持索引策略精益求精、目标明确。
已暂停Atlas Search索引
Atlas Search索引可能会由于以下任一原因而过时：
由于磁盘利用率较高，复制已停止。
对于专用Atlas Search节点，暂停复制阈值为 90%，恢复复制阈值为集群上所有写入的磁盘利用率 85%。如果没有专用的Atlas Search节点，则暂停复制阈值为 96%，恢复复制阈值为集群上所有写入的磁盘利用率 94%。
如果复制停止的时间长于oplog window，则Atlas Search
mongot进程脱离oplog ，然后必须重新同步。当当前复制点在
mongodoplog上不再可用时，通常会出现此状态。如果mongot进程脱离oplog ， Atlas会重建索引，这可能会占用大量资源并需要大量时间。索引已达到 20 亿文档限制。
复制因错误而失败。
您仍然可以查询现有索引。但是，针对过时索引的查询结果可能包含过时数据。您可以升级搜索节点以获得更多磁盘空间，如果当前未超过区块阈值，删除现有索引以发布磁盘空间。或者，使用 View status details 模式窗口中的错误来解决问题。
优化模式
与Atlas团队合作，查看您的集合是否存在高成本模式，例如超大文档、无界数组或强制执行成本高昂操作的模式。寻找机会嵌入一起访问的相关数据，同时将单个文档保持在合理的大小。当可以使用更简单的文档结构时，重点关注消除需要复杂聚合或跨集合查找的模式。
糟糕的模式设计会导致低效查询和存储膨胀，从而悄悄推高成本。如果设计得当， Atlas文档模型自然会消除昂贵的关系操作。设计良好的集合可降低计算开销，最大限度地减少索引要求，并提高查询性能，所有这些都会直接影响您的每月账单。
优化存储
使用在线存档或 TTL 索引等功能，将较早的数据从较昂贵的热存储转移到较便宜的冷存储，或删除不再需要的数据。存档数据后，您可以通过 Atlas Data Federation 访问数据。
使用成本浏览器
定期使用成本浏览器工具监控组织、项目、集群和服务级别的支出模式。设置适合您需求的频率。
设置警报
为关键阈值配置账单警报，例如当每月费用超过一定金额时。示例，设立当成本超过 $100 时发出警报。这种主动的方法可以帮助您避免意外情况。
查看发票
每个月查看您的发票，使用以前的账单优化建议评估成本最高的服务。 这是识别费用降低机会的推荐最佳实践。
如果您在发票上发现意外变化，请检查您的云计算成本，该成本通常占账单的最大部分。 您可以在Atlas Billing部分中任何发票的Summary By Service卡中查看云计算成本。 Summary By Service视图按提供商、层级和地区显示所有集群的成本。
选择合适的部署范式和拓扑结构
您选择的部署范式和拓扑结构可能会改变您的 Atlas 费用。
要了解有关不同拓扑结构的费用节省详情，请参阅 Atlas 高可用性指导。
设置资源标记
按团队、环境或费用中心一致的标签应用于Atlas项目和集群。使用“团队营销”、“环境生产”或“项目移动应用”等描述性标签，在整个组织中创建清晰的所有权和支出可见性。
如果没有适当的标记，您的Atlas账单就会变得模糊，无法追踪哪些团队或项目增加了成本。资源标记可将 Cost Explorer 转变为功能强大的问责工具，从而轻松识别费用趋势、准确分配费用以及按部门或工作负载类型发现优化机会。