Azure cosmosdb 高RU电荷，不区分大小写搜索

我有一个Cosmos DB集合，有400万个文档（~5GB）。以下查询报告的费用为2.79卢比：

SELECT * FROM c WHERE c.type='type1' and STRINGEQUALS(c.name,'abc',false)

但是使用不区分大小写搜索的相同查询（通过将

false

替换为

true

）的成本1228 RUs

有没有解释为什么不区分大小写的查询比区分大小写的查询贵470倍以上？我对此感到惊讶，因为美国

StartsWith和StringEquals使用不区分大小写选项时的RU费用略高于不使用它时的费用

---

详情：

• 两个查询都返回0个结果
• 分区键是

  类型

• 逻辑分区

  type1

  包含200万个文档

• name

  属性对于几乎所有200万个文档都具有不同的值
• 使用默认索引策略（

  “路径”：“/*”

  ）

---

这是我目前发现的情况：

Cosmos DB是否支持高效的不区分大小写的字符串比较？ 不幸的是，不区分大小写的

STRINGEQUALS

的RU费用在属性的基数（即该属性的不同值的数量）上似乎是线性的。如果你有很多文件，这真的很糟糕。在10000 RU/s的吞吐量下，上述查询几乎需要1s。相反，区分大小写的字符串比较与集合的大小无关。另见讨论

如果我需要高效的不区分大小写的字符串比较呢？ 对于小型集合（<10000个文档），区分大小写并没有多大区别。（当然，如果分区键的包含将潜在结果集的大小限制为一个小得多的数字，也是如此。）

对于较大的集合，您可以存储每个属性的副本，这些属性应支持高效的小写不区分大小写搜索，并对小写属性执行区分大小写的搜索

---

您可以投票支持支持高效的不区分大小写查询的功能请求。

可能是emulator没有随时间增加的所有优化。当我对100000个集合进行查询时，我得到几乎相同的RU使用率（2,79 vs 2,80）。即使只有100000份文档，我也会期望有显著的差异。因此，我认为仿真器的RU在本例中不是一个很好的表示。@404我在仿真器上也有几乎相同的RU费用，收集量较小（几千个文档）。我曾希望我能在Emulator上通过各种不同的数据收集来衡量各种查询的费用，以节省时间和金钱-（@404我现在可以确认，同样的行为在一个“真实”的场景中被展示Cosmos DB collection.2.79 RUs用于区分大小写的搜索，1228.01 RUs用于区分大小写的搜索。@404我怀疑您在RU消耗量方面没有观察到任何差异，因为第一个标准

c.type='type1'

将可能结果的数量限制在一个较小的数字内，或者

c.name

的基数在您的数据库中要小得多集合。我在没有使用

c.type

表达式的情况下进行了测试，因此查询在MD5哈希上对我的整个集合进行了筛选。在对一个包含1200万个文档的新数据库进行相同的尝试后，性能甚至比您使用569604 RU的结果还要差。考虑到我的100k集合几乎没有显示出任何结果，我对这个结果感到非常惊讶差异。通过c.md5添加

订单以强制索引扫描将其降低到7700 RU