考虑数百万行中客户端时区的逐日聚合

Question

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

1. ID
2. 访问者id
3. visit_time(自"1970-01-01 00:00:00")

此表中有数百万行，而且还在增长。

在这种情况下，如果我想看到任何时区的报告(天与访客)，那么一个解决方案是：

解决方案#1:

1. 获取报表查看器(即客户端)的时区
2. 根据客户的时区聚合此表中的数据
3. 按天显示结果

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

解决方案2:

• 使用忽略客户端时区的预聚合表/摘要表

但在任何一种情况下都存在trade off between performance and correctness。

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

我想知道在这种特殊情况下，最佳做法是什么？

Answer 1

当你进入分布式系统、用户和各种数据源之间的匹配事件时，处理时间的问题会出现。

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

然后，当收到请求时，您可以从用户时区转换为UTC。在这一点上，您有相同的决定——执行实时查询，或者访问以前汇总的一些数据。

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

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

如果你还没有，一定要考虑到你保存的数据的寿命。您是否需要十年的备份数据？希望不会。当不再需要旧数据时，您有剔除旧数据的策略吗？你知道如果你存储每一条记录(估计不同的流量增长率)，你会有多少数据吗？

同样，对于较大的数据集，最好的做法是了解您将如何处理大小，以及随着数据的老化，您将如何管理数据。这可能涉及长期存储、删除，或者可能简化为摘要形式

哦，用矩阵来比喻，真正能让你"正确"的是，正确性在这里没有问题。每个时区在自己的区域内对"一天"的交通有不同的看法，每个时区都是"正确的"。即使是那些与你的时区不同的奇怪时区，也会有一个并非仅以小时为单位的调整。