首页 文章

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

提问于
浏览
168

我正在创建一个系统,该系统使用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

其中 ddevices 的编号, m_d 是为所有设备记录的累计 number of metricsffrequency ,在该处查询数据, t 是系统收集数据的总量 time .

对于一年中每5分钟记录3个设备的10个度量标准的用户,我们将只有 5 million 记录 .

索引

如果没有索引在 fk_to_devicefk_to_metric 扫描,这个不断扩展的表将花费太多时间 . 因此,索引上述字段以及 timestamp (用于创建具有本地化期间的图表)是必需的 .

非关系(NoSQL)

MongoDB具有集合的概念,与表不同,这些可以在没有设置的情况下以编程方式创建 . 通过这些,我可以为每个设备划分数据存储,甚至为每个设备记录每个指标 .

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

未定

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

10 回答

  • 2

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

    两个更正,包括概念和应用,然后是提升 .

    更正

    • 不是"filtering out the un-needed data";它是 selecting only 所需的数据 . 是的,当然,如果你有一个索引来支持WHERE子句中标识的列,它非常快,并且查询不依赖于表的大小(从160亿行表中抓取1,000行是瞬时的) .

    • 你的 table 有一个严重的障碍 . 根据您的描述,实际的PK是(Device,Metric,DateTime) . (请不要将其称为TimeStamp,这意味着其他的东西,但这是一个小问题 . ) row 的唯一性由以下标识:

    (Device, Metric, DateTime)
    
    • Id 列什么都不做,它完全是完全冗余的 .

    • Id 列永远不是密钥(必须通过其他方法阻止在关系数据库中禁止的重复行) .

    • Id 列需要一个额外的索引,这显然会阻碍 INSERT/DELETE 的速度,并添加到使用的磁盘空间 .

    • 你可以摆脱它 . 请 .

    海拔

    • 既然你已经删除了障碍,你可能没有认出来,但你的 table 是第六范式 . 速度非常快,只有一个PK指数 . 要了解,请从 What is Sixth Normal Form ? Headers 开始阅读this answer .

    • (我只有一个索引,而不是三个;在非SQL上你可能需要三个索引) .

    • 我有完全相同的表(当然没有 Id "key") . 我有一个额外的列 Server . 我远程支持多个客户 .

    (Server, Device, Metric, DateTime)

    该表可用于使用完全相同的SQL代码(是,切换单元格)来旋转数据(即,顶部的 Devices 和侧面的 Metrics ,或者旋转) . 我使用该表为客户 Build 无限种类的图形和图表,以确定其服务器性能 .

    • Monitor Statistics Data Model .
      (内联太大;有些浏览器无法加载内联;点击链接 . 这也是过时的演示版本,由于显而易见的原因,我无法向您展示商业产品DM . )

    • 它允许我在使用 single SELECT command 从客户收到原始监控统计文件后生成Charts Like This,六次击键 . 请注意连连看;操作系统和服务器在同一图表上;各种各样的Pivots . 当然,统计矩阵的数量没有限制,因此图表也没有限制 . (与客户的许可一起使用 . )

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

    One More Thing

    最后但同样重要的是,SQL是IEC / ISO / ANSI标准 . 免费软件实际上是非SQL的;如果他们不提供标准,则使用术语SQL是欺诈性的 . 他们可能提供“额外”,但他们没有基本要素 .

  • 2

    发现以上答案非常有趣 . 尝试在此处添加更多注意事项 .

    1)数据老化

    时间序列管理通常需要创建老化策略 . 典型场景(例如监视服务器CPU)需要存储:

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

    • 5分钟细节聚合样本中期(例如1周)

    • 1小时的详细信息(例如最多1年)

    虽然关系模型可以肯定(我的公司为一些拥有数万个数据系列的大客户实施大规模集中式数据库)来适当地管理它,但新一代数据存储增加了有趣的功能,有待探索:

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

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

    2)实时收集

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

  • 7

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

    大多数NoSQL数据库会将您的数据存储在磁盘上的相同位置并以压缩形式存储,以避免多个磁盘访问 .

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

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

  • 1

    如果您正在查看GPL包,RRDTool是一个很好的选择 . 它是存储,提取和绘制时间序列数据的好工具 . 您的用例看起来与时间序列数据完全相同 .

  • 3

    创建一个文件,将其命名为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,因为他们为你做了这一切:)面向列是可以帮助你的 .

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

  • 2

    这是我们在ApiAxle必须解决的问题 . 我们wrote up a blog post关于我们如何使用Redis做到这一点 . 它没有证明是有效的 .

    我还用RRDTool作为另一个很棒的项目 .

  • 0

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

    一世已经找到了Columnar数据库(google it,你会发现MonetDB,InfoBright,parAccel等)在时间序列方面做得非常好 .

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

  • 144

    5百万行对于今天的暴雨数据来说并不算什么 . 预计数据将在几个月内出现在TB或PB中 . 此时RDBMS无法扩展到任务,我们需要NoSql数据库的线性可伸缩性 . 用于存储数据的柱状分区将实现性能,添加更多列和更少行的概念以提高性能 . 利用在HBASE或MapR_DB等基础上完成的Open TSDB工作 .

  • 19

    我经常面临类似的要求,并且最近开始使用Zabbix收集和存储此类数据 . Zabbix有自己的图形功能,但是很容易从Zabbix的数据库中提取数据并随意处理它 . 如果你还没有检查过Zabbix,你可能会觉得值得花时间去做 .

  • 3

    你应该看看Time series database . 它是为此目的而创建的 .

    时间序列数据库(TSDB)是一种优化用于处理时间序列数据的软件系统,时间序列数据是按时间(日期时间或日期时间范围)索引的数字数组 .

    时间序列数据库的热门示例InfluxDB

相关问题