azure-cosmosdb - 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
.
对于上述文档的适当分区键有什么建议吗?
解决方案
基数很好记住,但将业务逻辑和有意义的东西放在一切之上。您希望通过选择始终可用的键来消除必须执行跨分区查询的可能性。
您不希望在应用程序中将任何跨分区查询作为日常工作流程的一部分。
uniqueBusinessId
如果您能够访问 99% 的时间,那么选择将是一个不错的选择。它将允许良好的性能和低成本的操作。
但请记住,每个逻辑分区的最大大小为 10 GB。如果使用uniqueBusinessId
有任何机会满足该限制,那么您将无法使用它。
推荐阅读
- keras - 用于 2d 图像旋转估计的 CNN(角度回归)
- angular - 并行运行 Angular i18 构建
- reactjs - Material-UI 没有将颜色主题应用到按钮上,因为它应该是
- javascript - 将全局变量传递给函数以在 javascript 中重新分配
- java - 复杂性:条件运算符与 if-else
- google-earth-engine - 在 Ubuntu 上安装地球引擎
- django - 无法在 html 文件中访问我的“类别”模型
- vuejs2 - Vuetify 附加项目以选择菜单未选择正常项目
- java - 使用 apache camel 转换器 EIP 将模块导入 xquery
- python-3.x - 设计模式推荐 - 带有解析器和数据库的 Python Selenium 多页网页抓取工具