Cosmos DB热点分区是否会增加RU消耗？多租户场景技术问询

可能的核心原因 #

• 目标租户的数据量差异：虽然总库仅大5GB，但如果生产环境中该<random-guid>租户下的type='myType'文档数量远多于开发环境，MAX(c._ts)查询需要扫描更多文档。Cosmos DB的RU计算直接关联扫描的文档数、单文档大小及索引使用效率，开发环境数据量小，扫描开销低；生产环境大量同类型文档会显著拉高RU。
• 热点分区的资源挤占：即使查询限定单个tenantId（单分区查询），若该租户所在分区为热点分区，其他租户的高并发请求会挤占该分区的CPU、IO资源，导致本次查询需要等待资源释放，最终表现为RU消耗激增（RU是资源占用时间与计算量的综合计量）。
• 生产环境索引碎片：长期的写入、更新、删除操作会导致生产环境的索引产生碎片，查询扫描索引时需要处理更多无效条目，额外增加计算开销，推高RU。

快速排查验证步骤 #

• 统计目标文档数量：在生产和开发环境分别执行以下查询，对比结果：

  SELECT VALUE COUNT(1) 
  FROM c 
  WHERE c.type='myType' AND c.tenantId='<random-guid>'
  

  若生产环境文档数是开发的10倍以上，数据量差异就是主因。
• 检查分区负载：查看Cosmos DB控制台的Partition Key RU Consumption指标，确认该tenantId所在分区的RU使用率是否接近或超过限额。若是，说明热点挤占是关键因素。
• 验证索引碎片：尝试对容器执行索引重建，重建后再次执行目标查询，若RU明显下降，则索引碎片是问题根源。

优化方案 #

• 创建复合索引：针对tenantId、type、_ts创建复合索引，让MAX(_ts)查询直接通过索引定位，无需扫描分区内的同类型文档，大幅降低RU消耗。索引配置示例：

  {
      "indexingMode": "consistent",
      "includedPaths": [{"path": "/*"}],
      "compositeIndexes": [
          [
              {"path": "/tenantId", "order": "ascending"},
              {"path": "/type", "order": "ascending"},
              {"path": "/_ts", "order": "descending"}
          ]
      ]
  }
  

• 治理热点分区：若为热点问题，可考虑调整大租户的分区键（如tenantId+业务子维度），或通过手动拆分热点分区、调整分区级吞吐量分配缓解资源竞争。
• 定期维护索引：定期清理生产环境的过期数据，避免索引碎片累积；必要时执行索引重建操作，维持索引效率。

内容的提问来源于stack exchange，提问作者levis