Mar*_*row 177 database time-series non-relational-database relational-database nosql
我正在创建一个系统,使用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(用于创建具有本地化期间的图表)是必需的.
MongoDB具有集合的概念,与表不同,这些可以在没有设置的情况下以编程方式创建.有了这些,我可以为每个设备划分数据存储,甚至为每个设备记录每个指标.
我没有使用NoSQL的经验,也不知道它们是否提供任何查询性能增强功能,例如索引,但是前一段提出在数据存储在NoSQL下的结构中进行大多数传统的关系查询工作.
具有正确索引的关系解决方案是否会在一年内减少爬行？或者NoSQL方法的基于集合的结构(与我存储的数据的心智模型相匹配)是否提供了明显的好处？
Per*_*DBA 150
绝对是关系.无限的灵活性和扩展.
两个更正,包括概念和应用,然后是提升.
它不是"过滤掉不需要的数据"; 它只选择所需的数据.是的,当然,如果你有一个索引来支持WHERE子句中标识的列,它非常快,并且查询不依赖于表的大小(从160亿行表中抓取1,000行是瞬时的) .
你的桌子有一个严重的障碍.根据您的描述,实际的PK是(Device,Metric,DateTime).(请不要将其称为TimeStamp,这意味着其他内容,但这是一个小问题.)行的唯一性通过以下方式标识:
(Device, Metric, DateTime)
该Id列没有任何作用,它完全是完全冗余的.
Id列是从未一个密钥(重复的行,这是禁止的在关系数据库中,必须通过其它方式来防止). 该Id列需要一个额外的索引,这显然会阻碍其INSERT/DELETE使用的磁盘空间并增加其速度.
你可以摆脱它.请.
既然你已经消除了障碍,你可能没有认出它,但你的桌子是第六范式.速度非常快,只有一个PK指数.为了理解,阅读这个答案从什么是第六范式？向前走.
(我只有一个索引,而不是三个;在非SQL上你可能需要三个索引).
我有完全相同的表(Id当然没有"键").我还有一个专栏Server.我远程支持多个客户.
(Server, Device, Metric, DateTime)
该表可用于使用完全相同的SQL代码(即,切换单元格)来旋转数据(即,Devices跨越顶部和Metrics侧面,或者旋转).我使用该表为客户建立无限种类的图形和图表,以提高其服务器性能.
还有一件事
最后但并非最不重要的是,SQL是IEC/ISO/ANSI标准.免费软件实际上是非SQL的; 如果他们不提供标准,则使用术语SQL是欺诈性的.他们可能提供"额外",但他们缺乏基础知识.
Pao*_*ola 20
发现以上答案非常有趣.尝试在此处添加更多注意事项.
1)数据老化
时间序列管理通常需要创建老化策略.典型场景(例如监视服务器CPU)需要存储:
1秒的原始样品短期(例如24小时)
中期(例如1周)的5分钟细节聚合样本
1小时的细节(例如长达1年)
虽然关系模型可以肯定(我公司为一些拥有数万个数据系列的大客户实施大规模集中式数据库)来适当地管理它,但新一代数据存储增加了有趣的功能,有待探索:
自动数据清除(请参阅Redis的EXPIRE命令)
多维聚合(例如map-reduce job a-la-Splunk)
2)实时收集
更重要的是,一些非关系数据存储本质上是分布式的,并且允许更高效的实时(或接近实时)数据收集,这可能是RDBMS的一个问题,因为热点的创建(在插入时管理索引)一张桌子).RDBMS空间中的这个问题通常被解决为恢复批量导入过程(我们过去以这种方式管理),而no-sql技术已成功进行大规模实时收集和聚合(例如,参见Splunk,在之前的回复中提到过) .
您的表在单个表中有数据.所以关系与非关系不是问题.基本上你需要阅读大量的顺序数据.现在,如果你有足够的RAM存储一年的数据,那么就像使用Redis/MongoDB等.
大多数NoSQL数据库会将您的数据存储在磁盘上的相同位置并以压缩形式存储,以避免多个磁盘访问.
NoSQL以与设备ID和度量标识创建索引相同的方式,但以自己的方式.使用数据库即使你这样做,索引和数据可能在不同的地方,并且会有很多磁盘IO.
像Splunk这样的工具使用NoSQL后端来存储时间序列数据,然后使用map reduce来创建聚合(这可能是您以后想要的).所以在我看来使用NoSQL是一个选项,因为人们已经尝试过类似的用例.但是,一百万行会使数据库爬行(可能没有,具有合适的硬件和正确的配置).