Lucene学习笔记： 五，Lucene搜索过程解析
2024-07-15 21:47:23 221人阅读
一、Lucene搜索过程总论
搜索的过程总的来说就是将词典及倒排表信息从索引中读出来，根据用户输入的查询语句合并倒排表，得到结果文档集并对文档进行打分的过程。
其可用如下图示：
总共包括以下几个过程：
- IndexReader打开索引文件，读取并打开指向索引文件的流。
- 用户输入查询语句
- 将查询语句转换为查询对象Query对象树
- 构造Weight对象树，用于计算词的权重Term Weight，也即计算打分公式中与仅与搜索语句相关与文档无关的部分(红色部分)。
- 构造Scorer对象树，用于计算打分(TermScorer.score())。
- 在构造Scorer对象树的过程中，其叶子节点的TermScorer会将词典和倒排表从索引中读出来。
- 构造SumScorer对象树，其是为了方便合并倒排表对Scorer对象树的从新组织，它的叶子节点仍为TermScorer，包含词典和倒排表。此步将倒排表合并后得到结果文档集，并对结果文档计算打分公式中的蓝色部分。打分公式中的求和符合，并非简单的相加，而是根据子查询倒排表的合并方式(与或非)来对子查询的打分求和，计算出父查询的打分。
- 将收集的结果集合及打分返回给用户。
2.1、打开IndexReader指向索引文件夹
代码为：
IndexReader reader = IndexReader.open(FSDirectory.open(indexDir));
其实是调用了DirectoryReader.open(Directory, IndexDeletionPolicy, IndexCommit, boolean, int) 函数，其主要作用是生成一个SegmentInfos.FindSegmentsFile对象，并用它来找到此索引文件中所有的段，并打开这些段。
SegmentInfos.FindSegmentsFile.run(IndexCommit commit)主要做以下事情：
2.1.1、找到最新的segment_N文件
- 由于segment_N是整个索引中总的元数据，因而正确的选择segment_N更加重要。
- 然而有时候为了使得索引能够保存在另外的存储系统上，有时候需要用NFS mount一个远程的磁盘来存放索引，然而NFS为了提高性能，在本地有Cache，因而有可能使得此次打开的索引不是另外的writer写入的最新信息，所以在此处用了双保险。
- 一方面，列出所有的segment_N，并取出其中的最大的N，设为genA
String[] files = directory.listAll(); long genA = getCurrentSegmentGeneration(files); |
long getCurrentSegmentGeneration(String[] files) { long max = -1; for (int i = 0; i < files.length; i++) { String file = files[i]; if (file.startsWith(IndexFileNames.SEGMENTS) //"segments_N" && !file.equals(IndexFileNames.SEGMENTS_GEN)) { //"segments.gen" long gen = generationFromSegmentsFileName(file); if (gen > max) { max = gen; } } } return max; } |
- 另一方面，打开segment.gen文件，从中读出N，设为genB
IndexInput genInput = directory.openInput(IndexFileNames.SEGMENTS_GEN); int version = genInput.readInt(); long gen0 = genInput.readLong(); long gen1 = genInput.readLong(); if (gen0 == gen1) { genB = gen0; } |
- 在genA和genB中去较大者，为gen，并用此gen构造要打开的segments_N的文件名
if (genA > genB) gen = genA; else gen = genB; String segmentFileName = IndexFileNames.fileNameFromGeneration(IndexFileNames.SEGMENTS, "", gen); //segmentFileName "segments_4" |
2.1.2、通过segment_N文件中保存的各个段的信息打开各个段
- 从segment_N中读出段的元数据信息，生成SegmentInfos
2.1.3、得到的IndexReader对象如下
reader ReadOnlyDirectoryReader (id=466)
closed false
deletionPolicy null //索引文件夹
directory SimpleFSDirectory (id=31)
checked false
chunkSize 104857600
directory File (id=487)
path "D:\\lucene-3.0.0\\TestSearch\\index"
prefixLength 3
isOpen true
lockFactory NativeFSLockFactory (id=488)
hasChanges false
hasDeletions false
maxDoc 12
normsCache HashMap<K,V> (id=483)
numDocs -1
readOnly true
refCount 1
rollbackHasChanges false
rollbackSegmentInfos null //段元数据信息
segmentInfos SegmentInfos (id=457)
elementCount 3
elementData Object[10] (id=532)
[0] SegmentInfo (id=464)
delCount 0
delGen -1
diagnostics HashMap<K,V> (id=537)
dir SimpleFSDirectory (id=31)
docCount 4
docStoreIsCompoundFile false
docStoreOffset -1
docStoreSegment "_0"
files null
hasProx true
hasSingleNormFile true
isCompoundFile 1
name "_0"
normGen null
preLockless false
sizeInBytes -1
[1] SegmentInfo (id=517)
delCount 0
delGen -1
diagnostics HashMap<K,V> (id=542)
dir SimpleFSDirectory (id=31)
docCount 4
docStoreIsCompoundFile false
docStoreOffset -1
docStoreSegment "_1"
files null
hasProx true
hasSingleNormFile true
isCompoundFile 1
name "_1"
normGen null
preLockless false
sizeInBytes -1
[2] SegmentInfo (id=470)
delCount 0
delGen -1
diagnostics HashMap<K,V> (id=547)
dir SimpleFSDirectory (id=31)
docCount 4
docStoreIsCompoundFile false
docStoreOffset -1
docStoreSegment "_2"
files null
hasProx true
hasSingleNormFile true
isCompoundFile 1
name "_2"
normGen null
preLockless false
sizeInBytes -1
generation 4
lastGeneration 4
modCount 4
pendingSegnOutput null
userData HashMap<K,V> (id=533)
version 1268193441675
segmentInfosStart null
stale false
starts int[4] (id=484) //每个段的Reader
subReaders SegmentReader[3] (id=467)
[0] ReadOnlySegmentReader (id=492)
closed false
core SegmentReader$CoreReaders (id=495)
cfsDir CompoundFileReader (id=552)
cfsReader CompoundFileReader (id=552)
dir SimpleFSDirectory (id=31)
fieldInfos FieldInfos (id=553)
fieldsReaderOrig FieldsReader (id=554)
freqStream CompoundFileReader$CSIndexInput (id=555)
proxStream CompoundFileReader$CSIndexInput (id=556)
readBufferSize 1024
ref SegmentReader$Ref (id=557)
segment "_0"
storeCFSReader null
termsIndexDivisor 1
termVectorsReaderOrig null
tis TermInfosReader (id=558)
tisNoIndex null
deletedDocs null
deletedDocsDirty false
deletedDocsRef null
fieldsReaderLocal SegmentReader$FieldsReaderLocal (id=496)
hasChanges false
norms HashMap<K,V> (id=500)
normsDirty false
pendingDeleteCount 0
readBufferSize 1024
readOnly true
refCount 1
rollbackDeletedDocsDirty false
rollbackHasChanges false
rollbackNormsDirty false
rollbackPendingDeleteCount 0
si SegmentInfo (id=464)
singleNormRef SegmentReader$Ref (id=504)
singleNormStream CompoundFileReader$CSIndexInput (id=506)
termVectorsLocal CloseableThreadLocal<T> (id=508)
[1] ReadOnlySegmentReader (id=493)
closed false
core SegmentReader$CoreReaders (id=511)
cfsDir CompoundFileReader (id=561)
cfsReader CompoundFileReader (id=561)
dir SimpleFSDirectory (id=31)
fieldInfos FieldInfos (id=562)
fieldsReaderOrig FieldsReader (id=563)
freqStream CompoundFileReader$CSIndexInput (id=564)
proxStream CompoundFileReader$CSIndexInput (id=565)
readBufferSize 1024
ref SegmentReader$Ref (id=566)
segment "_1"
storeCFSReader null
termsIndexDivisor 1
termVectorsReaderOrig null
tis TermInfosReader (id=567)
tisNoIndex null
deletedDocs null
deletedDocsDirty false
deletedDocsRef null
fieldsReaderLocal SegmentReader$FieldsReaderLocal (id=512)
hasChanges false
norms HashMap<K,V> (id=514)
normsDirty false
pendingDeleteCount 0
readBufferSize 1024
readOnly true
refCount 1
rollbackDeletedDocsDirty false
rollbackHasChanges false
rollbackNormsDirty false
rollbackPendingDeleteCount 0
si SegmentInfo (id=517)
singleNormRef SegmentReader$Ref (id=519)
singleNormStream CompoundFileReader$CSIndexInput (id=520)
termVectorsLocal CloseableThreadLocal<T> (id=521)
[2] ReadOnlySegmentReader (id=471)
closed false
core SegmentReader$CoreReaders (id=475)
cfsDir CompoundFileReader (id=476)
cfsReader CompoundFileReader (id=476)
dir SimpleFSDirectory (id=31)
fieldInfos FieldInfos (id=480)
fieldsReaderOrig FieldsReader (id=570)
freqStream CompoundFileReader$CSIndexInput (id=571)
proxStream CompoundFileReader$CSIndexInput (id=572)
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 HashMap<K,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 CloseableThreadLocal<T> (id=530)
synced HashSet<E> (id=485)
termInfosIndexDivisor 1
writeLock null
writer null |
从上面的过程来看，IndexReader有以下几个特性：
- 段元数据信息已经被读入到内存中，因而索引文件夹中因为新添加文档而新增加的段对已经打开的reader是不可见的。
- .del文件已经读入内存，因而其他的reader或者writer删除的文档对打开的reader也是不可见的。
- 打开的reader已经有inputstream指向cfs文件，从段合并的过程我们知道，一个段文件从生成起就不会改变，新添加的文档都在新的段中，删除的文档都在.del中，段之间的合并是生成新的段，而不会改变旧的段，只不过在段的合并过程中，会将旧的段文件删除，这没有问题，因为从操作系统的角度来讲，一旦一个文件被打开一个inputstream也即打开了一个文件描述符，在内核中，此文件会保持reference count，只要reader还没有关闭，文件描述符还在，文件是不会被删除的，仅仅reference count减一。
- 以上三点保证了IndexReader的snapshot的性质，也即一个IndexReader打开一个索引，就好像对此索引照了一张像，无论背后索引如何改变，此IndexReader在被重新打开之前，看到的信息总是相同的。
- 严格的来讲，Lucene的文档号仅仅对打开的某个reader有效，当索引发生了变化，再打开另外一个reader的时候，前面reader的文档0就不一定是后面reader的文档0了，因而我们进行查询的时候，从结果中得到文档号的时候，一定要在reader关闭之前应用，从存储域中得到真正能够唯一标识你的业务逻辑中的文档的信息，如url，md5等等，一旦reader关闭了，则文档号已经无意义，如果用其他的reader查询这些文档号，得到的可能是不期望的文档。
2.2、打开IndexSearcher
代码为：
IndexSearcher searcher = new IndexSearcher(reader);
其过程非常简单：
private IndexSearcher(IndexReader r, boolean closeReader) { reader = r; //当关闭searcher的时候，是否关闭其reader this.closeReader = closeReader; //对文档号进行编号 List<IndexReader> subReadersList = new ArrayList<IndexReader>(); gatherSubReaders(subReadersList, reader); subReaders = subReadersList.toArray(new IndexReader[subReadersList.size()]); docStarts = new int[subReaders.length]; int maxDoc = 0; for (int i = 0; i < subReaders.length; i++) { docStarts[i] = maxDoc; maxDoc += subReaders[i].maxDoc(); } } |
IndexSearcher表面上看起来好像仅仅是reader的一个封装，它的很多函数都是直接调用reader的相应函数，如：int docFreq(Term term)，Document doc(int i)，int maxDoc()。然而它提供了两个非常重要的函数：
- void setSimilarity(Similarity similarity)，用户可以实现自己的Similarity对象，从而影响搜索过程的打分，详见有关Lucene的问题(4):影响Lucene对文档打分的四种方式
- 一系列search函数，是搜索过程的关键，主要负责打分的计算和倒排表的合并。
因而在某些应用之中，只想得到某个词的倒排表的时候，最好不要用IndexSearcher，而直接用IndexReader.termDocs(Term term)，则省去了打分的计算。
2.3、QueryParser解析查询语句生成查询对象
代码为：
QueryParser parser = new QueryParser(Version.LUCENE_CURRENT, "contents", new StandardAnalyzer(Version.LUCENE_CURRENT)); Query query = parser.parse("+(+apple* -boy) (cat* dog) -(eat~ foods)"); |
此过程相对复杂，涉及JavaCC，QueryParser，分词器，查询语法等，本章不会详细论述，会在后面的章节中一一说明。
此处唯一要说明的是，根据查询语句生成的是一个Query树，这棵树很重要，并且会生成其他的树，一直贯穿整个索引过程。
对于Query对象有以下说明：
- BooleanQuery即所有的子语句按照布尔关系合并
- +也即MUST表示必须满足的语句
- SHOULD表示可以满足的，minNrShouldMatch表示在SHOULD中必须满足的最小语句个数，默认是0，也即既然是SHOULD，也即或的关系，可以一个也不满足(当然没有MUST的时候除外)。
- -也即MUST_NOT表示必须不能满足的语句
- 树的叶子节点中：
- 最基本的是TermQuery，也即表示一个词
- 当然也可以是PrefixQuery和FuzzyQuery，这些查询语句由于特殊的语法，可能对应的不是一个词，而是多个词，因而他们都有rewriteMethod对象指向MultiTermQuery的Inner Class，表示对应多个词，在查询过程中会得到特殊处理。
2.4、搜索查询对象
代码为：
TopDocs docs = searcher.search(query, 50);
其最终调用search(createWeight(query), filter, n);
索引过程包含以下子过程：
- 创建weight树，计算term weight
- 创建scorer及SumScorer树，为合并倒排表做准备
- 用SumScorer进行倒排表合并
- 收集文档结果集合及计算打分
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉：
投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。
