實現文檔的搜索引擎

背景問題實現文檔的搜索引擎

大家好，我是工作在一堆根據所提供的查詢文檔中搜索相關文件的項目。由於這是一個小型項目，我有一個典型的內存體系結構，我假設我沒有更多的100個文檔，每個文檔包含不超過1000個單詞（一個單詞不超過10個字符）。我收到很多查詢，並且必須儘快處理查詢（絕對不會超過一秒）。

我的第一種方法（天真和不可擴展）：

由於允許用戶上傳文件，每當我收到一個文檔，我找了「勢」的關鍵字和存儲關鍵字作爲關鍵並將其記錄爲值對或MYSQL表中。顯然，這必須手動完成，看起來不像程序員會做什麼。

我的第二個方法（稍好）：

我把每個文檔，掃描它的每一個字，該字添加到特里數據結構，因此對於100個文件我必須搜尋100嘗試，如果查詢的長度爲l，則此方法將採用最差的O（所有文檔中的字數*最大的單詞長度）來構建查詢樹並查詢O（查詢的長度）。這很合理。爲了實現這個功能，我會爲每個文檔保留一個Trie根節點的向量，並遍歷每個trie節點並在每個trie中進行搜索。如果至少有一半的查詢詞匹配，我將該文檔存儲爲潛在結果。作爲結果，我不會給出超過某些截止數量的文件。

我的問題給社區：

我會問什麼你覺得我的方法？我如何優化它們，在現有方法中可以做哪些其他改進？這可以通過使用其他算法或數據結構更有效地完成嗎？在網上衝浪我遇到了像Boyer-Moore和Aho-Corasick這樣的算法，以及一些建議，以調整Lucene Apache實現的算法等等。

來源

2017-06-21 hulk_baba

看看[elasticsearch]（https://www.elastic.co/）。它具有極高的可擴展性，應該完美地適合您的項目。 – CaptainTrunky

@CaptainTrunky，請不要使用這個庫，這個項目的全部內容都是由我自己來完成的。如果你能說出彈性搜索的核心是什麼，對我來說是有用的。 –

對於每個1000個單詞和每秒1個請求的100個文檔，grep應該就足夠了。如果您堅持某種索引策略，請維護一個按字和二進制排序的（字，文檔集）對列表。這可能只是一個文件。 –

實現全文搜索的最基本的方法是建立一個inverted index和等級相符的文件與指標，如TF-IDF

隨着新文件進來，你的文檔中提取文字和文檔添加到您的倒排索引。

當查詢進入時，您會從索引中找到匹配的文檔，並根據TF-IDF（或您關心的其他度量標準）執行一些排序。作爲查詢的結果，然後返回k個排名最前的文檔。

除此之外，在Information Retrieval字段中有大量的研究使得操作更高效，並使結果（top-k文檔）更好。

來源

2017-06-22 19:06:39

實現文檔的搜索引擎

回答

相關問題