Question

我正在尝试开发 用户个人资料服务 （ Asp.Net核心Web API ），该存储具有持久存储为 Azure Cosmos数据库。即使阅读了各种文章，我也无法找出适合该服务的分区键。根据各种文章

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

下面是示例文档，该文档存储在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来过滤文档。

关于上述文档适当的分区键应该有什么建议？

Answer 1

记住基数是很好的，但是要把业务逻辑以及什么才是最重要的。您希望通过选择一个始终可用的密钥来消除执行跨分区查询的可能性。

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

如果您有99％的时间可以访问uniqueBusinessId，则是一个不错的选择。它将实现良好的性能和低成本的运营。

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

什么是Cosmos DB中用户配置文件文档的适当分区键

1 个答案: