存储时间序列数据，关系数据还是非关系数据？

我正在创建一个系统，它可以轮询设备的各种指标数据，如CPU利用率，磁盘利用率，温度等。使用SNMP以（大概）5分钟的间隔。最终目标是以时间序列图的形式向系统用户提供可视化。

我过去曾考虑过使用RRDTool，但拒绝了它，因为无限期地存储捕获的数据对我的项目很重要，而且我想要更高级别和更灵活地访问捕获的数据。所以我的问题是：

关系数据库（如MySQL或PostgreSQL）或非关系数据库或NoSQL数据库（如MongoDB或Redis）在查询数据进行绘图时的性能更好。

关系的

给定一个关系数据库，我将使用data_instances表，其中将存储为所有设备测量的每个指标捕获的每个数据实例，包含以下字段：

字段：idfk_to_devicefk_to_metricmetric_valuetimestamp

当我想要为特定设备上的特定指标绘制图形时，我必须查询此单数表过滤掉其他设备，以及为此设备分析的其他指标：

SELECT metric_value, timestamp FROM data_instances
WHERE fk_to_device=1 AND fk_to_metric=2

此表中的行数为：

d * m_d * f * t

其中d是设备的数量，m_d是为所有设备记录的累积指标数量，f是轮询数据的频率，t是系统收集数据的时间的总量。

如果一个用户在一年内每5分钟为3台设备记录10个指标，我们将有不到五百万个记录。

索引

在fk_to_device和fk_to_metric上没有索引的情况下，扫描这个连续扩展的表将花费太多时间。因此，索引上述字段以及timestamp（用于创建具有局部化周期的图）是必需的。

非关系型（NoSQL）

MongoDB具有收集的概念，与表不同的是，它们可以通过编程方式创建，而无需设置。有了这些，我可以为每个设备的数据存储分区，甚至为每个设备记录的每个指标。

我没有使用NoSQL的经验，也不知道它们是否提供任何查询性能增强功能（如索引），但上一段建议在NoSQL下存储数据的结构中执行大部分传统关系查询工作。

未决定

具有正确索引的关系解决方案是否会在一年内变得非常缓慢？或者，NoSQL方法的基于集合的结构（符合我对存储数据的心理模型）是否提供了显著的好处？

69191 次浏览
小开

我经常遇到类似的需求，最近开始使用Zabbix来收集和存储这类数据。Zabbix有自己的绘图功能，但从Zabbix的数据库中提取数据并按照您喜欢的方式进行处理非常容易。如果你还没有看过Zabbix，你可能会发现它值得你花时间去看。

小开

您的表在单个表中有数据。所以关系与非关系不是问题。基本上你需要读取大量的顺序数据。现在，如果你有足够的内存来存储一年的数据，那么没有什么比使用Redis/MongoDB等。

大多数情况下，NoSQL数据库会将您的数据以压缩形式存储在磁盘上的同一位置，以避免多个磁盘访问。

NoSQL的功能与在设备ID和指标ID上创建索引相同，但它有自己的方式。对于数据库，即使您这样做，索引和数据也可能位于不同的位置，并且会有大量的磁盘IO.

像Splunk这样的工具使用NoSQL后端来存储时间序列数据，然后使用Map Reduce来创建聚合（这可能是您以后想要的）。所以在我看来，使用NoSQL是一种选择，因为人们已经在类似的用例中尝试过了。但是一百万行会让数据库爬行吗（也许不会，如果有像样的硬件和适当的配置）？

小开
最佳答案

绝对是关系。无限的灵活性和扩展性。

在概念和应用方面进行两次修正，然后进行一次提升。

更正

  1. 它不是“过滤掉不需要的数据”；它只选择所需的数据。是的，当然，如果您有一个索引来支持WHERE子句中标识的列，则速度非常快，并且查询不依赖于表的大小（从160亿行的表中抓取1，000行是即时的）。

  2. 你的桌子有一个严重的障碍。根据您的描述，实际的PK是（device，metric，datetime）。（请不要称其为时间戳，这意味着其他东西，但这是一个小问题。）行的唯一性由以下内容标识：

       (Device, Metric, DateTime)

    • Id列不执行任何操作，它完全是冗余的。

      • Id列永远不是键（在关系数据库中禁止的重复行必须通过其他方式来防止）。

      • Id列需要额外的索引，这显然会影响INSERT/DELETE的速度，并增加所使用的磁盘空间。

      • 你可以摆脱它。请。

