我们在azure上使用DocumentDB。我们有一个包含7个集合的数据库，每个集合最多有15个记录。它不需要太多存储空间。
只有少数开发人员正在使用此数据库实例。因此流量也低于平均水平。
此服务器仍然每天使用67,600个RU。 DocumentDB设置必定存在一些问题。那么，我正在寻找方向来准确分析这些RU的收费方式以及如何减少它们？
答案 0 :(得分：5)
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 =＆gt;的消耗量。 400.（至少在开发/测试期间）。
编辑截至2017年2月，分区馆藏的最低RU降至2,500（最低10,100）。 2017年12月，它再次下降至1,000。
答案 1 :(得分：3)
对于刚接触DocumentDB的人来说，通常会想到类似于SQL中的表的集合，甚至是MongoDB称之为“集合”的集合。但是，DocumentDB的设计不同。最好使用单个分区集合来存储所有文档类型和分区，例如地理位置，租户或用户。您可以使用type = <MyType>字段区分文档类型，或者我实际上更喜欢使用myType = true方法，因此我可以对继承和混合进行建模。
这意味着，您只需支付单个分区集合的费用。单个分区集合最终可能会比表存储花费更多，但如果您希望DocumentDB在以后几乎具有无限可扩展性，那么我强烈建议您从我描述的方式开始。
关于David建议使用非分区集合的另一个注释。这是DocumentDB首次启动时唯一的选择，但现在建议使用分区集合。我怀疑非分区收集选项可能会在某个时候逐步淘汰。您与它们的交互方式略有不同，正如David指出的那样，目前没有转换协助（特别是如果您使用多个非分区集合），因此稍后从非分区集合转换到分区集合并不难，但它并不像更改您的分区类型，将花费您的开发工作。单个分区集合比单个非分区集合花费你多一点，但是以后节省转换成本是值得的，恕我直言，并且它会花费你更少的单个分区集合而不是成本有七个未分区的。