Azure 在MongoAPI查询中使用投影对CosmosDB RUs有什么影响

我找不到有关“”是指原始文档大小还是指投影后查询的结果大小的任何信息

我可以观察到像这样的简单查询

 documents.find({ /*...*/ }, { name: 1 })

对于400个项目的结果（查询字段被索引），消耗超过1000 RU。原始文档相当大，大约500KB。由于投影，实际接收的数据很小。如果删除投影，查询将运行几秒钟，但不会消耗更多的RU（实际上稍微多了一点，但似乎是因为它被拆分为更多的

GetMore

调用）

对我来说，这听起来真的很奇怪，查询的成本主要取决于集合中原始文档的大小，而不是检索到的数据。这是真的吗？我是否可以在不将数据拆分为多个集合的情况下重新计算此查询的成本？其逻辑基本上是：“只需获取集合中所有这些大型文档的‘名称’”

---

（数据库上没有分区…

不幸的是，微软似乎没有公布确定RU成本的公式，只是进行了广泛的描述。他们确实说：

随着项目大小的增加，用于读取的RU数量也会增加 或者写的项目也会增加

因此，成本取决于项目的原始大小，而不仅仅是读取操作输出的部分。如果使用Data Explorer运行一些查询并检查查询统计信息，您将看到两个指标，

检索到的文档大小

和

输出文档大小

。通过投影属性子集，可以减小输出大小，但不能减小检索到的大小。在对我的数据进行的测试中，我发现通过选择返回属性，RU费用会有很小的降低——这肯定不是与减少的输出成比例的节约

---

从根本上说，无论是从属性数据大小还是属性数量来看，使项目变小可能是最重要的工作。如果可以避免，您肯定不想要500 KB的项目。

如果可以避免，您肯定不想要500 KB的项目。

在成本方面，或者这是一个一般建议？我认为没有必要不将整个文档存储在基于文档的数据库中。所有的查询、命令和聚合都工作得很好，性能也很好，但它们太昂贵了。但非常感谢您的回答；）我会问MS团队，为什么运行几个MS的查询与运行100倍长的查询成本相同……“它们太贵了”。这基本上是正确的，你的物品越大，不管你试图优化什么。如果你不关心费用，那么只要你没有达到2 MB的项目限制，就没什么好担心的。不清楚“简单查询”是什么意思-你没有显示你正在执行的

find（）

操作的类型，或者你是如何设置索引的。编辑您的问题并分享更多细节可能会有帮助。另外，不清楚“数据库上没有分区”是什么意思-您如何避免分区？