这是一个简短的系列，我想分享很久以来关于 AWS 上“成本优化”的基础知识。

让我们从DocumentDB开始这段旅程吧！

如果您喜欢这篇文章，请不要犹豫👏；）

好吧，说实话，这个标题是点击诱饵*.*

我绝对可以写一些类似“我如何通过遵守文档中提供的一些通用指南来优化我们的 AWS 基础设施的成本”之类的东西，但这不太吸引人，不是吗？

也许你们中的一些人已经知道这些技巧和良好做法。

如果您正在寻找我建议的清单，请滚动此处。

了解 DocumentDB 服务的棘手 I/O 成本

如果您查看他们的定价页面，它会除以 4 个成本维度，我在这里继续：

• 实例的价格：这个成本很快就可以理解：您为一个实例付费，定价将取决于它的资源（CPU、RAM 等）
• 存储和备份存储成本：同上，这很容易理解，我们可以轻松跟踪和估算它们的成本，AWS 每 GB 存储的费用。合法的。
• 棘手的部分是数据库 I/O ：AWS 将在每 100 万次 I/O收费0.20 美元到0.30 美元（取决于实例所在的区域）之间！

那么，I/O 的背后是什么？

AWS 解释说，使用 DocumentDB 服务，您不必提前预置 I/O 资源，这很有趣，因为您没有存储限制，并且可以轻松处理一些 I/O 操作。这似乎是公平的，因为您需要为使用量付费。

AWS 在他们的文档中描述了涵盖 I/O 操作的内容，主要是所有操作，如查找、插入、更新和删除，或一些功能，如更改流和 TTL（生存时间）索引。

好吧，所有会影响存储量的东西都将向您收费。

等等，什么，每百万 I/O 0.20 美元？

让我们现在就让 AWS 赔钱吧！

AWS DocumentDB 文档中有一句话会引起你的注意（和钱包💸）：

一旦从存储卷中读取数据并继续驻留在内存中，随后对相同数据的读取不会产生额外的 I/O。

这句话是理解 I/O 背后的关键。

哪些操作使用较少的 I/O？

使用索引的查询可能会使用更少的 I/O，因为您没有扫描集合的所有存储。它肯定会消耗 I/O，但比扫描整个集合要少得多。

此外，您的实例的 RAM 需要覆盖您的索引大小，这样您就不会产生额外的 I/O。

请记住，您需要在使用索引时遵守一些原则。

清单✅

当您想要优化 I/O 使用并降低成本和提高性能时，这是我的建议/清单。

您会发现我不是天才，因为我只是汇总了来自 AWS DocumentDB 文档页面的信息以及一些并不严格适用于 DocumentDB 的常见最佳实践。

用原则来刷新我们的思想总是好的。

• 🧠首先，请记住：更少的 I/O = 更便宜 = 更好的性能，这里不只是成本或性能，但这两件事是联系在一起的。

• ❌删除未使用的索引：您不知道对于繁忙的集合而言，未使用的索引有多昂贵。通过删除未使用的索引，我让我的公司每月节省 2,000 美元🤌。使用此查询很容易跟踪未使用的索引：

  
  

索引统计查询

该查询将输出与您的索引被命中的次数相对应的字段ops 。根据您的应用程序的负载，请考虑删除未使用的索引。

• 🧐激活性能洞察和分析操作：如果您使用 RDS，您可能会意识到性能洞察，它会为您提供一些非常有用的指标和有关影响 DocumentDB 性能的查询的信息，并且您可以快速查看消耗 I /Os 操作（以及它们的数量），因此很容易跟踪瓶颈。监控慢查询或 collscan 查询的另一种方法是激活Profiling operations ，顾名思义，它会为您分析一些操作（这里是获取更多信息的链接：），您可以设置一个阈值，该阈值将在 CloudWatch 上放置一个日志耗时超过n ms的操作。例如，对于跟踪执行 COLLSCAN 的查询数量非常有用。请激活这两个选项，因为它们非常有价值！

  
  

• 💾始终首先查看您的数据：您需要确定要索引的最佳高基数字段，如果您不习惯索引基数的概念，AWS DocumentDB 的文档有很好的解释:)

  
  

• 🫠避免小的棘手集合：如果您计划拥有一个包含三个字段的集合，其中一个字段具有唯一键，并且如果您计划执行大量更新/插入，请考虑您的集合的建模，因为你的 I/O 操作会像地狱一样受到打击，所以你的 I/O 使用也会如此。

  
  

• ⏱️避免 TTL，也就是 time-to-leave 索引：（大多数时候）你可以在不设置 time-to-leave 索引的情况下处理它，所以请检查实例或集群上是否未启用 TTL 参数。

  
  

• 💡解释！在进行新查询（或不进行）时检查查询计划器的索引选择性的一种非常简单的方法是使用executionStats参数执行解释操作。您会惊讶于您正在考虑的一些查询命中索引，只是没有命中任何索引......

  
  

• ☯️不要为布尔字段创建索引。只是不要。记住基数。

  
  

• ⚖️ 使用以下命令监视每个集合的对象的平均大小： db.<mycollection>.stats(1024)极端的平均大小可以快速锁定您的查询并增加 I/O 操作，因为 RAM你的实例是不够的。请密切监视对象，不要存储不必要的字段。如果您需要存储许多字段，请考虑通过不选择所有字段来优化查询。

  
  

• ⚠️请注意 DocumentDB 不是 MongoDB。它主要与 MongoDB 兼容，但它不是 MongoDB，因为有一些糟糕的特定行为。例如，如果您想使用$regex运算符执行查询，则需要 `hint()` 你是索引，因为它是强制性的。排除运算符永远不会使用任何索引，因此在制作或优化索引时请考虑这些行为！

  
  

• 👉永远不要暗示。除了上面提到的非常具体的用例之外，您应该避免使用hint ，请记住，如果查询计划器没有选择您的索引，这是有充分理由的。大多数时候是因为它更长或等同于扫描索引而不是扫描集合中的所有文档。

• 
  

希望您会喜欢我在为我的公司从事 AWS 成本优化工作时学到的这些技巧。

请继续关注另一篇文章！

如果您喜欢这篇文章，请不要犹豫👏；）

PS：如果有什么问题或误解，请不要犹豫，私信我。

也在这里发布