Question

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

让我们说它是运动员数据库，每排只有4列（运动员姓名，运动员纪律，运动员等级，日期）。我只需要按运动员姓名和日期检索数据。例如，为特定运动员建立过去30天的图表。

最初我使用的是Google Big Query，这是一个很棒的工具，非常便宜，每日开箱即用，线性可扩展性但缺点很少。查询3亿桌面大约需要5秒钟，对我来说太多了。当插入数据时，它出现在＆＃34; Streaming buffer＆＃34;并且无法查询一段时间（约5-10分钟）
另一种方法是使用Postgres并使用适当的索引将所有数据存储在一个表中。此外，我可以使用每日分片（在一天开始时自动创建新表）但我担心Postgres是否可以处理十亿行。此外，如果我想获取最近30天的历史数据，我必须以这种方式对数据进行分片时进行30次SELECT查询。

我不想打扰像Cassandra这样过于复杂的解决方案（尽管从未尝试过）。此外，我不认为我将从使用面向列的数据库中获益，因为我只有4列。

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

Answer 1

只能使用一个节点存储数据。实际上，每天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的作者，所以我有点偏颇。但我很乐意得到任何反馈，无论好坏。

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

1 个答案: