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

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

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

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

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

2 Berkeley DB

Berkeley DB是由sleepycat software開發(fā)的輕量級嵌入式數(shù)據(jù)庫，它不僅適用于嵌入式系統(tǒng)，而且可以直接連接到應用程序內(nèi)部，和應用程序運行在同一地址空間。傳統(tǒng)的數(shù)據(jù)庫一般作為獨立服務器工作，而Berkeley DB是軟件開發(fā)庫，開發(fā)者將它嵌入到應用程序中，應用程序本身就是一個服務器，而只是利用嵌入式數(shù)據(jù)庫開發(fā)來實現(xiàn)定制的數(shù)據(jù)庫邏輯，避免了與應用服務器進程間通信的開銷，因此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ù)庫文件提供基本的支持。在沒有事務管理的情況下，該子系統(tǒng)中的模塊可單獨使用，為應用程序提供快速高效的數(shù)據(jù)存取服務。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

采用上述方法以時間點（小時）為單位命名數(shù)據(jù)庫，存放對應時間里的信息。但由于路由器偶爾會發(fā)生信息滯留現(xiàn)象（路由器滯留時間最大為30 分鐘，例如：可能6 點30 以后收到的信息7 點才轉(zhuǎn)發(fā)），如果按照上述存儲方法將會存入7 點的數(shù)據(jù)庫。導致存儲信息失真，不是網(wǎng)絡某一時刻的真實反映。為解決這一現(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ù)庫、那個進程負責關閉數(shù)據(jù)庫、多個進程之間如何管理。為解決這些問題系統(tǒng)采取了基于多進程、多數(shù)據(jù)庫的加鎖機制和心跳機制。

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

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

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

由于Berkeley DB 不是關系型數(shù)據(jù)庫，因此我們不能像對關系型數(shù)據(jù)庫一樣對其進行復合條件查詢，而經(jīng)?？蛻粜枰榭茨骋欢螘r間里的圖形如：某一段時間里某一端口流量圖、某一段時間里某一種服務圖等等，而這些圖形的成圖數(shù)據(jù)都是基于復合條件查詢所得到的。為解決這個問題Berkeley DB 為我們提供了附加數(shù)據(jù)庫（二級數(shù)據(jù)庫），在附加數(shù)據(jù)庫中我們可以設定任意的key（可以是關系數(shù)據(jù)庫中多列屬性的組合），因此我們可以根據(jù)附加數(shù)據(jù)庫的key方便地在附加數(shù)據(jù)庫中進行查詢，得到所需要的數(shù)據(jù)然后在成圖模塊展示，為此我們引入了在對網(wǎng)絡流量數(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ù)的插入速度，結合Berkeley DB 的四種訪問方式，我們?yōu)橹鲾?shù)據(jù)庫采取Queue 訪問方式以提高數(shù)據(jù)插入速度，并且以時間作為key。而對于附加數(shù)據(jù)庫我們則BTree 訪問方式以提高查詢效率，而其key 則根據(jù)不同的關聯(lián)函數(shù)產(chǎn)生，這里我們以附加數(shù)據(jù)庫SCRIP_SUBDB 為例討論主數(shù)據(jù)庫與附加數(shù)據(jù)庫之間的關系：[!--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ù)據(jù)庫

init_primary_db(conf,&(current-db),CURRENT,type); //初始化當前時間點數(shù)據(jù)庫

⋯⋯

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

⋯⋯

}

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

//附加數(shù)據(jù)庫到主數(shù)據(jù)庫設定key 的關聯(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ù)關聯(lián)到主數(shù)據(jù)庫并設定附加數(shù)據(jù)庫中的key

⋯⋯

}

⋯⋯

4 小結:

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