所以有这个新的很酷的东西，这些NoSQL数据库。因此，我的数据是：一行行气象数据的行：值，代表特定站点的某些测量值（由WMO编号标识，而不是坐标），在特定时间。NoSQL和气象数据
并非每个站都测量每个参数，并非每个参数都始终测量。
我在MySQL中存储了这些数据（价值30年的小时值，导致10亿个值）。持续的增长和更多数据的增加让我感到头痛。
阅读关于基于文档的NoSQL系统，看起来很容易扩展，我想知道NoSQL是否也是一个可行的数据存储概念。你有这方面的经验吗？
更新：忘记了典型查询：大多数查询需要时间轴上的数据：即，从01.01.2010 00:00到01.03.2010 00:00给我066310站的温度。
或者：给我一个特定站的所有参数的最新值。
如果数据结构非常简单（例如简单的键值存储）/可预测，并且您不需要关系完整性或需要临时和/或高级查询，则NoSQL可能是合适的。
您在简单的可扩展性方面取得的成就可能会失去灵活性和一致性。
最大的问题是要有一个简单的方法来编写复杂的数据查询。我认为，气象数据不是NoSQL的最佳人选。
我个人比MySQL更喜欢PostgreSQL，并且在正确安装时发现它非常具有伸缩性（甚至有数百万甚至数十亿行）。
这不完全正确。 NoSQL也可以适应非常复杂的数据，例如思考图形数据库。然后还有更简单的键值NoSQL数据存储。有很多种NoSQL解决方案。 – adamse 2010-04-09 08:18:24
@adamse：关于NoSQL术语的宽泛性的好处，尽管我认为图形数据库不适合用于气象数据;-) – ChristopheD 2010-04-09 08:23:08
不，显然不是:) – adamse 2010-04-09 08:26:06
我觉得很难，现在建立一个连贯的答案，但在这里不用。
感谢收听;）
我会看看Cassandra。感谢您的意见。 – 2010-04-16 12:40:21
我们真正需要知道，如果我们应该能够回答你的问题是你如何使用您的数据。你通过什么样的查询来运行它。 – adamse 2010-04-09 08:15:08
啊，我忘了。谢谢，我已经添加了两个样本。 – 2010-04-09 08:24:53
究竟是什么让你头痛？数据库管理？性能？汇总数据？还有别的吗？如果它的性能相关，你分析了查询的查询计划 - 也许你需要更好的索引，或者调整你的数据库设置（PostgreSQL在这方面很出色）。你的数据集有多大 - 磁盘上。 1GB？更多？减？ – Mike 2010-04-09 08:27:24