Cosmos DB 分区键选择

Question

我正在为我为客户开发的应用程序使用 Cosmos DB。该客户是一家跨国公司，在全球拥有约 175,000 名员工。该应用程序必须整合来自各种源系统的通知，并在用户单击与任何在线系统（例如 LinkedIn 等）名称相同的下拉菜单时将它们显示在用户的门户上

我正在尝试确定 Cosmos DB 的 'Partition Key'。我相信这就是"User Id"。我想确保我能从在 Cosmos DB 数据库设计方面有更多经验的人那里受益。

以下是我选择用户 ID 作为分区键的原因。我知道可能有大约 175,000 'Logical' 个分区，它们将映射到底层 Azure 数据存储平台上少得多的 'Physical' 个分区。 'User Id' 的选择保证当前用户的所有通知记录都存储在同一个 'Logical' 上，因此 'Physical' 分区。

我错了吗？请确认。如果是，那么什么是更好的策略？

谢谢。

巴拉特

Answer 1

一般的经验法则是您要查看高容量操作并对您的分区策略进行负载测试以验证它是否可以扩展。不需要面面俱到。帕累托原则适用于此。

基于您引用的查询，尽管您的逻辑看起来很合理。其他需要注意的是存储。最大分区大小为 20GB。我不知道每个通知的有效载荷大小是多少，但可以通过给定的 X 数量的通知来衡量和处理，直到达到 20GB 大小为止。此外，您可能希望避免在将来的某个时候查询不断增长的分区，因此将来可能还想查看 TTL 策略。

希望对您有所帮助。