嵌入式數(shù)據(jù)庫的海量存儲技術(shù)研究

1嵌入式數(shù)據(jù)庫

通常， 我們采用數(shù)據(jù)庫來實現(xiàn)對數(shù)據(jù)的存儲、檢索等功能。像MySQL這類基于C/S結(jié)構(gòu)的關(guān)系型數(shù)據(jù)庫系統(tǒng)， 雖然代表著目前數(shù)據(jù)庫應(yīng)用的主流， 卻并不能滿足所有應(yīng)用場合的需要。很多的應(yīng)用，僅僅利用到了這些數(shù)據(jù)庫產(chǎn)品的基本特性而已。有時我們需要的可能只是一個簡單的基于磁盤文件的數(shù)據(jù)庫系統(tǒng)，這樣就不必安裝龐大的數(shù)據(jù)庫服務(wù)器， 以簡化數(shù)據(jù)庫應(yīng)用程序的設(shè)計。在某些特殊應(yīng)用場合，比如在嵌入式系統(tǒng)中，由于系統(tǒng)的硬件軟件資源都有限，這些數(shù)據(jù)庫產(chǎn)品就明顯有一些臃腫，甚至是不可實現(xiàn)的。在這些情況下，嵌入式數(shù)據(jù)庫的優(yōu)勢就特別明顯了。

嵌入式數(shù)據(jù)庫通常與操作系統(tǒng)和具體應(yīng)用集成在一起， 無須獨立運行的數(shù)據(jù)庫引擎，由程序直接調(diào)用相應(yīng)的API去實現(xiàn)對數(shù)據(jù)的存取操作。更直白地講， 嵌入式數(shù)據(jù)庫是一種具備了基本數(shù)據(jù)庫特性的數(shù)據(jù)文件。嵌入式數(shù)據(jù)庫與其它數(shù)據(jù)庫產(chǎn)品的區(qū)別是，前者是程序驅(qū)動式，而后者是引擎響應(yīng)式。嵌入式數(shù)據(jù)庫的一個很重要的特點是它們的體積非常小，編譯后的產(chǎn)品也不過幾十KB， 在一些移動設(shè)備上極具競爭力。

從目前嵌入式應(yīng)用的發(fā)展趨勢來看，嵌入式數(shù)據(jù)庫的實現(xiàn)必須充分體現(xiàn)系統(tǒng)的可定制性，即系統(tǒng)選擇的技術(shù)路線要面向具體的行業(yè)應(yīng)用，因而研究源碼開放的嵌入式數(shù)據(jù)庫具有特殊意義。

2 Berkeley DB

Berkeley DB是由sleepycat software開發(fā)的輕量級嵌入式數(shù)據(jù)庫，它不僅適用于嵌入式系統(tǒng)，而且可以直接連接到應(yīng)用程序內(nèi)部，和應(yīng)用程序運行在同一地址空間。傳統(tǒng)的數(shù)據(jù)庫一般作為獨立服務(wù)器工作，而Berkeley DB是軟件開發(fā)庫，開發(fā)者將它嵌入到應(yīng)用程序中，應(yīng)用程序本身就是一個服務(wù)器，而只是利用嵌入式數(shù)據(jù)庫開發(fā)來實現(xiàn)定制的數(shù)據(jù)庫邏輯，避免了與應(yīng)用服務(wù)器進程間通信的開銷，因此Berkeley DB具有較高的運行效率，適用于資源受限的嵌入式系統(tǒng)。

一般而言，Berkeley DB數(shù)據(jù)庫系統(tǒng)可以大致分為五個子系統(tǒng)，如圖1所示。

圖1 Berkeley DB 子系統(tǒng)圖

1、 存取管理子系統(tǒng)（Access Methods）

該子系統(tǒng)為創(chuàng)建和訪問數(shù)據(jù)庫文件提供基本的支持。在沒有事務(wù)管理的情況下，該子系統(tǒng)中的模塊可單獨使用，為應(yīng)用程序提供快速高效的數(shù)據(jù)存取服務(wù)。

2、 內(nèi)存池管理子系統(tǒng)（Memory Pool）

該子系統(tǒng)就是Berkeley DB所使用的通用共享內(nèi)存緩沖區(qū)，該子系統(tǒng)可以被應(yīng)用程序單獨使用。

3、 事務(wù)子系統(tǒng)（Transaction）

該子系統(tǒng)為Berkekey DB提供事務(wù)管理功能，保證操作的原則性、一致性和孤立性。事務(wù)子系統(tǒng)適用于對需要事務(wù)保證的數(shù)據(jù)進行修改的場合。

4、 鎖子系統(tǒng)（Locking）

該子系統(tǒng)提供進程之間以及進程內(nèi)部的并發(fā)管理機制，為系統(tǒng)提供多用戶讀取和單用戶修改同一對象的共享控制。該子系統(tǒng)可以被應(yīng)用程序單獨使用。

5、 日志子系統(tǒng)（Logging）

