MongoDB - 最好的Shard Key用于存储电子邮件像素跟踪数据

Question

目前，我们会在邮件列表中向订阅者发送电子邮件。这具有跟踪像素，该像素映射到PHP文件，然后将数据插入到我们的SQL Server数据库中。

电子邮件跟踪像素插页的当前平均值是每天大约80,000次插入。大约800,000个插件相当于大约1GB的硬盘空间，因此10天1GB的数据。

除此之外，我们还将其他插入和跟踪数据插入到SQL Server数据库中，该数据库也恰好与网站使用的数据库相同。因此，对于空间，性能，许可成本和水平扩展等原因，我想将此分析跟踪数据从SQL Server数据库中移除+网站不需要此分析跟踪数据，因此我想移动这些写入重插入离开，以便网站数据库就是这样。

目前的表格结构

TrackingPixelId | UserId |代码|中|来源| DateViewed |的SessionID

9109616 | 1234 | 'BULLETIN120115'| '电子邮件'| 'BULLETIN120115'| {datetime} | bf7e2f801 ... 的

列信息

TrackingPixelId：PK整数自动增量

UserId：整数

Code，Medium和Source：Strings / varchars

DateViewed：DateTime例如2015-01-13 06：18：24.920

SessionId：例如fa5cac87896e1c7b423051fffdb836a6

代码和来源基本相同，即打开的电子邮件发送的唯一ID。

因此，就如何报告数据而言，我们将查看已打开电子邮件的数量。所以每日，每周，每月和每年的报告，我们不需要立即生成报告，可能每天写入大量的报告，但只需要一手完整的读取，但可能首先需要最新的数据。

因此，考虑所有这些因素，什么是最好的分片键？

Answer 1

首先，我要提醒你不要马上进入分片。使用您的数据量，您应该能够使用单个副本集来处理流量。分片的实际触发点是当工作集变得大于单个机器上RAM的合理时间时。

也就是说，鉴于您主要关注写入性能并且可以容忍较慢的报告读取，我认为散列的分片键最有效。您可以散列一些唯一的id或散列MongoDB生成的ObjectId值。这将保证写入在集群中均匀分布。读取将是分散 - 聚集，但听起来可以容忍获得非常好的写入缩放。

另外，由于您对生成每日，每周......报告感兴趣，我认为您可以采用hierarchical aggregation策略来最小化和分摊读取负载，这对于由于分片键选择，集群比写入负载。这将允许您以新数据的形式逐步生成报告，然后查询完成的报告，而无需在查询时生成报告。我还建议尽可能使用聚合管道而不是map / reduce来生成报告数据，即使手册页使用map / reduce。