0

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

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

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

目前的表结构

TrackingPixelId | 用户名 | 代码 | 中 | 来源 | 查看日期 | 会话 ID

9109616 | 第1234章 'BULLETIN120115' | '电子邮件' | 'BULLETIN120115' | {日期时间} | bf7e2f801...

栏目信息

TrackingPixelId : PK 整数自动递增

用户 ID：整数

代码、媒介和来源：字符串/varchars

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

SessionId : 例如 fa5cac87896e1c7b423051fffdb836a6

Code 和 Source 本质上是相同的，即打开的 Email Mail Out 的唯一 ID。

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

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

4

1 回答 1

1

首先，我会提醒您不要立即跳入分片。凭借您的数据量，您应该能够让单个副本集处理您的流量。分片的真正触发点是当工作集变得大于单台机器上 RAM 的合理值时。

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

另外，由于您对生成每日、每周...报告感兴趣，我认为您可以采用分层聚合策略来最小化和分摊读取负载，这对于集群来说比写入负载要昂贵得多，因为分片键选择。这将让您在新数据上增量生成报告，然后查询完成的报告，而无需在查询时生成它。我还建议尽可能使用聚合管道而不是 map/reduce 来生成报告数据，即使手册页使用 map/reduce。

于 2015-01-16T15:35:00.987 回答