【问题标题】:Day wise aggregation considering client's timezone from millions of rows从数百万行考虑客户时区的日间聚合
【发布时间】:2015-06-28 00:48:00
【问题描述】:

假设我有一个存储访问者(网站访问者)信息的表格。假设,表结构由以下字段组成:

  1. 身份证
  2. visitor_id
  3. visit_time(自 UTC 起以毫秒为单位存储 '1970-01-01 00:00:00')

此表中有数百万行,并且还在增长。

在这种情况下,如果我想查看任何时区的报告(天 vs 访问者),那么一种解决方案是:

解决方案 #1:

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

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

解决方案 #2:

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

但无论哪种情况都有trade off between performance and correctness

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

我想知道在这种特定情况下的最佳做法是什么?

【问题讨论】:

    标签: mysql bigdata web-analytics


    【解决方案1】:

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

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

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

    您是否要提前汇总数据取决于很多事情。其中一些可能需要减少保留的数据量、减少支持查询的处理量、执行查询的频率,甚至是构建系统的成本与可能看到的使用量之间的关系。

    关于最佳做法 - 保持显示特征(例如时区)独立于数据处理。

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

    同样,大型数据集的最佳做法是了解您将如何处理规模以及随着时间的推移如何管理这些数据。这可能涉及长期存储、删除或简化为汇总形式。

    哦,打个 Matrix 类比,就“正确性”而言,真正要烤你的面条的是,正确性在这里不是问题。每个时区在他们自己的区域的“一天”中对流量有不同的看法,而且每个时区都是“正确的”。即使是那些与您的时区不同的奇怪时区,其调整也不仅仅以小时为单位。

    【讨论】:

      猜你喜欢
      • 2021-09-16
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-01-31
      • 1970-01-01
      • 1970-01-01
      • 2015-09-27
      • 2019-12-06
      相关资源
      最近更新 更多