該子系統(tǒng)采用的是先寫日志的策略，支持事務(wù)子系統(tǒng)進行數(shù)據(jù)恢復(fù)，保證數(shù)據(jù)一致性。

3 基于嵌入式數(shù)據(jù)庫的海量存儲技術(shù)在網(wǎng)絡(luò)性能管理系統(tǒng)中的應(yīng)用

3.1 嵌入式數(shù)據(jù)庫Berkeley DB 處理海量數(shù)據(jù)存儲

傳統(tǒng)的網(wǎng)絡(luò)管理軟件在海量數(shù)據(jù)存儲方面大部分采取大型關(guān)系型數(shù)據(jù)庫，由于網(wǎng)絡(luò)管理軟件要與數(shù)據(jù)庫服務(wù)器進行通信，這種方式造成了系統(tǒng)性能的極大下降，另外隨著所管網(wǎng)絡(luò)規(guī)模的增大，信息采集的急劇增加，緩慢而頻繁的數(shù)據(jù)庫讀寫操作來不及處理實時采集到的海量數(shù)據(jù)，導(dǎo)致數(shù)據(jù)丟失，網(wǎng)絡(luò)管理失真，甚至會導(dǎo)致系統(tǒng)的癱瘓。也有少數(shù)網(wǎng)絡(luò)管理軟件采取使用一種日志文件以ASCII 文本形式來記錄采集到的流量數(shù)據(jù)，通常該種日志文件具有常量大小的特征，能夠支持長期的網(wǎng)絡(luò)監(jiān)測任務(wù)，如國內(nèi)外最為流行的免費且開放源代碼的流量監(jiān)測軟件MRTG 就是采用這種方式實現(xiàn)海量數(shù)據(jù)存儲的。MRTG 定期對數(shù)據(jù)進行整合，根據(jù)記錄數(shù)據(jù)的日期不同而以不同的粒度保存數(shù)據(jù)，隨著時間的推移，相應(yīng)數(shù)據(jù)的粒度逐漸變大，但這種方式存在兩個缺點：（1）所存儲的數(shù)據(jù)粒度受到限制，如不能從中得到一個月前的某天平均每半個小時的數(shù)據(jù)；（2）每次數(shù)據(jù)采集后，MRTG 都根據(jù)日志文件進行流量圖生成，并以HTML 格式呈現(xiàn)，而在實際應(yīng)用場合，一個端口的流量統(tǒng)計分析圖形被用戶調(diào)用查看的概率遠遠小于不被調(diào)用的概率，因此浪費了大量用于生成圖形的系統(tǒng)開銷，隨著網(wǎng)絡(luò)規(guī)模的擴大，MTRG 在性能上明顯不能滿足要求。本文提出了一種如圖2所示的流量數(shù)據(jù)采集及存儲方案。網(wǎng)絡(luò)性能管理軟件實時地接收路由器發(fā)送過來的Netflow/sFlow 包（當然這里也包括用SNMP 協(xié)議定時采集到的流量數(shù)據(jù)），將其結(jié)果存儲到嵌入式數(shù)據(jù)庫Berkeley DB 當中，供長期歷史保存。與MRTG 不同的是：（1）它采用了嵌入式數(shù)據(jù)庫Berkeley DB, Berkeley DB可以直接連接到應(yīng)用程序內(nèi)部，和應(yīng)用程序運行在同一地址空間，因此它不需要與另外的數(shù)據(jù)庫應(yīng)用程序進行通信,提高了應(yīng)用程序的速度,減少磁盤操作的時間,防止了數(shù)據(jù)因磁盤操作緩慢而導(dǎo)致的數(shù)據(jù)丟失現(xiàn)象。（2）它并非每次采集都生成圖形，而是引入觸發(fā)控制方式的“按需成圖”，當客戶需要查看某一段時間里的圖形、或者是某一端口流量、或者是某一種服務(wù)的圖形等時，只需對成圖控制模塊執(zhí)行相應(yīng)的操作，成圖模塊則向數(shù)據(jù)庫里查找特定的數(shù)據(jù)生成相應(yīng)的圖形。

圖2 流量數(shù)據(jù)采集及存儲方案圖

3.2 多進程、多數(shù)據(jù)庫加鎖機制在網(wǎng)絡(luò)性能管理系統(tǒng)中處理海量數(shù)據(jù)的實現(xiàn)

