氣象數據庫分析

1、項目背景

存儲氣象數據，用什么數據庫好呢

2、數據庫簡介

數據庫是存放數據的倉庫。簡單分為關系型數據庫與非關系型數據庫。

關系型數據庫，存儲的格式可以直觀地反映實體間的關系。關系型數據庫和常見的表格比較相似，關系型數據庫中表與表之間是有很多復雜的關聯關系的。 常見的關系型數據庫有Mysql，SqlServer等。在輕量或者小型的應用中，使用不同的關系型數據庫對系統的性能影響不大，但是在構建大型應用時，則需要根據應用的業務需求和性能需求，選擇合適的關系型數據庫。

非關系型數據庫（NoSQL）：指的是分布式的、非關系型的、不保證遵循ACID原則的數據存儲系統。大量的NoSql數據庫如MongoDB[11]?、Redis、Memcache出于簡化數據庫結構、避免冗余、影響性能的表連接、摒棄復雜分布式的目的被設計。

2.1 NoSQL數據庫分類

2.1.1 鍵值對數據庫 (Key/value databases)

鍵值對數據庫是最簡單的幾種NoSQL數據庫之一，由帶索引的鍵 (indexed key) 和其所對應的值 (value) 組成。

當給出一個鍵時，鍵值對數據庫可以通過哈希機制快速找到與其相關聯的值。哈希機制的時間復雜度為常數時間 (constant time)，這意味著即使數據規模很大，鍵值對數據庫依然可以維持高性能。

鍵值對的鍵可以是任意類別的對象，但通常是一個字符串 (string)。鍵值對的值一般來說是模糊的BLOB類型（即：一串數據庫不解讀的字節）。

鍵值對數據庫包括：Redis, Amazon DynamoDB, Riak以及Oracle NoSQL。一些像是Cassandra一樣的表格式的NoSQL數據庫也可以滿足鍵值對的需求。

思考：鍵值對數據庫都是一個key對應一或多個value,而全球海洋數據是三個維度，經緯度和時間對應u風或v風數據。故排除這類分布式數據庫。

其實Redis應該可以用key-list-list，就是list嵌套list實現多維，但費力。

2.1.2 文檔型數據庫 (Document databases)

文檔型數據庫由基本的鍵值對存儲模式而來，但是存儲數據的“文檔”則更為復雜一些。

每一個文檔都會被分配一個唯一的鍵 (key)，用來調取文檔。這些數據庫是為了存儲、調取和管理面向文檔的信息（通常以JSON的格式存儲）而設計的。

因為文檔型數據庫可以檢閱文檔內容，它們可以實現一些額外的調取處理。與要求靜態模式(schema) 的關系型數據庫管理系統 (RDBMSs) 相比，文檔型數據庫則有著由文檔內容定義的、更為靈活的模式。

文檔型數據庫的例子包括MongoDB和CouchDB。注意：一些關系型數據庫管理系統和非純存儲文檔的NoSQL數據庫也可以存儲和查詢JSON文檔，其中包括了Cassandra。

思考：同樣不適合全球海洋數據的處理

2.1.3 表格型數據庫 (Tabular databases)

表格型數據庫用行和列來存儲數據，但是與傳統的數據庫管理系統略有不同。

這種數據庫也被稱為寬表存儲 (wide-column stores) 或是分區行存儲 (partitioned row stores)，他們提供把數據庫中屬于同一個分區的相關行分到同一數據副本的能力，從而達到更快查詢的目的。

與關系型數據庫管理系統不同的是，表格的格式并不是嚴格固定的。例如Apache Cassandra?并不要求表格中所有的行的每一列都要有值。

與鍵值對和文檔型數據庫一樣，表格型數據庫也使用哈希函數來調取表格中的記錄。

表格型數據庫包括：Cassandra、HBase以及Google Bigtable。

思考：應該最后就是從表格型數據庫中找一個開源的、合適的來進行數據處理。其中HBase要收費，暫時放棄。

還有圖型數據庫和混合型數據庫，但應該對全球海洋數據處理不太合適，暫且不考慮。

3、所需數據庫要求

? 首先要知道我們要處理的這全球海洋數據的特點：

數據量巨大，大約180g，為1990-2021年的全球海洋u風v風數據

為nc文件，數據具有多維的特點，具有三個緯度：經度、緯度、時間

?目前簡單分析，可以知道最少要滿足以下三個要求：

可以提供超大規模的存儲容量，查詢低延遲，性能好

屬于開源數據庫，節約項目成本

具有實操性，可以應用到項目，且最好有c++API，便于之后的項目流程

4、目前備選方案

4.1 收費數據庫

??查閱知網相關文獻，搜索數據庫處理氣象數據關鍵詞，知道了GBase數據庫、虛谷數據庫、TableStore、Hbase等數據庫等可以較適合地處理海量氣象數據。特別是TableStore數據庫，TableStore是一款阿里自研的分布式NoSQL服務，可以提供超大規模的存儲容量，支撐超大規模的并發訪問和低延遲的性能，可以很好的解決氣象數據的規模和查詢性能問題，并且該數據庫有基于TableStore的海量氣象格點數據解決方案實戰等文章可以查閱學習，有諸多便利。

