Azure cosmosdb Cosmos db用户id/电子邮件作为分区密钥

关于为存储用户数据的分区键选择最佳（syntetic）值，我有一个难题

用户文档有： -id（guid） -电子邮件（用于登录，例如） -剖面数据

有两种主要类型的查询：

通过

id

查找用户（大多数查询）

通过

电子邮件
查找用户（登录和一些管理员查询）

我希望避免跨分区查询

如果我为

partitionKey

（合成字段）选择

id

，那么登录查询将是跨分区的。 另一方面，如果我选择了

email

，那么如果用户改变了email，那就是一个问题

我的想法是在系列中引入新类型。比如：

userId: guid,
userEmail: “email1”,
partitonKey: “users-mappings”

然后，我可以将

用户

文档本身作为：

id: someguid,
type: “user”,
partitionKey: “user_someguid”,
profileData: {}

这样，当用户登录时，我首先通过

email

检查映射类型/分区，获取

guid

，然后通过

guid

检查实际的

user

文档

此外，这种方式可以在不影响分区的情况下更改电子邮件

---

这是一种有效的方法吗？有什么问题吗？我遗漏了什么吗？

你的问题没有标准答案。在我看来，名为

映射类型的解决方案

会导致两个查询，这也是低效的。选择分区密钥始终是一个权衡利弊的过程。请参阅官方文档中的

根据您的描述：

1.按id查找用户（大多数查询）

2.通过电子邮件查找用户（登录和一些管理员查询）

我建议您对最频繁的查询进行优先级排序，也就是说，

id

我的理由：

1.id不易更改，相对稳定

2.登录后可以保存会话或cookie，因此与id相同的登录权限不多

3.id是最常见的查询条件，因此不可能每次都跨越所有分区

---

4.如果您确实担心登录性能，请不要忘记添加电子邮件列。这也可以提高性能。

如您所知，在查询Cosmos DB时，扇出应该是最后一个查询选项，尤其是在登录等大容量操作中。此外，如果数据量大，RUs的成本将显著提高

在COSMOSDBSQLAPI中，一种模式是使用合成分区键。您可以通过在写入时连接id和电子邮件来合成合成分区密钥。此模式适用于大量提供灵活性的查询场景

大概是这样的：

{
“id”：“123”，
“电子邮件”：joe@abc.com",
“分区键”：“123-joe@abc.com"
}

感谢您的输入！所以你基本上是建议将用户登录查询保留为跨分区查询？@deezg是的，这是我的意见。是的，我明白了。好的，这将像物理分区一样并行地扇出尽可能多的查询。偶尔（哪种登录方式是），这很好。我只是想知道，你能详细说明一下为什么你认为

用户映射

（不超过2个单分区查询）解决方案比跨分区解决方案效率低？这就是我一直在寻找的确认。我只在模拟器上测试过，它产生的RU比随机属性的完全扫描要高。你有在Azure托管数据库上使用此功能的统计信息吗？