使用 RDBMS 查询数十 TB 的时间序列数据?

Mar*_*tin 6 performance database-recommendation database-size

我偶然发现了一个关于 SO的算法/数据结构问题,我将简短引用:

(...) 关于用于索引时间序列的最佳数据结构的意见(又名列数据,又名扁平线性)。

需要的查询:

All values in the time range [t0,t1]

All values in the time range [t0,t1] that are greater/less than v0

All values in the time range [t0,t1] that are in the value range[v0,v1]
Run Code Online (Sandbox Code Playgroud)

数据集由汇总的时间序列组成 (...) 所讨论的数据集大小约为 15-20TB,因此以分布式方式进行处理 - 因为上述某些查询将产生数据集大于任何一个系统上可用的物理内存量。

在这种情况下,分布式处理还意味着将所需的数据特定计算与时间序列查询一起分派,以便计算可以尽可能靠近数据发生 - 从而减少节点到节点的通信(有点类似于 map/减少范式)-简而言之,计算和数据的接近度非常关键。

我很容易承认这种规模的问题超出了我的头脑,但是我的第一个预感(即使提到了数据大小)考虑到这个问题,我会问他们是否检查了大型 RDBMS(好吧,我猜是 Oracle ,或 Oracle,对吗?)可以以理智的方式处理这个问题。

所以这里的问题是:今天,(企业?)RDBMS 能否以可接受的性能与“手工编码”解决方案处理此类问题。

注意:希望这不是太模糊,并随时根据需要重新标记:-)

Rem*_*anu 1

从一个角度回答这个问题:SQL Server 2012列存储可以轻松处理这个问题。我已经看到它的工作原理,一旦分段消除和批处理启动,这些 TB 就会减少到很少的实际 IO,结果会在几毫秒内发生变化(即,大多数数据会被预先消除,并且根本不需要扫描 100 秒) TB)。您询问的查询正是存储的设计目的。这是一种非常高效的存储/处理范例,甚至不需要分布式计算,即使是数百 TB 的数据