我们正在建立一个最终由数千个测量站组成的测量系统。每个站点将在其生命周期内节省大约5亿个测量值,包括30个标量值。这些将是浮动值。我们现在想知道如何在每个站点上保存这些数据,考虑到我们将在每个站点上构建一个Web应用程序,以便
现在我想知道noSQL解决方案是否可能比mySQL更好用于这些目的。特别是 couchDB , Cassandra 以及像 Redis 这样的键值商店看起来很吸引我。您认为哪一种最适合“测量时间序列”数据模型?那么其他优点如崩溃安全和从测量站到主服务器的复制呢?
答案 0 :(得分:3)
我认为CouchDB是一个很棒的数据库 - 但它处理大数据的能力值得怀疑。 CouchDB的主要关注点是开发和离线复制的简单性,而不一定是性能或可伸缩性。 CouchDB本身不支持分区,因此除非您使用BigCouch或发明自己的分区方案,否则您将受到最大节点大小的限制。
没有傻瓜,Redis是一个内存数据库。它可以非常快速有效地将数据输入和输出RAM。它确实能够使用磁盘进行存储,但它并不是非常好用。对于经常变化的大量数据非常有用。 Redis确实有复制,但没有任何内置的分区支持,所以再次,你将独自在这里。
您还提到了Cassandra,我认为它更适用于您的用例。 Cassandra非常适合无限增长的数据库,基本上它是原始用例。分区和可用性已经完成,因此您不必非常担心它。数据模型也比平均键/值存储更灵活,添加了第二维列,并且实际上可以容纳每行数百万列。例如,这允许时间序列数据被“划分”成覆盖时间范围的行。整个集群中的数据分配(分区)是在行级别完成的,因此只需要一个节点即可在一行内执行操作。
Hadoop直接插入Cassandra,带有MapReduce,Pig和Hive的“本机驱动程序”,因此它可能用于聚合收集的数据并实现运行平均值。最佳实践是围绕查询对数据进行整形,因此可能希望以“非规范化”形式存储多个数据副本,每种类型的查询都有一个副本。
查看这篇关于在Cassandra做时间序列的帖子:
答案 1 :(得分:2)
对于这种性质的高度结构化数据(浮点向量的时间序列),我倾向于回避数据库。数据库的大多数功能都不是很有趣;你基本上对原子性或事务语义这样的东西不感兴趣。 唯一需要的功能是恢复崩溃。但是,当您不需要撤消写入(无更新/删除)时,只需附加到文件即可轻松实现该功能。崩溃恢复很简单;在文件名中打开一个带有递增序列号的新文件。
这种逻辑格式是普通的csv。在进行每次测量后,请在基础flush()
上调用file
。将数据复制回中央服务器是rsync(1)
有效解决的工作。然后,您可以在您选择的分析工具中导入数据。
答案 2 :(得分:0)
我会毫不犹豫地回避“csv”和“明文”文件。当您的音量较低并且想要跳过工具以快速查看数据或对数据进行小的更改时,这些都很方便。
当你谈论“50Tb”的数据时,这是非常多的。如果一个简单的技巧可以将其减少两倍,那将会收回存储成本和带宽费用。
如果定期进行测量,这意味着不是保存每次测量的时间戳,而是存储开始时间和间隔,只存储测量值。
我会选择具有小标题的文件格式,然后只是一堆浮点测量。要防止文件变得非常大,请确定最大文件大小。如果在开始使用文件之前通过完全写入文件来初始化文件,则在开始使用文件时它将完全分配到磁盘上。现在您可以mmap文件并更改数据。如果在更改数据时电源关闭,它只是将其设置为磁盘,或者不是。