时间序列数据的简单存储方法

Question

我每天有大约10亿个活动。我需要将这些事件存储在数据库中长达30天，所以大约有300亿行。

假设是运动员数据库，每行只有4列(运动员姓名、运动员纪律、运动员排名、日期)。我只需要通过运动员的名字和日期来检索数据。例如，为特定运动员建立一个过去30天的图表。

1. 最初我使用的是Google，这是一个很好的工具，非常便宜，每天都是开箱即用，线性可伸缩性，但没有什么缺点。查询30亿表大约需要5秒，对我的情况来说太过分了。当插入数据时，它会出现在“流缓冲区”中，并且不能在一段时间内进行查询(大约5-10分钟)。
2. 另一种方法使用Postgres，并使用适当的索引将所有数据存储在一个表中。此外，我还可以使用每日分片(在一天开始时自动创建新表)，但我担心Postgres能否处理数十亿行。此外，如果我想获得过去30天的历史数据，我必须作出30个选择查询时，切分数据的方式。

我不想费心于过于复杂的解决方案，如卡桑德拉(从来没有尝试过)。另外，我认为我不会从使用面向列的数据库中获得任何好处，因为我只有4列。

寻找类似于大型查询，但没有提到的缺点。我认为数据可以存储在一个节点中。

Answer 1

数据只能使用一个节点存储。实际上，每天10亿行并不多。它只有32K写/秒。相比较而言，阿库穆利可以处理m4.xLargeAWS实例上大约150万个插入/秒的SSD (几乎一半带有默认设置的EBS卷，但您可以提供更多的IOPS)。要存储30B数据点，您将需要少于200 30B的磁盘空间(这取决于您的数据，但可以安全地假设数据点在磁盘上的占用不到5个字节)。

在您的情况下，数据模型很简单。系列名称如下所示：

athlet_rank name=<Name> discipline=<Discipline>

您将能够按名称查询数据：

{
  "select": "athlete_rank",
  "range": { "from": "20170501T000000",
             "to": "20170530T000000" },
  "where": { "name": <Name> }
}

如果你有很大的基数(很多独特的系列)，你不应该选择Akumuli。它每系列消耗大约12 on的RAM，例如，要处理100万系列的数据库，您将需要一个至少16 on的服务器(实际数量取决于系列大小)。这将最终得到改善，但目前这正是我们所拥有的。

免责声明:我是Akumuli的作者，所以我有点偏见。但是我很乐意得到任何反馈，不管是好是坏。