解决CosmosDB 20GB逻辑分区限制 按客户ID分区方案咨询

问题1答复 #

• 单个逻辑分区的20GB为固定硬上限，无法自动拆分。同一个corporationId对应的所有数据属于同一个逻辑分区，CosmosDB不会将同一个分区键值的数据拆分到多个逻辑分区中。
• 当逻辑分区容量达到20GB后，新的写入请求会直接被拒绝，返回带分区容量超限提示的429错误码，不存在自动拆分到第二个物理分区的机制。

问题2答复 #

推荐方案：合成/分层分区键 #

完全可以在不破坏客户逻辑隔离规则的前提下实现分区拆分，目前行业内普遍使用的成熟方案有两类：

1. 时间后缀合成分区键

适配你们现有6个月归档的业务规则，将分区键设置为{corporationId}_{年月}格式的合成值，例如a7d23fbc-1892-4d89-a6b7-6c9a8f7e6d5c_202406。

• 隔离性完全符合要求：所有数据仍归属对应客户，不存在跨客户数据混存的情况。
• 写入逻辑改动极小：.NET SDK层做轻量封装，写入时自动拼接当前年月即可，上层业务无感知。
• 查询性能损耗极低：单月查询直接传入对应合成分区键即可；跨多月查询时，将对应月份的合成分区键放入IN条件查询即可，性能损耗可以忽略。
• 归档效率大幅提升：到期数据直接删除对应年月的逻辑分区即可，无需扫描全量客户数据执行删除操作。

2. 分层分区键（原生支持）

目前Azure Cosmos DB SQL API已经原生支持最多3级的分层分区键，你无需自行拼接字符串，直接将分层分区键的第一层设为corporationId，第二层设为createMonth（年月）或自定义分片号即可：

• 完全兼容原有查询逻辑：如果查询时只传入第一层corporationId，SDK会自动扫描该客户下所有第二层分区的数据，原有查询代码几乎不用改动。
• 针对超大型客户，如果你不想按时间拆分，也可以把第二层设为分片号，写入时按/id哈希取模分配分片号即可，性能同样稳定。

其他补充建议 #

• 如果你仅存在1家超大型客户，也可以单独为该客户做特殊适配，其余99%的普通客户仍沿用原有单corporationId作为分区键的逻辑，最小化改动量。
• 归档逻辑可以配合Cosmos DB的生存时间（TTL）配置实现自动删除到期数据，无需自行实现定时任务。

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