我正在考虑重新开发一个存储和可视化传感器数据的应用程序。多个用户可以访问该应用程序,他们可以添加无限的传感器。我们现在有10个用户,我们有大约1000个传感器。用户数量可能不会改变。如果有足够的电力(太阳能电池板),传感器每5秒发送一次数据。
现在数据存储在4个表中。
问题是数据表变得非常大。目标是保留近一年的数据。我使用MySQL,我对它的性能非常失望。现在我正在使用带有Gunicorn的烧瓶,我正在使用RabbitMQ对存储过程进行排队。有什么我可以改变以提高现有系统的性能吗?如果你从头开始做这件事你会做出什么改变? NoSQL会在这种情况下有很大的不同吗?我问的太多了,但这是我第一次遇到这种问题。
答案 0 :(得分:3)
由于你有1k传感器并且每个传感器每5秒产生一次数据,我觉得在很好的例子中可以使用像Akka这样的框架来处理许多请求并避免许多线程问题
一旦您的处理阶段看起来优化,您就正确地写了关于NoSQL的文章。注释中的人提到缺少索引,但由于您只有一个表,这可能导致表的每个insert
触发所有数据的索引重新计算。这可能会损害您应用的吞吐量。
您有很多选择如何解决此问题。将表分为最后一个包含最新数据或使用两个表,一个用于读取和查询,第二个用于写入以及从第二个到第一个的批量插入 - 这绝对是使用截断索引的快速。众所周知的问题是,您可以优化存储以进行大量读取或大量写入,而不是两者兼而有之。
或者你可以看看NoSQL,特别是Redis进入我的脑海,看看他们的数据类型http://redis.io/topics/data-types-intro
Redis本质上支持长列表。由于它不支持SELECT ... FROM ... WHERE ...
的任何查询,因此您必须提供自己的索引和缓存才能提供所需的查询。如果您对如何使用key:value store感兴趣,只需查看他们的twitter演示。 Twitter必须像你一样解决同样的问题。
这让我想到了最后一点。如果你想提供更好的可扩展性并且你不知道如何,只需看看facebook,twitter或netflix架构。
答案 1 :(得分:1)
作为Martin Podval你应该看一下NoSql,但是你可以尝试一些技巧。首先,开始将数据分区为多个表。根据最常用的时间范围,您可以为一个表分区一周或每月分区一个表。然后,对于时间范围,您将不得不查询多个表并组合结果(小地图和减少作业),但较小的表上的多个查询将比大型表上的单个查询更快。
第二个技巧是优化表的索引,并不惜一切代价避免JOIN操作。
最后你可以添加缓存,这是一个非常古老的技巧,它有很多争论,但1000个传感器上的10个用户一年,我认为他们很有可能看到相同的数据然后一次
我认为最好的解决方案不仅仅是使用NoSQL解决方案,而是更多的分布式系统,即使使用cheep服务器,您也可以获得更好的性能。做一个数学,你应该有一年约63亿条记录。无论计算机有多快,它使用什么系统(存储系统),甚至从内存中读取数据也需要很长时间。
答案 2 :(得分:1)
如果没有讨论业界已经证明的解决方案,就不会有关于遥测数据的讨论。
HDF5就是这样一种解决方案。 HDF5是用于存储和管理遥测数据的数据模型,库和文件格式。它支持无限种类的数据类型,专为灵活高效的I / O以及大容量和复杂数据而设计。
SQL Server具有FILESTREAM数据类型,该数据类型特别适合处理大型遥测数据集。麦克拉伦系统公司用它来收集一级方程式赛车的遥测数据。
答案 3 :(得分:0)
自您提出问题以来,数据库格局已经发生了很大变化,但是这个问题在今天仍然有效,甚至更多。总而言之,您的需求似乎如下:
您似乎需要针对传感器/ IoT /时间序列数据进行优化的数据库。根据{{3}},在过去两年中,时间序列数据库获得了最大的关注。我认为值得尝试这些数据库,因为它们针对此类数据进行了优化。一些值得注意的东西:
这些数据库均旨在通过快速摄取和查询来存储时间序列/ IoT数据,并具有数据保留功能。
例如,使用CrateDB,您的数据模型将如下所示:
容器的工作方式类似于表,但是可以对数据进行分区而没有花样,您可以在其中快速查询单个或一组传感器的数据。由于每个传感器数据都是按容器存储的,因此不会出现膨胀的表。