我正在尋找建議，因爲我之前沒有處理大文件解析，並且希望避免在開源解決方案已經存在的情況下重新發明輪子。這是我的情況：大文本文件搜索
我在工作的實驗室中有大約200-300個大的XML和文本文件被一個自動化機器進程放在一個目錄中。這是定期發生的。這些文件的大小範圍可以從幾百MB到幾GB。這些文件會定期修改（每週幾次），並隨機更改舊文件。
我需要能夠搜索這些文件並提取符合特定條件的記錄。在文件（組合）中約2000-3000萬條記錄中，我們實際上可能使用了< 100,000條記錄，但是我們無法確定哪些記錄被搜索到。
我首先想到它設置了一種常規文件處理作業，它檢測更新並將文件處理成可搜索的數據庫。我唯一擔心的是，插入和更新記錄的速度可能會越來越慢，越來越大。
有沒有人有任何建議可能更適合我的情況的方法？關閉我的頭頂我正在考慮一些像Lucene這樣的文本搜索系統，但從未使用它我不積極，如果它將比數據庫更有用...
任何幫助將不勝感激。
有很多很多選擇。 Lucene可能是一個很好的解決方案 - 或者是一個糟糕的選擇。
答案是「這取決於」 ......
你還沒有給你的項目的環境或約束的許多細節。
特別是：什麼是操作系統，什麼是存儲介質，最重要的是您使用的是RDBMS，例如DB2或SQL Server？
如果您的應用程序已經在使用DB2，爲什麼不利用它的內置XML和文本搜索功能？
我其實並沒有真正有什麼進展。這是一個乾淨的石板。我主要想要一些建議，或者一些選項。至於數據庫，我認爲它可能是MySQL或PostGreSQL，只是基於我可以訪問的內容。至於系統，它最有可能是運行在LAMP風格的單服務器系統上，除了內置的RAID設置以外，對於存儲來說可能沒什麼奇特的了。 – 2012-02-19 23:25:34
這取決於您的查詢具體如何。 Lucene和Xapian是索引的好例子。 一般來說，你應該看看索引方法，而不是數據挖掘（我重申了你的問題）。
常規數據庫可能太慢，因爲它需要確保ACID屬性並針對在線更新進行優化。對於你的情況，批量更新可能就足夠了。
因此，本質上我建議看看Xapian或Lucene（我更喜歡xapian），並考慮使用它來爲您的數據構建索引。您可能不會將所有數據都放入索引中（以便更易於管理），但實質上只需將交叉引用放入您現有的XML文件中即可。
取決於您的搜索查詢是什麼樣，更簡單的事情可能會訣竅。考慮一個存儲key->filename,linenumber引用的大型低級別樹。
只是爲了更多的細節。我不想進入實際的文件格式（這真的很無聊，相信我），但想象一下，這是一些患者詳細信息，我需要搜索幾個細節來查找我想要提取的記錄。當我找到我想要的一個時，我需要整個記錄XML或文本文件中的整行，然後將其加載到單獨的數據庫中以供進一步訪問。 – 2012-02-19 23:29:36
此外，搜索需要有點快，我需要能夠在幾秒鐘或一分鐘內找到幾十個結果。快速搜索比快速更新更重要。 – 2012-02-19 23:31:05
您的數據是否包含明確定義的（和相對較短的）記錄？你需要完全匹配還是全文搜索？ – biziclop 2012-02-19 23:46:51