Web访问日志的实时数据仓库

听起来不是问题。MySQL 是 非常快。

对于存储日志数据,使用myisam表——它们速度更快,非常适合于Web服务器日志。(我认为InnoDB是这些天新安装的默认设置-对于日志表,不需要使用外键和InnoDB的所有其他功能)。您也可以考虑使用 merge 表-您可以将单个表保持在可管理的大小,同时仍然可以将它们作为一个大表访问。

如果您仍然无法跟上进度,那么请按顺序为您自己增加内存、更快的磁盘、RAID或更快的系统。

另外:永远不要丢弃数据可能是个坏主意。如果每行大约有200字节长,那么您所说的是每年至少50 GB,仅针对原始日志数据。如果有索引,至少乘以2。再乘以(至少)2作为备份。

如果你愿意的话,你可以把它全部保留下来,但我认为你应该考虑将原始数据存储几周,并将聚合数据存储几年。对于任何更旧的内容,只需存储报告。(也就是说,除非法律要求你保持在周围。即使那样,也可能不会超过3-4年)。

赛斯的回答是一个非常合理的答案,我相信如果你在适当的知识和硬件上投资,它将有很高的成功机会。

Mozilla做了很多Web服务分析。我们每小时跟踪细节,并使用商业数据库产品Vertica。对于这种方法,它会很好地工作,但是由于它是一种专有的商业产品,所以它有一组不同的相关成本。

您可能想研究的另一种技术是MongoDB。它是一个文档存储数据库,有一些特性使它可能非常适合这个用例。 即封顶集合(搜索MongoDB封顶集合了解更多信息)

以及快速增量操作,如跟踪页面视图、点击量等。 http://blog.mongodb.org/post/171353301/using-mongodb-for-real-time-analytics

此外,还要研究分区,尤其是当查询大多访问最新数据时;例如,您可以设置大约5.5米行的每周分区。

如果每天和每小时进行聚合,可以考虑使用日期和时间维度——您没有列出它们,所以我假设您没有使用它们。其思想是不要在查询中有任何函数,比如hour(mytimestamp)或date(mytimestamp)。日期维度的分区方式应与事实数据表相同。

有了这个功能,查询优化器就可以使用分区修剪,因此表的总大小不会像以前那样影响查询响应。

这已经成为一个相当常见的数据仓库应用程序。我已经运行了几年,每天支持2000-1亿行,响应时间为0.1秒(从数据库),超过一秒(从Web服务器)。这甚至不在大型服务器上。

您的数据量不太大,所以我认为您不需要非常昂贵的硬件。但我还是会用多核64位内存。

但是,您将希望主要命中聚合数据而不是细节数据,尤其是对于在数天、数月等时间序列图。聚合数据可以通过异步过程定期在数据库上创建,或者在这种情况下,如果转换数据的ETL过程创建聚合数据,则通常效果最好。阿塔。请注意,聚合通常只是事实数据表的分组依据。

正如其他人所说,在访问细节数据时,分区是一个好主意。但对于聚合数据来说,这并不那么重要。此外,对预先创建的维度值的依赖性比对函数或存储过程的依赖性要好得多。这两种策略都是典型的数据仓库策略。

关于数据库-如果是我,我会尝试PostgreSQL而不是MySQL。原因主要是优化器的成熟度:PostgreSQL可以更好地处理您可能运行的查询类型。MySQL更容易在五路连接时混淆,在运行子select时自下而上,等等。如果这个应用程序很值钱,那么我会考虑使用商业数据库,如DB2、Oracle、SQL Server。然后您将获得额外的特性,如查询并行性、针对聚合表的自动查询重写、额外的优化器复杂性等。