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

我每天有大约10亿次事件。我需要将这些事件存储在过去30天的数据库中，因此大约有300亿行。存储时间序列数据的简单方法

假设它是运动员数据库，每排只有4列（运动员名字，运动员纪律，运动员等级，日期）。我只需要通过运动员姓名和日期来检索数据。例如，为特定运动员制作过去30天的图形。

起初我用谷歌大查询，这是伟大的工具，非常便宜，每天分片开箱和线性可扩展性，但具有一些缺点。查询30亿张桌子大概需要5秒，对我来说太多了。当插入数据时，它会出现在“数据流缓冲区”中，并且无法查询一段时间（大约5-10分钟）
另一种方法使用Postgres并将所有数据存储在具有适当索引的一个表中。此外，我可以使用每日分片（在一天开始时自动创建新表）但我担心Postgres是否可以处理数十亿行。另外，如果我想获取最近30天的历史数据，那么在以这种方式对数据进行分片时，必须进行30次SELECT查询。

我不想打扰像Cassandra这样的过于复杂的解决方案（尽管从来没有尝试过）。另外我不认为我会从使用面向列的数据库中获得任何好处，因为我只有4列。

寻找类似于Big Query的东西，但没有提到缺点。我认为数据可以存储在一个节点中。

来源

2017-06-18 user12384512

您不需要30次选择查询最近30天。如果查询总是30天，那么无论如何您都不需要进行分区。在这种情况下唯一的优点是可以用一个简单的“drop table”丢弃前一天。我不确定你了解Postgresql的分区。 –

最好的解决方案取决于完整的情况和确切的要求。每日分区*可能会有用。 –

@ClodoaldoNeto我的意思是30个选择查询，当我没有分区手动创建表。我需要查询1到30天的范围。 – user12384512

只能使用一个节点存储数据。实际上，每天10亿行并不多。它只有大约32K次写入/秒。为进行比较，Akumuli可以在具有SSD的m4.xlarge AWS实例上处理大约150万次插入/秒（几乎是使用默认设置的EBS卷的一半，但您可以提供更多IOPS）。要存储30B数据点，您将需要少于200GB的磁盘空间（这取决于您的数据，但假设数据点在磁盘上的占用少于5个字节是安全的）。

数据模型在你的情况下很简单。该系列的名称应该是这样的：

athlet_rank name=<Name> discipline=<Discipline>

您可以通过名称来查询数据：

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

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

声明：我是Akumuli的作者，所以我有点偏见。但我很乐意获得任何反馈，无论好坏。

来源

2017-06-19 14:31:32 Lazin

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

回答

相关问题