17lucene學習總結之七：lucene搜索過程解析(2)-資料下載頁
2025-10-19 09:09本頁面
【導讀】它來找到此索引文件中所有的段，并打開這些段。由于segment_N是整個索引中總的元數(shù)據(jù)，因而正確的選擇segment_N更加重要。然而有時候為了使得索引能夠保存在另外的存儲系統(tǒng)上，有時候需要用NFSmount. 一方面，列出所有的segment_N，并取出其中的最大的N，設為genA. 在genA和genB中去較大者，為gen，并用此gen構造要打開的segments_N的文件。從segment_N中讀出段的元數(shù)據(jù)信息，生成SegmentInfos. SegmentInfo構造函數(shù)如下：。其實不用多介紹，看過Lucene學習總結之三：Lucene的索引文件格式一章，就很容易明白。;//生成用于讀取存儲域和詞向量的對象。
【正文】 readBufferSize 1024 ref SegmentReader$Ref (id=573) segment _2 storeCFSReader null termsIndexDivisor 1 termVectorsReaderOrig null tis TermInfosReader (id=574) tisNoIndex null deletedDocs null deletedDocsDirty false deletedDocsRef null fieldsReaderLocal SegmentReader$FieldsReaderLocal (id=524) hasChanges false norms HashMapK,V (id=525) normsDirty false pendingDeleteCount 0 readBufferSize 1024 readOnly true refCount 1 rollbackDeletedDocsDirty false rollbackHasChanges false rollbackNormsDirty false rollbackPendingDeleteCount 0 si SegmentInfo (id=470) singleNormRef SegmentReader$Ref (id=527) singleNormStream CompoundFileReader$CSIndexInput (id=528) termVectorsLocal CloseableThreadLocalT (id=530) synced HashSetE (id=485) termInfosIndexDivisor 1 writeLock null writer null 從上面的過程來看， IndexReader 有以下幾個特性： ? 段元數(shù)據(jù)信息已經被讀入到內存中，因而索引文件夾中因為新添加 文檔而新增加的段對已經打開的 reader 是不可見的。 ? .del 文件已經讀入內存，因而其他的 reader 或者 writer 刪除的文檔對打開的reader 也是不可見的。 ? 打開的 reader 已經有 inputstream 指向 cfs 文件，從段合并的過程我們知道，一個段文件從生成起就不會改變，新添加的文檔都在新的段中，刪除的文檔都在 .del 中，段之間的合并是生成新的段，而不會改變舊的段，只不過在段的合并過程中，會將舊的段文件刪除，這沒有問題，因為從操作系統(tǒng)的角度來講，一旦一個文件被打開一個 inputstream 也即打 開了一個文件描述符，在內核中，此文件會保持 reference count，只要 reader 還沒有關閉，文件描述符還在，文件是不會被刪除的，僅僅reference count 減一。 ? 以上三點保證了 IndexReader 的 snapshot 的性質，也即一個 IndexReader 打開一個索引，就好像對此索引照了一張像，無論背后索引如何改變，此 IndexReader 在被重新打開之前，看到的信息總是相同的。 ? 嚴格的來講， Lucene 的文檔號僅僅對打開的某個 reader 有效，當索引發(fā)生了變化，再打開另外一個 reader 的時候，前面 reader 的文檔 0 就不一定是后面 reader 的文檔 0 了，因而我們進行查詢的時候，從結果中得到文檔號的時候，一定要在 reader關閉之前應用，從存儲域中得到真正能夠唯一標識你的業(yè)務邏輯中的文檔的信息，如 url， md5 等等，一旦 reader 關閉了，則文檔號已經無意義，如果用其他的 reader查詢這些文檔號，得到的可能是不期望的文檔。 、打開 IndexSearcher 代碼為： IndexSearcher searcher = new IndexSearcher(reader)。 其過程非 常簡單： private IndexSearcher(IndexReader r, boolean closeReader) { reader = r。 //當關閉 searcher 的時候，是否關閉其 reader = closeReader。 //對文檔號進行編號 ListIndexReader subReadersList = new ArrayListIndexReader()。 gatherSubReaders(subReadersList, reader)。 subReaders = (new IndexReader[()])。 docStarts = new int[]。 int maxDoc = 0。 for (int i = 0。 i 。 i++) { docStarts[i] = maxDoc。 maxDoc += subReaders[i].maxDoc()。 } } IndexSearcher 表面上看起來好像僅僅是 reader 的一個封裝，它的很多函數(shù)都是直接調用reader 的相應函數(shù)，如： int docFreq(Term term)， Document doc(int i)， int maxDoc()。然而它提供了兩個非常重要的函數(shù)： ? void setSimilarity(Similarity similarity)，用戶可以實現(xiàn)自己的 Similarity對象，從而影響搜索過程的打分，詳見 有關 Lucene 的問題 (4):影響 Lucene 對文檔打分的四種方式 ? 一系列 search 函數(shù)，是搜索過程的關鍵，主要負責打分的計算和倒排表的合并。 因而在某些應用之中，只想得到某個詞的倒排表的時候，最好不要用 IndexSearcher，而直接用 (Term term)，則省去了打分的計算。
環(huán)評公示相關推薦
鄂ICP備17016276號-1