适用于物理测量的好的（NoSQL？）数据库

Question

我们正在建立一个测量系统，最终将包括数千个测量站。每个测量站在其寿命周期内将保存大约500万次测量，由30个标量值组成。这些将是浮点值。我们现在在考虑如何在每个测量站上保存这些数据，考虑到我们将在每个测量站上构建一个Web应用程序，以便：

• 我们想要在多个时间尺度上可视化数据（例如一周、一个月、一年的测量）
• 我们需要在数据上构建移动平均线（例如在一个月内平均，以在年度图表中显示）
• 数据库需要具有崩溃恢复功能（停电时）
• 我们只进行数据的写入和读取，没有更新或删除数据的操作

此外，我们希望再增加一个服务器，可以显示1000个测量站的数据。那将是大约50TB的数据和5000亿次测量。为了将数据从测量站传输到服务器，我认为某种类型的数据库级别的复制是一种干净而有效的方式。

现在我在思考是否无SQL解决方案比mySQL更好地适合这些目的。特别是couchDB、Cassandra和可能的键值存储（如Redis），看起来很有吸引力。你认为哪种方法最适合“测量时间序列”数据模型？对于诸如崩溃安全和从测量站到主服务器的复制等其他优点呢？

- Chris

---

我也发现了NetCDF - 有人对这个有经验吗？它是为时间序列而设计的，但我不确定它在多台服务器上的崩溃抵抗和扩展性如何... - Chris

Answer 1

我认为CouchDB是一个很棒的数据库，但它处理大数据的能力值得怀疑。CouchDB的主要重点在于开发简易性和离线复制，而不一定关注性能或可扩展性。CouchDB本身不支持分区，因此您将受到最大节点大小的限制，除非您使用BigCouch或发明自己的分区方案。

别开玩笑，Redis是一个内存数据库。它非常快速和高效地将数据放入和取出RAM。它确实有使用磁盘存储的能力，但这并不是它的强项。它非常适合变化频繁的有界数据。Redis确实具有复制功能，但没有任何内置的分区支持，所以在这里你将需要自己解决。

你还提到了Cassandra，我认为它更适合你的用例。Cassandra非常适合无限增长的数据库，这基本上是它最初的用例。分区和可用性已经内置，因此你不必太担心。数据模型也比平均键/值存储更加灵活，添加了第二个列维度，并且每行可以实际容纳数百万个列。例如，这允许将时间序列数据“分桶”到覆盖时间范围的行中。跨集群分布（分区）的数据是在行级别完成的，因此只需要一个节点就可以在行内执行操作。

Hadoop可以直接插入Cassandra，具有适用于MapReduce、Pig和Hive的“本地驱动程序”，因此它可能被用于聚合收集的数据并实现运行平均值。最佳实践是根据查询来设计数据，因此可能需要以“去规范化”的形式存储数据的多个副本，每个副本对应一种类型的查询。

请查看此帖子，了解如何在Cassandra中处理时间序列：

http://rubyscale.com/2011/basic-time-series-with-cassandra/

- rbranson

---

谢谢，我会对Cassandra再多研究一下，也许放弃CouchDB的想法... - Chris

Answer 2

对于这种高度结构化的数据（浮点向量的时间序列），我倾向于完全避开数据库。大多数数据库的特性并不是很有趣；你基本上不感兴趣原子性或事务语义之类的东西。唯一有用的特性就是抗崩溃能力。然而，当你永远不需要撤销写入操作（没有更新/删除）时，实现这个特性非常容易，只需将数据附加到一个文件中即可。崩溃恢复很简单：使用带有递增序列号的文件名打开一个新文件。

一个逻辑格式是普通的csv。在每次测量后，调用底层文件的flush()函数。将数据复制回中央服务器的工作可以通过rsync(1)有效地解决。然后，您可以在所选的分析工具中导入数据。

- SingleNegationElimination

Answer 3

我个人会避开“csv”和“plaintext”文件。当您数据量较小且想要跳过工具快速查看数据或对数据进行微小修改时，这些文件比较方便。

而当您谈及“50Tb”的数据时，那是非常庞大的数据量。如果有一个简单的技巧能将其减少一半，那将节省存储成本和带宽费用。

假如测量是定期进行的，那意味着您可以保存起始时间和间隔，只需存储测量值，而无需为每个测量值保存时间戳。

我建议使用一个具有简短文件头并包含一系列浮点测量值的文件格式。为了防止文件变得非常大，在文件大小达到最大值时停止写入。在开始使用文件之前先完全写入文件，这样就可以将其完全分配到磁盘上。现在，您可以映射文件并修改数据。如果正在更改数据时出现断电，则数据将被写入磁盘或不会写入。

- user1182692