我正在创建一个系统，该系统使用SNMP（可能）每5分钟间隔以不同的指标（例如CPU使用率，磁盘使用率，温度等）轮询设备以获取数据。最终目标是以时间序列图的形式向系统用户提供可视化效果。

过去，我曾研究过使用RRDTool，但由于它无限期地存储捕获的数据对我的项目很重要，因此拒绝了它，并且我希望对捕获的数据进行更高级别和更灵活的访问。所以我的问题是真的：

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

关系型

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

领域： id fk_to_device fk_to_metric metric_value timestamp

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

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个指标，那么我们的记录将不足500万条。

指标

如果没有索引fk_to_device并且无法fk_to_metric扫描此不断扩展的表，则将花费太多时间。因此，索引上述字段以及timestamp（用于创建具有局部时间段的图形）都必须是索引。

非关系（NoSQL）

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

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

未定

具有正确索引的关系解决方案会在一年之内减少吗？还是NoSQL方法的基于集合的结构（与我对存储数据的思维模型匹配）提供了明显的好处？

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

在概念和应用上都进行了两次更正，然后进行了标高。

更正

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

2. 您的餐桌有一个严重的障碍。根据您的描述，实际的PK是（设备，指标，日期时间）。（请不要将其称为TimeStamp，这意味着其他事情，但这是一个小问题。）该行的唯一性由以下方式标识：

      (Device, Metric, DateTime)
   

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

     • 一个Id列是从未一个密钥（重复的行，这是禁止的在关系数据库中，必须通过其它方式来防止）。

     • 该Id列需要附加索引，这显然会阻碍的速度INSERT/DELETE，并增加所使用的磁盘空间。

     • 您可以摆脱它。请。

海拔

1. 现在，您已经消除了障碍，您可能还没有意识到，但是您的表格处于第六范式。极高的速度，PK上只有一个索引。为了理解，请从什么是第六范式阅读此答案？前进。

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

   • 我有完全相同的表（Id当然没有“键”）。我还有一个专栏Server。我支持多个客户。

     (Server, Device, Metric, DateTime)

   该表可用于使用完全相同的SQL代码（是的，切换单元格）来旋转数据（即，Devices越过顶部和Metrics底部或旋转）。我使用该表来建立各种图形和图表，以使客户重新了解其服务器性能。

   • 监视统计数据模型。
     （对于内联太大，某些浏览器无法内联加载；请单击链接。这也是已过时的演示版本，出于明显的原因，我无法向您展示商业产品DM。）

   • 它使我能够使用一个SELECT命令从客户接收到原始的监视统计信息文件后，生成这样的Charts（六个击键）。注意混合搭配；操作系统和服务器在同一图表上；各种枢轴。当然，统计矩阵的数量没有限制，因此图表也没有限制。（经客户同意后使用。）

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

还有一件事

最后但并非最不重要的一点是，SQL是IEC / ISO / ANSI标准。该免费软件实际上是Non-SQL。如果SQL不提供标准，则使用术语SQL是欺诈性的。他们可能会提供“额外费用”，但缺少基础知识。

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

1）数据老化

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

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

• 中等时间（例如1周）的5分钟详细汇总样本

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

尽管关系模型可以确保（我的公司为具有数以万计的数据系列的一些大客户实现了大规模的集中式数据库）进行适当的管理，但是新的数据存储种类增加了有趣的功能，例如：

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

• 多维聚合（例如，地图缩减作业-杂音）

2）实时采集

更重要的是，某些非关系数据存储是固有分布的，并允许更高效的实时（或近实时）数据收集，这可能是RDBMS的问题，因为会创建热点（在插入时管理索引）一张桌子）。RDBMS空间中的此问题通常可以通过恢复为批处理导入过程来解决（我们过去以这种方式进行管理），而无SQL技术已成功进行了大规模的实时收集和聚合（例如，请参见先前答复中提到的Splunk） 。

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

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

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

诸如Splunk之类的工具正在使用NoSQL后端来存储时间序列数据，然后使用map reduce来创建聚合（这可能是您以后想要的）。因此，我认为使用NoSQL是一种选择，因为人们已经在类似的用例中尝试过使用NoSQL。但是一百万行将使数据库进行爬网（如果不是这样的话，那么要有适当的硬件和适当的配置）。

创建一个文件，将其命名为1_2.data。奇怪的主意？你得到什么：

• 您节省了多达50％的空间，因为您无需为每个数据点重复fk_to_device和fk_to_metric值。
• 因为不需要任何索引，所以可以节省更多空间。
• 通过附加数据，将（timestamp，metric_value）对保存到文件中，这样您就可以免费获得时间戳的订单。（假设您的来源没有发送设备的乱序数据）

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

如果您更喜欢优化，请开始考虑像这样拆分文件；

• 1_2_january2014.data
• 1_2_february2014.data
• 1_2_march2014.data

或使用http://kx.com上的 kdb +，因为它们可以为您完成所有这些操作：）面向列的内容可能会对您有所帮助。

弹出一个基于云的面向列的解决方案，因此您可能需要看看：http : //timeseries.guru

如果您正在寻找GPL软件包，那么RRDTool是一个不错的选择。这是用于存储，提取和绘制时序数据的好工具。您的用例看起来完全像时间序列数据。

这是我们在ApiAxle中必须解决的问题。我们撰写了一篇关于如何使用Redis 的博客文章。它已经存在了很长时间，但是事实证明它是有效的。

我也将RRDTool用于另一个出色的项目。

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

我发现列式数据库（在Google上，您会发现MonetDB，InfoBright，parAccel等）在时间序列方面做得很棒。

至于您的问题，我个人认为这是无效的（因为所有讨论都使用故障术语NoSQL-IMO）：您可以使用一方面可以使用SQL的数据库服务器，因为每个人都知道SQL，因此您的生活非常轻松多年以来，这种语言已经为数据查询而不断完善。但仍以面向列的方式利用RAM，CPU缓存和磁盘，使您的解决方案最适合时间序列

500万行对于今天的洪流数据而言已经一无是处。预计在短短几个月内数据就会在TB或PB中。此时，RDBMS不能扩展到该任务，因此我们需要NoSql数据库的线性可伸缩性。通过使用用于存储数据的列分区，可以增加性能，增加更多的列和更少的行这种概念可以提高性能。利用在HBASE或MapR_DB等之上完成的Open TSDB工作。

我经常面临类似的要求，并且最近开始使用Zabbix来收集和存储此类数据。Zabbix拥有自己的图形绘制功能，但是很容易从Zabbix的数据库中提取数据并按需要进行处理。如果您尚未签出Zabbix，那么您可能会发现值得这样做。

您应该查看时间序列数据库。为此创建的。

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

时间序列数据库InfluxDB的流行示例