所以有這個新的很酷的東西，這些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