我们一直在研究专有的“分析系统”,它允许我们在我们的应用程序中嵌入代码,并让应用程序在每次运行时向我们的中央服务器报告一些统计信息.目前,系统运行正常;然而,它只是在测试版中,每小时100-200次点击. “命中”会毫无问题地发送到服务器.我们已经构建了一个非常可靠的API来处理命中的接受和存储(在MySQL数据库中).我们测试了负载,我们应该能够每小时容纳数十万次点击而没有任何问题.这不是一个真正的问题.
问题是显示统计数据.我们已经建立了一个类似于Mint(hasamint.com)的显示面板,它显示了每小时,过去几天,几个月,几周,几年等的点击量.第一个版本直接查询从命中表中提取数据并在运行中解释它.这不会持续很长时间.我们目前的解决方案是命中“排队”进行处理,我们每5分钟就有一个cron来点击并将它们分成每个小时,每天,每周,每月,每年等的“缓存”.这非常有效,并且具有令人难以置信的可扩展性;但是,它仅适用于1个时区.由于整个公司都可以访问这个,我们正在处理各个时区的几百个用户.我在圣何塞定义的“今天”与我在伦敦的同事定义为今天的情况大不相同.由于当前解决方案仅缓存到1个时区,因此对于检查时区之外的数据的人来说,这是一场噩梦.
我们目前解决这个问题的计划是为每个时区创建缓存(总共40个);然而,这意味着我们将数据量乘以40 ……这对我来说太糟糕了,并且考虑到缓存可能非常大,增加它只是听起来像个坏主意;另外,当我们去处理队列时,将需要更多的cpu时间将它们放入40个不同的缓存中.
其他任何人都更好地了解如何解决这个问题？
(抱歉,这么长的问题……解释起来并不容易.谢谢大家！)
使用30分钟的存储桶,如果用户在-4.5 UTC之间的1 – 2PM请求每小时数据,您可以从系统中获取数据,并在5:30 – 6:30 PM显示数据.如果以一小时为增量存储数据,则无法在时区中向用户提供N 0.5小时差异的请求.
对于每日数字,您需要汇总48个半小时的时段.要挑选的位置将由用户的时区决定.
当您获得年度数据时,它会变得很有趣,因为您最终必须汇总17,520个半小时的桶.为了简化计算,我建议您获得每UTC时间预先汇总的年度数据,并减去一年中4.5小时的第一次汇总数据,并为下一年的前4.5个小时添加汇总数据.这基本上会使全年的工作时间缩短4.5小时,而且工作量并不多.在这里工作,您可以进一步调整系统.
编辑：结果加德满都是格林尼治标准时间5.45,因此您需要将数据存储在15分钟的桶中而不是30分钟的桶中.
编辑2：另一个简单的改进是围绕年度汇总,因此您不必每次添加17,520个桶,而且每个国家/地区不需要一个汇总.汇总了1月02日至12月30日的年度数据.由于任意两个国家/地区之间的最大时区差异为23小时,这意味着您可以获取年度数据(1月2日 – 12月30日)并在之前和之后添加几个桶作为适当的.例如,对于-5 UTC时区,您将在0500之后的1月1日添加所有桶,在12月31日添加所有桶,在次年1月1月添加桶到0500小时.
