嵌入式資料庫的海量儲存技術研究

嵌入式資料庫的海量儲存技術研究時間：2009-03-04 15:52:25 來源：微電腦資訊 作者：許薇

1嵌入式資料庫

通
常， 我們採用資料庫來實現對資料的儲存、檢索等功能。像MySQL這類基於C/S結構的關係型資料庫系統， 雖然代表著目前資料庫應用的主流，
卻並不能滿足所有應用場合的需要。很多的應用，僅僅利用到了這些資料庫產品的基本特性而已。有時我們需要的可能只是一個簡單的基於磁碟檔案的資料庫系統，
這樣就不必安裝龐大的資料庫伺服器，
以簡化資料庫應用程式的設計。在某些特殊應用場合，比如在嵌入式系統中，由於系統的硬體軟體資源都有限，這些資料庫產品就明顯有一些臃腫，甚至是不可實現
的。在這些情況下，嵌入式資料庫的優勢就特別明顯了。

嵌入式資料庫通常與作業系統和具體應用整合在一起，
無須獨立啟動並執行資料庫引擎，由程式直接調用相應的API去實現對資料的存取操作。更直白地講，
嵌入式資料庫是一種具備了基本資料庫特性的資料檔案。嵌入式資料庫與其它資料庫產品的區別是，前者是程式驅動式，而後者是引擎響應式。嵌入式資料庫的一個
很重要的特點是它們的體積非常小，編譯後的產品也不過幾十KB， 在一些行動裝置上極具競爭力。

從目前嵌入式應用的發展趨勢來看，嵌入式資料庫的實現必須充分體現系統的可定製性，即系統選擇的技術路線要面向具體的行業應用，因而研究源碼開放的嵌入式資料庫具有特殊意義。

2 Berkeley DB

Berkeley
DB是由sleepycat
software開發的輕量級嵌入式資料庫，它不僅適用於嵌入式系統，而且可以直接連接到應用程式內部，和應用程式運行在同一地址空間。傳統的資料庫一般
作為獨立伺服器工作，而Berkeley
DB是軟體開發庫，開發人員將它嵌入到應用程式中，應用程式本身就是一個伺服器，而只是利用嵌入式資料庫開發來實現定製的資料庫邏輯，避免了與應用伺服器進
程間通訊的開銷，因此Berkeley DB具有較高的運行效率，適用於資源受限的嵌入式系統。

一般而言，Berkeley DB資料庫系統可以大致分為五個子系統，1所示。

圖1 Berkeley DB 子系統圖

1、  存取管理子系統（Access Methods）

該子系統為建立和訪問資料庫檔案提供基本的支援。在沒有交易管理的情況下，該子系統中的模組可單獨使用，為應用程式提供快速高效的資料存取服務。

2、  記憶體池管理子系統（Memory Pool）

該子系統就是Berkeley DB所使用的通用共用記憶體緩衝區，該子系統可以被應用程式單獨使用。

3、  事務子系統（Transaction）

該子系統為Berkekey DB提供交易管理功能，保證操作的原則性、一致性和孤立性。事務子系統適用於對需要事務保證的資料進行修改的場合。

4、  鎖子系統（Locking）

該子系統提供進程之間以及進程內部的並發管理機制，為系統提供多使用者讀取和單使用者修改同一對象的共用控制。該子系統可以被應用程式單獨使用。

5、  日誌子系統（Logging）

該子系統採用的是先寫日誌的策略，支援事務子系統進行資料恢複，保證資料一致性。

3 基於嵌入式資料庫的海量儲存技術在網路效能管理系統中的應用

3.1 嵌入式資料庫Berkeley DB 處理海量資料存放區