但因為這些數據庫并非開源，成本較高，且因為非開源故用戶少，相關數據庫學習方面不如開源數據庫便利，故暫且不考慮。

思考：如果考慮收費數據庫的話，最好的是TableStore。

4.2 MySQL數據庫

開始潛意識認為MySQL這種關系型數據庫不適合做為該項目的數據庫。阿里巴巴《Java開發手冊》提出：單表行數超過500萬行或者單表容量超過2GB，才推薦進行分庫分表。但是如果按照時間來進行讀取數據，大約一個生成的特定時刻全球海洋數據的txt文件里大約為480*61個數據。一年有722個這樣的txt文件，一共有31年，存儲肯定是沒問題，目前不知道具體實現細節是怎樣的，能不能用MySQL的分庫分表操作來實現功能，以及最后查詢時延會不會過大。

有CSDN相關文檔使用python爬取全國天氣數據并導入MySQL數據庫表提供一點思路，但因數據量不同故或許存在許多問題，具體能否用MySQL進行項目應用有待商榷。

思考：實在沒辦法的時候，可以考慮，應該是可以做到分庫分表始實現所需要求的，但是應該會事倍功半。

4.3 cassandra數據庫

Cassandra是一套開源分布式NoSQL數據庫系統。它最初由Facebook開發，用于儲存收件箱等簡單格式數據，集GoogleBigTable的數據模型與Amazon Dynamo的完全分布式的架構于一身Facebook于2008將 Cassandra 開源，此后，由于Cassandra良好的可擴展性，被Digg、Twitter等知名Web 2.0網站所采納，成為了一種流行的分布式結構化數據存儲方案。

Cassandra是一個混合型的非關系的數據庫，類似于Google的BigTable。其主要功能比Dynamo （分布式的Key-Value存儲系統）更豐富，但支持度卻不如文檔存儲MongoDB（介于關系數據庫和非關系數據庫之間的開源產品，是非關系數據庫當中功能最豐富，最像關系數據庫的。支持的數據結構非常松散，是類似json的bjson格式，因此可以存儲比較復雜的數據類型）。

主要是屬于表格型數據庫，且開源。表格型數據庫用行和列來存儲數據，但是與傳統的數據庫管理系統略有不同。與鍵值對和文檔型數據庫一樣，表格型數據庫也使用哈希函數來調取表格中的記錄。

思考：表格型數據庫，且開源，目前是最優選擇，如果后續沒有更合適的數據庫，優先拿此數據庫進行嘗試。

4.4 Google Bigtable數據庫

Bigtable是一個分布式多維映射表，表中的數據通過一個行關鍵字（Row Key）、一個列關鍵字（Column Key）以及一個時間戳（Time Stamp）進行索引。Bigtable對存儲在其中的數據不做任何解析，一律看做字符串，具體數據結構的實現需要用戶自行處理。

思考：也是表格型數據庫，開源，全球海洋數據可以用這個數據庫，行為經度，列為緯度，時間戳為時間。理論上應該可以實現。還未具體查閱。

4.5 SequoiaDB巨杉數據庫

進入巨杉數據庫的關鍵技術——分區概念，我們支持兩種分區，一種是水平分區，另一種是垂直分區。

水平分區： 這里提到兩個概念，一是集合空間（CS），二是集合（CL），我們基本數據存儲單元是集合，可以等同于傳統關系型數據庫里的表，水平分區的概念是在集合里，可以選定一個字段或者多個字段作為水平分區的鍵（key）。

巨杉數據庫會根據你選定的鍵或者鍵值，把數據對應到集合對應的所有分區。水平分區最大的好處是可以把多個節點組成復制組，你可以把數據均勻的分布到多個數據節點或者多個復制組，避免單一存儲或者單一節點帶來的瓶頸，對于分布式數據庫來講是必不可少的特性。

垂直分區： 垂直分區更多的跟業務邏輯相關，常見信息是流水表，如果你想保存銀行過去10年甚至20年的交易流水表，這是海量天文數字的數據。因此，我們可以將龐大的數據從邏輯意義上區分開，按時間戳作為分隔的字段。

多維分區：

多維分區機制，把水平分區和垂直分區兩種方式結合在一起使用。這跟垂直分區的圖類似，在每一個子集合內部可以用水平分區，均勻打散到多個不同的物理存儲上。

思考：應該是屬于鍵值型數據庫的一種，但是它可以選定一個字段或多個字段作為key，而非固定一個字段作為Key,如果選經緯度、時間作為key，應該就可以滿足項目要求。重點是開源，但不為首選，還是表格型數據庫最合適。

---

總結

以上是生活随笔為你收集整理的气象数据库分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。