不区分大小写搜索的高 RU 费用答案

【问题标题】：High RU charge with case-insensitive search不区分大小写搜索的高 RU 费用
【发布时间】：2021-02-03 08:48:03
【问题描述】：

我有一个包含 400 万个文档 (~5GB) 的 Cosmos DB 集合。以下查询报告了 2.79 RU 的费用：

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

但是使用不区分大小写的搜索（通过将 false 替换为 true）的相同查询需要 1228 RUs。

是否解释了为什么不区分大小写的查询比区分大小写的查询贵 470 多倍？我对此感到惊讶，因为documentation 状态

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

详情：

【问题讨论】：

可能是模拟器没有 Cosmos 随着时间的推移添加的所有优化。当我对 100,000 个集合进行查询时，我得到几乎相等的 RU 使用率（2,79 对 2,80）。即使只有 100,000 个文档，我也预计会有显着差异。所以我认为模拟器中的 RU 在这种情况下并不是一个很好的表示。
@404 我在模拟器上也有几乎相同的 RU 费用，但集合较小（几千个文档）。我曾希望我可以在模拟器上使用各种不同的数据收集来衡量各种查询的费用，以节省时间和金钱。 :-(
@404 我现在可以确认在“真正的”Cosmos DB 集合中表现出相同的行为。 2.79 RUs 用于区分大小写的搜索，1228.01 RUs 用于不区分大小写的搜索。
@404 我怀疑您没有观察到 RU 消耗量的差异，因为第一个标准 c.type = 'type1' 将可能结果的数量限制在一个很小的范围内，或者 c.name 的基数在您的收藏。
我在没有c.type 表达式的情况下进行了测试，因此查询运行在我对 MD5 哈希值的整个集合过滤上。在尝试使用具有 1200 万个文档的新数据库时，性能甚至比使用 569604 RU 的结果还要差。考虑到我的 100k 收藏几乎没有显示出差异，我对这个结果感到非常惊讶。添加order by c.md5 强制索引扫描会将其降低到 7700 RU

【解决方案1】：

这是我目前发现的：

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

对于小型集合（

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

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

【讨论】：