如何在 Azure Cosmos 中 select 分区键以防卷非常低（总记录 < 50k）
How to select Partition Key in Azure Cosmos in case volume is very low ( total records < 50k)
我已经阅读了 Microsoft 网站和 Internet 上的所有文档，但大多数都在谈论大数据，但我的要求很小。
我正在尝试保存客户入职数据。在客户入职之前，我们为其分配公司 ID 和用户 ID 以及管理员角色和默认环境。公司可以创建多个虚拟环境进行测试。例如。 Dev1、Stage 和 Test123 等，Onboarding 将在环境级别完成。
入职培训JSON
{
"companyId": "Company123",
"environment": "stg1",
"userId": "User123",
"startDate": 1212121212,
"modifiedDate": 1212121212,
"uniqueId": "<companyId_UserId>"
}
可以在环境级别完成入职。根据数据，一家公司最多可以拥有 10 到 15 个环境。在上面的文档中，用户 ID 只是元数据，用于检查哪个用户开始在环境 stg1 上入职。
最初我想使用公司 Id 作为分区键，但在这种情况下，每个逻辑分区最多有 15 条记录。
我的 Cosmos 查询将包含公司 ID 和环境 ID 作为过滤器。
这是一个好方法吗？或者我是否应该使用哈希函数生成合成分区键并将逻辑分区限制为 10 或 20。
哪个更快？
- 大量逻辑分区，但所有分区都包含 10 到 15 个文档
- 逻辑分区数量较少，但分区包含的文档数量较多。
我的完整数据大小约为 < 1 GB，因此请不要假设我们会在这里达到 "logical partition limit 10 GB" 的限制。
我的其他查询是
- 使用 Azure SDK 在插入新文档的情况下，我的 RU 是 7.67，但在更新插入的情况下，它是 10.9。有什么办法可以减少这个。
据我所知，逻辑分区限制不是 20gb。据我从与开发 cosmos db 的产品组的谈话中了解到，创建所需数量的分区没有害处，请记住，您应该不惜一切代价避免跨分区查询（因此以这样的方式设计数据您将永远不必进行跨分区查询的时尚。
所以一个客户的逻辑分区是有意义的，除非你想对所有客户进行查询。但考虑到数据集的大小，它不应该产生巨大的影响。无论哪种方式，两种方法都有效。我想说的是，只有当您不生成它就找不到合理的密钥时，才需要创建合成密钥
如果您的集合永远不会超过 20GB，那么您用作分区键的内容就不那么重要了，因为您的所有数据（和您的查询）都将驻留在一个物理分区上。分区键（和分区）都是关于规模的（这就是为什么我们总是在大量数据或大量操作的上下文中谈论它们）。
在读取繁重的工作负载中，选择在所有查询 where 子句中使用的分区键是一种安全策略，在您的情况下，environmentId-companyId 的合成键是一个不错的选择。如果这是写入繁重的工作负载，那么您还希望分区键值跨分区分配写入。但同样，如果这是一个小集合，那么这在这里无关紧要。
您的 id 属性 很好，因为它可以使用具有不同分区键值的相同 companyId-userId 值，这正是我假设您想要的。您还可以使用 environmentId、companyId 和 userId 进行点读，如果您拥有所有这三个，您应该尽可能多地做，而不是在查找单个项目时进行查询。即使这个集合不会增长，根据你所说的，这里的分区策略应该允许它在你想要的时候扩展。
更新插入总是比插入更昂贵，因为它是两个操作而不是一个。降低写入成本的唯一方法是创建自定义索引策略并排除您从不查询的路径。但是根据您 post 中的示例文档，自定义索引策略不会给您带来任何改进。
希望这对您有所帮助。
我已经阅读了 Microsoft 网站和 Internet 上的所有文档，但大多数都在谈论大数据，但我的要求很小。
我正在尝试保存客户入职数据。在客户入职之前，我们为其分配公司 ID 和用户 ID 以及管理员角色和默认环境。公司可以创建多个虚拟环境进行测试。例如。 Dev1、Stage 和 Test123 等，Onboarding 将在环境级别完成。
入职培训JSON
{
"companyId": "Company123",
"environment": "stg1",
"userId": "User123",
"startDate": 1212121212,
"modifiedDate": 1212121212,
"uniqueId": "<companyId_UserId>"
}
可以在环境级别完成入职。根据数据，一家公司最多可以拥有 10 到 15 个环境。在上面的文档中，用户 ID 只是元数据，用于检查哪个用户开始在环境 stg1 上入职。
最初我想使用公司 Id 作为分区键，但在这种情况下，每个逻辑分区最多有 15 条记录。
我的 Cosmos 查询将包含公司 ID 和环境 ID 作为过滤器。
这是一个好方法吗？或者我是否应该使用哈希函数生成合成分区键并将逻辑分区限制为 10 或 20。
哪个更快？
- 大量逻辑分区，但所有分区都包含 10 到 15 个文档
- 逻辑分区数量较少，但分区包含的文档数量较多。
我的完整数据大小约为 < 1 GB，因此请不要假设我们会在这里达到 "logical partition limit 10 GB" 的限制。
我的其他查询是
- 使用 Azure SDK 在插入新文档的情况下，我的 RU 是 7.67，但在更新插入的情况下，它是 10.9。有什么办法可以减少这个。
据我所知，逻辑分区限制不是 20gb。据我从与开发 cosmos db 的产品组的谈话中了解到，创建所需数量的分区没有害处，请记住，您应该不惜一切代价避免跨分区查询（因此以这样的方式设计数据您将永远不必进行跨分区查询的时尚。
所以一个客户的逻辑分区是有意义的，除非你想对所有客户进行查询。但考虑到数据集的大小，它不应该产生巨大的影响。无论哪种方式，两种方法都有效。我想说的是，只有当您不生成它就找不到合理的密钥时，才需要创建合成密钥
如果您的集合永远不会超过 20GB，那么您用作分区键的内容就不那么重要了，因为您的所有数据（和您的查询）都将驻留在一个物理分区上。分区键（和分区）都是关于规模的（这就是为什么我们总是在大量数据或大量操作的上下文中谈论它们）。
在读取繁重的工作负载中，选择在所有查询 where 子句中使用的分区键是一种安全策略，在您的情况下，environmentId-companyId 的合成键是一个不错的选择。如果这是写入繁重的工作负载，那么您还希望分区键值跨分区分配写入。但同样，如果这是一个小集合，那么这在这里无关紧要。
您的 id 属性 很好，因为它可以使用具有不同分区键值的相同 companyId-userId 值，这正是我假设您想要的。您还可以使用 environmentId、companyId 和 userId 进行点读，如果您拥有所有这三个，您应该尽可能多地做，而不是在查找单个项目时进行查询。即使这个集合不会增长，根据你所说的，这里的分区策略应该允许它在你想要的时候扩展。
更新插入总是比插入更昂贵，因为它是两个操作而不是一个。降低写入成本的唯一方法是创建自定义索引策略并排除您从不查询的路径。但是根据您 post 中的示例文档，自定义索引策略不会给您带来任何改进。
希望这对您有所帮助。