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

Question

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

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

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

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

Answer 1

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

此类的详细信息远远超出本论坛的范围，最适合您的具体技术涉及许多问题。我在三个博客中介绍了大部分内容：DW、Summary Tables 和 High speed ingestion。如果您还有其他更具体的问题，请打开一个新问题，我会根据需要深入研究更多细节。

我在几个项目中都这样做过；通常性能比读取 Fact 表好 10 倍；在一种极端情况下，它是 1000 倍。我总是以来自汇总表的 UI 友好的“报告”告终。

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

如果您要收集一年的数据，然后清除“旧”数据，请参阅my blog on partitioning。我经常在 Fact 表上使用它，但很少觉得需要在 Summary 表上，因为 Summary 表要小得多（也就是说，不会填满磁盘）。

一个用例每小时有一个 1GB 的转储。一个 perl 脚本在不到 10 分钟的时间内将数据移动到一个 Fact 表中，并增加了 7 个汇总表。该系统也被复制，这增加了一些额外的挑战。所以，我可以肯定地说，天 1GB 不是问题。