首页 > 解决方案 > Cosmos DB 中用户配置文件文档的适当分区键是什么

问题描述

我正在尝试开发一个用户配置文件服务Asp.Net 核心 Web API ),它具有作为Azure Cosmos DB的持久存储。即使阅读了各种文章,我也无法为这项服务找出合适的分区键。根据各种文章,

分区键(逻辑分区)应该是一个具有均匀访问模式的键。理想的分区键是在您的查询中经常作为过滤器出现并且具有足够的基数以确保您的解决方案具有可扩展性的分区键。

下面是存储在 Azure Cosmos DB (SQL API) 中的示例文档。

{
    "id": <<Id>>,   
    "uniqueBusinessId": <<uniqueBusinessId>>,               
    "userName": <<userName>>,                                   
    "isActive": <<isActive>>,                       
    "email" : <<email>>
    "salutation": <<"salutation>>
    "firstName": <<firstName>>,                 
    "middleName": <<middleName>>,                       
    "lastName": <<lastName>>,                                           
    "companyName": <<companyName>>,         
    "jobTitle": <<jobTitle>>        
    "address": [                
        {                                   
            "countryCode": <<Country Code>>,        
            "stateProvinceCode": <<StateProvinceCode>>,     
            "address1": <<addressLine1>>,   
            "address2": null,               
            "city": <<city>>,               
            "postalCode": <<postalCode>>,           
        }
    ]
    "phone": [              
         {          
            "countryCode":  <<Country Code>>,           
            "areaCode": <<area Code>>,          
            "number": <<number>>,       
            "extension": <<extension>>          
        }
    ]
  }

集合中的每个用户都有一个文档,99% 的查询将根据uniqueBusinessId每个用户的唯一 id 获取数据(系统中约有 100 万用户)。

如果我选择uniqueBusinessId上述集合作为分区键,这意味着它将创建 100 万个逻辑分区(并且它没有基数)。是uniqueBusinessId分区键的合适人选吗?我可以选择分区键/address/city或文档中的任何其他键以具有良好的基数;但它会与查询产生问题,因为它们将是跨分区扫描以过滤基于uniqueBusinessId.

对于上述文档的适当分区键有什么建议吗?

标签: azure-cosmosdbazure-cosmosdb-sqlapi

解决方案


基数很好记住,但将业务逻辑和有意义的东西放在一切之上。您希望通过选择始终可用的键来消除必须执行跨分区查询的可能性。

您不希望在应用程序中将任何跨分区查询作为日常工作流程的一部分。

uniqueBusinessId如果您能够访问 99% 的时间,那么选择将是一个不错的选择。它将允许良好的性能和低成本的操作。

但请记住,每个逻辑分区的最大大小为 10 GB。如果使用uniqueBusinessId有任何机会满足该限制,那么您将无法使用它。


推荐阅读