同一查询的 Cosmos DB 图 RU 成本不一致

Question

我们正在使用配置了 120K RU 的 CosmosDB Graph API 实例。我们使用/partition_key 属性设置了一致的分区结构。

在使用 Gremlin 查询我们的图表时，我们注意到与其他查询相比，某些查询使用了不合理的大量 RU。查询本身是相同的，但对于 partition_key 值本身。

例如，以下查询花费 23.25 RU：

g.V().has('partition_key', 'xxx')

而具有不同 partition_key 值的同一查询需要 4.14 RU：

g.V().has('partition_key', 'yyy')

查看两个查询的.exectionProfile() 结果；它们看起来很相似。

花费 23.25 RU (xxx) 的昂贵查询：

[
  {
    "gremlin": "g.V().has('partition_key', 'xxx').executionProfile()",
    "activityId": "ec181c9d-59a1-4849-9c08-111d6b465b88",
    "totalTime": 12,
    "totalResourceUsage": 19.8,
    "metrics": [
      {
        "name": "GetVertices",
        "time": 12.324,
        "stepResourceUsage": 19.8,
        "annotations": {
          "percentTime": 98.78,
          "percentResourceUsage": 100
        },
        "counts": {
          "resultCount": 1
        },
        "storeOps": [
          {
            "fanoutFactor": 1,
            "count": 1,
            "size": 848,
            "storageCount": 1,
            "storageSize": 791,
            "time": 12.02,
            "storeResourceUsage": 19.8
          }
        ]
      },
      {
        "name": "ProjectOperator",
        "time": 0.15259999999999962,
        "stepResourceUsage": 0,
        "annotations": {
          "percentTime": 1.22,
          "percentResourceUsage": 0
        },
        "counts": {
          "resultCount": 1
        }
      }
    ]
  }
]

花费 4.14 RU (yyy) 的廉价查询：

[
  {
    "gremlin": "g.V().has('partition_key', 'yyy').executionProfile()",
    "activityId": "841e1c37-471c-461e-b784-b53893a3c349",
    "totalTime": 6,
    "totalResourceUsage": 3.08,
    "metrics": [
      {
        "name": "GetVertices",
        "time": 5.7595,
        "stepResourceUsage": 3.08,
        "annotations": {
          "percentTime": 98.71,
          "percentResourceUsage": 100
        },
        "counts": {
          "resultCount": 1
        },
        "storeOps": [
          {
            "fanoutFactor": 1,
            "count": 1,
            "size": 862,
            "storageCount": 1,
            "storageSize": 805,
            "time": 5.4,
            "storeResourceUsage": 3.08
          }
        ]
      },
      {
        "name": "ProjectOperator",
        "time": 0.07500000000000018,
        "stepResourceUsage": 0,
        "annotations": {
          "percentTime": 1.29,
          "percentResourceUsage": 0
        },
        "counts": {
          "resultCount": 1
        }
      }
    ]
  }
]

两个查询的结果都返回一个大小大致相同的顶点。

有人可以帮忙解释一下为什么会这样吗？为什么一个比另一个贵得多？关于 Cosmos DB 分区，我有什么不明白的地方吗？

编辑 1： 我们还通过添加其他查询参数进行了一些实验，例如id 和label。 id 子句确实将昂贵查询的成本从 ~23 RU 降低到 ~4.57 RU。这种方法的问题在于，通常它会降低所有其他查询的效率（即增加 RU）。

例如，其他查询（如此票证中的快速查询）从 ~4.14 RUs 变为 ~4.80 RUs，并添加了 id 子句。所以这并不是真正可行的，因为 99% 的查询会更糟。我们需要找到根本原因。

编辑 2： 使用 Azure 门户中的数据资源管理器工具在同一容器上运行查询。这是分区分布图：

Answer 1

您所描述的“问题”可能与物理分区 (PP) 和逻辑分区 (LP) 的大小边界有关。 Cosmos DB 允许基于其partitioning architecture 进行“无限”缩放。但是扩展性能和数据增长高度依赖于逻辑分区策略。 Microsoft 强烈建议使用尽可能精细的 LP 密钥，以便数据在 PP 之间平均分布。

最初为 120k RU 创建容器时，您最终会得到每个物理分区 12 PP - 10k RU 的限制。一旦你开始加载数据，就有可能得到更多的 PP。以下情况可能会导致“分裂”：

• LP 大小（每个分区键的数据总大小）大于 20GB
• PP 大小（此 PP 中存储的所有 LP 大小的总和）大于 50GB

根据documentation

A physical partition split simply creates a new mapping of logical partitions to physical partitions.

根据 PP 存储分配，您似乎有多个“拆分”，导致配置了大约 20 个 PP。 每次发生“拆分”时，Cosmos DB 都会创建两个新的 PP，并在新创建的之间平均拆分现有的 PP。一旦这个过程完成，“倾斜”的 PP 就会被删除。您可以通过您提供的 Metrics 图表上的 PP id 粗略猜测拆分次数（如果没有发生拆分，您将获得 id: [1-12]）。

由于请求扇出和跨分区查询，拆分可能会导致更高的 RU 消耗。