我工作的公司为 Blackberry 平台开发应用程序。
我们一直致力于开发专有的“分析系统”，该系统允许我们将代码嵌入到我们的应用程序中，并让应用程序在每次运行时向我们的中央服务器报告一些统计数据。目前，系统运行正常；然而，它仅处于测试阶段，每小时有 100-200 次点击。 “命中”会毫无问题地发送到服务器。我们已经构建了一个非常可靠的 API 来处理命中的接受和存储(在 MySQL 数据库中)。我们已经测试了负载，我们应该能够毫无问题地容纳每小时数十万次点击。这不是真正的问题。
问题是显示统计数据。我们建立了一个类似于 Mint (haveamint.com) 的显示面板，它显示了每小时、过去几天、几个月、几周、几年等的点击量。第一个版本直接运行查询，从命中表中提取数据并即时解释。这并没有奏效很长时间。我们当前的解决方案是将命中“排队”以进行处理，并且我们每 5 分钟就会有一个 cron 接收命中并将它们分类到每小时、每天、每周、每月、每年等的“缓存”中。这非常有效，而且具有令人难以置信的可扩展性；但是，它仅适用于 1 个时区。由于整个公司都可以访问它，因此我们要与不同时区的数百名用户打交道。我在圣何塞定义的“今天”与我在伦敦的同事定义的“今天”大不相同。由于当前的解决方案仅缓存到 1 个时区，因此对于在我们时区之外检查数据的任何人来说都是一场噩梦。
我们目前解决这个问题的计划是为每个时区创建缓存(总共 40 个)；然而，这意味着我们将数据量乘以 40……这对我来说太糟糕了，考虑到缓存可能非常大，乘以它听起来是个坏主意；另外，当我们去处理队列时，将它们放入 40 个不同的缓存中将花费更多的 CPU 时间。
还有其他人对如何解决这个问题有更好的想法吗？
(很抱歉问了这么长的问题..解释起来并不容易。谢谢大家!)
最佳答案
您提出的解决方案冗余过多。我建议您将数据存储在至少 30 分钟的存储桶中而不是每小时存储一次，并将时区标准化为 UTC。
对于 30 分钟的存储桶，如果用户请求从 -4.5 UTC 开始的下午 1 点到 2 点的每小时数据，您可以从系统中获取下午 5:30 到 6:30 的数据并显示该数据。如果您以一小时为增量存储数据，则无法为时差为 N + 0.5 小时的用户提供服务请求。
对于每日数字，您需要聚合 48 个半小时时段。选择的时段将由用户的时区决定。
当您获取年度数据时，这会变得很有趣，因为您最终必须聚合 17,520 个半小时时段。为了简化计算，我建议您获取每个 UTC 时间的预聚合年度数据，减去一年中第一个 4.5 小时的聚合数据，然后添加下一年前 4.5 小时的聚合数据。这基本上会使全年增加 4.5 小时，而且工作量并不大。从这里开始，您可以进一步调整系统。
编辑:事实证明，加德满都是格林威治标准时间 +5.45，因此您需要将数据存储在 15 分钟的存储桶中，而不是 30 分钟的存储桶中。
编辑 2:另一个简单的改进是围绕年度汇总，这样您就不必每次都添加 17,520 个桶，也不需要每个国家/地区进行一次汇总。汇总 1 月 2 日 - 12 月 30 日的年度数据。由于任何两个国家之间的最大时区差异为 23 小时，这意味着您可以获取年度数据(1 月 2 日 - 12 月 30 日)并在前后添加几个桶作为适当的。例如，对于 -5 UTC 时区，您可以在 0500 点之后添加 1 月 1 日的所有存储桶、12 月 31 日的所有存储桶以及次年 1 月 1 日的所有存储桶，直到 0500 小时。
关于php - 设计可扩展的点击/分析系统的最佳方式？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/742073/