如何解释 Cosmos DB 查询的“RequestCharge”？答案

【问题标题】：How to interpret `RequestCharge` for Cosmos DB query?如何解释 Cosmos DB 查询的“RequestCharge”？
【发布时间】：2020-04-27 19:02:07
【问题描述】：

对于一个项目，我正在考虑使用 Cosmos DB (SQL API) 作为我的数据库解决方案。阅读有关请求单元的文档，我了解到 here 和 here 读取 1 项大小为 1 KB 的项目占用 1 RU（请求单元）。

当我执行下面的查询时（我查询单个分区中的所有项目（性别是 PartitionKey），我得到 5.000 个项目的结果（在 1.000 个项目的五个块中）。每个项目的大小为 1.5 KB，所以每个项目应该超过 1 RU。但是，标题指出 RequestCharge 总共只有 88.12，对于 1.000 个项目。遵循每个大小为 1 KB 的项目 1 RU 的规则，我期望至少 1000 RU .

有人知道如何正确解释RequestCharge 吗？

代码和查询：

    public async Task<List<Profile>> GetAllProfilesByGender(string gender)
    {
        var container = GetContainer();
        var queryIterator = GetQueryIterator(container, gender);

        var profiles = new List<Profile>();
        while (queryIterator.HasMoreResults)
        {
            var resultSet = await queryIterator.ReadNextAsync();
            foreach (var profile in resultSet)
            {
                profiles.Add(profile);
            }
        }

        return profiles;
    }

    private FeedIterator<Profile> GetQueryIterator(Container container, string gender)
    {
        var query = new QueryDefinition($"SELECT * FROM c WHERE c.Gender = '{gender}'");
        return container.GetItemQueryIterator<Profile>(query);
    }

【问题讨论】：

这与您的问题无关，但如果您计划超过 20GB 的大小和/或写入繁重的场景，性别不是一个可以很好地扩展的分区键。您可以通过Partitioning in Cosmos DB了解更多信息
@MarkBrown 感谢您的评论。数据库永远不会达到那个大小（最大为 1-2 GB），并且写入操作只会针对单个项目。
好的。对于单分区容器而言，重要性不那么重要。谢谢。
@MarkBrown 你的评论让我重新思考。也许您可以就这一点提供一些建议？鉴于此容器上的查询将始终至少指定性别（用户查询男性或女性，但绝不会同时查询）和 Profile 文档的某些其他属性的子集（最终用户可以选择过滤 FirstName、City、Education、Profession，在 Gender 旁边）我选择 Gender 作为 PartitionKey，因为它是唯一合适的 PartitionKey，它阻止我进行跨分区查询。您对此有何看法？
当然，如果它总是在查询中使用，那么这就是良好分区键的一部分，因为没有分区键的查询将在所有分区中散开。同样，在小型收藏中没什么大不了的。在设计大规模 NoSQL 数据库时，这只是一个设计考虑因素。

标签： azure azure-cosmosdb azure-cosmosdb-sqlapi

【解决方案1】：

请求单位 (RU) 费用不会随检索到的文档数量呈线性增长。涉及的因素很多：查询的复杂度、索引的使用等。

“一个读取一个 1K 文档的成本为 1 RU”的概念是完全不同的。很多时候，需要一个文档（这就是为什么有一个 read API 调用，而不是一个 query 调用）。如果您比较同一单个文档的 read 与 query，您会发现 query 版本的文档检索成本更高，RU 方面，而不是 read 版本（因为它必须调用查询引擎、处理索引等）。

附带说明：我不确定您是否希望看到 RU 使用规模（在您的示例中，1,000 RU 用于 1,000 个返回的文档） - 这最终会非常昂贵。查询引擎多年来经历了许多优化，以降低 RU 成本。

【讨论】：

谢谢！这是有道理的:).. 哈哈，我明白了，我很高兴看到它只有 88 RU 而不是 1,000。