Question

我正在寻找一个包含大量，大部分不可压缩的时间序列数据的项目，并想知道带有原始SQL的Django + Postgres是否是正确的调用。

我的时间序列数据是每小时约2K对象/小时。这是我每年存储的大约200万行，我想1）能够通过连接切片数据进行分析，2）能够在网上进行基本概览工作，由Django提供服务。我认为最好的想法是将Django用于对象本身，但是使用原始SQL来处理与之关联的大型时间序列数据。我认为这是一种混合方式;这可能是一个红旗，但使用完整的ORM进行一系列的数据样本感觉就像是过度杀伤。还有更好的方法吗？

Answer 1

如果我理解你的想法，你正在考虑将时间序列存储在PostgreSQL中，一个时间序列记录存储在一个数据库行中。别这么做。

一方面，问题是理论上的。关系数据库（我认为大多数数据库）都基于行独立性的前提，而时间序列的记录是物理排序的。当然，数据库索引为数据库表提供了一些顺序，但该顺序旨在加快搜索或按字母顺序或以其他顺序显示结果;它并不意味着该命令具有任何自然意义。无论您如何订购，每个客户都独立于其他客户，每个客户的购买都独立于其他购买，即使您可以按时间顺序获取它们以形成客户的购买历史记录。时间序列记录的相互依赖性要强得多，这使得关系数据库不合适。

实际上，这意味着表占用的磁盘空间及其索引将是巨大的（可能比在文件中存储时间序列大20倍），并且从数据库读取时间序列将非常慢，某些东西比存储在文件中慢一个数量级。它也不会给你任何重要的好处。您可能无法进行查询＆＃34;给我所有时间序列记录，其值大于X＆＃34;。如果您需要这样的查询，您还需要进行其他分析，而这些分析是关系数据库未设计执行的，因此您无论如何都会将整个时间序列读入某个对象。

因此每个时间序列都应存储为文件。它可能是文件系统上的文件，也可能是数据库中的blob。尽管事实上我implemented the latter，但我相信前者更好;在Django，我写了这样的东西：

class Timeseries(models.model):
    name = models.CharField(max_length=50)
    time_step = models.ForeignKey(...)
    other_metadata = models.Whatever(...)
    data = models.FileField(...)

使用FileField将使您的数据库更小，并使您可以更轻松地对系统进行增量备份。通过在文件中搜索来获取切片也会更容易，这可能是一个blob可能不可能或困难的事情。

现在，什么样的文件？我建议你去看看大熊猫。它是一个用于数学分析的python库，支持时间序列，它还应该有一种方法将时间序列存储在文件中。

我上面链接到我不建议你使用的我的图书馆;一方面它不能做你想做的事情（它不能处理比一分钟更精细的粒度，还有其他缺点），另一方面它已经过时了 - 我之前写过它大熊猫，我打算将它转换成将来使用熊猫。大熊猫的作者有一本书，＃34; Python用于数据分析＆＃34;，我发现它非常宝贵。

更新：还有InfluxDB。从来没有使用它，因此我没有意见，但如果你想知道如何存储时间序列，你肯定需要检查它。

Answer 2

时间序列数据库似乎是不断重新发明的事情之一，如上所述，关系数据库并不适合。

我所做的是将Django与InfluxDB结合起来，{{3}}是为时间序列数据而构建的。这很棒，使用python客户端库可以使用pandas数据帧。这意味着您既可以使用InfluxDB查询语言就地使用数据，也可以将所有数据（聚合，如果需要）用于python中的分析。我的应用程序正在处理与您需要的数量相似的数据流。

我根据需要将InfluxDB系列名称与django app / model / primary key相关联。时间序列数据在关联的InfluxDB系列中，杂项缓慢变化或关系数据进入django ORM字段。

Answer 3

听起来你想要调查timescale。我自己还没有使用它，但它显然是PostgreSQL的扩展，所以我假设完全支持Django并按照他们的说法进行处理

每秒100K行和数百万个度量标准，即使在单个节点上有1000亿行。

Answer 4

您也可以考虑使用PostGIS postgres扩展，其中包括对栅格数据类型（基本上是大型数字网格）的支持，并且具有许多可以使用它们的功能。

但是，在这种情况下不要使用ORM，您将希望直接在服务器上执行SQL。 ORM将为大型数值数据集增加大量开销。它也不太适合在python本身中处理大型矩阵，因为你需要numpy。

Django + Postgres +大型时间序列

4 个答案: