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