2011-01-05 75 views
-1

我有一個文本文件(大約1.5千兆字節),我想要搜索特定標題的出現。我的列表中有大約1000萬個標題。fgrep可以處理多少個搜索字符串?

顯然,列表中的每個標題都不會存在於文本文件中。沒關係。我只需要知道文本中存在哪些標題。

現在,如果只有幾百個標題,我會使用fgrep並告訴它從文件(即fgrep -f patternlist.txt bigtextfile.txt)中讀取搜索字符串。

但是fgrep會扼殺那麼多的數據嗎?

將我的標題列表和文本文件轉換爲可與fgrep一起使用的形式,這是一項有點工作,所以我想了解一下在我付出這些努力之前是否可以使用這種形式。

另一種選擇是將標題列表拆分爲多個文件併爲每個子列表運行fgrep一次。這並不瘋狂,前提是fgrep可以處理相當多的搜索字符串。如果它可以處理100萬,這是一個不容易的事情。如果它不能處理100,000個(需要超過100個單獨運行),那麼這是一個不太有吸引力的選擇。

那麼,任何人都有使用fgrep搜索大量字符串的經驗嗎?如果沒有,有沒有其他的程序可用?我可以自己寫一兩天,但是如果我能避免這項工作。 。 。

+0

你爲什麼不試試呢? – 2011-01-10 11:36:50

+0

正如我所說,這是幾個小時的工作,使我的數據進入適當的格式來嘗試。我希望有人在我花時間之前嘗試過。 – 2011-01-10 16:26:02

+0

Downvoter?習慣上提供解釋性評論。 – 2014-12-17 15:14:32

回答

0

fgrep規模很好用的發明,如:

你的模式列表讀取,編譯並保存在內存中, 當然即輸入文件可以使用--mmap選項進行存儲器映射以獲得最佳資源使用情況 - 內核將文件映射到內存區域;應用程序本身不知道如何,但整個文件可以通過一個簡單的內存地址訪問。

+0

謝謝。我很熟悉算法的工作原理,並且毫不懷疑它可以高效地匹配大量的字符串。問題是fgreq是否可以在不耗盡內存的情況下處理1000萬個輸入字符串,或者花費很長時間構建DFA。在1.5千兆字節,我不認爲輸入文件特別大,並且具有足夠的內存,標準OS文件緩存應該足夠了。 – 2011-01-05 22:19:17

+0

來自Iulian Moraru和David G. Andersen的研究項目(__快速緩存爲您的文本:加速與前饋布隆過濾器_的精確模式匹配)給現有(f)grep實現的邊界留下了良好的印象。我自己,我從來沒有達到過他們。 – 2011-01-05 22:47:44