关于如何存储和检索时间序列数据的建议答案

【问题标题】：Suggestions on how to store and retrieve time-series data关于如何存储和检索时间序列数据的建议
【发布时间】：2018-02-15 22:25:11
【问题描述】：

我目前正在开展一个项目，该项目需要我们存储大量时间序列数据，但更重要的是，要快速检索大量数据。

将有 N 个设备 (>10,000) 定期向系统发送数据，假设每 5 秒一次。这些数据会很快建立起来，但我们通常只对最近的数据感兴趣，并希望压缩较旧的数据。我们不想删除它，因为它仍然有用，但不是一天有数千个数据点，我们可能会在 N 天/周/月过去后仅保存 5 或 10 个数据点。

具体来说，我们希望能够在很长一段时间内（比如一两年）获取采样数据。这里可能有数百万个点，但我们只需要一个小的、线性分布的数据样本。

今天我们正在试验 influxdb，它最初似乎是一个不错的解决方案。它足够快，可以让我们以合理的结构存储数据，但我们发现它并不完全令人满意。我们无法执行上述示例查询，总体而言，系统对我们来说还不够成熟。

非常感谢任何有关我们如何进行的建议或替代解决方案。

【问题讨论】：

【解决方案1】：

您可能有兴趣查看 TimescaleDB：

它在 Postgres 之上构建了一个时间序列数据库，因此提供了完整的 SQL 支持，以及 Postgres 生态系统/可靠性。这可以为您提供更大的查询灵活性，这听起来就像您想要的那样。

就您的具体用例而言，确实有两种解决方案。

首先，人们通常会创建两个“超表”，一个用于原始数据，另一个用于采样数据。这些超表在用户看来就像标准表，尽管为了更好的可扩展性而在幕后进行了大量分区（例如，对于大表大小，插入吞吐量是 postgres 的 20 倍）。

然后，您基本上会从原始表汇总到抽样表，并对每个表使用不同的数据保留策略（因此您将原始数据保留 1 个月，将抽样数据保留数年）。

其次，您可以使用单个超表，然后只需安排一个正常的 SQL 查询来从早于某个时间段的数据中删除单个行。

如果后一种方法成为一个足够常见的请求功能，我们甚至可能在未来为它添加更好的一流支持，尽管迄今为止我们遇到的大多数用例似乎更关注#1，尤其是。为了保留有关已删除数据点的统计数据，而不仅仅是直接样本。

（免责声明：我是 TimescaleDB 的作者之一。）

【讨论】：

感谢您的回答。我们确实在 influxdb 中使用了称为保留策略和连续查询的东西。这些连续查询会定期为我们采样数据，但在此期间，表中包含“陈旧”数据。如果我们每周采样，那么我们的数据总是落后 1 周。如果我们每天采样，那么我们总是落后一天，等等。一个要求是始终能够获取绝对最新的数据（采样）。 TimescaleDB 可以做到这一点吗？