Cosmos DB分区键与查询设计优化：避免热点及高RU消耗

针对你的Cosmos DB设计难题，结合你的业务场景（多客户分布、EventId为主键、文档不可变永久存储、数千客户端定期轮询），我给你几个针对性的解决方案，帮你避开热点分区、高RU消耗以及单分区容量超限的问题：

方案1：时间分片+复合分区键（最匹配你的写入模式） #

分区键设计 #

用CustomerId_<TimeBucket>作为分区键，其中TimeBucket按你的写入周期（15分钟）来划分，比如格式可以是yyyyMMddHHmm的前12位（精确到15分钟，比如202405201415代表2024年5月20日14点15分的桶）。

为什么适合你？ #

• 容量控制：每日写入1GB，按15分钟分片的话，每个时间桶仅约10MB（1GB/(24*4)），远低于逻辑分区10GB的容量限制，完全不用担心单个分区超限。
• 避免写入热点：每个15分钟的写入只会对应一批时间桶分区，写完后该分区就不再有写入操作，不会出现持续的热点分区。
• 查询高效：客户端查询时，只需要针对最近的几个时间桶（比如最近2-3个，覆盖可能的最新事件）发起查询，不需要扫描全量分区。

查询实现逻辑 #

1. 根据客户端提供的LastEventId，解析出对应的时间（建议把时间戳嵌入EventId，比如yyyyMMddHHmm_xxxxxx，这样可以直接提取时间桶）；如果EventId是纯递增ID，就直接从当前时间往前推几个15分钟桶。
2. 生成目标时间桶对应的分区键前缀列表，比如["customerA_202405201415", "customerA_202405201430", "customerB_202405201415", ...]（对应要查询的CustomerId列表+时间桶）。
3. 执行查询：

   SELECT * FROM c 
   WHERE c.PartitionKey IN ("customerA_202405201415", "customerA_202405201430", "customerB_202405201415")
   AND c.EventId > @LastEventId
   ORDER BY c.EventId DESC
   OFFSET 0 LIMIT @MaxCount
   

4. 把多个分区的查询结果合并后，再按EventId排序取前@MaxCount条（因为是查最新事件，最近时间桶的EventId通常比旧桶大，大部分情况无需额外排序）。

方案2：客户分区拆分+复合分区键（适合客户事件量差异大的场景） #

如果你的部分客户事件量特别大（比如单个客户每日写入就超过10GB），时间分片可能不够用，可以用这个方案：

分区键设计 #

用CustomerId_<PartitionIndex>作为分区键，其中PartitionIndex是对CustomerId做哈希取模后的结果，比如Hash(CustomerId) % 6（把每个客户拆成6个逻辑分区，确保单个分区不超10GB）。

为什么适合你？ #

• 容量可控：即使单个客户的事件量增长到60GB，每个子分区也只有10GB，刚好符合Cosmos DB的限制。
• 写入均匀：同一个客户的事件会被均匀分到多个子分区，避免单个客户的单个分区成为写入热点。
• 查询定向：客户端查询时，能精准定位到目标客户的所有子分区，不会跨无关分区。

查询实现逻辑 #

1. 对每个要查询的CustomerId，计算出对应的所有PartitionIndex（比如0-5），生成完整的分区键列表：["customerA_0", "customerA_1", ..., "customerA_5", "customerB_0", ...]。
2. 执行类似方案1的查询，用IN子句指定这些分区键，再过滤EventId > @LastEventId，最后取top N条。

方案3：全局二级索引（GSI）优化跨分区查询 #

如果坚持要用EventId作为主分区键（比如依赖主键的唯一性约束），可以通过GSI来优化查询效率：

索引设计 #

创建一个以CustomerId为分区键、EventId为排序键的复合GSI。如果单个客户事件量超10GB，GSI的分区键可以用CustomerId_<PartitionIndex>（和方案2的拆分逻辑一致）。

为什么适合你？ #

• 主分区用EventId可以保证主键唯一性（注意：如果EventId是递增的，主分区会有写入热点，此方案更适合EventId随机生成的场景）。
• 查询时直接走GSI，每个CustomerId的GSI分区是独立的，Cosmos DB会并行查询这些分区，RU消耗比跨主分区查询低很多。

查询实现逻辑 #

直接针对GSI执行查询：

SELECT * FROM c 
WHERE c.CustomerId IN ("customerA", "customerB")
AND c.EventId > @LastEventId
ORDER BY c.EventId DESC
OFFSET 0 LIMIT @MaxCount

（如果GSI分区键是拆分后的CustomerId_<PartitionIndex>，就需要生成对应的分区键列表，用IN子句指定）

最终推荐 #

结合你的写入模式（15分钟增量）和查询需求，**方案1（时间分片+复合分区键）**是最优选择：它完全匹配你的写入节奏，天然避免热点，查询时只访问少量分区，RU消耗极低，也不会有单分区容量超限的问题。

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