0

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

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

但是使用不区分大小写的搜索（通过替换）的相同查询false花费true1228 RUs。

有没有解释为什么不区分大小写的查询比区分大小写的查询贵 470 多倍？我对此感到惊讶，因为文档指出

StartsWith 和 StringEquals 的 RU 费用与不区分大小写选项相比略高。

细节：

  • 两个查询都返回 0 个结果。
  • 分区键是type.
  • 逻辑分区type1包含 200 万个文档。
  • 对于几乎所有 200 万份文件，该name属性具有不同的价值。
  • 使用默认索引策略 ( "path": "/*")
4

1 回答 1

1

这是我到目前为止发现的：

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

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

如果我需要有效的不区分大小写的字符串比较怎么办？

对于小型集合（< 10,000 个文档），区分大小写并没有太大的区别。（当然，如果包含分区键将潜在结果集的大小限制为更小的数字。）

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

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

于 2021-02-17T20:29:17.173 回答