3

我们在 azure 上使用 DocumentDB。我们有一个包含 7 个集合的数据库，每个集合最多有 15 条记录。它不需要太多的存储空间。

只有少数开发人员在使用此数据库实例。所以流量也低于平均水平。

该服务器仍然每天使用 67,600 RU。DocumentDB 设置一定有问题。所以，我正在寻找方向来准确分析这些 RU 是如何收费的以及如何减少它？

4

2 回答 2

6

DocumentDB 设置没有问题。您预配了 7 个集合。默认情况下，通过门户为每个集合分配 1000 RU（您可以随意使用，无论您使用 0 RU 还是全部 1000 RU）。非分区集合的最小 RU 设置为 400。

编辑-我误读了-如果您的容量为 67,000 RU，那么您可能已经配置了多个分区集合（从 10,100 RU 开始）。对于最初的开发/测试，只有 15 个文档，您已经严重过度分配了容量。

由于您预置了七个集合（可能根据您的 RU 大小进行了分区），因此您的部署约为 70,000 RU。无论您实际消耗什么（您实际上是在保留容量）。

我不知道您的应用程序需要什么，以及出于某种特定原因您是否需要 7 个集合。但是......客观地说，没有规则说您需要将不同的文档类型分成不同的集合。您可以轻松地将异构数据存储在单个集合中。您如何查询特定类型实际上取决于您，但type向每个文档添加诸如属性之类的东西是微不足道的）。

请注意，因为我现在相信您正在使用分区集合：您不能将它们转换为非分区集合；您需要创建新的非分区集合并从分区集合中移动数据。（鉴于您总共有 15 个文档，这应该是微不足道的）。

请注意，单个非分区集合可能会缩小到 400 RU。如果您随后将 7 个集合合并为 1 个集合，您应该能够将消耗量从 ~70,000 => 400 减少。（至少在开发/测试期间）。

编辑截至 2017 年 2 月，分区集合的最小 RU 下降到 2,500（从最初的 10,100 最小值）。2017 年 12 月，它再次下降至 1,000。

于 2017-01-05T12:19:10.570 回答
4

对于 DocumentDB 的新手来说，通常会想到一个类似于 SQL 中的表的集合，甚至是 MongoDB 所称的“集合”。但是，DocumentDB 的设计不同。最好使用单个分区集合来存储所有文档类型和分区，例如地理、租户或用户。您将使用type = <MyType>字段来区分文档类型，或者我实际上更喜欢使用myType = true方法，这样我就可以对继承和混合进行建模。

这意味着，您只需为单个分区集合付费。单个分区集合最终可能仍然比表存储花费更多，但是如果您以后想要 DocumentDB 近乎无限的可伸缩性，那么我强烈建议您从我描述的方式开始。

关于 David 建议使用非分区集合的另一条注释。这是 DocumentDB 首次启动时的唯一选择，但现在建议使用分区集合。我怀疑非分区收集选项可能会在某个时候被淘汰。您与它们的交互略有不同，正如 David 指出的那样，目前没有转换帮助（特别是如果您使用多个非分区集合），因此稍后从非分区集合过渡到分区集合并不难，但它并不像更改您的分区类型并将花费您的开发工作。与单个非分区集合相比，拥有单个分区集合的成本会多一点，但以后节省转换成本是值得的，恕我直言，它'

于 2017-02-08T19:44:43.983 回答