NoSQL和气象数据

Question

所以有了一个新的很酷的东西，这些NoSQL数据库。这就是我的数据:一行行的气象数据:数值，代表在特定时间在特定站点的特定测量值(由世界气象组织的数字标识，而不是坐标)。

并不是每个站点都要测量每个参数，也不是每个参数都是一直测量的。

我将这些数据(30年的每小时值，结果是大约10亿个值)当前存储在MySQL中。持续的增长和可预见的更多数据的增加让我有点头疼。

读到基于文档的NoSQL系统似乎相当容易扩展时，我想知道NoSQL是否也是气象数据的可行数据存储概念。你有这方面的经验吗？

更新:忘记了典型的查询:大多数查询都需要时间轴上的数据:例如，给我066310站从01.01.2010 00:00到01.03.2010 00:00的温度。

或者:提供特定工作站所有参数的最新值。

Answer 1

当您的数据结构非常简单(例如，简单的键值存储)/可预测，并且您不需要关系完整性或不需要即席和/或高级查询时，NoSQL可能是一个合适的选择。

不过，您在轻松可伸缩性方面的优势可能会在灵活性和一致性方面有所损失。

最大的问题是有一种简单的方法来对数据进行复杂的查询。我想说气象数据不是NoSQL的最佳候选者。

与MySQL相比，我个人更喜欢PostgreSQL，并且发现它在正确设置时具有很强的可扩展性(即使有数百万甚至数十亿行)。

Answer 2

我认为在放弃SQL之前，你应该尝试一个功能齐全的成熟的DBMS。

例如，请参阅：

http://www.yafla.com/dforbes/Getting_Real_about_NoSQL_and_the_SQL_Performance_Lie/

http://www.yafla.com/dforbes/The_Impact_of_SSDs_on_Database_Performance_and_the_Performance_Paradox_of_Data_Explodification/

Answer 3

我发现现在很难找到一个连贯的答案，但这里有。

1. 你的数据可以毫不费力地放在"nosql“数据存储中，比如Cassandra (可能还有更多)
2. 你会从很多"nosql”解决方案的无模式设计中受益(看起来并不是所有的列(使用MySQL术语)都存在)
3. 基于时间的查询在Cassandra中是没有问题的(查看基于键的TimeUUID )
4. 你似乎并没有利用MySQL的关系部分，所以当失去它时，你不会受到太大的伤害

< MySQL >h19>，尽管你可能用MySQL很好，既然你真的没有描述这类问题，你真的有什么问题吗？(仅仅是感兴趣是非常酷的)

1. 像索引和搜索这样的东西是你必须在许多nosql数据存储中手动实现的，如果这让你害怕，也许你可以继续使用sql。

感谢您的收听;)