系列数据，关系还是非关系？
我正在创建一个系统，该系统使用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的基于集合的结构方法（与我存储数据的心智模型相匹配）提供了明显的好处？
绝对关系。 无限的灵活性和扩展。
两个更正，无论是在概念和应用程序，然后提升。
更正
它不是“过滤不需要的数据”; 它只选择所需的数据。 是的，当然，如果您有一个索引来支持WHERE子句中标识的列，那么速度非常快，查询不依赖于表的大小（从160亿行表中抓取1,000行是瞬时的） 。
你的桌子有一个严重的障碍。 根据你的描述，实际的PK是（设备，度量，日期时间）。 （请不要称它为TimeStamp，这意味着别的东西，但这是一个小问题。） 行的唯一性由以下标识：
(Device, Metric, DateTime)
Id列没有任何作用，它完全和完全是多余的。
Id列永远不是Key（重复行，在关系数据库中禁止使用，必须通过其他方法阻止）。 Id列需要额外的索引，这明显阻碍了INSERT/DELETE的速度，并增加了使用的磁盘空间。
你可以摆脱它。 请。
海拔
现在你已经消除了障碍，你可能没有认出它，但你的桌子是在第六范式。 非常高的速度，在PK上只有一个索引。 为了理解，宣读了什么是第六范式 这个答案 ？ 向前。
（我只有一个索引，而不是三个;在非SQL中，您可能需要三个索引）。
我有完全相同的表格（当然没有Id “键”）。 我有一个额外的列Server 。 我远程支持多个客户。
(Server, Device, Metric, DateTime)
该表可以用于使用完全相同的SQL代码（是，切换单元格）来旋转数据（即，顶部和Metrics下面的Devices或透视）。 我使用该表来为客户提供无限多种图表和图表，以便他们的服务器性能得到提升。
监视统计数据模型 。
（内联过大;某些浏览器无法加载内联;点击链接，这也是过时的演示版本，原因很明显，我无法向您展示商业产品DM。）
它允许我在收到来自客户的原始监控统计文件后，使用单个SELECT命令生成这样的图表 ，六次按键。 注意混搭; 操作系统和服务器在同一张图上; 各种枢轴。 当然，统计矩阵的数量没有限制，因此也没有限制。 （与客户的许可使用）。
不熟悉关系数据库建模标准的读者可能会发现IDEF1X Notation有帮助。
还有一件事
最后但并非最不重要的一点，SQL是一个IEC / ISO / ANSI标准。 免费软件实际上是非SQL; 如果他们不提供标准，则使用术语SQL是欺诈性的。 他们可能会提供“临时演员”，但他们缺乏基础知识。
发现上面的答案非常有趣。 试图在这里添加更多的考虑因素。
1）数据老化
时间序列管理通常需要制定老化政策。 典型的场景（例如监控服务器CPU）需要存储：
短时间内的1秒原始样品（例如24小时）
中期（例如1周）的5分钟细节总量样品
1小时以上的细节（例如最多1年）
尽管关系模型可以确保（我的公司为一些拥有数以万计数据序列的大型客户实施了大规模集中式数据库）进行适当管理，但新一代数据存储添加了一些有趣的功能，以便进行探索：
自动数据清除（请参阅Redis的EXPIRE命令）
多维聚合（例如map-reduce作业a-la-Splunk）
2）实时收集
更重要的是，一些非关系数据存储本质上是分布式的，并且允许更高效的实时（或接近实时）数据收集，这可能成为RDBMS的问题，因为创建了热点（管理索引时插入一张桌子）。 RDBMS空间中的这个问题通常可以解决，回到批量导入过程（我们过去是这样管理的），而没有sql技术成功实现了大规模的实时收集和聚合（参见前面的回复中提到的Splunk） 。
你的表有单个表中的数据。 所以关系与非关系不是问题。 基本上你需要阅读很多顺序数据。 现在，如果你有足够的内存来存储一年的数据，那么就不会像使用Redis / MongoDB等。
大多数NoSQL数据库会将您的数据存储在磁盘上的同一位置和压缩格式中以避免多个磁盘访问。
NoSQL与在设备ID和度量标识上创建索引的做法相同，但是以其自己的方式。 即使你这样做了数据库，索引和数据可能会在不同的地方，并且会有很多磁盘IO。
像Splunk这样的工具正在使用NoSQL后端来存储时间序列数据，然后使用map reduce来创建聚合（这可能是您以后想要的）。 所以在我看来，使用NoSQL是一种选择，因为人们已经尝试过使用类似的用例。 但是会有一百万行将数据库抓取（可能不是，具有合适的硬件和正确的配置）。
链接地址: http://www.djcxy.com/p/93959.html