NoSQL和气象数据

Question

所以这是一个很酷的东西，这些NoSQL数据库。所以有我的数据：一排排的气象数据行：值，表示某个站点的某些测量值（由WMO编号识别，而不是坐标），在某个时间。

并非每个站都测量每个参数，并非每个参数都是一直测量的。

我存储了目前在MySQL中的这些数据（价值30年的小时值，产生约10亿个值）。持续增长和可预见的更多数据的添加让我有点头疼。

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

更新：忘记了典型的查询：大多数查询需要时间轴上的数据：I.e。从2010年1月1日00:00到2010年3月1日00:00，给我066310站的温度。

或者：给我一个特定电台所有参数的最新值。

Answer 1

当您的数据结构非常简单（例如简单的键值存储）/可预测且您不需要关系完整性或需要进行临时和/或高级查询时，NoSQL可能是合适的。

您在轻松扩展性方面取得的成就可能会失去灵活性和一致性。

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

我个人更喜欢PostgreSQL而不是MySQL，并且在正确设置时发现它具有很高的可扩展性（即使有数百万甚至数十亿行）。

Answer 2

我认为你应该尝试使用功能齐全且成熟的DBMS，然后再放弃使用SQL。

参见例如：

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的关系部分，所以当你失去它时你不会受到太大伤害
5. 虽然你可能对MySQL很好，但你真的没有描述这类问题，你真的有吗？ （只是感兴趣是非常酷）
6. 像索引和搜索这样的东西是你必须在许多nosql数据存储区中手动实现的东西，如果这样你可能会坚持使用sql。

感谢收听;）