傳
統的網路管理軟體在海量資料存放區方面大部分採取大型關係型資料庫，由於網路管理軟體要與資料庫伺服器進行通訊，這種方式造成了系統效能的極大下降，另外隨
著所管網路規模的增大，資訊採集的急劇增加，緩慢而頻繁的資料庫讀寫操作來不及處理即時採集到的海量資料，導致資料丟失，網路管理失真，甚至會導致系統的
癱瘓。也有少數網路管理軟體採取使用一種記錄檔以ASCII
文本形式來記錄採集到的流量資料，通常該種記錄檔具有常量大小的特徵，能夠支援長期的網路監測任務，如國內外最為流行的免費且開放原始碼的流量監測軟體
MRTG 就是採用這種方式實現海量資料存放區的。MRTG
定期對資料進行整合，根據記錄資料的日期不同而以不同的粒度儲存資料，隨著時間的推移，相應資料的粒度逐漸層大，但這種方式存在兩個缺點：（1）所儲存的
資料粒度受到限制，如不能從中得到一個月前的某天平均每半個小時的資料；（2）每次資料擷取後，MRTG 都根據記錄檔進行流量圖產生，並以HTML
格式呈現，而在實際應用場合，一個連接埠的流量統計分析圖形被使用者調用查看的機率遠遠小於不被調用的機率，因此浪費了大量用於產生圖形的系統開銷，隨著網路
規模的擴大，MTRG
在效能上明顯不能滿足要求。本文提出了一種2所示的流量資料擷取及儲存方案。網路效能管理軟體即時地接收路由器發送過來的Netflow/sFlow
包（當然這裡也包括用SNMP 協議定時採集到的流量資料），將其結果儲存到嵌入式資料庫Berkeley DB 當中，供長期曆史儲存。與MRTG
不同的是：（1）它採用了嵌入式資料庫Berkeley DB, Berkeley
DB可以直接連接到應用程式內部，和應用程式運行在同一地址空間，因此它不需要與另外的資料庫應用程式進行通訊,提高了應用程式的速度,減少磁碟操作的時
間,防止了資料因磁碟操作緩慢而導致的資料丟失現象。（2）它並非每次採集都產生圖形，而是引入觸發控制方式的“按需成圖”，當客戶需要查看某一段時間裡
的圖形、或者是某一連接埠流量、或者是某一種服務的圖形等時，只需對成圖控制模組執行相應的操作，成圖模組則向資料庫裡尋找特定的資料產生相應的圖形。

圖2 流量資料擷取及儲存方案圖

3.2 多進程、多資料庫加鎖機制在網路效能管理系統中處理海量資料的實現

網
絡管理的前提是資訊採集，全面而即時地採集到所有的資訊，然後對資訊進行分類匯總，進而使網路管理軟體實現：網路效能即時監測、系統效能即時監測、應用性
能即時監測、SLA 服務品質管理、故障預警、DOS
攻擊定位、病毒掃描、統計分析報告、網路容量趨勢分析、系統管理與維護等功能。由於Berkeley DB
單個資料庫的容量只能為256T，而網路管理資訊龐大，為了擴充其儲存容量，採取了多個資料庫的方法。另外客戶在使用網路效能管理系統軟體的成圖控制模組
時，往往關注的是某一段時間裡的圖形如：某一段時間裡某一連接埠流量圖、某一段時間裡某一種服務圖等等，因此為了日後的成圖，我們以時間（年、月、日）為單
位建立若干個資料庫。資料庫名以某年某月某日某小時（24
小時制）命名，來存放該小時裡採集到的資訊。另外為了緩衝網路管理當中採集到的海量資訊，我們採取了訊息佇列機制，父進程將採集到的資訊先寫入訊息佇列。
然後子進程從訊息佇列中讀出資訊寫入資料庫（為了防止訊息佇列中資訊過多單進程來不及讀訊息佇列並寫資料庫而導致訊息佇列阻塞,整個系統效率低下。為此我
們建立了多個子進程來讀訊息佇列寫資料庫）。

