我正在为要为客户端开发的应用程序使用Cosmos DB。客户是跨国公司，在全球拥有约175,000名员工。该应用程序必须合并来自各种源系统的通知，并在用户单击与任何在线系统（例如，LinkedIn等）相同名称的下拉菜单时将其显示在用户的门户上。
我正在尝试确定Cosmos DB的“分区密钥”。我相信这是“用户ID”。我想确保我能从拥有Cosmos DB数据库设计经验的人们中受益。
这是我选择用户ID作为分区键的原因。我知道潜在地可能有大约175,000个“逻辑”分区，它们将映射到基础Azure数据存储平台上更少的“物理”分区。选择“用户ID”可确保所有当前用户的通知记录都存储在相同的“逻辑”分区中，因此也存储在“物理”分区中。
我错了吗？请确认。如果是，那么什么是更好的策略？
谢谢。
巴拉特
答案 0 :(得分：0)
一般经验法则是，您要查看您的大容量操作，并对分区策略进行负载测试，以验证它可以扩展。不需要穷举。帕累托原理在这里适用。
尽管您的逻辑看起来很合理，但根据您引用的查询。需要注意的其他事项是存储。最大分区大小为20GB。我不知道每个通知的有效负载大小是多少，但是要测量并通过给定X数量的通知来工作，需要多长时间才能达到20GB大小。此外，您可能希望避免在将来的某个时刻查询一个不断增长的分区，因此也可能希望将来也考虑使用TTL策略。
希望这会有所帮助。