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

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

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

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

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

2 Berkeley DB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

initenv（const conf_st *conf）//初始化數(shù)據(jù)庫環(huán)境

initalldb (const conf_st *conf ,int type) //初始化所有數(shù)據(jù)庫

{

⋯⋯

init_primary_db(conf,&last-db,LAST,type);//初始化前一時(shí)間點(diǎn)數(shù)據(jù)庫

init_primary_db(conf,&(current-db),CURRENT,type); //初始化當(dāng)前時(shí)間點(diǎn)數(shù)據(jù)庫

⋯⋯

INIT_SEC_DB(srcip,SRCIP,type); //該函數(shù)實(shí)際上是定義為初始化附加數(shù)據(jù)庫的一個(gè)宏

⋯⋯

}

int get_item_srcip(DB *sdbp,const DBT *pkey,const DBT *pdata,DBT *skey)

//附加數(shù)據(jù)庫到主數(shù)據(jù)庫設(shè)定key 的關(guān)聯(lián)函數(shù)

int init_sub_db(const conf_st *conf, DB**primary_db, DB **sub_db, int sub_db_type, inttime_db_type, int type)//初始化附加數(shù)據(jù)庫

{

⋯⋯

ret =(*primary)->associate(*primary_db,NULL,*sub_db,get_item_srcip,

DB_CREATE); //調(diào)用Berkeley DB 系統(tǒng)函數(shù)將附加數(shù)據(jù)關(guān)聯(lián)到主數(shù)據(jù)庫并設(shè)定附加數(shù)據(jù)庫中的key

⋯⋯

}

⋯⋯

4 小結(jié):

本文作者創(chuàng)新點(diǎn)是在項(xiàng)目的開發(fā)和實(shí)踐過程中，我們分別以不同數(shù)量級(jí)的記錄寫入關(guān)系型數(shù)據(jù)庫Mysql 和嵌入試數(shù)據(jù)庫BerkeleyDB，比較發(fā)現(xiàn)引入嵌入試數(shù)據(jù)庫Berkeley DB 大大提高了系統(tǒng)的存儲(chǔ)速度，使存取時(shí)間成倍減少。由此看來,嵌入式數(shù)據(jù)庫Berkeley DB 在處理海量數(shù)據(jù)存儲(chǔ)上比關(guān)系型數(shù)據(jù)庫贏得了時(shí)間和速度上的優(yōu)勢(shì),但網(wǎng)絡(luò)管理性能系統(tǒng)中采集到的信息龐大，如何將Berkeley DB 數(shù)據(jù)庫中存儲(chǔ)的海量數(shù)據(jù)進(jìn)行壓縮仍然是值得探討的問題。