採用上述方法以時間點（小時）為單位命名資料庫，存放對應時間裡的資訊。但由於路由器偶爾會發
生資訊滯留現象（路由器滯留時間最大為30 分鐘，例如：可能6 點30 以後收到的資訊7 點才轉寄），如果按照上述儲存方法將會存入7
點的資料庫。導致儲存資訊失真，不是網路某一時刻的真實反映。為解決這一現象，每次開啟兩個資料庫,即既開啟當前點的資料庫亦開啟前一時間點的資料庫。當
收到資料包時，根據資料包中Netflow/sFlow流到達路由器的時間來判別寫哪個資料庫。

由於上述兩個原因系統當中存在著多個子進程寫多個資料庫，如果不採取一定的措施很容易發生一序列的問題如：哪個進程負責建立資料庫、那個進程負責關閉資料庫、多個進程之間如何管理。為解決這些問題系統採取了基於多進程、多資料庫的加鎖機制和心跳機制。

多進程、多資料庫的加鎖機制實現流程3所示

圖3 多進程、多資料庫的加鎖機制實現流程圖

3.3 多個附加資料庫查詢機制的實現

由
於Berkeley DB
不是關係型資料庫，因此我們不能像對關係型資料庫一樣對其進行複合條件查詢，而經常客戶需要查看某一段時間裡的圖形如：某一段時間裡某一連接埠流量圖、某一
段時間裡某一種服務圖等等，而這些圖形的成圖資料都是基於複合條件查詢所得到的。為解決這個問題Berkeley DB
為我們提供了附加資料庫（二級資料庫），在附加資料庫中我們可以設定任意的key（可以是關聯式資料庫中多列屬性的組合），因此我們可以根據附加資料庫的
key方便地在附加資料庫中進行查詢，得到所需要的資料然後在成圖模組展示，為此我們引入了在對網路流量資料做統計時使用頻率較高、方便成圖模組查詢的的
5 個附加資料庫分別是： SCRIP_SUBDB 、DSTIP_SUBDB 、SRCPORT_SUBDB 、DSTPORT_SUBDB
、STARTTIME_SUBDB。而且根據實際的情況我們還可以增加附加資料庫的個數。另外為了提高資料庫的查詢效率和資料的插入速度，結合
Berkeley DB 的四種訪問方式，我們為主要資料庫採取Queue
訪問方式以提高資料插入速度，並且以時間作為key。而對於附加資料庫我們則BTree 訪問方式以提高查詢效率，而其key
則根據不同的關聯函數產生，這裡我們以附加資料庫SCRIP_SUBDB 為例討論主要資料庫與附加資料庫之間的關係：

initenv（const conf_st *conf）//初始化資料庫環境

initalldb (const conf_st *conf ,int type) //初始化所有資料庫

{

⋯⋯

init_primary_db(conf,&last-db,LAST,type);//初始化前一時間點資料庫

init_primary_db(conf,&(current-db),CURRENT,type); //初始化目前時間點資料庫

⋯⋯

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

⋯⋯

}

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

//附加資料庫到主要資料庫設定key 的關聯函數

int init_sub_db(const conf_st *conf, DB**primary_db, DB **sub_db, int sub_db_type, int/time_db_type, int type)//初始化附加資料庫

{

⋯⋯

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

DB_CREATE); //調用Berkeley DB 系統函數將附加資料關聯到主要資料庫並設定附加資料庫中的key

⋯⋯

}

⋯⋯

4 小結:

本
文作者創新點是在項目的開發和實踐過程中，我們分別以不同數量級的記錄寫入關係型資料庫Mysql
和嵌入試資料庫BerkeleyDB，比較發現引入嵌入試資料庫Berkeley DB
大大提高了系統的儲存速度，使存取時間成倍減少。由此看來,嵌入式資料庫Berkeley DB
在處理海量資料存放區上比關係型資料庫贏得了時間和速度上的優勢,但網路管理效能系統中採集到的資訊龐大，如何將Berkeley DB
資料庫中儲存的海量資料進行壓縮仍然是值得探討的問題。