database - 时间序列数据的存储和计算开源时序数据库解析 - 时间序列数据集




存储时间序列数据,关系还是非? (7)

我正在创建一个系统,该系统使用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_devicefk_to_metric扫描的索引,这个连续扩展的表会花费太多时间。 因此索引前述字段和timestamp (用于创建具有本地化时间段的图)是一项要求。

非关系(NoSQL)

MongoDB具有集合的概念,与表格不同,这些可以在没有安装的情况下以编程方式创建。 有了这些,我可以划分每个设备的数据存储空间,甚至可以划分每个设备的每个数据记录。

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

未定

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


5百万行对今天的暴雨数据毫无用处。 预计数据将在几个月内在TB或PB中。 此时RDBMS不能扩展到任务,我们需要NoSql数据库的线性可伸缩性。 性能将用于存储数据的列分区,添加更多的列和更少的行类型的概念来提高性能。 利用在HBASE或MapR_DB之上完成的Open TSDB工作


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

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

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

像Splunk这样的工具正在使用NoSQL后端来存储时间序列数据,然后使用map reduce来创建聚合(这可能是您以后想要的)。 所以在我看来,使用NoSQL是一种选择,因为人们已经尝试过使用类似的用例。 但是会有一百万行将数据库抓取(可能不是,具有合适的硬件和正确的配置)。


发现上面的答案非常有趣。 试图在这里添加更多的考虑因素。

1)数据老化

时间序列管理通常需要制定老化政策。 典型的场景(例如监控服务器CPU)需要存储:

  • 短时间内的1秒原始样品(例如24小时)

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

  • 1小时以上的细节(例如最多1年)

尽管关系模型可以确保(我的公司为一些拥有数以万计数据序列的大型客户实施了大规模集中式数据库)进行适当管理,但新一代数据存储添加了一些有趣的功能,以便进行探索:

  • 自动数据清除(请参阅Redis的EXPIRE命令)

  • 多维聚合(例如map-reduce作业a-la-Splunk)

2)实时收集

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


如果您正在查看GPL软件包, RRDTool是一个不错的选择。 这是存储,提取和绘制时间序列数据的好工具。 您的用例与时间序列数据非常相似。


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


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

我发现了Columnar数据库(谷歌它,你会发现MonetDB,InfoBright,parAccel等)在时间序列方面做得非常出色。

至于你的问题,我个人认为这个问题有些无效(因为所有的讨论都使用了NoSQL - IMO这个错误术语):你可以使用一个数据库服务器,它可以一方面谈论SQL,让你的生活变得非常简单,因为每个人都知道SQL有很多并且这种语言一次又一次地被完善以用于数据查询; 但仍以柱状导向的方式利用RAM,CPU缓存和磁盘,使您的解决方案最适合时间序列


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

我还使用RRDTool作为另一个非常出色的项目。







non-relational-database