2015-02-08 57 views
1

我需要存儲15GB或記錄,記錄有一個固定的大小等於270個字節,我想有能力通過鍵找到記錄。密鑰是記錄中幾個字段的散列,多個記錄可以具有相同的密鑰。 我試圖使用gdbm,但它的速度很慢,現在我正在嘗試製作自己的解決方案。 我有兩個主要想法。 1-direct尋址。我創建了一個空記錄的大文件。根據這個概率,新記錄的索引(new_key%(文件中的全部記錄))是空記錄的索引至少等於1/2,如果記錄與此索引已經忙於下一個索引= hash(key)%文件中的總記錄以及迄今爲止。 這種方法給了我很好的查找操作速度。平均而言,我需要1.65次讀取記錄操作才能找到合適的。 但由於大量的隨機訪問操作,初始填充該文件的速度非常慢。它可能需要4個小時。 2 - 二分查找。只是執行並行合併排序來創建文件。 但是二分查找需要隨機訪問12次以上的隨機讀操作才能找到合適的記錄。 我的應用程序對查找操作的速度非常敏感,但我需要加快創建此文件的進程。你有什麼想法嗎?如何加速磁盤上的大哈希表的隨機存取操作

+0

嘗試'next_index = previous_index + 1'。這會將1/3的隨機訪問轉換爲順序訪問,希望可以提供25%的加速。除非散列函數不好,否則不應該給出更多的衝突。 – doublep 2015-02-08 19:08:28

+0

即使是過程切換,機械大容量存儲的嚴重非均勻訪問時間也是存在不適合RAM的密鑰訪問數據的不同方法的原因[B * -trees](http: //en.wikipedia.org/wiki/B%2B_tree)。 – greybeard 2015-02-08 19:31:52

回答

0

假設您擁有1 GB的可用RAM,將散列表分成15個部分,並將其中所包含的哈希表所屬的數據進行分區。然後將每個部分構建在RAM中並寫出。

+0

這意味着讀取所有輸入15次。此外,由於碰撞,人們必須非常小心從一個1 GB塊跳到另一個塊;如果處理不當,由此造成的錯誤將在以後變得非常混亂。 – doublep 2015-02-08 21:23:49

+0

「這意味着讀取所有輸入15次。」不,有更好的算法。 「另外,人們必須非常小心跳躍」我認爲你在這裏誇大了難度。 – 2015-02-08 21:41:08