在不记录每次点击的情况下，估算每小时URL点击量的聪明方法？

我有一个有数百万网址的网站。每次单击URL时，都会更新与该URL对应的数据库行，指示该单击的时间戳。我希望，使用额外的列，但不需要为每次单击插入不同的行，估计此URL每小时收到的单击数。一些想法包括存储一些时间戳，这些时间戳与最近的秒、分钟、15分钟和小时间隔对齐（但我不清楚这个想法，它实际上是如何得到我们想要的），或者更糟糕的解决方案，将时间增量的“日志”序列化到某种序列化行中

虽然一种简单的方法建议测量当前点击和最后一次点击之间的时间来确定一个速率，但只有在链接以非常一致的速率点击时，才能产生有用的估计。事实上，该链接可能在一分钟内收到一连串的点击，而在另一个20分钟内则一无所获

---

我不想清楚地记录每次单击的原因是，这样数据库就不会因为每小时数千条额外的INSERT语句（以及一个多小时前的相应数据删除）而变得沉重，或者我也不必启动额外的存储系统（tokyo tyrant、Greping apache日志等）记录这些点击。

您是否尝试过其他方法，如外部统计服务？也许是谷歌分析？它可以在不增加服务器负载的情况下为您提供所需的信息。

您有什么理由忽略对apache访问日志的处理吗？它们的优点是由服务器自动添加时间戳并创建，而且重量相当轻。然后，一个相当简单的perl或awk脚本可以保存日志的运行摘要，以便进行简单的解析。

在memcached中存储一个计数器，由URL键控，在DB中存储一个

最后一次计数器重置时间如何

Memcached有一个轻量级的原子
incr
操作。每次请求都打电话。定期重置计数器，更新上次计数器重置时间

---

我不是memcached的老手，但我想有一些方法可以确保所有URL的计数器都保持缓存状态。没有持久性，因此您随时都可能丢失计数器，但偶尔丢失此类数据可能是可以接受的。

首先，为什么要保留时间戳？通过在数据库中为每个URL保留一条记录，并在每次单击时增加一个计数，可以保持精确的计数

即使这样也太多了，我认为下一个最明显的答案是统计抽样。选择一个时间段，比如说十分钟。对于每个10分钟的片段，选择一个URL。计算该URL的单击次数。假设这十分钟的速率是一致的，然后乘以一个常数，得到所需时间段的估计速率。然后在接下来的十分钟里，选择一个不同的URL。等等

实际上，您可以一次计算多个URL，而不会使服务器负担过重，因此您可以选择一些方便的URL数量，十个或一百个，或者您的系统可以处理的任何数量

---

你也要考虑一天的时间。如果您的大多数用户都在加利福尼亚州，那么在太平洋时间下午4:00采样的URL可能会比在凌晨4:00采样的URL获得更高的点击率。因此，您希望以一种确保当您返回到给定URL时，它与您第一次对其进行采样时处于不同的时间的方式在URL之间循环。如果你的用户平均分布在全世界，这不是问题，但听起来不太可能。

这可能不是一个实际的解决方案，但既然你要求一个“聪明”的方法，那么这是一个关于一个问题的学术研究，这个问题不完全是你的问题，但可能是可以修改的。“被引用者”名单中的一些论文可能更接近

如果您想要精确计数，Redis非常适合此任务。它的速度与memcached大致相当，但提供了持久性。持久性基于分叉和顺序写入磁盘，因此它避免了将此类信息保留在数据库中的高io负载

如果您想要一种非常简单的方法：只需以无偏见的方式丢弃样本（即，如果rand（1）<0.1对10%的流量进行采样，则记录请求（foo））。如果访问的URL小于子采样的比率，则会丢失任何信号，但是如果您主要对高度访问的URL感兴趣，那么这可能非常简单和高效

在上面的方案中有更复杂的变化，你用一个概率更新计数器，这个概率随着计数的增长而变化（然后在读取计数器时通过概率函数适当地加权计数器），这是一种非标准化的重要性抽样形式。这些方法几乎同样简单，可以更好地保留分布尾部的计数

• 编辑：

啊，对不起，我现在从评论中看到，你在一段时间内都在追求价格。我使用的方法基本上与采样/计数器相同，只需将单个计数器存储一段时间（即每小时一次）。为了保存长期存档，可以在批处理作业从细粒度（每小时）表填充的较长时间段（每天、每周）中使用附加的汇总表，以便从细粒度表中删除旧数据

---

RRDTool是这个想法的一个更通用的实现，几个OSS监控解决方案都使用它。

我想我必须看看他们是否有API（当然我们已经在他们身上了，他们的脚本像泥浆一样减慢了我们的网站速度）是的，谷歌的API将非常直接地提供这一点。尽管我被告知他们在过去的一个小时里滞后太多，无法得到一个合适的数字。而且……我不得不使用chartbeat，而不是复杂的是，他们分布在多个应用程序中