考虑客户的数百万行时区,进行日间聚合

5 mysql web-analytics bigdata

假设我有一个表格,其中存储了访问者(网站访问者)的信息.假设,表结构包含以下字段:

  1. ID
  2. visitor_id
  3. visit_time(自1970-01-01 00:00:00以来以UTC为单位存储)

这张表中有数百万行,而且还在增长.

在这种情况下,如果我想从任何时区看到报告(日期与访问者),那么一个解决方案是:

解决方案#1:

  1. 获取报表查看器的时区(即客户端)
  2. 考虑客户端的时区,汇总此表中的数据
  3. 明天显示结果

但在这种情况下,性能会下降.另一种解决方案可能如下:

解决方案#2:

  • 使用预聚合表/汇总表,忽略客户端的时区

但在任何一种情况下都有一个trade off between performance and correctness.

解决方案#1确保正确性,解决方案#2确保更好的性能.

我想知道这个特定场景中的最佳做法是什么?

A S*_*ith 0

当您进入分布式系统、用户以及各种数据源之间的匹配事件时,处理时间的问题就会出现相当多的问题。

我强烈建议您确保所有日志系统都使用 UTC。这允许从位于世界任何地方的任何类型的服务器(希望这些服务器都在当前 UTC 时间的视图上保持同步)进行收集。

然后,当收到请求时,您可以将用户时区转换为 UTC。此时您有相同的决定 - 执行实时查询或可能访问之前汇总的一些数据。

是否要提前聚合数据将取决于很多因素。其中一些可能需要减少保留的数据量、减少支持查询的处理量、执行查询的频率,甚至减少构建系统的成本与其可能使用的量的能力。

关于最佳实践——保持显示特性(例如时区)独立于数据处理。

如果您还没有考虑过,请务必考虑所保存数据的生命周期。您需要十年的可用回溯数据吗?但愿不会。您是否有在不再需要旧数据时剔除旧数据的策略?您知道如果存储每条记录(根据不同的流量增长率进行估计),您将拥有多少数据吗?

同样,对于较大数据集的最佳实践是了解您将如何处理数据大小以及如何随着时间的推移管理数据。这可能涉及长期存储、删除,或者可能还原为汇总形式。

哦,用矩阵类比来说,真正在“正确性”方面影响你的面条的是正确性在这里不是问题的事实。每个时区对自己所在区域“一天”内的流量都有不同的看法,并且每个时区都是“正确的”。即使是那些与您的时区不同的奇怪时区,其调整也不仅仅以小时为单位。