存储时间序列数据，关系数据还是非关系数据？
我正在创建一个系统，它使用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方法的结构(与我对存储数据的心理模型相匹配)是否提供了显著的好处？
回答 10
Stack Overflow用户
发布于 2011-02-03 17:33:59
绝对是关系型的。无限的灵活性和可扩展性。
在概念和应用上都进行了两次修正，然后进行了提升。
更正
- 它不是“过滤掉不需要的数据”，而是只选择需要的数据。是的，当然，如果您有一个索引来支持WHERE子句中标识的列，那么它是非常快的，并且查询不依赖于表的大小(从160亿行表中抓取1,000行是instantaneous).
- Your表有一个严重的障碍。根据您的描述，实际PK为(Device，Metric，DateTime)。(请不要将其称为TimeStamp，这意味着其他东西，但这是一个小问题。)行的唯一性由以下内容标识：
(设备、公制、DateTime)
- The `Id` column does nothing, it is totally and completely redundant. - An `Id` column is never a Key (duplicate rows, which are prohibited in a Relational database, must be prevented by other means).
- The `Id` column requires an additional Index, which obviously impedes the speed of `INSERT/DELETE`, and adds to the disk space used.
- You can get rid of it. Please.
标高
- 现在你已经移除了障碍，你可能还没有认识到它，但是你的表格是第六范式。非常高的速度，在PK上只有一个索引。为了理解，请阅读中的 What is Sixth Normal Form ? heading What。
- (I have one index only, not three; on the Non-SQLs you may need three indices).
- I have the exact same table (without the `Id` "key", of course). I have an additional column `Server`. I support multiple customers remotely. (Server, Device, Metric, DateTime)
该表可用于透视数据(即，顶部的Devices和侧面的Metrics )使用完全相同的SQL代码(是的，交换单元格)。我使用该表建立了无限种类的图形和图表，以供客户评估他们的服务器性能。
- [**Monitor Statistics Data Model**](http://www.softwaregems.com.au/Documents/Documentary%20Examples/sysmon%20Public.pdf).(对于内联来说太大；某些浏览器无法内联加载；请单击该链接。这也是过时的演示版本，由于明显的原因，我不能向您展示商业产品DM。)
-它允许我在从客户那里收到原始监控统计文件后，使用单一选择命令生成，只需击键六次。请注意同一图表上的操作系统和服务器的混合搭配；不同的轴心点。当然，统计矩阵的数量没有限制，因此图表也没有限制。(经客户同意后使用。)
-不熟悉关系数据库建模标准的读者可能会发现很有帮助。
还有一件事
最后但并非最不重要的一点是，SQL是IEC/ISO/ANSI标准。免费软件实际上是非SQL的；如果它们不提供标准，则使用术语SQL是欺骗性的。他们可能会提供“额外的”，但他们缺乏基本的东西。
Stack Overflow用户
发布于 2011-03-20 21:18:33
发现上面的答案非常有趣。在这里尝试添加更多的注意事项。
1)数据老化
时间序列管理通常需要创建老化策略。一个典型的场景(例如监控服务器CPU)需要存储：
短期(例如，24小时)的
- 1秒原始样本
- 5分钟详细信息聚合样本(例如，1周)在此期间(例如，最多1年)的
- 1小时详细信息
虽然关系模型可以确保(我的公司为一些具有数万个数据系列的大客户实现了大量的集中式数据库)来适当地管理它，但新类型的数据存储添加了一些有趣的功能，如：
地图还原自动数据清除(请参阅command)
- multidimensional的过期作业聚合(例如，-reduce
- a-la-Splunk)
2)实时采集
更重要的是，一些非关系数据存储本质上是分布式的，并允许更有效的实时(或接近实时)数据收集，这可能是RDBMS的一个问题，因为创建了热点(在单个表中插入时管理索引)。RDBMS领域的这个问题通常是通过恢复到批量导入过程来解决的(我们过去是这样处理的)，而非sql技术在大规模实时收集和聚合方面取得了成功(例如，请参阅前面的回复中提到的Splunk )。
Stack Overflow用户
发布于 2011-01-27 20:53:18
您的表在单个表中有数据。所以关系和非关系不是问题所在。基本上，你需要读取大量的顺序数据。现在，如果你有足够的RAM来存储一年的数据，那么就没有什么比使用Redis/MongoDB等更好的了。
大多数情况下，NoSQL数据库会将数据以压缩形式存储在磁盘上的相同位置，以避免多次访问磁盘。
NoSQL的作用与在设备id和度量id上创建索引相同，但以自己的方式。对于数据库，即使这样做，索引和数据也可能位于不同的位置，并且会有大量的磁盘IO。
像Splunk这样的工具使用NoSQL后端存储时间序列数据，然后使用map reduce创建聚合(这可能是您稍后需要的)。因此，在我看来，使用NoSQL是一种选择，因为人们已经在类似的用例中尝试过它。但是，一百万行是否会使数据库爬行(也许不会，只要有合适的硬件和适当的配置)。
https://stackoverflow.com/questions/4814167
复制相似问题