02.26 給你一個含有1億個QQ號碼的文件,如何快速的查找某個QQ號碼?

井迪迪迪迪迪


如果只找一次,說句實話就是暴力掃最快。怎麼優化複雜度起碼是n,不過就1g數據其實不算什麼。

如果多次查找,其實就1g數據,映射到內存,想怎麼找其實都很快。

如果多次查找並且數據再加幾個量級,那麼肯定是先各種排序處理數據,再二分法查找。


強力路過


我來搗亂一下,1億個QQ號的文件,不用管他是怎麼存放,放在那都行。

然後你只要告訴我你要找的那個qq號,我就能立即告訴你你要找的QQ號是什麼。這個什麼算法都不用。

好吧話回正題,1億個QQ號,對應著什麼?用一個QQ號是要確定在不在這個文件當中,還是說,這個文件裡每個qq號都對應著一個暱稱,要得到這個暱稱呢?

這兩種算法是完全不一樣的,如果只需要確定是否存在,最價辦法應該是布隆過濾器,只需要構建一個信息指紋的大文件,通過集群,可以把速度縮減到毫秒級。

如果是找對應關係,之前的信息指紋就不行了,如果想夠快,依然需要一個集群,先按qq號的最大位數做一個大集合,然後把這1億個qq號按對應位置存入集合,最後把這個集合按0xFF分解到對應的機器上,查找時,只要把QQ號換算成地址,就可以直接訪問了,速也不慢,只是空間上比較浪費,實際做的時候,應該還會做一定的壓縮,以避免空間浪費,但這就需要使用cpu時間了,極限速度挑戰的話,應該不會用這個。


迷人的呆子


哈哈,我看了下都是扯犢子,什麼文本直接點開,你試過沒有。

我來給大家吹吹牛,大概是在15.16年左右,脫庫非常猖狂,網上流傳了各大網站平臺的註冊賬號數據庫,網易的,騰訊的,以及各種中小企業網站數據庫,比如YY,那時候360雲盤可以存40TB+的內容,我就逛各大黑客網站論壇,有幸蒐集了多達38T的數據庫資料以及視頻,只要洩露了,基本上都被收集了,大多數dat這些數據庫文件,需要******才能打開看,還有些是txt文件格式的,比如最出名的一個就是3億QQ賬號密碼那個文件,整個文件有幾G,如果按照其他答主的說法直接打開就行了,可以基本上點開就會卡死,打不開。

其實有很多種辦法可以打開,最簡單的一種,用****軟件切割,把一個txt文件分割為幾十個幾百個幾千個,比如分割為每個文件為100kb,或者把1開頭的分成一個文件,分為多個。這樣子你就能打開了,但是這樣子分割好之後不用打開,蒐集到一個目錄用*****彙總搜索自己需要的就行了。還有一種就是用SQL server這些打開。當然還有其他方法就不一一闡述。

好了牛吹完了360雲盤也封了給你們驗證不了。。。就當吹牛的吧


歡樂深圳


如果你學過信息理論,那麼根據信息熵值理論,對於無序的信息,任何查找算法都不可能比順序查找快.

所謂順序查找算法,就是挨個逐條比較,直到找到為止.

所以如果你只是查找一次,那麼就只有一個方法,挨個逐條比較。其他的所有方法都是扯淡. 這個早就有數學家作了詳細的分析研究,那些連基本算法常識都沒的人,就別扯淡了. 無序信息,除了順序查找,沒有更快的算法,想提高速度,只能想法提高算力(更塊的CPU,分佈式計算等等)

但是,如果你想製作一個查找的系統,最好的辦法就是對原始數據進行預處理,使原始數據形成結構化的有序數據。當數據有序化後,查找的效率就能大大的提高了,這個過程叫做索引.

一個最簡單的方法就是先把QQ號數據做一次排序,形成一個新按照大小順序排列的新文本.

針對於大小順序排列的數據,有二分法和插入法兩種可以提高速度得查找算法. 詳細實現請去網上查找.

其次,更有效的方法是把無序的原始數據,通過算法形成結構化的樹,然後再通過各種樹的遍歷萊進行查找.

常用的有二叉樹查找,平衡樹查找,紅黑樹查找等等.

其中紅黑樹是綜合新能最好,應用最廣泛的查找算法. 大家常見的數據庫中的查找算法,系統文件查找,一般都是紅黑樹算法.

上大學的時候,計算機專業有一門課叫算法與數據結構. 隨意請大家一定記住,算法和數據結構是密不可分的.


shawn25


