我目前正在开发一种分析工具，每天晚上（使用Java程序）将大量事件日志（每个大约1 GB）分析到MySQL数据库 - 对于每个事件，大约有40个属性。事件日志被解析＆＃34; raw＆＃34;到数据库。
应用程序的用户需要根据日志数据的复杂计算查看不同的图形和图表。为了让用户不要等待几分钟来完成图表请求，我们需要以某种方式存储预处理数据，以便为用户显示（用户可以按日期，单位等进行过滤，但最大的部分是计算可以事先完成）。我的问题是关于如何维护这样的预处理数据 - 目前，所有计算都用SQL表示，因为我们假设这是最有效的方法（这是一个正确的假设吗？）。我们需要能够通过新图表的新计算，客户特定的愿望等轻松扩展。
某种物化视图在我脑海中浮现，但MySQL似乎并不支持这一功能。同样，我们可以在导入事件日志后每晚执行SQL计算，但这样每个计算/预处理数据表都需要知道它已经处理了哪些事件以及它没有处理过哪些事件。该表将包含长达一年的数据（即事件），因此简单地截断表并再次进行所有计算似乎不是解决方案？使用触发器似乎也不正确，因为有些计算需要考虑例如特定种类事件之间的时间差异？
我很难权衡可能解决方案的利弊。
答案 0 :(得分：0)
MySQL不直接支持“物化视图”。在此上下文中，“摘要表”是他们的另一个名称。是的，这是使用的技术。您必须自己创建和维护摘要表。当您将数据插入“Fact”表时，或者定期通过cron作业，或者只是在上传每晚转储后，它们都会更新。
此类论坛的详细信息远不止在本论坛中列出，最适合您的具体技巧涉及许多问题。我在三个博客中介绍了大部分内容：DW，Summary Tables和High speed ingestion。如果您有更具体的问题，请打开一个新的问题，我会根据需要深入了解更多细节。
我在几个项目中做过这样的事情;通常表现比阅读Fact表好10倍;在一个极端情况下，它是1000倍。我总是最终得到来自摘要表的UI友好“报告”。
在某些情况下，实际上最好不要构建摘要表，也不要将Fact行保存在表中。或者，您可以简单地保留源文件以防需要重新处理它。不构建Fact表将更快地向最终用户提供摘要信息。
如果您要收集一年的数据，然后清除“旧”数据，请参阅my blog on partitioning。我经常在Fact表上使用它，但很少在Summary Table上感觉到需要，因为Summary表要小得多（即不填满磁盘）。
一个用例每小时有1GB转储。 perl脚本在不到10分钟的时间内将数据移动到Fact表，再加上增强的7个Summary Tables。该系统也被复制，增加了一些额外的挑战。所以，我可以肯定地说1GB 天不是问题。