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 回答