網(wǎng)絡(luò)管理的前提是信息采集，全面而實時地采集到所有的信息，然后對信息進行分類匯總，進而使網(wǎng)絡(luò)管理軟件實現(xiàn)：網(wǎng)絡(luò)性能實時監(jiān)測、系統(tǒng)性能實時監(jiān)測、應(yīng)用性能實時監(jiān)測、SLA 服務(wù)質(zhì)量管理、故障預(yù)警、DOS 攻擊定位、病毒掃描、統(tǒng)計分析報告、網(wǎng)絡(luò)容量趨勢分析、系統(tǒng)管理與維護等功能。由于Berkeley DB 單個數(shù)據(jù)庫的容量只能為256T，而網(wǎng)絡(luò)管理信息龐大，為了擴充其存儲容量，采取了多個數(shù)據(jù)庫的方法。另外客戶在使用網(wǎng)絡(luò)性能管理系統(tǒng)軟件的成圖控制模塊時，往往關(guān)注的是某一段時間里的圖形如：某一段時間里某一端口流量圖、某一段時間里某一種服務(wù)圖等等，因此為了日后的成圖，我們以時間（年、月、日）為單位建立若干個數(shù)據(jù)庫。數(shù)據(jù)庫名以某年某月某日某小時（24 小時制）命名，來存放該小時里采集到的信息。另外為了緩沖網(wǎng)絡(luò)管理當中采集到的海量信息，我們采取了消息隊列機制，父進程將采集到的信息先寫入消息隊列。然后子進程從消息隊列中讀出信息寫入數(shù)據(jù)庫（為了防止消息隊列中信息過多單進程來不及讀消息隊列并寫數(shù)據(jù)庫而導(dǎo)致消息隊列阻塞,整個系統(tǒng)效率低下。為此我們創(chuàng)建了多個子進程來讀消息隊列寫數(shù)據(jù)庫）。

采用上述方法以時間點（小時）為單位命名數(shù)據(jù)庫，存放對應(yīng)時間里的信息。但由于路由器偶爾會發(fā)生信息滯留現(xiàn)象（路由器滯留時間最大為30 分鐘，例如：可能6 點30 以后收到的信息7 點才轉(zhuǎn)發(fā)），如果按照上述存儲方法將會存入7 點的數(shù)據(jù)庫。導(dǎo)致存儲信息失真，不是網(wǎng)絡(luò)某一時刻的真實反映。為解決這一現(xiàn)象，每次打開兩個數(shù)據(jù)庫,即既打開當前點的數(shù)據(jù)庫亦打開前一時間點的數(shù)據(jù)庫。當收到數(shù)據(jù)包時，根據(jù)數(shù)據(jù)包中Netflow/sFlow流到達路由器的時間來判別寫哪個數(shù)據(jù)庫。

由于上述兩個原因系統(tǒng)當中存在著多個子進程寫多個數(shù)據(jù)庫，如果不采取一定的措施很容易發(fā)生一序列的問題如：哪個進程負責創(chuàng)建數(shù)據(jù)庫、那個進程負責關(guān)閉數(shù)據(jù)庫、多個進程之間如何管理。為解決這些問題系統(tǒng)采取了基于多進程、多數(shù)據(jù)庫的加鎖機制和心跳機制。

多進程、多數(shù)據(jù)庫的加鎖機制實現(xiàn)流程如圖3所示

圖3 多進程、多數(shù)據(jù)庫的加鎖機制實現(xiàn)流程圖

3.3 多個附加數(shù)據(jù)庫查詢機制的實現(xiàn)

由于Berkeley DB 不是關(guān)系型數(shù)據(jù)庫，因此我們不能像對關(guān)系型數(shù)據(jù)庫一樣對其進行復(fù)合條件查詢，而經(jīng)?？蛻粜枰榭茨骋欢螘r間里的圖形如：某一段時間里某一端口流量圖、某一段時間里某一種服務(wù)圖等等，而這些圖形的成圖數(shù)據(jù)都是基于復(fù)合條件查詢所得到的。為解決這個問題Berkeley DB 為我們提供了附加數(shù)據(jù)庫（二級數(shù)據(jù)庫），在附加數(shù)據(jù)庫中我們可以設(shè)定任意的key（可以是關(guān)系數(shù)據(jù)庫中多列屬性的組合），因此我們可以根據(jù)附加數(shù)據(jù)庫的key方便地在附加數(shù)據(jù)庫中進行查詢，得到所需要的數(shù)據(jù)然后在成圖模塊展示，為此我們引入了在對網(wǎng)絡(luò)流量數(shù)據(jù)做統(tǒng)計時使用頻率較高、方便成圖模塊查詢的的5 個附加數(shù)據(jù)庫分別是： SCRIP_SUBDB 、DSTIP_SUBDB 、SRCPORT_SUBDB 、DSTPORT_SUBDB 、STARTTIME_SUBDB。而且根據(jù)實際的情況我們還可以增加附加數(shù)據(jù)庫的個數(shù)。另外為了提高數(shù)據(jù)庫的查詢效率和數(shù)據(jù)的插入速度，結(jié)合Berkeley DB 的四種訪問方式，我們?yōu)橹鲾?shù)據(jù)庫采取Queue 訪問方式以提高數(shù)據(jù)插入速度，并且以時間作為key。而對于附加數(shù)據(jù)庫我們則BTree 訪問方式以提高查詢效率，而其key 則根據(jù)不同的關(guān)聯(lián)函數(shù)產(chǎn)生，這里我們以附加數(shù)據(jù)庫SCRIP_SUBDB 為例討論主數(shù)據(jù)庫與附加數(shù)據(jù)庫之間的關(guān)系：