在研究MonetDB時深刻的學習了hash算法,看了做者的文章頗有感觸,因此轉發,但願可以使更多人受益!php
11、從頭至尾完全解析Hash 表算法html
做者:July、wuliming、pkuoliver
出處:http://blog.csdn.net/v_JULY_v。
說明:本文分爲三部份內容,
第一部分爲一道百度面試題Top K算法的詳解;第二部分爲關於Hash表算法的詳細闡述;第三部分爲打造一個最快的Hash表算法。
------------------------------------linux
第一部分:Top K 算法詳解
問題描述
百度面試題:
搜索引擎會經過日誌文件把用戶每次檢索使用的全部檢索串都記錄下來,每一個查詢串的長度爲1-255字節。
假設目前有一千萬個記錄(這些查詢串的重複度比較高,雖然總數是1千萬,但若是除去重複後,不超過3百萬個。一個查詢串的重複度越高,說明查詢它的用戶越多,也就是越熱門。),請你統計最熱門的10個查詢串,要求使用的內存不能超過1G。程序員
必備知識:
什麼是哈希表?
哈希表(Hash table,也叫散列表),是根據關鍵碼值(Key value)而直接進行訪問的數據結構。也就是說,它經過把關鍵碼值映射到表中一個位置來訪問記錄,以加快查找的速度。這個映射函數叫作散列函數,存放記錄的數組叫作散列表。面試
哈希表hashtable(key,value) 的作法其實很簡單,就是把Key經過一個固定的算法函數既所謂的哈希函數轉換成一個整型數字,而後就將該數字對數組長度進行取餘,取餘結果就看成數組的下標,將value存儲在以該數字爲下標的數組空間裏。
而當使用哈希表進行查詢的時候,就是再次使用哈希函數將key轉換爲對應的數組下標,並定位到該空間獲取value,如此一來,就能夠充分利用到數組的定位性能進行數據定位(文章第2、三部分,會針對Hash表詳細闡述)。算法
問題解析:
要統計最熱門查詢,首先就是要統計每一個Query出現的次數,而後根據統計結果,找出Top 10。因此咱們能夠基於這個思路分兩步來設計該算法。
即,此問題的解決分爲如下倆個步驟:編程
第一步:Query統計
Query統計有如下倆個方法,可供選擇:
一、直接排序法
首先咱們最早想到的的算法就是排序了,首先對這個日誌裏面的全部Query都進行排序,而後再遍歷排好序的Query,統計每一個Query出現的次數了。數組
可是題目中有明確要求,那就是內存不能超過1G,一千萬條記錄,每條記錄是255Byte,很顯然要佔據2.375G內存,這個條件就不知足要求了。安全
讓咱們回憶一下數據結構課程上的內容,當數據量比較大並且內存沒法裝下的時候,咱們能夠採用外排序的方法來進行排序,這裏咱們能夠採用歸併排序,由於歸併排序有一個比較好的時間複雜度O(NlgN)。數據結構
排完序以後咱們再對已經有序的Query文件進行遍歷,統計每一個Query出現的次數,再次寫入文件中。
綜合分析一下,排序的時間複雜度是O(NlgN),而遍歷的時間複雜度是O(N),所以該算法的整體時間複雜度就是O(N+NlgN)=O(NlgN)。
二、Hash Table法
在第1個方法中,咱們採用了排序的辦法來統計每一個Query出現的次數,時間複雜度是NlgN,那麼能不能有更好的方法來存儲,而時間複雜度更低呢?
題目中說明了,雖然有一千萬個Query,可是因爲重複度比較高,所以事實上只有300萬的Query,每一個Query255Byte,所以咱們能夠考慮把他們都放進內存中去,而如今只是須要一個合適的數據結構,在這裏,Hash Table絕對是咱們優先的選擇,由於Hash Table的查詢速度很是的快,幾乎是O(1)的時間複雜度。
那麼,咱們的算法就有了:維護一個Key爲Query字串,Value爲該Query出現次數的HashTable,每次讀取一個Query,若是該字串不在Table中,那麼加入該字串,而且將Value值設爲1;若是該字串在Table中,那麼將該字串的計數加一便可。最終咱們在O(N)的時間複雜度內完成了對該海量數據的處理。
本方法相比算法1:在時間複雜度上提升了一個數量級,爲O(N),但不只僅是時間複雜度上的優化,該方法只須要IO數據文件一次,而算法1的IO次數較多的,所以該算法2比算法1在工程上有更好的可操做性。
第二步:找出Top 10
算法一:普通排序
我想對於排序算法你們都已經不陌生了,這裏不在贅述,咱們要注意的是排序算法的時間複雜度是NlgN,在本題目中,三百萬條記錄,用1G內存是能夠存下的。
算法二:部分排序
題目要求是求出Top 10,所以咱們沒有必要對全部的Query都進行排序,咱們只須要維護一個10個大小的數組,初始化放入10個Query,按照每一個Query的統計次數由大到小排序,而後遍歷這300萬條記錄,每讀一條記錄就和數組最後一個Query對比,若是小於這個Query,那麼繼續遍歷,不然,將數組中最後一條數據淘汰,加入當前的Query。最後當全部的數據都遍歷完畢以後,那麼這個數組中的10個Query即是咱們要找的Top10了。
不難分析出,這樣,算法的最壞時間複雜度是N*K, 其中K是指top多少。
算法三:堆
在算法二中,咱們已經將時間複雜度由NlogN優化到NK,不得不說這是一個比較大的改進了,但是有沒有更好的辦法呢?
分析一下,在算法二中,每次比較完成以後,須要的操做複雜度都是K,由於要把元素插入到一個線性表之中,並且採用的是順序比較。這裏咱們注意一下,該數組是有序的,一次咱們每次查找的時候能夠採用二分的方法查找,這樣操做的複雜度就降到了logK,但是,隨之而來的問題就是數據移動,由於移動數據次數增多了。不過,這個算法仍是比算法二有了改進。
基於以上的分析,咱們想一想,有沒有一種既能快速查找,又能快速移動元素的數據結構呢?回答是確定的,那就是堆。
藉助堆結構,咱們能夠在log量級的時間內查找和調整/移動。所以到這裏,咱們的算法能夠改進爲這樣,維護一個K(該題目中是10)大小的小根堆,而後遍歷300萬的Query,分別和根元素進行對比。
具體過程是,堆頂存放的是整個堆中最小的數,如今遍歷N個數,把最早遍歷到的k個數存放到最小堆中,並假設它們就是咱們要找的最大的k個數,X1>X2...Xmin(堆頂),然後遍歷後續的N-K個數,一一與堆頂元素進行比較,若是遍歷到的Xi大於堆頂元素Xmin,則把Xi放入堆中,然後更新整個堆,更新的時間複雜度爲logK,若是Xi<Xmin,則不更新堆,整個過程的複雜度爲O(K)+O((N-K)*logK)=O(N*logK)。
(堆排序的3D動畫演示能夠參看此連接:http://www.benfrederickson.com/2013/10/10/heap-visualization.html)
思想與上述算法二一致,只是算法在算法三,咱們採用了最小堆這種數據結構代替數組,把查找目標元素的時間複雜度有O(K)降到了O(logK)。
那麼這樣,採用堆數據結構,算法三,最終的時間複雜度就降到了N‘logK,和算法二相比,又有了比較大的改進。
總結:
至此,算法就徹底結束了,通過上述第一步、先用Hash表統計每一個Query出現的次數,O(N);而後第二步、採用堆數據結構找出Top 10,N*O(logK)。因此,咱們最終的時間複雜度是:O(N) + N'*O(logK)。(N爲1000萬,N’爲300萬)。若是各位有什麼更好的算法,歡迎留言評論。
此外,還能夠看下此文第二部分的第二題:http://blog.csdn.net/v_july_v/article/details/7382693。
第二部分、Hash表 算法的詳細解析
什麼是Hash
Hash,通常翻譯作「散列」,也有直接音譯爲「哈希」的,就是把任意長度的輸入(又叫作預映射, pre-image),經過散列算法,變換成固定長度的輸出,該輸出就是散列值。這種轉換是一種壓縮映射,也就是,散列值的空間一般遠小於輸入的空間,不一樣的輸入可能會散列成相同的輸出,而不可能從散列值來惟一的肯定輸入值。簡單的說就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的函數。
HASH主要用於信息安全領域中加密算法,它把一些不一樣長度的信息轉化成雜亂的128位的編碼,這些編碼值叫作HASH值. 也能夠說,hash就是找到一種數據內容和數據存放地址之間的映射關係。
數組的特色是:尋址容易,插入和刪除困難;而鏈表的特色是:尋址困難,插入和刪除容易。那麼咱們能不能綜合二者的特性,作出一種尋址容易,插入刪除也容易的數據結構?答案是確定的,這就是咱們要提起的哈希表,哈希表有多種不一樣的實現方法,我接下來解釋的是最經常使用的一種方法——拉鍊法,咱們能夠理解爲「鏈表的數組」,如圖:
左邊很明顯是個數組,數組的每一個成員包括一個指針,指向一個鏈表的頭,固然這個鏈表可能爲空,也可能元素不少。咱們根據元素的一些特徵把元素分配到不一樣的鏈表中去,也是根據這些特徵,找到正確的鏈表,再從鏈表中找出這個元素。
元素特徵轉變爲數組下標的方法就是散列法。散列法固然不止一種,下面列出三種比較經常使用的:
1,除法散列法
最直觀的一種,上圖使用的就是這種散列法,公式:
index = value % 16
學過彙編的都知道,求模數實際上是經過一個除法運算獲得的,因此叫「除法散列法」。
2,平方散列法
求index是很是頻繁的操做,而乘法的運算要比除法來得省時(對如今的CPU來講,估計咱們感受不出來),因此咱們考慮把除法換成乘法和一個位移操做。公式:
index = (value * value) >> 28 (右移,除以2^28。記法:左移變大,是乘。右移變小,是除。)
若是數值分配比較均勻的話這種方法能獲得不錯的結果,但我上面畫的那個圖的各個元素的值算出來的index都是0——很是失敗。也許你還有個問題,value若是很大,value * value不會溢出嗎?答案是會的,但咱們這個乘法不關心溢出,由於咱們根本不是爲了獲取相乘結果,而是爲了獲取index。
3,斐波那契(Fibonacci)散列法
平方散列法的缺點是顯而易見的,因此咱們能不能找出一個理想的乘數,而不是拿value自己看成乘數呢?答案是確定的。
1,對於16位整數而言,這個乘數是40503
2,對於32位整數而言,這個乘數是2654435769
3,對於64位整數而言,這個乘數是11400714819323198485
這幾個「理想乘數」是如何得出來的呢?這跟一個法則有關,叫黃金分割法則,而描述黃金分割法則的最經典表達式無疑就是著名的斐波那契數列,即如此形式的序列:0,1, 1,2, 3,5, 8,13, 21,34, 55,89, 144,233,377,610, 987, 1597, 2584, 4181, 6765, 10946,…。另外,斐波那契數列的值和太陽系八大行星的軌道半徑的比例出奇吻合。
對咱們常見的32位整數而言,公式:
index = (value * 2654435769) >> 28
若是用這種斐波那契散列法的話,那上面的圖就變成這樣了:
注:用斐波那契散列法調整以後會比原來的取摸散列法好不少。
適用範圍
快速查找,刪除的基本數據結構,一般須要總數據量能夠放入內存。
基本原理及要點
hash函數選擇,針對字符串,整數,排列,具體相應的hash方法。
碰撞處理,一種是open hashing,也稱爲拉鍊法;另外一種就是closed hashing,也稱開地址法,opened addressing。
擴展
d-left hashing中的d是多個的意思,咱們先簡化這個問題,看一看2-left hashing。2-left hashing指的是將一個哈希表分紅長度相等的兩半,分別叫作T1和T2,給T1和T2分別配備一個哈希函數,h1和h2。在存儲一個新的key時,同 時用兩個哈希函數進行計算,得出兩個地址h1[key]和h2[key]。這時須要檢查T1中的h1[key]位置和T2中的h2[key]位置,哪個 位置已經存儲的(有碰撞的)key比較多,而後將新key存儲在負載少的位置。若是兩邊同樣多,好比兩個位置都爲空或者都存儲了一個key,就把新key 存儲在左邊的T1子表中,2-left也由此而來。在查找一個key時,必須進行兩次hash,同時查找兩個位置。
問題實例(海量數據處理)
咱們知道hash 表在海量數據處理中有着普遍的應用,下面,請看另外一道百度面試題:
題目:海量日誌數據,提取出某日訪問百度次數最多的那個IP。
方案:IP的數目仍是有限的,最多2^32個,因此能夠考慮使用hash將ip直接存入內存,而後進行統計。
第三部分、最快的Hash表算法
接下來,我們來具體分析一下一個最快的Hasb表算法。
咱們由一個簡單的問題逐步入手:有一個龐大的字符串數組,而後給你一個單獨的字符串,讓你從這個數組中查找是否有這個字符串並找到它,你會怎麼作?有一個方法最簡單,老老實實從頭查到尾,一個一個比較,直到找到爲止,我想只要學過程序設計的人都能把這樣一個程序做出來,但要是有程序員把這樣的程序交給用戶,我只能用無語來評價,或許它真的能工做,但...也只能如此了。
最合適的算法天然是使用HashTable(哈希表),先介紹介紹其中的基本知識,所謂Hash,通常是一個整數,經過某種算法,能夠把一個字符串"壓縮" 成一個整數。固然,不管如何,一個32位整數是沒法對應回一個字符串的,但在程序中,兩個字符串計算出的Hash值相等的可能很是小,下面看看在MPQ中的Hash算法(參看自此文:http://sfsrealm.hopto.org/inside_mopaq/chapter2.htm):
函數1、如下的函數生成一個長度爲0x500(合10進制數:1280)的cryptTable[0x500]
void prepareCryptTable()
{
unsigned long seed = 0x00100001, index1 = 0, index2 = 0, i;
for( index1 = 0; index1 < 0x100; index1++ )
{
for( index2 = index1, i = 0; i < 5; i++, index2 += 0x100 )
{
unsigned long temp1, temp2;
seed = (seed * 125 + 3) % 0x2AAAAB;
temp1 = (seed & 0xFFFF) << 0x10;
seed = (seed * 125 + 3) % 0x2AAAAB;
temp2 = (seed & 0xFFFF);
cryptTable[index2] = ( temp1 | temp2 );
}
}
}
函數2、如下函數計算lpszFileName 字符串的hash值,其中dwHashType 爲hash的類型,在下面的函數三、GetHashTablePos函數中調用此函數二,其能夠取的值爲0、一、2;該函數返回lpszFileName 字符串的hash值:
unsigned long HashString( char *lpszFileName, unsigned long dwHashType )
{
unsigned char *key = (unsigned char *)lpszFileName;
unsigned long seed1 = 0x7FED7FED;
unsigned long seed2 = 0xEEEEEEEE;
int ch;
while( *key != 0 )
{
ch = toupper(*key++);
seed1 = cryptTable[(dwHashType << 8) + ch] ^ (seed1 + seed2);
seed2 = ch + seed1 + seed2 + (seed2 << 5) + 3;
}
return seed1;
}
Blizzard的這個算法是很是高效的,被稱爲"One-Way Hash"( A one-way hash is a an algorithm that is constructed in such a way that deriving the original string (set of strings, actually) is virtually impossible)。舉個例子,字符串"unitneutralacritter.grp"經過這個算法獲得的結果是0xA26067F3。
是否是把第一個算法改進一下,改爲逐個比較字符串的Hash值就能夠了呢,答案是,遠遠不夠,要想獲得最快的算法,就不能進行逐個的比較,一般是構造一個哈希表(Hash Table)來解決問題,哈希表是一個大數組,這個數組的容量根據程序的要求來定義,例如1024,每個Hash值經過取模運算 (mod) 對應到數組中的一個位置,這樣,只要比較這個字符串的哈希值對應的位置有沒有被佔用,就能夠獲得最後的結果了,想一想這是什麼速度?是的,是最快的O(1),如今仔細看看這個算法吧:
typedef struct
{
int nHashA;
int nHashB;
char bExists;
......
} SOMESTRUCTRUE;
一種可能的結構體定義?
函數3、下述函數爲在Hash表中查找是否存在目標字符串,有則返回要查找字符串的Hash值,無則,return -1.
int GetHashTablePos( har *lpszString, SOMESTRUCTURE *lpTable )
//lpszString要在Hash表中查找的字符串,lpTable爲存儲字符串Hash值的Hash表。
{
int nHash = HashString(lpszString); //調用上述函數二,返回要查找字符串lpszString的Hash值。
int nHashPos = nHash % nTableSize;
if ( lpTable[nHashPos].bExists && !strcmp( lpTable[nHashPos].pString, lpszString ) )
{ //若是找到的Hash值在表中存在,且要查找的字符串與表中對應位置的字符串相同,
return nHashPos; //則返回上述調用函數二後,找到的Hash值
}
else
{
return -1;
}
}
看到此,我想你們都在想一個很嚴重的問題:「若是兩個字符串在哈希表中對應的位置相同怎麼辦?」,畢竟一個數組容量是有限的,這種可能性很大。解決該問題的方法不少,我首先想到的就是用「鏈表」,感謝大學裏學的數據結構教會了這個百試百靈的法寶,我遇到的不少算法均可以轉化成鏈表來解決,只要在哈希表的每一個入口掛一個鏈表,保存全部對應的字符串就OK了。事情到此彷佛有了完美的結局,若是是把問題獨自交給我解決,此時我可能就要開始定義數據結構而後寫代碼了。
然而Blizzard的程序員使用的方法則是更精妙的方法。基本原理就是:他們在哈希表中不是用一個哈希值而是用三個哈希值來校驗字符串。
MPQ使用文件名哈希表來跟蹤內部的全部文件。可是這個表的格式與正常的哈希表有一些不一樣。首先,它沒有使用哈希做爲下標,把實際的文件名存儲在表中用於驗證,實際上它根本就沒有存儲文件名。而是使用了3種不一樣的哈希:一個用於哈希表的下標,兩個用於驗證。這兩個驗證哈希替代了實際文件名。
固然了,這樣仍然會出現2個不一樣的文件名哈希到3個一樣的哈希。可是這種狀況發生的機率平均是:1:18889465931478580854784,這個機率對於任何人來講應該都是足夠小的。如今再回到數據結構上,Blizzard使用的哈希表沒有使用鏈表,而採用"順延"的方式來解決問題,看看這個算法:
函數4、lpszString 爲要在hash表中查找的字符串;lpTable 爲存儲字符串hash值的hash表;nTableSize 爲hash表的長度:
int GetHashTablePos( char *lpszString, MPQHASHTABLE *lpTable, int nTableSize )
{
const int HASH_OFFSET = 0, HASH_A = 1, HASH_B = 2;
int nHash = HashString( lpszString, HASH_OFFSET );
int nHashA = HashString( lpszString, HASH_A );
int nHashB = HashString( lpszString, HASH_B );
int nHashStart = nHash % nTableSize;
int nHashPos = nHashStart;
while ( lpTable[nHashPos].bExists )
{
/*若是僅僅是判斷在該表中時候存在這個字符串,就比較這兩個hash值就能夠了,不用對
*結構體中的字符串進行比較。這樣會加快運行的速度?減小hash表佔用的空間?這種
*方法通常應用在什麼場合?*/
if ( lpTable[nHashPos].nHashA == nHashA
&& lpTable[nHashPos].nHashB == nHashB )
{
return nHashPos;
}
else
{
nHashPos = (nHashPos + 1) % nTableSize;
}
if (nHashPos == nHashStart)
break;
}
return -1;
}
上述程序解釋:
1.計算出字符串的三個哈希值(一個用來肯定位置,另外兩個用來校驗)
2. 察看哈希表中的這個位置
3. 哈希表中這個位置爲空嗎?若是爲空,則確定該字符串不存在,返回-1。
4. 若是存在,則檢查其餘兩個哈希值是否也匹配,若是匹配,則表示找到了該字符串,返回其Hash值。
5. 移到下一個位置,若是已經移到了表的末尾,則反繞到表的開始位置起繼續查詢
6. 看看是否是又回到了原來的位置,若是是,則返回沒找到
7. 回到3
ok,這就是本文中所說的最快的Hash表算法。什麼?不夠快?:D。歡迎,各位批評指正。
--------------------------------------------
補充一、一個簡單的hash函數:
/*key爲一個字符串,nTableLength爲哈希表的長度
*該函數獲得的hash值分佈比較均勻*/
unsigned long getHashIndex( const char *key, int nTableLength )
{
unsigned long nHash = 0;
while (*key)
{
nHash = (nHash<<5) + nHash + *key++;
}
return ( nHash % nTableLength );
}
補充二、一個完整測試程序:
哈希表的數組是定長的,若是太大,則浪費,若是過小,體現不出效率。合適的數組大小是哈希表的性能的關鍵。哈希表的尺寸最好是一個質數。固然,根據不一樣的數據量,會有不一樣的哈希表的大小。對於數據量時多時少的應用,最好的設計是使用動態可變尺寸的哈希表,那麼若是你發現哈希表尺寸過小了,好比其中的元素是哈希表尺寸的2倍時,咱們就須要擴大哈希表尺寸,通常是擴大一倍。
下面是哈希表尺寸大小的可能取值:
17, 37, 79, 163, 331,
673, 1361, 2729, 5471, 10949,
21911, 43853, 87719, 175447, 350899,
701819, 1403641, 2807303, 5614657, 11229331,
22458671, 44917381, 89834777, 179669557, 359339171,
718678369, 1437356741, 2147483647
如下爲該程序的完整源碼,已在linux下測試經過:
相關引用:
一、http://blog.redfox66.com/。
二、http://blog.csdn.net/wuliming_sc/。
更多請參見本hash算法以後續:十一(續)、倒排索引關鍵詞Hash不重複編碼實踐。完。
第二十3、四章:楊氏矩陣查找,倒排索引關鍵詞Hash不重複編碼實踐
做者:July、yansha。編程藝術室出品。
出處:結構之法算法之道。
本文闡述兩個問題,第二十三章是楊氏矩陣查找問題,第二十四章是有關倒排索引中關鍵詞Hash編碼的問題,主要要解決不重複以及追加的功能,同時也是經典算法研究系列11、從頭至尾完全解析Hash表算法之續。
OK,有任何問題,也歡迎隨時交流或批評指正。謝謝。
先看一個來自算法導論習題裏6-3與劍指offer的一道編程題(也被常常用做面試題,本人此前去搜狗二面時便遇到了):
在一個m行n列二維數組中,每一行都按照從左到右遞增的順序排序,每一列都按照從上到下遞增的順序排序。請完成一個函數,輸入這樣的一個二維數組和一個整數,判斷數組中是否含有該整數。
例以下面的二維數組就是每行、每列都遞增排序。若是在這個數組中查找數字6,則返回true;若是查找數字5,因爲數組不含有該數字,則返回false。
本Young問題解法有二(如查找數字6):
一、分治法,分爲四個矩形,配以二分查找,若是要找的數是6介於對角線上相鄰的兩個數四、10,能夠排除掉左上和右下的兩個矩形,而遞歸在左下和右上的兩個矩形繼續找,以下圖所示:
二、定位法,時間複雜度O(m+n)。首先直接定位到最右上角的元素,再配以二分查找,比要找的數(6)大就往左走,比要找數(6)的小就往下走,直到找到要找的數字(6)爲止,以下圖所示:
上述方法二的關鍵代碼+程序運行以下圖所示:
試問,上述算法複雜麼?不復雜,只要稍微動點腦筋便能想到,還能夠參看友人老夢的文章,Young氏矩陣:http://blog.csdn.net/zhanglei8893/article/details/6234564,以及IT練兵場的:http://www.jobcoding.com/array/matrix/young-tableau-problem/,除此以外,何海濤先生一書劍指offer中也收集了此題,感興趣的朋友也能夠去看看。
本章要介紹這樣一個問題,對倒排索引中的關鍵詞進行編碼。那麼,這個問題將分爲兩個個步驟:
24.一、正排索引與倒排索引
我們先來看什麼是倒排索引,以及倒排索引與正排索引之間的區別:
咱們知道,搜索引擎的關鍵步驟就是創建倒排索引,所謂倒排索引通常表示爲一個關鍵詞,而後是它的頻度(出現的次數),位置(出如今哪一篇文章或網頁中,及有關的日期,做者等信息),它至關於爲互聯網上幾千億頁網頁作了一個索引,比如一本書的目錄、標籤通常。讀者想看哪個主題相關的章節,直接根據目錄便可找到相關的頁面。沒必要再從書的第一頁到最後一頁,一頁一頁的查找。
接下來,闡述下正排索引與倒排索引的區別:
正排表是以文檔的ID爲關鍵字,表中記錄文檔中每一個字的位置信息,查找時掃描表中每一個文檔中字的信息直到找出全部包含查詢關鍵字的文檔。正排表結構如圖1所示,這種組織方法在創建索引的時候結構比較簡單,創建比較方便且易於維護;由於索引是基於文檔創建的,如果有新的文檔假如,直接爲該文檔創建一個新的索引塊,掛接在原來索引文件的後面。如果有文檔刪除,則直接找到該文檔號文檔對因的索引信息,將其直接刪除。可是在查詢的時候需對全部的文檔進行掃描以確保沒有遺漏,這樣就使得檢索時間大大延長,檢索效率低下。
儘管正排表的工做原理很是的簡單,可是因爲其檢索效率過低,除非在特定狀況下,不然實用性價值不大。
倒排表以字或詞爲關鍵字進行索引,表中關鍵字所對應的記錄表項記錄了出現這個字或詞的全部文檔,一個表項就是一個字表段,它記錄該文檔的ID和字符在該文檔中出現的位置狀況。因爲每一個字或詞對應的文檔數量在動態變化,因此倒排表的創建和維護都較爲複雜,可是在查詢的時候因爲能夠一次獲得查詢關鍵字所對應的全部文檔,因此效率高於正排表。在全文檢索中,檢索的快速響應是一個最爲關鍵的性能,而索引創建因爲在後臺進行,儘管效率相對低一些,但不會影響整個搜索引擎的效率。
倒排表的結構圖如圖2:
倒排表的索引信息保存的是字或詞後繼數組模型、互關聯後繼數組模型條在文檔內的位置,在同一篇文檔內相鄰的字或詞條的先後關係沒有被保存到索引文件內。
倒排索引是搜索引擎之基石。建成了倒排索引後,用戶要查找某個query,如在搜索框輸入某個關鍵詞:「結構之法」後,搜索引擎不會再次使用爬蟲又一個一個去抓取每個網頁,從上到下掃描網頁,看這個網頁有沒有出現這個關鍵詞,而是會在它預先生成的倒排索引文件中查找和匹配包含這個關鍵詞「結構之法」的全部網頁。找到了以後,再按相關性度排序,最終把排序後的結果顯示給用戶。
以下,便是一個倒排索引文件(不全),咱們把它取名爲big_index,文件中每一較短的,不包含有「#####」符號的即是某個關鍵詞,及這個關鍵詞的出現次數。如今要從這個大索引文件中提取出這些關鍵詞,--Firelf--,-11,-Winter-,.,007,007:天降殺機,02Chan..如何作到呢?一行一行的掃描整個索引文件麼?
何意?以前已經說過:倒排索引包含詞典和倒排記錄表兩個部分,詞典通常有詞項(或稱爲關鍵詞)和詞項頻率(即這個詞項或關鍵詞出現的次數),倒排記錄表則記錄着上述詞項(或關鍵詞)所出現的位置,或出現的文檔及網頁ID等相關信息。
最簡單的講,就是要提取詞典中的詞項(關鍵詞):--Firelf--,-11,-Winter-,.,007,007:天降殺機,02Chan...。
--Firelf--(關鍵詞) 8(出現次數)
咱們能夠試着這麼解決:經過查找#####即可判斷某一行出現的詞是否是關鍵詞,但若是這樣作的話,便要掃描整個索引文件的每一行,代價實在巨大。如何提升速度呢?對了,關鍵詞後面的那個出現次數爲咱們問題的解決起到了很好的做用,以下注釋所示:
// 自己沒有##### 的行斷定爲關鍵詞行,後跟這個關鍵詞的行數N(即詞項頻率)
// 接下來,截取關鍵詞--Firelf--,而後讀取後面關鍵詞的行數N
// 再跳過N行(濾過和避免掃描中間的倒排記錄表信息)
// 讀取下一個關鍵詞..
有朋友指出,上述方法雖然減小了掃描的行數,但並無減小I0開銷。讀者是否有更好地辦法?歡迎隨時交流。
愛思考的朋友可能會問,上述從倒排索引文件中提取出那些關鍵詞(詞項)的操做是爲了什麼呢?其實如我我的微博上12月12日所述的Hash詞典編碼:
詞典文件的編碼:一、詞典怎麼生成(存儲和構造詞典);二、如何運用hash對輸入的漢字進行編碼;三、如何更好的解決衝突,即不重複以及追加功能。具體例子爲:事先構造好詞典文件後,輸入一個詞,要求找到這個詞的編碼,而後將其編碼輸出。且要有不斷能添加詞的功能,不得重複。
步驟應該是以下:一、讀索引文件;二、提取索引中的詞出來;三、詞典怎麼生成,存儲和構造詞典;四、詞典文件的編碼:不重複與追加功能。編碼好比,輸入中國,他的編碼能夠爲10001,而後輸入銀行,他的編碼能夠爲10002。只要實現不斷添加詞功能,以及不重複便可,詞典類的大文件,hash最重要的是怎樣避免衝突。
也就是說,如今我要對上述提取出來後的關鍵詞進行編碼,採起何種方式編碼呢?暫時用hash函數編碼。編碼以後的效果將是每個關鍵詞都有一個特定的編碼,以下圖所示(與上文big_index文件比較一下便知):
--Firelf-- 對應編碼爲:135942
-11 對應編碼爲:106101
....
但細心的朋友一看上圖便知,其中第34~39行顯示,有重複的編碼,那麼如何解決這個不重複編碼的問題呢?
用hash表編碼?但其極易產生衝突碰撞,爲何?請看:
哈希表是一種查找效率極高的數據結構,不少語言都在內部實現了哈希表。PHP中的哈希表是一種極爲重要的數據結構,不但用於表示Array數據類型,還在Zend虛擬機內部用於存儲上下文環境信息(執行上下文的變量及函數均使用哈希表結構存儲)。
理想狀況下哈希表插入和查找操做的時間複雜度均爲O(1),任何一個數據項能夠在一個與哈希表長度無關的時間內計算出一個哈希值(key),而後在常量時間內定位到一個桶(術語bucket,表示哈希表中的一個位置)。固然這是理想狀況下,由於任何哈希表的長度都是有限的,因此必定存在不一樣的數據項具備相同哈希值的狀況,此時不一樣數據項被定爲到同一個桶,稱爲碰撞(collision)。
哈希表的實現須要解決碰撞問題,碰撞解決大致有兩種思路,
不論使用了哪一種碰撞解決策略,都致使插入和查找操做的時間複雜度再也不是O(1)。以查找爲例,不能經過key定位到桶就結束,必須還要比較原始key(即未作哈希以前的key)是否相等,若是不相等,則要使用與插入相同的算法繼續查找,直到找到匹配的值或確認數據不在哈希表中。
PHP是使用單鏈表存儲碰撞的數據,所以實際上PHP哈希表的平均查找複雜度爲O(L),其中L爲桶鏈表的平均長度;而最壞複雜度爲O(N),此時全部數據所有碰撞,哈希表退化成單鏈表。下圖PHP中正常哈希表和退化哈希表的示意圖。
哈希表碰撞攻擊就是經過精心構造數據,使得全部數據所有碰撞,人爲將哈希表變成一個退化的單鏈表,此時哈希表各類操做的時間均提高了一個數量級,所以會消耗大量CPU資源,致使系統沒法快速響應請求,從而達到拒絕服務攻擊(DoS)的目的。
能夠看到,進行哈希碰撞攻擊的前提是哈希算法特別容易找出碰撞,若是是MD5或者SHA1那基本就沒戲了,幸運的是(也能夠說不幸的是)大多數編程語言使用的哈希算法都十分簡單(這是爲了效率考慮),所以能夠不費吹灰之力之力構造出攻擊數據.(上述五段文字引自:http://www.codinglabs.org/html/hash-collisions-attack-on-php.html)。
值得一提的是,在解決Hash衝突的時候,搞的焦頭爛額,結果今天上午在本身的博客內的一篇文章(11、從頭至尾完全解析Hash表算法)內找到了解決辦法:網上流傳甚廣的暴雪的Hash算法。 OK,接下來,我們回顧下暴雪的hash表算法:
「接下來,我們來具體分析一下一個最快的Hash表算法。
咱們由一個簡單的問題逐步入手:有一個龐大的字符串數組,而後給你一個單獨的字符串,讓你從這個數組中查找是否有這個字符串並找到它,你會怎麼作?
有一個方法最簡單,老老實實從頭查到尾,一個一個比較,直到找到爲止,我想只要學過程序設計的人都能把這樣一個程序做出來,但要是有程序員把這樣的程序交給用戶,我只能用無語來評價,或許它真的能工做,但...也只能如此了。
最合適的算法天然是使用HashTable(哈希表),先介紹介紹其中的基本知識,所謂Hash,通常是一個整數,經過某種算法,能夠把一個字符串"壓縮" 成一個整數。固然,不管如何,一個32位整數是沒法對應回一個字符串的,但在程序中,兩個字符串計算出的Hash值相等的可能很是小,下面看看在MPQ中的Hash算法:
函數prepareCryptTable如下的函數生成一個長度爲0x500(合10進制數:1280)的cryptTable[0x500]
函數HashString如下函數計算lpszFileName 字符串的hash值,其中dwHashType 爲hash的類型,
Blizzard的這個算法是很是高效的,被稱爲"One-Way Hash"( A one-way hash is a an algorithm that is constructed in such a way that deriving the original string (set of strings, actually) is virtually impossible)。舉個例子,字符串"unitneutralacritter.grp"經過這個算法獲得的結果是0xA26067F3。
是否是把第一個算法改進一下,改爲逐個比較字符串的Hash值就能夠了呢,答案是,遠遠不夠,要想獲得最快的算法,就不能進行逐個的比較,一般是構造一個哈希表(Hash Table)來解決問題,哈希表是一個大數組,這個數組的容量根據程序的要求來定義,
例如1024,每個Hash值經過取模運算 (mod) 對應到數組中的一個位置,這樣,只要比較這個字符串的哈希值對應的位置有沒有被佔用,就能夠獲得最後的結果了,想一想這是什麼速度?是的,是最快的O(1),如今仔細看看這個算法吧:
函數GetHashTablePos下述函數爲在Hash表中查找是否存在目標字符串,有則返回要查找字符串的Hash值,無則,return -1.
看到此,我想你們都在想一個很嚴重的問題:「若是兩個字符串在哈希表中對應的位置相同怎麼辦?」,畢竟一個數組容量是有限的,這種可能性很大。解決該問題的方法不少,我首先想到的就是用「鏈表」,感謝大學裏學的數據結構教會了這個百試百靈的法寶,我遇到的不少算法均可以轉化成鏈表來解決,只要在哈希表的每一個入口掛一個鏈表,保存全部對應的字符串就OK了。事情到此彷佛有了完美的結局,若是是把問題獨自交給我解決,此時我可能就要開始定義數據結構而後寫代碼了。
然而Blizzard的程序員使用的方法則是更精妙的方法。基本原理就是:他們在哈希表中不是用一個哈希值而是用三個哈希值來校驗字符串。」
「MPQ使用文件名哈希表來跟蹤內部的全部文件。可是這個表的格式與正常的哈希表有一些不一樣。首先,它沒有使用哈希做爲下標,把實際的文件名存儲在表中用於驗證,實際上它根本就沒有存儲文件名。而是使用了3種不一樣的哈希:一個用於哈希表的下標,兩個用於驗證。這兩個驗證哈希替代了實際文件名。
固然了,這樣仍然會出現2個不一樣的文件名哈希到3個一樣的哈希。可是這種狀況發生的機率平均是:1:18889465931478580854784,這個機率對於任何人來講應該都是足夠小的。如今再回到數據結構上,Blizzard使用的哈希表沒有使用鏈表,而採用"順延"的方式來解決問題。」下面,我們來看看這個網上流傳甚廣的暴雪hash算法:
函數GetHashTablePos中,lpszString 爲要在hash表中查找的字符串;lpTable 爲存儲字符串hash值的hash表;nTableSize 爲hash表的長度:
上述程序解釋:
有了上面的暴雪Hash算法。我們的問題即可解決了。不過,有兩點必須先提醒讀者:一、Hash表起初要初始化;二、暴雪的Hash算法對於查詢那樣處理能夠,但對插入就不能那麼解決。
關鍵主體代碼以下:
接下來要讀取索引文件big_index對其中的關鍵詞進行編碼(爲了簡單起見,直接一行一行掃描讀寫,沒有跳過行數了):
主函數已經很簡單了,以下:
程序運行後生成的hashpath.txt文件以下:
如上所示,採起暴雪的Hash算法並在插入的時候作適當處理,當再次對上文中的索引文件big_index進行Hash編碼後,衝突問題已經獲得初步解決。固然,還有待更進一步更深刻的測試。
後來又爲上述文件中的關鍵詞編了碼一個計數的內碼,不過,奇怪的是,一樣的代碼,在Dev C++ 與VS2010上運行結果卻不一樣(左邊dev上計數從"1"開始,VS上計數從「1994014002」開始),以下圖所示:
在上面的bigIndex_hashcode函數的基礎上,修改以下,便可獲得上面的效果:
小結
本文有一點值得一提的是,在此前的這篇文章(11、從頭至尾完全解析Hash表算法)之中,只是對Hash表及暴雪的Hash算法有過學習和了解,但還沒有真正運用過它,而今在本章中體現,證實仍是以前寫的文章,及以前對Hash表等算法的學習仍是有必定做用的。同時,也順便對暴雪的Hash函數算是作了個測試,其的確能解決通常的衝突性問題,創造這個算法的人不簡單吶。