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

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

过去我使用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是所有设备logging的累计度量数 ， f是数据被轮询的频率 ， t是系统已经收集数据的总时间 。

对于每5分钟logging一次3个设备的10个指标的用户，我们只有不到500万条logging。

索引

没有fk_to_device和fk_to_metric扫描的索引，这个不断扩展的表将花费太多时间。 因此索引上述字段和timestamp （用于创build具有本地化时间段的图）是一项要求。

非关系（NoSQL）

MongoDB具有集合的概念，与表格不同，这些可以在没有设置的情况下以编程方式创build。 有了这些，我可以将每个设备的数据存储分区，甚至每个设备的每个数据分区。

我对NoSQL没有经验，也不知道他们是否提供了任何查询性能增强function，如索引，但是前面的段落提出了在NoSQL中存储数据的结构中执行大部分传统的关系查询工作。

未定

具有正确索引的关系解决scheme是否会在一年内减less爬行？ 还是NoSQL的基于集合的结构方法（与我存储的数据的心智模型相匹配）提供了明显的好处？

Answer 1

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

两个更正，无论是在概念和应用程序，其次是一个海拔。

1. 这不是“过滤不需要的数据”; 它只是select所需的数据 。 是的，当然，如果你有一个支持WHERE子句中标识的列的索引，它是非常快的，查询不取决于表的大小（从一个160亿行表中抓取1000行是瞬间的） 。

2. 你的桌子有一个严重的障碍。 鉴于你的描述，实际的PK是（设备，度量，date时间）。 （请不要把它称为TimeStamp，这意味着别的，但这是一个小问题。） Id列是完全和完全多余的。 该行的唯一性由以下标识：

     `(Device, Metric, DateTime)` 

   Id列什么也不做，这是多余的（不是多余的）。 额外的支持Id列的索引明显地阻碍了INSERT的速度，并且增加了使用的磁盘空间，你可以摆脱它。

3. 现在，你已经消除了障碍，你可能没有认出来，但你的桌子是在第六范式。 非常高的速度，在PK上只有一个索引。 为了理解，请阅读“ 第六范式”中的 这个答案 。 向前。

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

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

     `(Server, Device, Metric, DateTime)` 

   该表可用于使用完全相同的SQL代码（是，切换单元格）将数据（即顶部和Metrics下的Devices或透视）数据透视。 我使用该表为客户build立了无限多种图表和图表，以便他们的服务器性能。

   • 监视统计数据模型 。
     （内联太大，有些浏览器无法加载内联，点击链接，也是过时的演示版，原因很明显，我不能向您展示商业产品DM。）

   • 它允许我使用一个SELECT命令在收到来自客户的原始监视统计文件后，生成这样的图表 ，六个按键。 注意混搭; 操作系统和服务器在同一张图上; 各种枢轴。 当然，统计matrix的数量没有限制，因此也没有限制。 （与客户的许可使用）

   • 对“关系数据库build模标准”不熟悉的读者可能会发现IDEF1X Notation有帮助。

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

Answer 2

发现上面的答案很有意思。 试图在这里添加更多的考虑事项。

1）数据老化

时间序列pipe理通常需要制定老化政策。 典型的场景（例如监控服务器CPU）需要存储：

• 短时间内1秒的原始样品（如24小时）

• 中期（例如1周）的5分钟细节总量样品

• 1小时的细节（例如，最多1年）

尽pipe关系模型可以确保（我的公司为一些拥有数以万计的数据系列的大客户实施了大规模的集中式数据库）进行适当的pipe理，但新一代数据存储增加了一些有趣的function，如：

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

• 多维聚合（例如map-reduce作业a-la-Splunk）

2）实时收集

更重要的是，一些非关系数据存储本质上是分布式的，并且允许更有效的实时（或接近实时）的数据收集，这可能成为RDBMS的问题，因为创build了热点（在插入时pipe理索引一张桌子）。 在RDBMS空间中的这个问题通常被解决，回到批量导入程序（我们过去是这样pipe理的），而没有sql技术成功地进行了大量的实时收集和聚合（参见前面的回复中提到的Splunk） 。

Answer 3

你的表有单个表中的数据。 所以关系与非关系不是问题。 基本上你需要阅读大量的连续数据。 现在，如果你有足够的内存来存储一年的数据，那么就不会像使用Redis / MongoDB等

大多数NoSQL数据库将您的数据存储在磁盘上的同一位置和压缩forms，以避免多个磁盘访问。

NoSQL与在设备ID和度量标识上创build索引的做法是一样的，但是以它自己的方式。 有了数据库，即使你这样做了索引和数据可能会在不同的地方，会有很多的磁盘IO。

像Splunk这样的工具正在使用NoSQL后端来存储时间序列数据，然后使用map reduce来创build聚合（这可能是您以后想要的）。 所以在我看来，使用NoSQL是一种select，因为人们已经尝试过使用类似的用例。 但是，一百万行将使数据库爬行（可能不是，具有体面的硬件和适当的configuration）。

Answer 4

如果你正在看GPL包， RRDTool是一个很好的看看。 这是存储，提取和绘制时间序列数据的好工具。 您的用例与时间序列数据非常相似。

Answer 5

创build一个文件，将其命名为1_2.data。 我们的想法？ 你得到什么：

• 您最多可节省50％的空间，因为您无需为每个数据点重复使用fk_to_device和fk_to_metric值。
• 您节省了更多的空间，因为您不需要任何索引。
• 通过附加数据保存文件对（timestamp，metric_value）到文件，以便免费获得按时间戳的订单。 （假设您的资源不发送设备的订单数据）

=>通过时间戳查询运行得非常快，因为您可以使用二进制search来find文件中的正确位置来读取。

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

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

或从http://kx.com使用kdb +，因为他们为你做这一切:)列为导向是什么可以帮助你。

有一个基于云的列式解决scheme出现，所以你可能想看看： http ： //timeseries.guru

Answer 6

这是我们必须在ApiAxle上解决的一个问题。 我们写了一篇关于如何使用Redis来完成的博文 。 它没有很长时间，但certificate是有效的。

我还使用RRDTool的另一个很好的项目。

Answer 7

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

我发现了Columnar数据库（谷歌，你会发现MonetDB，InfoBright，parAccel等）在时间序列上做的很棒。

至于你的问题，我个人认为是有些无效的（所有的讨论都使用了NoSQL – IMO这个错误术语）：你可以使用一个数据库服务器，一方面可以谈论SQL，让你的生活变得非常简单，因为每个人都知道SQL数年来，这种语言一次又一次地完善了数据查询; 但仍然以列向导的方式利用RAM，CPUcaching和磁盘，使您的解决scheme最适合时间序列

Answer 8

5百万行不是今天的滔天大数据。 预计数据将在短短几个月内在TB或PB。 在这一点上，RDBMS不能扩展到任务，我们需要NoSql数据库的线性可伸缩性。 性能将实现用于存储数据的列分区，添加更多的列和更less的行types的概念，以提高性能。 利用在HBASE或MapR_DB之上完成的Open TSDB工作

Answer 9

我经常面对类似的需求，最近开始使用Zabbix来收集和存储这种types的数据。 Zabbix有它自己的graphicsfunction，但是很容易从Zabbix的数据库中提取数据并按照您的喜好进行处理。 如果你还没有检查过Zabbix，你可能会觉得这是值得的。

Answer 10

你应该看看时间系列数据库 。 它是为此目的而创build的。

时间序列数据库（TSDB）是针对时间序列数据，按时间（date时间或date时间范围）索引的数字数组进行优化的软件系统。

时间序列数据库InfluxDB的stream行例子