Java 在MySQL中维护来自大型连续数据源的预处理数据

我目前正在开发一个分析工具，每天晚上（使用Java程序）都会将巨大的事件日志（每个日志大约1 GB）解析到MySQL数据库中——每个事件大约有40个属性。事件日志被“原始”解析到数据库

应用程序的用户需要根据对日志数据的复杂计算查看不同的图形和图表。为了让用户不必等待几分钟来完成图表请求，我们需要以某种方式存储预处理的数据，以便为用户显示（用户可以按日期、单位等进行过滤，但计算的最大部分可以提前完成）。我的问题是如何维护这些预处理的数据——目前，所有计算都用SQL表示，因为我们认为这是最有效的方法（这是正确的假设吗？）。我们需要能够轻松扩展新图表的新计算、客户特定愿望等

我突然想到了某种物化视图，但MySQL似乎不支持此功能。类似地，我们可以在每晚导入事件日志后执行SQL计算，但通过这种方式，每个计算/预处理数据表都需要知道它处理了哪些事件，哪些没有。该表将包含长达一年的数据（即事件），因此简单地截断该表并再次进行所有计算似乎不是解决方案？使用触发器似乎也不正确，因为一些计算需要考虑，例如特定事件之间的时差（

）。 我很难权衡可能的解决方案的利弊。

MySQL不直接支持“物化视图”。“Summary Tables”是在这种上下文中的另一个名称。是的，这就是要使用的技术。您必须自己创建和维护汇总表。它们将在您将数据插入“事实”表时更新，或通过cron作业定期更新，或仅在上传夜间转储后更新

这些细节远远超出了本论坛的范围，而最适合您的具体技术涉及许多问题。我在三个博客中介绍了大部分内容：，和。如果您有更进一步、更具体的问题，请打开一个新问题，我将根据需要深入了解更多细节

我在几个项目中都做过这样的工作；通常性能是读取事实表的10倍；在一个极端情况下，它是1000倍。我总是从汇总表中得到用户界面友好的“报告”

在某些情况下，实际上最好是构建汇总表，而不是将事实行保存在表中。或者，您可以简单地保留源文件，以防需要重新处理它。不构建事实表将更快地向最终用户获取摘要信息

如果要收集一年的数据，然后清除“旧”数据，请参阅。我经常在事实表上使用它，但很少觉得有必要在摘要表上使用它，因为摘要表要小得多（也就是说，没有填满磁盘）

一个用例每小时有1GB转储。一个perl脚本在不到10分钟的时间内将数据移动到一个事实表，再加上增加的7个摘要表。该系统也被复制，这增加了一些额外的挑战。因此，我可以有把握地说，每天1GB不是问题