基于氣象數據收集分發系統的RDBMS設計分析

周永吉,黃 博，孟祥龍

（1.黑龍江省氣象數據中心，黑龍江 哈爾濱 150030；2.呼蘭區氣象局，黑龍江 哈爾濱 150500）

1 引言

氣象數據收集與分發系統簡稱CTS，是全國氣象數據在傳輸與共享過程中的主體承載系統， 不但承擔從基層臺站到省級節點再到國家級節點的縱向通信業務，也承擔省際之間的數據傳輸共享業務，這使得其中衍生的氣象觀測數據及各尺度產品在量級上呈現指數倍增長，對后臺數據庫的壓力與需求巨大，傳統的數據存儲管理技術力有不逮， 因此建立在RDBMS（關系數據庫管理系統）基礎上的合理設計顯得尤為重要[1]。 在數據庫整體設計上，對于收發信息、節目表、處理日志、用戶信息、管理信息、統計信息以及各種數據字典等，采用RDBMS 進行存儲，RDBMS設計的好壞直接關系到系統執行的效率和系統的穩定性。 在軟件開發過程中，數據庫設計應遵循必要的數據庫范式理論，以確保數據的一致性與完整性，同時也要適當增加冗余，達到以空間換時間的目的，提高數據庫的運行效率。

2 RDBMS分布式管理

在數據收集分發系統數據庫的總體建設上引入了Oracle 關系數據庫技術， 關系型數據可以滿足氣象數據以及各類日志數據、 信息數據在子數據庫的結構層面能夠保持清晰的邏輯關系， 同時在面向用戶的過程中又能完整呈現。 在前臺用戶的眼中，Oracle RDBMS 的存儲架構是不可見的， 是一個整體，因此對于軟件層面的調度完全可以看做是對單一數據庫的操作， 而實際上后臺的多個子庫則在Oracle RDBMS 的合理設計下協調運作，保證子庫間相對獨立安全的數據環境，從而可以做到邏輯嚴密、架構清晰、協調統一、安全獨立。

3 設計原則與容量評估

針對氣象數據收集與分發系統， 考慮到氣象數據的特殊性，在RDBMS 設計中需要遵守如下幾條原則：

（1）在名稱設計上，數據庫、表、索引等命名要體現氣象要素的規范性， 從整體設計上制定統一規范,并沿用全國， 在面向各級分系統工程師的過程中要有對應的詳細說明，以滿足部署和運維需求。 表名分為兩個部分，中間以下劃線分割。 第一個部分分四種類型，分別為 TB(業務表)、TW(監控表)、TD(字典表)、TS(統計表)。 第二個部分對數據表的具體功能描述，功能分割用下劃線。索引的命名為IDX_表_字段縮寫(字段 1，字段 2……)。

（2）在設計數據的過程中，應當分析選擇適用的設計工具。

（3）詳細調研分析業務特征，對數據庫進行合理分區。 并進行必要的表單拆分，預估出合理的表單調用頻率，拆分設計。 同時優化索引算法[2]。

根據數據收集與分發系統的業務特點以及各種信息在數據庫中的存取頻度、存儲生命周期、數據的穩定性等屬性， 同時也為了增強數據庫結構的可讀性， 在設計過程中RDBMS 從邏輯上被分為4 個子庫，包括：收發業務子庫、配置與系統管理子庫、系統監控子庫、統計分析子庫。

以收發業務子庫為例， 其容量估算主要是根據需求階段對進入數據收集與分發系統的數據量的調研，國家級CTS 每天約有200 萬個文件收發。將數據表中每個字段的長度相加，得出每條記錄的大小。 通過記錄數和記錄大小的乘積， 算出每個數據庫表每天的存儲容量， 收發業務子庫每天產生基本數據55 G[3]。

同樣的算法加以沿用可以估算出配置與系統管理子庫產生基本數據為64 M， 系統監控子庫每天產生基本數據9 G， 統計分析子庫每天產生基本數據883 M。

根據以上對四個邏輯存儲區域的容量估算匯總，平均每天增長的容量約為64 G，為了保證數據管理的性能，每月清除一次數據，這樣數據庫的存儲容量為64G/d*30 d=1.9 T，按30%的冗余量，存儲容量約為2.5T[3-5]。

4 結論

綜上所述， 針對氣象數據尤其是海量的觀測數據以及數據產品，Oracle RDBMS 的存儲架構可以有效解決邏輯管理和并發訪問的業務需求， 在結構設計和容量估算方面加以合理分析， 可以大大提高訪問效率， 從而實現數據收集與分發業務系統的高效穩定運轉。