有10 億個 url，每一個 url 大小小於 56B，要求去重，內存只給你4G

問題:有10 億個 url，每一個 url 大小小於 56B，要求去重，內存只給你4G

思路：

1.首先將給定的url調用hash方法計算出對應的hash的value，在10億的url中相同url必然有着相同的value。

2.將文件的hash table 放到第value%n臺機器上。

3.value/n是機器上hash table的值。

將文件分佈在多個機器上，這樣要處理網路延時。假設有n臺機器。

>>首先hash文件獲得hash value v

>>將文件的hash table 放到第v%n 臺機器上。

>>v/n是機器上hash table的值。

分析：

將文件的url進行hash，獲得值value，相同的url的文件具備相同的value，因此會被分配到同一臺機器v%n上。在同一臺機器上的重複的url文件具備相同的value/n值，若是出現了衝突，不一樣的url在同一臺機器上也可能有相同的value/n值。在每一個機器上將value/n值做爲key，url值做爲value構成hash表進行去重。最後將內存中去重後的hash表中的value值即url寫入磁盤。合併磁盤中的各部分url文件，完成去重。

56byte;

4G =4*1024=4096kb=4096*1024 byte;

 

--------

轉自：https://www.cnblogs.com/aspirant/p/7154551.html

假如每一個url大小爲10bytes，那麼能夠估計每一個文件的大小爲50G×64=320G，遠遠大於內存限制的4G，因此不可能將其徹底加載到內存中處理，能夠採用分治的思想來解決。

　　Step1：遍歷文件a，對每一個url求取hash(url)%1000，而後根據所取得的值將url分別存儲到1000個小文件(記爲a0,a1,...,a999，每一個小文件約300M);

　　Step2:遍歷文件b，採起和a相同的方式將url分別存儲到1000個小文件(記爲b0,b1,...,b999);

　　巧妙之處：這樣處理後，全部可能相同的url都被保存在對應的小文件(a0vsb0,a1vsb1,...,a999vsb999)中，不對應的小文件不可能有相同的url。而後咱們只要求出這個1000對小文件中相同的url便可。

　　Step3：求每對小文件ai和bi中相同的url時，能夠把ai的url存儲到hash_set/hash_map中。而後遍歷bi的每一個url，看其是否在剛纔構建的hash_set中，若是是，那麼就是共同的url，存到文件裏面就能夠了。

　　草圖以下(左邊分解A，右邊分解B，中間求解相同url)：

2.有一個1G大小的一個文件，裏面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M，要求返回頻數最高的100個詞。

　　Step1：順序讀文件中，對於每一個詞x，取hash(x)%5000，而後按照該值存到5000個小文件(記爲f0,f1,...,f4999)中，這樣每一個文件大概是200k左右，若是其中的有的文件超過了1M大小，還能夠按照相似的方法繼續往下分，直到分解獲得的小文件的大小都不超過1M;

　　Step2：對每一個小文件，統計每一個文件中出現的詞以及相應的頻率(能夠採用trie樹/hash_map等)，並取出出現頻率最大的100個詞(能夠用含100個結點的最小堆)，並把100詞及相應的頻率存入文件，這樣又獲得了5000個文件;

　　Step3：把這5000個文件進行歸併(相似與歸併排序);

　　草圖以下(分割大問題，求解小問題，歸併)：

　草圖以下(分割大問題，求解小問題，歸併)：

 

3.現有海量日誌數據保存在一個超級大的文件中，該文件沒法直接讀入內存，要求從中提取某天出訪問百度次數最多的那個IP。

　　Step1：從這一天的日誌數據中把訪問百度的IP取出來，逐個寫入到一個大文件中;

　　Step2：注意到IP是32位的，最多有2^32個IP。一樣能夠採用映射的方法，好比模1000，把整個大文件映射爲1000個小文件;

　　Step3：找出每一個小文中出現頻率最大的IP(能夠採用hash_map進行頻率統計，而後再找出頻率最大的幾個)及相應的頻率;

　　Step4：在這1000個最大的IP中，找出那個頻率最大的IP，即爲所求。

　　草圖以下：