我们正在考虑建立一个数据仓库系统来加载我们的Web服务器生成的Web访问日志。我们的想法是实时加载数据。
对于用户，我们希望提供数据的折线图，并允许用户使用尺寸向下钻取。
问题是如何平衡和设计系统，以便;
（1）可以获取数据并实时呈现给用户（＆lt; 2秒），
（2）数据可以按小时和每天汇总，并且
（2）因为大量数据仍然可以存储在仓库中，并且
我们当前的数据速率大约是每秒10次访问，这给我们每天大约80万行。我对MySQL的简单测试和一个简单的星型模式表明，当我们有超过800万行时，我的quires开始花费的时间超过2秒。
是否有可能从这样的“简单”数据仓库获得实时查询性能， 并且仍然存储了大量数据（能够从不丢弃任何数据会很好）
有没有办法将数据汇总到更高分辨率的表格中？
我觉得这不是一个新问题（虽然我已经搜索了很多）。也许有人会给像这样的数据仓库解决方案？想到的是Splunk。
也许我抓得太多了。
更新
我的架构看起来像这样;
尺寸：
事实;
答案 0 :(得分：2)
Seth上面的答案是一个非常合理的答案，我相信如果你投资于适当的知识和硬件，它很有可能获得成功。
Mozilla进行了大量的网络服务分析。我们每小时跟踪细节，并使用商业数据库产品Vertica。它对于这种方法非常有效，但由于它是一种专有的商业产品，因此它具有不同的相关成本。
您可能想要调查的另一项技术是MongoDB。它是一个文档存储数据库，具有一些功能，使其可能非常适合此用例。 即，上限集合（搜索mongodb上限集合以获取更多信息）
快速增加操作，例如跟踪页面浏览量，点击量等。 http://blog.mongodb.org/post/171353301/using-mongodb-for-real-time-analytics
答案 1 :(得分：1)
听起来不像是一个问题。 MySQL 非常快。
对于存储日志记录数据，请使用MyISAM表 - 它们更快，非常适合Web服务器日志。 （我认为InnoDB是目前新安装的默认设置 - 日志表不需要外键和InnoDB的所有其他功能）。您也可以考虑使用merge表 - 您可以将各个表保持在可管理的大小，同时仍然可以将它们作为一个大表访问。
如果您仍然无法跟上，那么请按顺序为自己增加内存，更快的磁盘，RAID或更快的系统。
另外：永远不丢弃数据可能是一个坏主意。如果每行大约200字节长，那么您每年至少要谈论50 GB，仅用于原始日志记录数据。如果您有索引，则乘以至少两个。再次乘以（至少）两个用于备份。
如果您愿意，可以保留所有内容，但在我看来，您应该考虑将原始数据存储几周，并将汇总数据存储几年。对于任何旧的，只需存储报告。 （也就是说，除非法律要求你保留。即便如此，它可能不会超过3 - 4年）。
答案 2 :(得分：1)
另外，请查看分区，特别是如果您的查询主要访问最新数据;你可以 - 例如 - 设置每周大约5.5M行的分区。
如果每天和每小时汇总，请考虑使用日期和时间维度 - 您没有列出它们，所以我假设您不使用它们。我们的想法是不要在查询中使用任何函数，例如HOUR（myTimestamp）或DATE（myTimestamp）。日期维度的划分方式应与事实表格相同。
有了这个，查询优化器可以使用分区修剪，因此表的总大小不会像以前一样影响查询响应。
答案 3 :(得分：0)
这已成为一个相当常见的数据仓库应用程序。我运行了多年，每天支持2000万到1亿行，响应时间为0.1秒（来自数据库），超过一秒钟来自Web服务器。这甚至不是在庞大的服务器上。
您的数据量不是太大，所以我认为您不需要非常昂贵的硬件。但是我仍然会使用大量内存的64位多核。
但是你想要主要点击聚合数据而不是详细数据 - 特别是对于数天，数月等的时间序列图表。聚合数据可以通过异步过程在数据库上定期创建，或者在这种情况下如果转换数据的ETL过程创建聚合数据，则通常最有效。请注意，聚合通常只是事实表的分组。
正如其他人所说的那样 - 在访问详细数据时，分区是一个好主意。但这对于汇总数据来说并不那么重要。此外，依赖于预先创建的维度值比在函数或存储过程上更好。这些都是典型的数据仓库策略。
关于数据库 - 如果是我，我会尝试Postgresql而不是MySQL。原因主要是优化器成熟度：postgresql可以更好地处理您可能运行的查询类型。 MySQL更容易在五路连接上混淆，在运行子选择时自下而上等等。如果这个应用程序值得花很多钱，那么我会考虑像db2，oracle，sql server这样的商业数据库。然后，您将获得其他功能，如查询并行性，针对聚合表的自动查询重写，其他优化器复杂性等。