仰角

  1. 现在你已经消除了障碍，你可能还没有认识到它，但你的表是第六范式。非常高的速度，在PK上只有一个索引。为便于理解，请阅读这个答案（从什么是第六范式？标题开始）。

    • （我只有一个索引，而不是三个；在非SQL上，您可能需要三个索引）。

    • 我有完全相同的表（当然，没有Id “ key ”）。我有一个额外的列Server。我远程支持多个客户。

      (Server, Device, Metric, DateTime)

    该表可用于使用完全相同的SQL代码（是的，交换单元格）透视数据（即，Devices穿过顶部，Metrics沿着侧面，或透视）。我使用该表为客户建立了关于其服务器性能的无限种类的图形和图表。

    • 监控统计数据模型.
      （对于内联来说太大了；有些浏览器不能以内联方式加载；单击链接。此外，这是过时的演示版本，由于显而易见的原因，我无法向您展示商业产品DM.

    • 它允许我生成这样的图表，在收到客户的原始监控统计文件后，使用单个SELECT命令进行六次击键。注意混合和匹配；操作系统和服务器在同一图表上；各种枢轴。当然，统计矩阵的数量没有限制，因此图表的数量也没有限制。（在客户允许的情况下使用。）

    • 不熟悉关系数据库建模标准的读者可能会发现IDEF1X符号很有帮助。

还有一件事

最后但并非最不重要的是，SQL是IEC/ISO/ANSI标准。免费软件实际上是非SQL的；如果他们不提供标准，使用术语SQL是欺骗性的。他们可能会提供“额外的”，但他们缺乏基本的。

小开

发现上面的答案很有趣。 试着在这里添加更多的注意事项。

1）数据老化

时间序列管理通常需要创建老化策略。一个典型的场景（例如监控服务器CPU）需要存储：

  • 1秒短时间（例如24小时）的原始样本

  • 5分钟中期（例如1周）的详细骨料样品

  • 1小时详细信息（例如，最长1年）

尽管关系模型确实可以（我的公司为一些拥有数万个数据系列的大型客户实施了大规模集中式数据库）对其进行适当的管理，但新一代数据存储添加了一些有趣的功能，以供探索，例如：

  • 自动清除数据（请参阅Redis的expire命令）

  • 多维聚合（例如Map-Reduce作业A-La-Splunk）

2）实时采集

更重要的是，一些非关系数据存储本质上是分布式的，并且允许更高效的实时（或接近实时）数据收集，这可能是RDBMS的一个问题，因为创建了热点（在插入单个表的同时管理索引）。RDBMS空间中的这个问题通常通过恢复到批量导入过程来解决（我们过去以这种方式管理它），而无SQL技术在大规模实时收集和聚合方面取得了成功（例如，请参阅前面的回复中提到的Splunk）。

小开

我认为这类问题的答案应该主要围绕您的数据库利用存储的方式。 有些数据库服务器使用RAM和磁盘，有些只使用RAM（可选的持久性磁盘），等等。 最常见的SQL数据库解决方案是使用内存+磁盘存储，并在基于行的布局中写入数据（每个插入的原始数据都被写入相同的物理位置）。 对于TimeSeries存储，在大多数情况下，工作负载类似于：相对较低的大量插入间隔，而读取是基于列的（在大多数情况下，您希望从表示度量的特定列读取一系列数据）。

我发现柱状数据库（谷歌一下，你会发现MonetDB，Infobright，ParAccel等）在时间序列方面做得很好。

至于你的问题，我个人认为有些无效（因为所有的讨论都使用了错误术语NoSQL-IMO）： 你可以使用一个数据库服务器，一方面可以谈论SQL，使你的生活非常容易，因为每个人都知道SQL多年，这种语言已经完善了一次又一次的数据查询。但仍然以列式方式利用RAM、CPU缓存和磁盘，使您的解决方案最适合时间序列

小开

创建一个文件，将其命名为1_2.data.weired idea？你会得到什么：

  • 您可以节省高达50%的空间，因为您不需要为每个数据点重复FK_到_设备和FK_到_度量值。
  • 您甚至可以节省更多空间，因为您不需要任何索引。
  • 通过附加数据将（时间戳、指标_值）对保存到文件中，这样您就可以免费获得按时间戳排序。（假设您的源不会为设备发送无序数据）

=>按时间戳查询的运行速度非常快，因为您可以使用二进制搜索在文件中找到要读取的正确位置。

如果你喜欢它，甚至更优化，开始考虑这样分割你的文件。

  • 1_2_2014年1月数据
  • 1_2_2014年2月数据
  • 1_2_2014年3月数据

或者使用http://kx.com中的KDB+，因为它们为您完成了所有这些工作：）面向列可能会对您有所帮助。

有一个基于云的面向列的解决方案弹出，所以你可能想看看：http://timeseries.guru

小开

对于今天的海量数据来说，500万行根本不算什么。预计数据将在短短几个月内达到TB或Pb.在这一点上，RDBMS不能根据任务进行扩展，我们需要NoSQL数据库的线性可伸缩性。对于用于存储数据的列式分区，可以通过添加更多的列和更少的行来提高性能。利用在HBase或MapR_数据库等基础上完成的开放TSDB工作。

小开

您应该查看时间序列数据库。它就是为了这个目的而创建的。

时间序列数据库（TSDB）是为处理时间序列数据（按时间（日期时间或日期时间范围）索引的数字数组）而优化的软件系统。

时间序列数据库_ABC_的常见示例0


提交答案