对于简单的OR条件，DocumentDB请求充电非常高，但对于每个条件，则分别非常低

Question

我有疑问：

1）SELECT * FROM c where c.id = '0060f06e-260c-4dc7-9496-4a52e1a512c0'

申请费用为3卢比。

2）SELECT * FROM c where c.clientId = '0060f06e-260c-4dc7-9496-4a52e1a512c0'

申请费用为3卢比。

3）SELECT * FROM c where c.id = '0060f06e-260c-4dc7-9496-4a52e1a512c0' OR c.clientId = '0060f06e-260c-4dc7-9496-4a52e1a512c0'

要求收费 147 RU 。

这是正常行为吗？我认为没有任何理由存在这么大的差异。

更新： 在案例3）中，查询返回2个小文档（每个几百字节）

UPDATE2： 我正在测试Azure门户。

Answer 1

  

这是正常行为吗？我认为没有任何理由存在这么大的差异。

如果您提到请求费用是RU，那就是异常行为。我同意你提到它应该没有这样的差异。我也在我身边用azure portal测试，但是我无法在我身边重现它。您也可以直接使用azure portal测试它。如果您对“请求费用”仍有疑问，可以创建support request。

或

有关RU的更多信息，请参阅Request Units in Azure Cosmos。以下是Request unit considerations

的摘录

  

在估算要为Azure Cosmos数据库容器保留的请求单元数时，请务必考虑以下变量：

     

  
• 商品尺寸。随着大小的增加，读取或写入数据所消耗的单位也会增加。
  
• 项目属性计数。假设所有属性的默认索引，写入文档/节点/实体所消耗的单位随着属性数量的增加而增加。
  
• 数据一致性。使用强或有界陈旧的数据一致性级别时，会消耗额外的单位来读取项目。
  
• 索引属性。每个容器上的索引策略确定默认情况下索引哪些属性。您可以通过限制索引属性的数量或启用延迟索引来减少请求单位消耗。   文档索引。默认情况下，每个项目都会自动编入索引如果您选择不为某些商品编制索引，则会消耗较少的请求单位。
  
• 查询模式。查询的复杂性会影响操作消耗的请求单元数。谓词的数量，谓词的性质，预测，UDF的数量以及源数据集的大小都会影响查询操作的成本。
  
• 脚本用法。与查询一样，存储过程和触发器根据正在执行的操作的复杂性来使用请求单元。在开发应用程序时，请检查请求计费标头，以便更好地了解每个操作如何消耗请求单元容量。
  

Answer 2

好的，我得到了支持团队的答复，可能会帮助其他人。这就是他们所说的：

  

“这与我们当前的指数有关，我们无法同时为'id'提供服务   和'clientId'同时来自索引。基本上'id'是   被认为是主键，索引与'clientId'不同。   如果两个表达式都是自己指定的话，那么它   将从索引中提供。但是，将它们一起指定   只选择其中一个并放弃另一个。“

这个问题应该在未来几个月内解决（直到夏天）。