我正试图从理论上解决一个用于数据聚合和存储的NxN问题。举个例子,我有大量通过流输入的数据。流以点发送数据。每一点有5个维度:
然后,需要对这些数据进行聚合和存储,以便允许另一个用户来查询数据的位置和时间。用户应该能够像下面这样进行查询(伪代码):
向我显示位置1,2,3,4,....N在2011年1月1日至2011年3月1日上午11时至下午4时之间的汇总统计数据
不幸的是,由于数据的规模,不可能将所有这些数据从动态点进行聚合,因此需要在此之前进行聚合。正如您所看到的,尽管有多个维度可以对数据进行聚合。
他们可以查询任意天数或位置,因此要找到所有的组合需要大量的预聚合:
在查询之前对所有这些组合进行预处理可能会导致不可行的处理量。如果我们有200个不同的位置,那么我们就有2^200个组合,这几乎不可能在任何合理的时间内预先计算。
我确实考虑过在一维上创建记录,然后在请求时可以动态地进行合并,但这也需要一定的时间。
问题:
谢谢您抽时间见我。
编辑1
当我说将数据聚合在一起时,我指的是将其他维度的统计数据和名称(维度4和5)组合起来。因此,例如,如果我请求位置1,2,3,4.N的数据,那么在向用户服务之前,我必须将这些N个位置的统计数据和名称计数合并在一起。
同样,如果我请求日期为01/01/2015 - 01/12/2015的数据,则必须在这些期间之间汇总所有数据(通过添加求和名称/统计数据)。
最后,如果我要求在01/01/2015 - 01/12/2015之间提供地点1、2、3、4.N之间的数据,那么我必须汇总所有这些地点之间的所有数据。
为了这个例子,让我们说,通过统计数据需要某种类型的嵌套循环,并且不能很好地扩展,特别是在动态过程中。
发布于 2015-10-05 14:09:17
去正规化是解决关系数据库中性能或可伸缩性问题的一种方法。
海事组织有一些新的表格来保存汇总数据并将其用于报告,这将对你有所帮助。
我有大量的数据是通过流输入的。流以点发送数据。
在这种情况下,实现非正规化的方法有多种:
在一个理想的场景中,当一条消息到达流级时,将有两个包含location, date, time, name, statistics
维度的数据消息副本,被分派用于处理,一个用于OLTP(当前应用程序逻辑),另一个用于OLAP(BI)进程。
BI流程将创建用于报告的非规范化聚合结构。
我建议每个位置、日期组都有汇总数据记录。
因此,最终用户将查询预先处理的数据,这些数据不需要进行大量的重新计算,有一些可接受的不精确性。
考虑到用户同样可能对所有维度进行查询,我应该如何选择正确的维度和/或维度组合?
这将取决于您的应用程序逻辑。如果可能的话,限制用户可以为用户分配值的预定义查询(如01/01/2015至01/12/2015之间的日期)。在更复杂的系统中,使用BI仓库之上的报表生成器将是一种选择。
发布于 2015-09-30 09:33:57
试试时间序列数据库!
从您的描述来看,您的数据似乎是一个时间序列数据集。用户似乎主要关注查询的时间,在选择时间框架后,用户将通过附加条件来细化结果。
考虑到这一点,我建议您尝试一个时间序列数据库,如InfluxDB或OpenTSD。例如,流提供了一种查询语言,它能够处理类似以下的查询,这非常接近于您试图实现的目标:
SELECT count(location) FROM events
WHERE time > '2013-08-12 22:32:01.232' AND time < '2013-08-13'
GROUP BY time(10m);
我不知道你所说的规模是什么意思,但是时间序列DBs被设计成对许多数据点来说是快速的。我建议在推出你自己的解决方案之前,一定要试一试!
发布于 2015-10-06 06:43:23
您至少可以将日期和时间减少到单个维度,并根据最小粒度(例如1秒或1分钟的分辨率)对数据进行预聚合。为了相同的分辨率,缓存和块输入流可能很有用,例如,每秒钟都将总计添加到数据存储中,而不是对每一点进行更新。
名称和位置域变化的大小和相似程度是什么?他们之间有什么关系吗?你说过地点可能多达200个。我在想,如果名称是一个很小的集合,并且不太可能改变,那么您可以在单个记录中保存每个名称列中的名称计数,从而将表的规模降低到每一单位时间的每个位置1行。
https://stackoverflow.com/questions/32773055
复制相似问题