1億個QQ號,每個十位數字來算,一個long型夠了,8個字節,約800MB大小。

1、Server端內存就夠了,可以直接hash存儲,查找起來也快,紅黑樹結構

2、放在mysql數據庫內存儲,按照QQ號做10個sharding,將QQ號設置為索引,等值查詢,查起來也很快,B+樹結構

3、放在redis裡面,key值帶有QQ號標識,只佔用約800M存儲,查的時候看是否存在key值就行


用戶8564438213735


布隆過濾器可以用於檢索一個元素是否在一個集合中。它的優點是空間效率和查詢時間都比一般的算法要好的多,缺點是有一定的誤識別率和刪除困難。

基本思路如下:

如果想要判斷一個元素是不是在一個集合裡,一般想到的是將所有元素保存起來,然後通過比較確定。鏈表,樹等等數據結構都是這種思路. 但是隨著集合中元素的增加,我們需要的存儲空間越來越大,檢索速度也越來越慢(O(n),O(logn))。不過世界上還有一種叫作散列表(又叫哈希表,Hash table)的數據結構。它可以通過一個Hash函數將一個元素映射成一個位陣列(Bit array)中的一個點。這樣一來,我們只要看看這個點是不是1就可以知道集合中有沒有它了。這就是布隆過濾器的基本思想。

Hash面臨的問題就是衝突。假設Hash函數是良好的,如果我們的位陣列長度為m個點,那麼如果我們想將衝突率降低到例如 1%, 這個散列表就只能容納m / 100個元素。顯然這就不叫空間效率了(Space-efficient)了。解決方法也簡單,就是使用多個Hash,如果它們有一個說元素不在集合中,那肯定就不在。如果它們都說在,雖然也有一定可能性它們在說謊,不過直覺上判斷這種事情的概率是比較低的



互聯網說事兒


其實,首先我覺得你應該導入數據庫,否則以現在的文本文件或Excel文件存放肯定非常大,連打開都難更不用說查找號碼。導入數據庫建立索引,這樣用SQL來查一個數字類的QQ號碼就十分簡單的事了


炒股的阿貴


1億qq號,按照每個文qq號11位算,大概佔用1.02g空間,因為數據量不大,可以全加載進內存。這樣的話可以有好多方法。

第一種是內存映射文件,Windows內存映射文件可以映射磁盤上的大文件,別說1g,就算10g也沒問題,然後操作就跟在內存操作一樣,我之前試過500m的純文本(打印的π),用c語言函數strstr查找字符串就能秒得結果,1g跟500m區別不大。

第二種方法,同樣是建立在數據量不大的基礎上,可以構造map存在內存中qq號就是key,因為map基於hash預算,查詢效率非常高,也是秒得結果。

第三種存數據庫,因為數據達到億級,還是考慮oracle這種單表性能爆表的比較好,放mysql估計比較懸。

第四種可以用內存數據庫,如redis,其中key存為qq號,人家專業幹這個的,也是秒得結果。

第五種es,其實es幹這個有點大材小用。


清風14518071


最簡單的,grep命令搞定。想加快,先split,再並行跑多個grep。另外一個辦法,perl腳本,先把整個文件讀入內存,在內存裡操作速度很快,再一條條比對。qq號只有十多位,按16位算,16字節,3億為48億字節,大約4.8GB,對服務器來說小case


用戶1362944465344


這是個比較有意思的問題,信息也比較模糊,首先,是在討論檢索的做法(比如用工具)還是在討論檢索的算法(自己寫代碼實現)。

假設在討論檢索的做法,那麼最快的必然是ag了,the silver searcher,ag要比grep快得多,用ag在linux下檢索一遍內核也是極快的,當然,如果是win系統就另說了。

假設在討論檢索算法,那麼要先考慮檢索是一次性的,還是以後還會再檢索其他號碼。

如果以後還會再檢索其他號碼,那麼就首先對1億個qq的文件進行處理,典型的方法比如是前導補0,讓所有號碼長度一致,再排序,然後按地址偏移做hash表存儲,這種做法雖然首次處理需要耗時很長,但以後查詢的話幾乎是直接按照號碼計算偏移來直接訪問,速度極快,如果做1萬次甚至1億次檢索的話,效率就體現出來了。

如果檢索是一次性的,也就是1億個號碼的記錄文件收到並僅檢索一次的話,那麼使用多線程分段暴力檢索是我目前想到最快的方法了。因為任何的對記錄文件的預處理工作都已經相當於把所有記錄擼了一遍,有這個時間已經完成檢索了。


分享到:


相關文章: