我正在调查为什么我们在Cosmos中耗尽了这么多RU。我们的写入量是RU的预期数量，但我们的读取量却很高-比我们的写入量大。我试图将其剥离到最简单的情况。在没有结果的分区上查询单个请求将占用2000 RU。为什么这么贵？
var query = new QueryDefinition("SELECT * FROM c WHERE c.partitionKey = @partionKey ORDER BY c._ts ASC, c.id ASC")
.WithParameter("@partionKey", id.Value)
using var queryResultSetIterator = container.GetItemQueryIterator<MyType>(query,
requestOptions: new QueryRequestOptions
{
PartitionKey = new PartitionKey(id.Value.ToString()),
});
while (queryResultSetIterator.HasMoreResults)
{
foreach (var response in await queryResultSetIterator.ReadNextAsync())
{
yield return response.Data;
}
}
集合的分区键为/partitionKey。RU容量直接在容器上设置，不共享。我们有一个匹配where子句的复合索引-_ts asc，id asc。尽管我不确定这对不返回记录有何影响。
不幸的是，当以这种方式查询时，SDK似乎并没有为您提供用过的RU，因此我一直在使用Azure监视器来观察RU的使用情况。
有谁能阐明为什么此查询返回零条记录并限制为单个分区需要2k RU？
更新：
我只是在同一存储帐户中数据库的另一个实例上运行了此查询。两者的配置相同。DB1中有0MB，DB2中有44MB。对于不返回记录的完全相同的操作，DB1使用111 RU，DB2使用4730RU-对于相同的无结果查询，其使用量是原来的40倍以上。
添加更多细节：一致性设置为一致前缀。这是单个区域。
另一个更新：
我已经复制了仅通过Azure门户查询的问题，它与容器中的记录数有关。查看查询统计信息，就好像它正在加载容器中的每个文档以搜索分区键一样。分区键不是最高效的搜索方式吗？Cosmos是否不确切地知道在哪里可以找到属于分区键的文档？
2445.38的RU
显示结果
0 - 0
检索的文档数：65671检索到的文档尺寸：294343656字节
输出文档计数：0
输出文件大小：147字节的索引命中文档计数：0
索引查找时间：0毫秒
文献加载时间：8804.060000000001毫秒
查询引擎执行时间：133.11 ms
系统功能执行时间：0 ms
用户定义功能执行时间：0 ms
文档写入时间：0 ms
我最终找到问题的根源。为了搜索分区键，需要对其进行索引。考虑到使用分区键来决定文档的存储位置，这使我感到奇怪，因此您可能认为Cosmos会固有地知道每个分区键的位置。
在索引项目列表中包含分区键解决了我的问题。这也解释了为什么随着数据库规模的增加，性能会随着时间的推移而下降-它正在扫描每个文档。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句