时事通讯活动的分区键设计

Question

在阅读了我可以在文档db上找到的所有文档之后，我仍然在努力设计分区密钥。让我们来看一下发送给员工/部门的公司电子邮件的情景。让我们说它是一家庞大的公司，100万名员工，这是虚构的我只想假设每周发送几百万封电子邮件，大部分都会被阅读并被点击以便摄取大量数据。

让我用json代表一些实体。出于所有意图和目的，这个数据至少在我的情况下是在sql服务器中，但我想跟踪打开，按成员和部门点击。对于大型组织，这些数据可以快速增长，这是DocumentDB的用例。我不想为此讨论DocumentDB的优点，只是为了更好地理解分区密钥设计。把它煮沸：

数据

• 时事通讯：{newsletterId: 1, name: 'something', departments:[1,2,3]} // this newsletter sent to 3 company departments
• 员工：{employeeId: 1212, name: 'John Smith'}
• NewsletterEmployeeActivity：{newsletterId: 1, employeeId:1212, link: 2, date: '1-2-2017'}和/或{newsletterId: 1, employeeId: 1212, open: '1-2-2017'} //其中link是电子邮件中链接的ID

报告

• 按部门通讯打开并点击
• 按部门打开和点击
• 打开并点击整个简报
• 按简报链接点击（只是假设我们可以将链接ID映射到链接）

你将如何构建分区键？是否有与报告相关的不同文档类型？即，一个跟踪员工点击/打开（这将是大量数据），一个按部门递增聚合，一个汇总的通讯（可能只是总结部门）等，或者这个交易实施成本高昂在阅读电子邮件的同时，您可能会遇到10000次打开？

阅读有关热门分区的内容后，上述方法似乎属于该类别。

Answer 1

对于NewsletterEmployeeActivity，由于您希望在简报发布时突然发生活动，@Input()将成为有效扩展写入流量的良好分区键。

由于报告通常可以稍微延迟构建，我建议您通过change feed运行窗口聚合，然后保存每小时/分钟的统计信息，通过简报，简报x部门，部门执行所有汇总到一个单独的DocumentDB“stats”集合中。

要存储简报和员工元数据，您可能需要分别使用employeeId和newsletterId。如果您愿意，可以通过创建合成分区键将这些文档存储在同一个集合中，然后根据类型存储适当的值。