气象数据库分析
氣象數(shù)據(jù)庫分析
1、項目背景
存儲氣象數(shù)據(jù)，用什么數(shù)據(jù)庫好呢
2、數(shù)據(jù)庫簡介
數(shù)據(jù)庫是存放數(shù)據(jù)的倉庫。簡單分為關(guān)系型數(shù)據(jù)庫與非關(guān)系型數(shù)據(jù)庫。
關(guān)系型數(shù)據(jù)庫，存儲的格式可以直觀地反映實體間的關(guān)系。關(guān)系型數(shù)據(jù)庫和常見的表格比較相似，關(guān)系型數(shù)據(jù)庫中表與表之間是有很多復(fù)雜的關(guān)聯(lián)關(guān)系的。 常見的關(guān)系型數(shù)據(jù)庫有Mysql，SqlServer等。在輕量或者小型的應(yīng)用中，使用不同的關(guān)系型數(shù)據(jù)庫對系統(tǒng)的性能影響不大，但是在構(gòu)建大型應(yīng)用時，則需要根據(jù)應(yīng)用的業(yè)務(wù)需求和性能需求，選擇合適的關(guān)系型數(shù)據(jù)庫。
非關(guān)系型數(shù)據(jù)庫（NoSQL）：指的是分布式的、非關(guān)系型的、不保證遵循ACID原則的數(shù)據(jù)存儲系統(tǒng)。大量的NoSql數(shù)據(jù)庫如MongoDB[11]?、Redis、Memcache出于簡化數(shù)據(jù)庫結(jié)構(gòu)、避免冗余、影響性能的表連接、摒棄復(fù)雜分布式的目的被設(shè)計。
2.1 NoSQL數(shù)據(jù)庫分類
2.1.1 鍵值對數(shù)據(jù)庫 (Key/value databases)
鍵值對數(shù)據(jù)庫是最簡單的幾種NoSQL數(shù)據(jù)庫之一，由帶索引的鍵 (indexed key) 和其所對應(yīng)的值 (value) 組成。
當(dāng)給出一個鍵時，鍵值對數(shù)據(jù)庫可以通過哈希機(jī)制快速找到與其相關(guān)聯(lián)的值。哈希機(jī)制的時間復(fù)雜度為常數(shù)時間 (constant time)，這意味著即使數(shù)據(jù)規(guī)模很大，鍵值對數(shù)據(jù)庫依然可以維持高性能。
鍵值對的鍵可以是任意類別的對象，但通常是一個字符串 (string)。鍵值對的值一般來說是模糊的BLOB類型（即：一串?dāng)?shù)據(jù)庫不解讀的字節(jié)）。
鍵值對數(shù)據(jù)庫包括：Redis, Amazon DynamoDB, Riak以及Oracle NoSQL。一些像是Cassandra一樣的表格式的NoSQL數(shù)據(jù)庫也可以滿足鍵值對的需求。
思考：鍵值對數(shù)據(jù)庫都是一個key對應(yīng)一或多個value,而全球海洋數(shù)據(jù)是三個維度，經(jīng)緯度和時間對應(yīng)u風(fēng)或v風(fēng)數(shù)據(jù)。故排除這類分布式數(shù)據(jù)庫。
其實Redis應(yīng)該可以用key-list-list，就是list嵌套list實現(xiàn)多維，但費力。
2.1.2 文檔型數(shù)據(jù)庫 (Document databases)
文檔型數(shù)據(jù)庫由基本的鍵值對存儲模式而來，但是存儲數(shù)據(jù)的“文檔”則更為復(fù)雜一些。
每一個文檔都會被分配一個唯一的鍵 (key)，用來調(diào)取文檔。這些數(shù)據(jù)庫是為了存儲、調(diào)取和管理面向文檔的信息（通常以JSON的格式存儲）而設(shè)計的。
因為文檔型數(shù)據(jù)庫可以檢閱文檔內(nèi)容，它們可以實現(xiàn)一些額外的調(diào)取處理。與要求靜態(tài)模式(schema) 的關(guān)系型數(shù)據(jù)庫管理系統(tǒng) (RDBMSs) 相比，文檔型數(shù)據(jù)庫則有著由文檔內(nèi)容定義的、更為靈活的模式。
文檔型數(shù)據(jù)庫的例子包括MongoDB和CouchDB。注意：一些關(guān)系型數(shù)據(jù)庫管理系統(tǒng)和非純存儲文檔的NoSQL數(shù)據(jù)庫也可以存儲和查詢JSON文檔，其中包括了Cassandra。
思考：同樣不適合全球海洋數(shù)據(jù)的處理
2.1.3 表格型數(shù)據(jù)庫 (Tabular databases)
表格型數(shù)據(jù)庫用行和列來存儲數(shù)據(jù)，但是與傳統(tǒng)的數(shù)據(jù)庫管理系統(tǒng)略有不同。
這種數(shù)據(jù)庫也被稱為寬表存儲 (wide-column stores) 或是分區(qū)行存儲 (partitioned row stores)，他們提供把數(shù)據(jù)庫中屬于同一個分區(qū)的相關(guān)行分到同一數(shù)據(jù)副本的能力，從而達(dá)到更快查詢的目的。
與關(guān)系型數(shù)據(jù)庫管理系統(tǒng)不同的是，表格的格式并不是嚴(yán)格固定的。例如Apache Cassandra?并不要求表格中所有的行的每一列都要有值。
與鍵值對和文檔型數(shù)據(jù)庫一樣，表格型數(shù)據(jù)庫也使用哈希函數(shù)來調(diào)取表格中的記錄。
表格型數(shù)據(jù)庫包括：Cassandra、HBase以及Google Bigtable。
思考：應(yīng)該最后就是從表格型數(shù)據(jù)庫中找一個開源的、合適的來進(jìn)行數(shù)據(jù)處理。其中HBase要收費，暫時放棄。
還有圖型數(shù)據(jù)庫和混合型數(shù)據(jù)庫，但應(yīng)該對全球海洋數(shù)據(jù)處理不太合適，暫且不考慮。
3、所需數(shù)據(jù)庫要求
? 首先要知道我們要處理的這全球海洋數(shù)據(jù)的特點：
?目前簡單分析，可以知道最少要滿足以下三個要求：
4、目前備選方案
4.1 收費數(shù)據(jù)庫
??查閱知網(wǎng)相關(guān)文獻(xiàn)，搜索數(shù)據(jù)庫處理氣象數(shù)據(jù)關(guān)鍵詞，知道了GBase數(shù)據(jù)庫、虛谷數(shù)據(jù)庫、TableStore、Hbase等數(shù)據(jù)庫等可以較適合地處理海量氣象數(shù)據(jù)。特別是TableStore數(shù)據(jù)庫，TableStore是一款阿里自研的分布式NoSQL服務(wù)，可以提供超大規(guī)模的存儲容量，支撐超大規(guī)模的并發(fā)訪問和低延遲的性能，可以很好的解決氣象數(shù)據(jù)的規(guī)模和查詢性能問題，并且該數(shù)據(jù)庫有基于TableStore的海量氣象格點數(shù)據(jù)解決方案實戰(zhàn)等文章可以查閱學(xué)習(xí)，有諸多便利。
但因為這些數(shù)據(jù)庫并非開源，成本較高，且因為非開源故用戶少，相關(guān)數(shù)據(jù)庫學(xué)習(xí)方面不如開源數(shù)據(jù)庫便利，故暫且不考慮。
思考：如果考慮收費數(shù)據(jù)庫的話，最好的是TableStore。
4.2 MySQL數(shù)據(jù)庫
開始潛意識認(rèn)為MySQL這種關(guān)系型數(shù)據(jù)庫不適合做為該項目的數(shù)據(jù)庫。阿里巴巴《Java開發(fā)手冊》提出：單表行數(shù)超過500萬行或者單表容量超過2GB，才推薦進(jìn)行分庫分表。但是如果按照時間來進(jìn)行讀取數(shù)據(jù)，大約一個生成的特定時刻全球海洋數(shù)據(jù)的txt文件里大約為480*61個數(shù)據(jù)。一年有722個這樣的txt文件，一共有31年，存儲肯定是沒問題，目前不知道具體實現(xiàn)細(xì)節(jié)是怎樣的，能不能用MySQL的分庫分表操作來實現(xiàn)功能，以及最后查詢時延會不會過大。
有CSDN相關(guān)文檔使用python爬取全國天氣數(shù)據(jù)并導(dǎo)入MySQL數(shù)據(jù)庫表提供一點思路，但因數(shù)據(jù)量不同故或許存在許多問題，具體能否用MySQL進(jìn)行項目應(yīng)用有待商榷。
思考：實在沒辦法的時候，可以考慮，應(yīng)該是可以做到分庫分表始實現(xiàn)所需要求的，但是應(yīng)該會事倍功半。
4.3 cassandra數(shù)據(jù)庫
Cassandra是一套開源分布式NoSQL數(shù)據(jù)庫系統(tǒng)。它最初由Facebook開發(fā)，用于儲存收件箱等簡單格式數(shù)據(jù)，集GoogleBigTable的數(shù)據(jù)模型與Amazon Dynamo的完全分布式的架構(gòu)于一身Facebook于2008將 Cassandra 開源，此后，由于Cassandra良好的可擴(kuò)展性，被Digg、Twitter等知名Web 2.0網(wǎng)站所采納，成為了一種流行的分布式結(jié)構(gòu)化數(shù)據(jù)存儲方案。
Cassandra是一個混合型的非關(guān)系的數(shù)據(jù)庫，類似于Google的BigTable。其主要功能比Dynamo （分布式的Key-Value存儲系統(tǒng)）更豐富，但支持度卻不如文檔存儲MongoDB（介于關(guān)系數(shù)據(jù)庫和非關(guān)系數(shù)據(jù)庫之間的開源產(chǎn)品，是非關(guān)系數(shù)據(jù)庫當(dāng)中功能最豐富，最像關(guān)系數(shù)據(jù)庫的。支持的數(shù)據(jù)結(jié)構(gòu)非常松散，是類似json的bjson格式，因此可以存儲比較復(fù)雜的數(shù)據(jù)類型）。
主要是屬于表格型數(shù)據(jù)庫，且開源。表格型數(shù)據(jù)庫用行和列來存儲數(shù)據(jù)，但是與傳統(tǒng)的數(shù)據(jù)庫管理系統(tǒng)略有不同。與鍵值對和文檔型數(shù)據(jù)庫一樣，表格型數(shù)據(jù)庫也使用哈希函數(shù)來調(diào)取表格中的記錄。
思考：表格型數(shù)據(jù)庫，且開源，目前是最優(yōu)選擇，如果后續(xù)沒有更合適的數(shù)據(jù)庫，優(yōu)先拿此數(shù)據(jù)庫進(jìn)行嘗試。
4.4 Google Bigtable數(shù)據(jù)庫
Bigtable是一個分布式多維映射表，表中的數(shù)據(jù)通過一個行關(guān)鍵字（Row Key）、一個列關(guān)鍵字（Column Key）以及一個時間戳（Time Stamp）進(jìn)行索引。Bigtable對存儲在其中的數(shù)據(jù)不做任何解析，一律看做字符串，具體數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)需要用戶自行處理。
思考：也是表格型數(shù)據(jù)庫，開源，全球海洋數(shù)據(jù)可以用這個數(shù)據(jù)庫，行為經(jīng)度，列為緯度，時間戳為時間。理論上應(yīng)該可以實現(xiàn)。還未具體查閱。
4.5 SequoiaDB巨杉數(shù)據(jù)庫
進(jìn)入巨杉數(shù)據(jù)庫的關(guān)鍵技術(shù)——分區(qū)概念，我們支持兩種分區(qū)，一種是水平分區(qū)，另一種是垂直分區(qū)。
水平分區(qū)： 這里提到兩個概念，一是集合空間（CS），二是集合（CL），我們基本數(shù)據(jù)存儲單元是集合，可以等同于傳統(tǒng)關(guān)系型數(shù)據(jù)庫里的表，水平分區(qū)的概念是在集合里，可以選定一個字段或者多個字段作為水平分區(qū)的鍵（key）。
巨杉數(shù)據(jù)庫會根據(jù)你選定的鍵或者鍵值，把數(shù)據(jù)對應(yīng)到集合對應(yīng)的所有分區(qū)。水平分區(qū)最大的好處是可以把多個節(jié)點組成復(fù)制組，你可以把數(shù)據(jù)均勻的分布到多個數(shù)據(jù)節(jié)點或者多個復(fù)制組，避免單一存儲或者單一節(jié)點帶來的瓶頸，對于分布式數(shù)據(jù)庫來講是必不可少的特性。
垂直分區(qū)： 垂直分區(qū)更多的跟業(yè)務(wù)邏輯相關(guān)，常見信息是流水表，如果你想保存銀行過去10年甚至20年的交易流水表，這是海量天文數(shù)字的數(shù)據(jù)。因此，我們可以將龐大的數(shù)據(jù)從邏輯意義上區(qū)分開，按時間戳作為分隔的字段。
多維分區(qū)：
多維分區(qū)機(jī)制，把水平分區(qū)和垂直分區(qū)兩種方式結(jié)合在一起使用。這跟垂直分區(qū)的圖類似，在每一個子集合內(nèi)部可以用水平分區(qū)，均勻打散到多個不同的物理存儲上。
思考：應(yīng)該是屬于鍵值型數(shù)據(jù)庫的一種，但是它可以選定一個字段或多個字段作為key，而非固定一個字段作為Key,如果選經(jīng)緯度、時間作為key，應(yīng)該就可以滿足項目要求。重點是開源，但不為首選，還是表格型數(shù)據(jù)庫最合適。
總結(jié)
- 上一篇： 地图坐标转换-火星坐标
- 下一篇： mysql 登录指定sock路径