Azure Cosmos DB选userID/region为分区键的性能差异咨询

以下为本次问题涉及的测试业务数据集：

[
    {
        "firstname": "Phil",
        "LastName": "Dixon",
        "age": 28,
        "org": "Fin",
        "Level": 3,
        "region": "India",
        "id": "123",
        "which-city": "Bangalore"
    },
    {
        "userID": 1,
        "Name": "Bob",
        "Hobbies": "Dancing",
        "Region": "USA"
    },
    {
        "userID": 2,
        "Name": "Anna",
        "Hobbies": "Dancing",
        "Region": "USA"
    },
    {
        "userID": 3,
        "Name": "Phil",
        "Hobbies": "Dancing",
        "Region": "USA"
    },
    {
        "userID": 4,
        "Name": "Jog",
        "Hobbies": "Dancing",
        "Region": "India"
    },
    {
        "userID": 5,
        "Name": "Maxi",
        "Hobbies": "Playing",
        "Region": "India"
    },
    {
        "userID": 6,
        "Name": "Capi",
        "Hobbies": "Playing",
        "Region": "Japan"
    }
]

问题1：以userID为分区键、每个数据项对应独立逻辑分区是否会引发性能下降？ #

不会。
这里存在一个普遍的认知误区：不少开发者认为「每个分区键值对应一个独立逻辑分区」会导致分区碎片化，带来额外性能开销。实际上逻辑分区是Cosmos DB用于数据路由的逻辑分组单元，并非底层物理存储节点：多个逻辑分区会被平台统一调度，共享底层物理分区的存储与计算资源，Cosmos DB会自动管理逻辑分区到物理分区的映射关系，单纯的逻辑分区数量多不会直接造成性能损耗。
结合场景前提：选择userID作为分区键时，所有查询都携带userID过滤条件，这类查询会被直接路由到对应逻辑分区所在的单个物理分区执行，完全没有跨分区扫描的额外开销，不存在分区粒度过细导致的性能问题。

问题2：userID与region作为分区键的性能差异 #

二者的性能差异本质来自分区键基数（即不同分区键值的总数量）、数据与请求分布均匀度的区别，结合当前场景前提（选择某字段作为分区键时，所有查询均携带该字段过滤条件、使用SQL API），具体性能差异可分为三个维度：

• 单查询RU消耗与延迟差异
  • 以userID为分区键时：单userID查询属于精准命中的单分区点查询，针对1KB大小的标准文档，这类查询稳定消耗约1RU，是Cosmos DB所有查询类型中延迟最低的一档，且RU消耗不会随容器总数据量的增长上涨。
  • 以region为分区键时：当前样例数据中region仅3个取值，基数极低。查询指定region的数据时，虽然也属于单分区查询，但查询的RU消耗和对应region逻辑分区下存储的总数据量正相关——如果某个region下存储了数十万、上百万条用户数据，查询时需要在分区内扫描大量数据，RU消耗会远高于userID对应的点查询，延迟也会随分区内数据量上涨逐步升高。
• 热点风险与水平扩展能力差异
  • 以userID为分区键时：分区键基数和用户总量正相关，数据和请求会均匀分散到不同物理分区上，不存在集中访问热点。哪怕后续用户规模增长到千万、亿级，Cosmos DB可以自动拆分物理分区承载流量，容器整体吞吐量可以线性扩展，性能不会因为业务规模增长出现明显衰减。
  • 以region为分区键时：单个逻辑分区的容量上限为20GB，吞吐量上限绑定单个物理分区的最大RU阈值，且同一个逻辑分区的数据永远不会被拆分到多个物理分区。如果后续某个region的用户量持续增长，要么会触发20GB的分区容量上限导致数据无法写入，要么会因为请求量超过单物理分区吞吐量上限出现请求限流，哪怕给容器配置再多RU也无法突破这个限制，水平扩展能力存在明确天花板。
• 资源利用率差异
  • 以userID为分区键时，用户请求均匀分布到所有物理分区，资源利用率可以长期保持在合理区间，不会出现部分节点空闲、部分节点过载的情况，同等RU配置下能承载的业务流量更高。
  • 以region为分区键时，流量会集中在少数几个逻辑分区对应的物理分区上，很容易出现大流量region对应节点过载、小流量region对应节点资源闲置的问题，整体资源利用率更低。

选型建议：如果业务查询100%是按userID查询单用户数据，userID是更优的分区键选择；只有当业务绝大多数查询是按region做聚合统计、且提前评估确认单个region下的数据量和请求量永远不会触碰单逻辑分区的容量、吞吐量上限时，才适合考虑将region作为分区键。

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