BDB學習筆記

介紹 

    Berkeley DB (DB)是一個高性能的，嵌入數據庫，和C語言，C++，Java，Perl，Python，PHP，Tcl以及其餘不少語言都有綁定。Berkeley DB能夠保存任意類型的鍵/值對，並且能夠爲一個鍵保存多個數據。Berkeley DB能夠支持數千的併發線程同時操做數據庫，支持最大256TB的數據，普遍用於各類操做系統包括大多數Unix類操做系統和Windows操做系統以及實時操做系統。

    在工做中使用的是java版本的bdb( Berkeley DB 如下簡稱爲bdb)，主要用來存儲計算結果提供給業務系統訪問，好比數據挖掘的結果，這類數據按期會刷新，訪問形式單一，存在數據庫有點大材小用，另外就是存儲大量的計算中間結果。整體來講bdb的性能很是不錯，但在使用時仍是遇到了一些問題，總結一些經驗教訓

問題1：按期build大量計算結果

實際使用時，寫入千萬數據後，寫入性能急劇降低，但硬盤還在飛轉，調節了不少的系統參數，關閉了事務，調大了btree索引緩存(根據bdb內部的DbCacheSize工具調節)，jvm啓動參數等等(懷疑是fgc的問題)，都沒有解決問題，最後調節了寫入數據的順序才解決了問題，一開始咱們沒有對寫入數據的key排序，而隨機寫入大量數據致使了btree索引性能的降低，改成順序寫入後，問題解決。那如何解釋硬盤飛轉呢，實際上是因爲寫操做頻繁觸發btree結構調整致使。

問題2：性能測試出現少許lock timeout，軟硬件環境不一樣出現的次數也不一樣

默認的locktimeout是500ms，而咱們在併發讀寫的性能測試時出現了少許的timeout狀況，32位環境（jdk1.5）下較少，64位環境(jdk1.6)下較多，500ms的timeout，在非高性能要求的環境下，貌似仍是短了點。問題是爲何對於不一樣的環境，出現timeout的次數差距較明顯，屢次測試發現32位環境出現的較少，64位環境出現的較多，com.sleepycat.je.util.DbCacheSize這個工具讓我發現了一些線索，原來我一直覺得這個工具就是粗略根據分支節點大概的大小，總數據量，key大小就能夠幫助咱們計算出大體的索引cache size，好比1000萬數據，key長20byte的cache size：

Inputs: records=10000000 keySize=20 dataSize=8092 nodeMax=128 density=80% overhead=10%

    Cache Size      Btree Size  Description

   871,284,622     784,156,160  Minimum, internal nodes only  

 1,180,450,133   1,062,405,120  Maximum, internal nodes only  

91,537,951,288  82,384,156,160  Minimum, internal nodes and leaf nodes  

91,847,116,800  82,662,405,120  Maximum, internal nodes and leaf nodes  

Btree levels: 4 

這個是在mac下的測試結果，而在32位的ubuntu下測試minimum internal nodes須要501M，主要的緣由是因爲在不一樣的環境對應的java對象佔用內存大小不一致，而java自己沒有提供動態檢測對象佔用內存大小的方法，在bdb中MemoryBudget類裏面定義了不一樣環境下對應的經常使用對象的大小，因此，若是用一樣的cachesize配置，在不一樣的環境下會表現出不一樣的性能，由於若是設置小了會致使部分索引的操做沒法命中緩存，性能會有所降低，因此我推測timeout的頻率不一樣的緣由是因爲固定的cachesize在不一樣的環境性能也會不一樣而致使。

問題3：數據build須要注意的

對於大數據量寫入bdb，同時須要把數據文件跨地區傳輸時，有個一個小的tips，就是在你build完數據之後，close environment後，從新開啓一個只讀的environment，設置啓動參數：

je.env.runCleaner ＝ false
je.cleaner.minUtilization ＝ 90

while (environment.cleanLog() > 0) {
    System.err.println("clean log ");
}
CheckpointConfig cleanCheckpointConfig = new CheckpointConfig()
cleanCheckpointConfig.setForce(true)
environment.checkpoint(cleanCheckpointConfig);
environment.close();

加上如上代碼，這樣就能夠清除掉大部分廢棄的log信息，把文件縮小，這樣傳輸時間會省很多，特別在帶寬受限的狀況下。