database - 分辨率不同的数据

Question

我有两个表，记录从外部源不断插入到这些表中。可以说，这些表保存着用户交互的统计信息。当用户单击按钮时，该单击的详细信息(用户，单击时间等)将写入表之一。当用户将鼠标悬停在该按钮上时，一条记录及其详细信息会添加到其他表中。

如果有很多用户不断与系统进行交互，那么将生成大量数据，并且这些表将极大地增长。

当我想查看数据时，我想以每小时或每天的分辨率查看它。

有没有一种方法或最佳实践可以按要求的分辨率不断地汇总数据(收集数据时)？

还是有解决此类问题的更好方法？

PS。到目前为止，我发现Talend之类的ETL工具可以使生活变得轻松。

更新:目前我正在使用MySQL，但是我想知道与数据库，环境等无关的最佳实践。

Answer 1

在低延迟数据仓库应用程序上执行此操作的通常方法是拥有一个分区表，该表的前导分区包含可以快速更新的内容(即，无需即时重新计算聚合)，但尾随分区则被聚合回填。换句话说，前导分区可以使用与尾随分区不同的存储方案。

大多数商业和某些开源RDBMS平台(例如PostgreSQL)都可以支持分区表，分区表可用于一种或多种方式。读者将练习如何从日志中填充数据库。

基本上，这种类型的系统的结构如下:

您有一个分区在某些表上的表
日期或日期时间值的种类，
按小时，天或其他方式划分
Cereal 似乎合适。日志
条目将附加到此表中。

随着时间窗口的滑动，
分区，定期作业索引或
总结并将其转换为
其“冻结”状态。例如，一个
Oracle上的作业可能会创建位图
在该分区上建立索引或更新
物化 View 以包含摘要
该分区的数据。

之后，您可以删除旧数据，
汇总或合并分区
一起。

随着时间的流逝，定期工作
回填在前沿之后
划分。历史数据是
转换为可借用的格式
自身进行绩效统计
边查询边查询
分区保持易于更新
很快。由于该分区没有
有这么多的数据，
整个数据集是相对的
快速。

在DBMS平台之间，此过程的确切性质有所不同。

例如，SQL Server上的表分区并不是很好，但是可以使用Analysis Services(Microsoft与SQL Server bundle 在一起的OLAP服务器)来完成。这是通过将前导分区配置为纯ROLAP(OLAP服务器仅对基础数据库发出查询)，然后将尾随分区重建为MOLAP(OLAP服务器构造自己的专用数据结构，包括称为“聚合”的持久性摘要)来完成的。 )。分析服务可以对用户完全透明地执行此操作。它可以在后台重建分区，而旧的ROLAP分区仍对用户可见。构建完成后，它将在分区中交换。该多维数据集始终可用，不会中断对用户的服务。

Oracle允许独立更新分区结构，因此可以构建索引，也可以在物化 View 上构建分区。通过查询重写，Oracle中的查询优化器可以计算出可以从实例化 View 中获得从基本事实表计算出的合计数字。该查询将从具有分区的实例化 View 中读取聚合数据，而从没有分区的前导分区中读取数据。

PostgreSQL也许可以做类似的事情，但是我从来没有考虑过在其上实现这种类型的系统。

如果您可以忍受周期性的中断，那么可以通过汇总并在前导数据和尾随数据上建立 View 来明确地执行类似操作。这允许在不支持透明分区的系统上进行这种类型的分析。但是，在重建 View 时，系统将发生短暂中断，因此您无法在工作时间内真正做到这一点-通常是在一夜之间。

编辑:根据日志文件的格式或可用的日志选项，有多种方法可以将数据加载到系统中。一些选项是:

使用您喜欢的编程语言编写一个脚本，该脚本可读取数据，解析相关位并将其插入数据库。这可能经常运行，但是您必须有某种方式来跟踪文件中的位置。注意锁定，尤其是在Windows上。 Unix / Linux上的默认文件锁定语义允许您执行此操作(这就是tail -f的工作方式)，但是Windows上的默认行为有所不同；两种系统都必须编写为能够很好地相互配合。

在unix-oid系统上，您可以将日志写入管道，并具有与上述从管道读取的过程类似的过程。这将是所有延迟中最低的，但是读取器中的故障可能会阻塞您的应用程序。

为您的应用程序编写一个日志记录接口(interface)，该接口(interface)直接填充数据库，而不是写出日志文件。

对数据库使用批量加载API(大多数(如果不是全部)都具有这种类型的API)，并分批加载日志记录数据。与第一个选项编写类似的程序，但使用批量加载API。但是，与逐行填充相比，这将使用更少的资源，但是设置大容量负载的开销却更大。较不频繁的负载(也许每小时或每天)是合适的，并且对系统的整体施加的压力较小。

在大多数情况下，跟踪您去过的地方成为一个问题。轮询文件以发现更改可能是不可行的，因此您可能需要设置记录器，以使其与日志阅读器配合使用。

一种选择是更改记录器，以便它每隔一段时间(例如每隔几分钟)开始写入另一个文件。让您的日志阅读器定期启动并加载尚未处理的新文件。读取旧文件。为此，文件的命名方案应基于时间，以便读者知道要拾取的文件。处理应用程序仍在使用的文件比较麻烦(然后您需要跟踪已读取的文件数量)，因此您只想读取最后一个文件。

另一个选择是移动文件然后读取它。这在性能与Unix相似的文件系统上最有效，但在NTFS上应该可以工作。您移动文件，然后随意阅读。但是，它要求记录器以创建/追加模式打开文件，写入文件然后关闭文件-而不是保持打开和锁定状态。这绝对是Unix的行为-移动操作必须是原子的。在Windows上，您可能实际上必须站起来记录器才能进行此工作。