Berkeley DB資料處理

標籤：des   style   blog   http   color   io   os   使用   java   

設計一個結構，利用Berkeley DB完成大資料的儲存，備份，查詢功能。

已有的儲備：

　　1.Berkeley DB的基本操作。

　　2.資料轉存後資料不丟失。

　　3.過百GB以上資料的儲存。

資料流如下，個人稱為資料流，具體跟其他術語衝突不在考慮範圍。

各部分功能：

　　A：負責將資料存進Berkeley DB，目的是將來源資料轉換為Berkeley DB能夠訪問的格式。方便後續使用。由於A的磁碟有限，而且A在源源不斷的插入過程中消耗大量的系統資源，同時一旦宕機，後果很嚴重（或許是處理方法沒有找到）。同時在A中利用一個進程插入資料，要利用另外一個進程對A進行檢索還得另外處理。此時的檢索效率也不一定會高。所以做相應修改。

　　node[]：定期擷取A上的資料。擷取規則根據實際情況制定。有點類似map的原理。經過我們的測試，做了這個步驟之後。出現了node中只有第一個node可以訪問資料。其他node開啟環境都會出錯。所以有一個merge的節點負責將所有節點資料收集起來，這樣開啟環境就不會出現問題了。資料也可以訪問了。

　　merge：根據上面所說，merge負責將資料合併。這樣Berkeley DB可以訪問。目的是能在merge上進行檢索。

問題：

　　1.A宕機導致node節點jdb檔案資料不按順序的問題。如果A是程式異常，而環境下的jdb檔案都丟失了，這時候如果重新啟動程式則開啟環境失敗。即使把環境下的內容清空，重新產生的檔案也是從頭開始。無法再跟之前的資料進行合并。一個方案是，如果把新產生的檔案的檔案名稱改成之前的最大檔案名稱的下一個，然後合并到merge上去。通過測試，此方案不可行，不能將兩個不同環境下的檔案按照檔案名稱有序強行組合成一個環境還想著去訪問他。畢竟記憶體資料庫不是硬碟。另外一個方案是，再利用一個merge把宕機之後的檔案都合成在merge2中。這樣要檢索的時候，我們遍曆下merge去訪問資料庫。（這裡所有的電腦通訊，串連等過程暫時都是考慮利用ssh來進行）。這個方法理論上可以，實際上有待考證。

　　2.我個人認為最大的問題就是利用的資源太多了。node的可以考慮去掉。node的作用是防止merge上的資料丟失所有資料都丟失了。但是實際上merge上的資料是很難丟失的。如果merge僅僅是用來做檢索操作，基本上是沒有丟失的可能。除非人工把硬碟的檔案給刪了。所以現在就在想著將以上結構改改。得到以下結構並給出相應解釋

A的功能不用多說，跟之前一樣。node資料。但是切換到下一個node的條件是PreNode的磁碟用完或者A宕機。我們保證每個node上儲存的資料都是一個Environment。宕機我就切換到下一個node。實驗室電腦現在能讓程式異常，終止，的資料量至少能達到200G。效能好的電腦能讓Berkeley DB管理TB級的檔案都沒壓力。A的磁碟最好是盡量大，這樣就可以考慮如果小資料就不用把A上的資料刪除。

檢索入口要求不高，基本能運行程式就行了，當然也可以直接利用一個node去作為檢索入口。

個人認為上述方案比第一個方案要好。還有一些隱藏的問題沒有發覺，畢竟經驗不足。

 轉載說明出處：http://www.cnblogs.com/ickelin/p/3975676.html

Berkeley DB資料處理