有关Lucene的问题：用Lucene构建实时索引
我的图书馆
有关Lucene的问题：用Lucene构建实时索引
所谓事务性，本多指数据库的属性，包括ACID四个基本要素：原子性(Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。我们这里主要讨论隔离性，Lucene的IndexReader和IndexWriter具有隔离性。当IndexReader.open打开一个索引的时候，相对于给当前索引进行了一次snapshot，此后的任何修改都不会被看到。仅当IndexReader.open打开一个索引后，才有可能看到从上次打开后对索引的修改。当IndexWriter没有调用Commit的时候，其修改的内容是不能够被看到的，哪怕IndexReader被重新打开。欲使最新的修改被看到，一方面IndexWriter需要commit，一方面IndexReader重新打开。下面我们举几个例子来说明上述隔离性：(1) 首先做准备，索引十篇文档File indexDir = new File("TestIsolation/index");IndexWriter writer = new IndexWriter(FSDirectory.open(indexDir), new StandardAnalyzer(Version.LUCENE_CURRENT), true, IndexWriter.MaxFieldLength.LIMITED);for(int i =0; i & 10; i++){& indexDocs(writer);}writer.close();(2) 然后再索引十篇文档，并不commitwriter = new IndexWriter(FSDirectory.open(indexDir), new StandardAnalyzer(Version.LUCENE_CURRENT), IndexWriter.MaxFieldLength.LIMITED);for(int i =0; i & 10; i++){& indexDocs(writer);}(3) 打开一个IndexReader，但是由于IndexWriter没有commit，所以仍然仅看到十篇文档。IndexReader reader = IndexReader.open(FSDirectory.open(indexDir));IndexSearcher searcher = new IndexSearcher(reader);TopDocs docs = searcher.search(new TermQuery(new Term("contents","hello")), 50);System.out.println(docs.totalHits);(4) IndexWriter进行提交commitmit();(5) 不重新打开IndexReader，进行搜索，仍然仅看到十篇文档。docs = searcher.search(new TermQuery(new Term("contents","hello")), 50);System.out.println(docs.totalHits);(6) IndexReader重新打开，则可以看到二十篇文档。reader = IndexReader.open(FSDirectory.open(indexDir));searcher = new IndexSearcher(reader);docs = searcher.search(new TermQuery(new Term("contents","hello")), 50);System.out.println(docs.totalHits);由于前一章所述的Lucene的事务性，使得Lucene可以增量的添加一个段，我们知道，倒排索引是有一定的格式的，而这个格式一旦写入是非常难以改变的，那么如何能够增量建索引呢？Lucene使用段这个概念解决了这个问题，对于每个已经生成的段，其倒排索引结构不会再改变，而增量添加的文档添加到新的段中，段之间在一定的时刻进行合并，从而形成新的倒排索引结构。然而也正因为Lucene的事务性，使得Lucene的索引不够实时，如果想Lucene实时，则必须新添加的文档后IndexWriter需要commit，在搜索的时候IndexReader需要重新的打开，然而当索引在硬盘上的时候，尤其是索引非常大的时候，IndexWriter的commit操作和IndexReader的open操作都是非常慢的，根本达不到实时性的需要。好在Lucene提供了RAMDirectory，也即内存中的索引，能够很快的commit和open，然而又存在如果索引很大，内存中不能够放下的问题。所以要构建实时的索引，就需要内存中的索引RAMDirectory和硬盘上的索引FSDirectory相互配合来解决问题。1、初始化阶段首先假设我们硬盘上已经有一个索引FileSystemIndex，由于IndexReader打开此索引非常的慢，因而其是需要事先打开的，并且不会时常的重新打开。我们在内存中有一个索引MemoryIndex，新来的文档全部索引到内存索引中，并且是索引完IndexWriter就commit，IndexReader就重新打开，这两个操作时非常快的。如下图，则此时新索引的文档全部能被用户看到，达到实时的目的。2、合并索引阶段然而经过一段时间，内存中的索引会比较大了，如果不合并到硬盘上，则可能造成内存不够用，则需要进行合并的过程。当然在合并的过程中，我们依然想让我们的搜索是实时的，这是就需要一个过渡的索引，我们称为MergingIndex。一旦内存索引达到一定的程度，则我们重新建立一个空的内存索引，用于合并阶段索引新的文档，然后将原来的内存索引称为合并中索引，并启动一个后台线程进行合并的操作。在合并的过程中，如果有查询过来，则需要三个IndexReader，一个是内存索引的IndexReader打开，这个过程是很快的，一个是合并中索引的IndexReader打开，这个过程也是很快的，一个是已经打开的硬盘索引的IndexReader，无需重新打开。这三个IndexReader可以覆盖所有的文档，唯一有可能重复的是，硬盘索引中已经有一些从合并中索引合并过去的文档了，然而不用担心，根据Lucene的事务性，在硬盘索引的IndexReader没有重新打开的情况下，背后的合并操作它是看不到的，因而这三个IndexReader所看到的文档应该是既不少也不多。合并使用IndexWriter(硬盘索引).addIndexes(IndexReader(合并中索引))，合并结束后Commit。如下图：&3、重新打开硬盘索引的IndexReader当合并结束后，是应该重新打开硬盘索引的时候了，然而这是一个可能比较慢的过程，在此过程中，我们仍然想保持实时性，因而在此过程中，合并中的索引不能丢弃，硬盘索引的IndexReader也不要动，而是为硬盘索引打开一个临时的IndexReader，在打开的过程中，如果有搜索进来，返回的仍然是上述的三个IndexReader，仍能够不多不少的看到所有的文档，而将要打开的临时的IndexReader将能看到合并中索引和原来的硬盘索引所有的文档，此IndexReader并不返回给客户。如下图：4、替代IndexReader当临时的IndexReader被打开的时候，其看到的是合并中索引的IndexReader和硬盘索引原来的IndexReader之和，下面要做的是:(1) 关闭合并中索引的IndexReader(2) 抛弃合并中索引(3) 用临时的IndexReader替换硬盘索引原来的IndexReader(4) 关闭硬盘索引原来的IndexReader。上面说的这几个操作必须是原子性的，如果做了(2)但没有做(3)，如果来一个搜索，则将少看到一部分数据，如果做了(3)没有做(2)则，多看到一部分数据。所以在进行上述四步操作的时候，需要加一个锁，如果这个时候有搜索进来的时候，或者在完全没有做的时候得到所有的IndexReader，或者在完全做好的时候得到所有的IndexReader，这时此搜索可能被block，但是没有关系，这四步是非常快的，丝毫不影响替代性。如下图：经过这几个过程，又达到了第一步的状态，则进行下一个合并的过程。5、多个索引有一点需要注意的是，在上述的合并过程中，新添加的文档是始终添加到内存索引中的，如果存在如下的情况，索引速度实在太快，在合并过程没有完成的时候，内存索引又满了，或者硬盘上的索引实在太大，合并和重新打开要花费太长的时间，使得内存索引以及满的情况下，还没有合并完成。为了处理这种情况，我们可以拥有多个合并中的索引，多个硬盘上的索引，如下图：新添加的文档永远是进入内存索引当内存索引到达一定的大小的时候，将其加入合并中索引链表有一个后台线程，每隔一定的时刻，将合并中索引写入一个新的硬盘索引中取。这样可以避免由于硬盘索引过大而合并较慢的情况。硬盘索引的IndexReader也是写完并重新打开后才替换合并中索引的IndexReader，新的硬盘索引也可保证打开的过程不会花费太长时间。这样会造成硬盘索引很多，所以，每隔一定的时刻，将硬盘索引合并成一个大的索引。也是合并完成后方才替换IndexReader大家可能会发现，此合并的过程和Lucene的段的合并很相似。然而Lucene的一个函数IndexReader.reopen一直是没有实现的，也即我们不能选择哪个段是在内存中的，可以被打开，哪些是硬盘中的，需要在后台打开然后进行替换，而IndexReader.open是会打开所有的内存中的和硬盘上的索引，因而会很慢，从而降低了实时性。在有关Lucene的问题(7)，讨论了使用Lucene内存索引和硬盘索引构建实时索引的问题。然而有的读者提到，如果涉及到文档的删除及更新，那么如何构建实时的索引呢？本节来讨论这个问题。1、Lucene删除文档的几种方式&IndexReader.deleteDocument(int docID)是用 IndexReader 按文档号删除。&&IndexReader.deleteDocuments(Term& term)是用 IndexReader 删除包含此词(Term)的文档。&&IndexWriter.deleteDocuments(Term& term)是用 IndexWriter 删除包含此词(Term)的文档。&&IndexWriter.deleteDocuments(Term[]& terms)是用 IndexWriter 删除包含这些词(Term)的文档。&&IndexWriter.deleteDocuments(Query& query)是用 IndexWriter 删除能满足此查询(Query)的文档。&&IndexWriter.deleteDocuments(Query[] queries)是用 IndexWriter 删除能满足这些查询(Query)的文档。删除文档既可以用reader进行删除，也可以用writer进行删除，不同的是，reader进行删除后，此reader马上能够生效，而用writer删除后，会被缓存，只有写入到索引文件中，当reader再次打开的时候，才能够看到。2、Lucene文档更新的几个问题&2.1、使用IndexReader还是IndexWriter进行删除既然IndexReader和IndexWriter都能够进行文档删除，那么到底是应该用哪个来进行删除呢？本文的建议是，用IndexWriter来进行删除。因为用IndexReader可能存在以下的问题：(1) 当有一个IndexWriter打开的时候，IndexReader的删除操作是不能够进行的，否则会报LockObtainFailedException(2) 当IndexReader被多个线程使用的时候，一个线程用其进行删除，会使得另一个线程看到的索引有所改变，使得另一个线程的结果带有不确定性。(3) 对于更新操作，在Lucene中是先删除，再添加的，然而删除的被立刻看到的，而添加却不能够立刻看到，造成了数据的不一致性。(4) 即便以上问题可以通过锁来解决，然而背后的操作影响到了搜索的速度，是我们不想看到的。2.2、如何在内存中缓存文档的删除在上一节中，为了能够做到实时性，我们使用内存中的索引，而硬盘上的索引则不经常打开，即便打开也在背后线程中打开。而要删除的文档如果在硬盘索引中，如果不重新打开则看不到新的删除，则需要将删除的文档缓存到内存中。那如何将缓存在内存中的文档删除在不重新打开IndexReader的情况下应用于硬盘上的索引呢？在Lucene中，有一种IndexReader为FilterIndexReader，可以对一个IndexReader进行封装，我们可以实现一个自己的FilterIndexReader来过滤掉删除的文档。一个例子如下：&public class MyFilterIndexReader extends FilterIndexReader {& OpenBitS& public MyFilterIndexReader(IndexReader in) {&&& super(in);&&& dels = new OpenBitSet(in.maxDoc());& }& public MyFilterIndexReader(IndexReader in, List&String& idToDelete) throws IOException {&&& super(in);&&& dels = new OpenBitSet(in.maxDoc());&&& for(String id : idToDelete){&&&&& TermDocs td = in.termDocs(new Term("id", id));&//如果能在内存中Cache从Lucene的ID到应用的ID的映射，Reader的生成将快得多。&&&&& if(td.next()){&&&&&&& dels.set(td.doc());&&&&& }&&& }& }& @Override& public int numDocs() {&&& return in.numDocs() - (int) dels.cardinality();& }& @Override& public TermDocs termDocs(Term term) throws IOException {&&& return new FilterTermDocs(in.termDocs(term)) {&&&&& @Override&&&&& public boolean next() throws IOException {&&&&&&&&&&&&&& while ((res = super.next())) {&&&&&&&&& if (!dels.get(doc())) {&&&&&&&&&&&&&&&&&&&& }&&&&&&& }&&&&&&&&&&&& }&&& };& }& @Override& public TermDocs termDocs() throws IOException {&&& return new FilterTermDocs(in.termDocs()) {&&&&& @Override&&&&& public boolean next() throws IOException {&&&&&&&&&&&&&& while ((res = super.next())) {&&&&&&&&& if (!dels.get(doc())) {&&&&&&&&&&&&&&&&&&&& }&&&&&&& }&&&&&&&&&&&& }&&& };& }}&2.3、文档更新的顺序性问题Lucene的文档更新其实是删除旧的文档，然后添加新的文档。如上所述，删除的文档是缓存在内存中的，并通过FilterIndexReader应用于硬盘上的索引，然而新的文档也是以相同的id加入到索引中去的，这就需要保证缓存的删除不会将新的文档也过滤掉，将缓存的删除合并到索引中的时候不会将新的文档也删除掉。Lucene的两次更新一定要后一次覆盖前一次，而不能让前一次覆盖后一次。所以内存中已经硬盘中的多个索引是要被保持一个顺序的，哪个是老的索引，哪个是新的索引，缓存的删除自然是应该应用于所有比他老的索引的，而不应该应用于他自己以及比他新的索引。3、具有更新功能的Lucene实时索引方案3.1、初始化首先假设我们硬盘上已经有一个索引FileSystemIndex，被事先打开的，其中包含文档1,2,3,4,5,6。我们在内存中有一个索引MemoryIndex，新来的文档全部索引到内存索引中，并且是索引完IndexWriter就commit，IndexReader就重新打开，其中包含文档7,8。&3.2、更新文档5这时候来一个新的更新文档5, 需要首先将文档5删除，然后加入新的文档5。需要做的事情是：首先在内存索引中删除文档5，当然没有文档5，删除无效。其次将对文档5的删除放入内存文档删除列表，并与硬盘的IndexReader组成FilterIndexReader最后，将新的文档5加入内存索引，这时候，用户可以看到的就是新的文档5了。将文档5放入删除列表以及将文档5提交到内存索引两者应该是一个原子操作，好在这两者都是比较块的。注：此处对硬盘上的索引，也可以进行对文档5的删除，由于IndexReader没有重新打开，此删除是删不掉的，我们之所以没有这样做，是想保持此次更新要么全部在内存中，要么全部在硬盘中，而非删除部分已经应用到硬盘中，而新文档却在内存中，此时，如果系统crash，则新的文档5丢失了，而旧的文档5也已经在硬盘上被删除。我们将硬盘上对文档5的删除放到从内存索引向硬盘索引的合并过程。如果再有一次对文档5的更新，则首先将内存索引中的文档5删除，添加新的文档5，然后将文档5加入删除列表，发现已经存在，则不必删除。3.3、合并索引然而经过一段时间，内存中的索引需要合并到硬盘上。在合并的过程中，需要重新建立一个空的内存索引，用于合并阶段索引新的文档，而合并中的索引的IndexReader以及硬盘索引和删除列表所组成的FilterIndexReader仍然保持打开，对外提供服务，而合并阶段从后台进行。后台的合并包括以下几步：将删除列表应用到硬盘索引中。将内存索引合并到硬盘索引中。IndexWriter提交。3.4、合并的过程中更新文档5在合并的过程中，如果还有更新那怎么办呢？首先将合并中索引的文档5删除，此删除不会影响合并，因为合并之前，合并中索引的IndexReader已经打开，索引合并中索引的文档5还是会合并到硬盘中去的。此删除影响的是此后的查询在合并中索引是看不到文档5的。然后将文档5的删除放入删除列表，并同合并中索引的删除列表，已经硬盘索引一起构成FilterIndexReader。将新的文档5添加到内存中索引。提交在合并中索引对文档5的删除，将文档5添加到删除列表，提交在内存索引中对文档5的添加三者应该是一个原子操作，好在三者也是很快的。3.5、重新打开硬盘索引的IndexReader当合并中索引合并到硬盘中的时候，是时候重新打开硬盘上的索引了，新打开的IndexReader是可以看到文档5的删除的。如果这个时候有新的更新，也是添加到内存索引和删除列表的，比如我们更新文档6.3.6、替代IndexReader&当IndexReader被重新打开后，则需要删除合并中的索引及其删除列表，将硬盘索引原来的IndexReader关闭，使用新的IndexReader。绿色通道：&&&&荣誉：我在关注他&10(请您对文章做出评价)博主前一篇：博主后一篇：&&&&&&&&&&&&&&&
TA的推荐TA的最新馆藏[转]&[转]&专注于框架、中间件、系统架构等。
本文转载自：
Lucene的索引里面存了些什么，如何存放的，也即Lucene的索引文件格式，是读懂Lucene源代码的一把钥匙。
当我们真正进入到Lucene源代码之中的时候，我们会发现:
Lucene的索引过程，就是按照全文检索的基本过程，将倒排表写成此文件格式的过程。
Lucene的搜索过程，就是按照此文件格式将索引进去的信息读出来，然后计算每篇文档打分(score)的过程。
本文详细解读了Apache Lucene - Index File Formats() 这篇文章。
一、基本概念
下图就是Lucene生成的索引的一个实例：
Lucene的索引结构是有层次结构的，主要分以下几个层次：
索引(Index)：
在Lucene中一个索引是放在一个文件夹中的。
如上图，同一文件夹中的所有的文件构成一个Lucene索引。
段(Segment)：
一个索引可以包含多个段，段与段之间是独立的，添加新文档可以生成新的段，不同的段可以合并。
如上图，具有相同前缀文件的属同一个段，图中共两个段 "_0" 和 "_1"。
segments.gen和segments_5是段的元数据文件，也即它们保存了段的属性信息。
文档(Document)：
文档是我们建索引的基本单位，不同的文档是保存在不同的段中的，一个段可以包含多篇文档。
新添加的文档是单独保存在一个新生成的段中，随着段的合并，不同的文档合并到同一个段中。
域(Field)：
一篇文档包含不同类型的信息，可以分开索引，比如标题，时间，正文，作者等，都可以保存在不同的域里。
不同域的索引方式可以不同，在真正解析域的存储的时候，我们会详细解读。
词(Term)：
词是索引的最小单位，是经过词法分析和语言处理后的字符串。
Lucene的索引结构中，即保存了正向信息，也保存了反向信息。
所谓正向信息：
按层次保存了从索引，一直到词的包含关系：索引(Index) && 段(segment) && 文档(Document) && 域(Field) && 词(Term)
也即此索引包含了那些段，每个段包含了那些文档，每个文档包含了那些域，每个域包含了那些词。
既然是层次结构，则每个层次都保存了本层次的信息以及下一层次的元信息，也即属性信息，比如一本介绍中国地理的书，应该首先介绍中国地理的概况，以及中国包含多少个省，每个省介绍本省的基本概况及包含多少个市，每个市介绍本市的基本概况及包含多少个县，每个县具体介绍每个县的具体情况。
如上图，包含正向信息的文件有：
segments_N保存了此索引包含多少个段，每个段包含多少篇文档。
XXX.fnm保存了此段包含了多少个域，每个域的名称及索引方式。
XXX.fdx，XXX.fdt保存了此段包含的所有文档，每篇文档包含了多少域，每个域保存了那些信息。
XXX.tvx，XXX.tvd，XXX.tvf保存了此段包含多少文档，每篇文档包含了多少域，每个域包含了多少词，每个词的字符串，位置等信息。
所谓反向信息：
保存了词典到倒排表的映射：词(Term) && 文档(Document)
如上图，包含反向信息的文件有：
XXX.tis，XXX.tii保存了词典(Term Dictionary)，也即此段包含的所有的词按字典顺序的排序。
XXX.frq保存了倒排表，也即包含每个词的文档ID列表。
XXX.prx保存了倒排表中每个词在包含此词的文档中的位置。
在了解Lucene索引的详细结构之前，先看看Lucene索引中的基本数据类型。
二、基本类型
Lucene索引文件中，用一下基本类型来保存信息：
Byte：是最基本的类型，长8位(bit)。
UInt32：由4个Byte组成。
UInt64：由8个Byte组成。
变长的整数类型，它可能包含多个Byte，对于每个Byte的8位，其中后7位表示数值，最高1位表示是否还有另一个Byte，0表示没有，1表示有。
越前面的Byte表示数值的低位，越后面的Byte表示数值的高位。
例如130化为二进制为 ，总共需要8位，一个Byte表示不了，因而需要两个Byte来表示，第一个Byte表示后7位，并且在最高位置1来表示后面还有一个Byte，所以为(1) 0000010，第二个Byte表示第8位，并且最高位置0来表示后面没有其他的Byte了，所以为(0) 0000001。
Chars：是UTF-8编码的一系列Byte。
String：一个字符串首先是一个VInt来表示此字符串包含的字符的个数，接着便是UTF-8编码的字符序列Chars。
三、基本规则
Lucene为了使的信息的存储占用的空间更小，访问速度更快，采取了一些特殊的技巧，然而在看Lucene文件格式的时候，这些技巧却容易使我们感到困惑，所以有必要把这些特殊的技巧规则提取出来介绍一下。
在下不才，胡乱给这些规则起了一些名字，是为了方便后面应用这些规则的时候能够简单，不妥之处请大家谅解。
1. 前缀后缀规则(Prefix+Suffix)
Lucene在反向索引中，要保存词典(Term Dictionary)的信息，所有的词(Term)在词典中是按照字典顺序进行排列的，然而词典中包含了文档中的几乎所有的词，并且有的词还是非常的长的，这样索引文件会非常的大，所谓前缀后缀规则，即当某个词和前一个词有共同的前缀的时候，后面的词仅仅保存前缀在词中的偏移(offset)，以及除前缀以外的字符串(称为后缀)。
比如要存储如下词:term，termagancy，termagant，terminal，
如果按照正常方式来存储，需要的空间如下：
[VInt = 4] [t][e][r][m]，[VInt = 10][t][e][r][m][a][g][a][n][c][y]，[VInt = 9][t][e][r][m][a][g][a][n][t]，[VInt = 8][t][e][r][m][i][n][a][l]
共需要35个Byte.
如果应用前缀后缀规则，需要的空间如下：
[VInt = 4] [t][e][r][m]，[VInt = 4 (offset)][VInt = 6][a][g][a][n][c][y]，[VInt = 8 (offset)][VInt = 1][t]，[VInt = 4(offset)][VInt = 4][i][n][a][l]
共需要22个Byte。(原文勘误：此处是18个Byte)
大大缩小了存储空间，尤其是在按字典顺序排序的情况下，前缀的重合率大大提高。
2. 差值规则(Delta)
在Lucene的反向索引中，需要保存很多整型数字的信息，比如文档ID号，比如词(Term)在文档中的位置等等。
由上面介绍，我们知道，整型数字是以VInt的格式存储的。随着数值的增大，每个数字占用的Byte的个数也逐渐的增多。所谓差值规则(Delta)就是先后保存两个整数的时候，后面的整数仅仅保存和前面整数的差即可。
比如要存储如下整数：1，1
如果按照正常方式来存储，需要的空间如下：
[(1) 000, 0010][(1) 000, 0000][(0) 000, 0001]，[(1) 000, 0011][(1) 000, 0000][(0) 000, 0001]，[(1) 000, 0100][(1) 000, 0000][(0) 000, 0001]，[(1) 000, 0101][(1) 000, 0000][(0) 000, 0001]
供需12个Byte。
如果应用差值规则来存储，需要的空间如下：
[(1) 000, 0010][(1) 000, 0000][(0) 000, 0001]，[(0) 000, 0001]，[(0) 000, 0001]，[(0) 000, 0001]
共需6个Byte。
大大缩小了存储空间，而且无论是文档ID，还是词在文档中的位置，都是按从小到大的顺序，逐渐增大的。
3. 或然跟随规则(A, B?)
Lucene的索引结构中存在这样的情况，某个值A后面可能存在某个值B，也可能不存在，需要一个标志来表示后面是否跟随着B。
一般的情况下，在A后面放置一个Byte，为0则后面不存在B，为1则后面存在B，或者0则后面存在B，1则后面不存在B。
但这样要浪费一个Byte的空间，其实一个Bit就可以了。
在Lucene中，采取以下的方式：A的值左移一位，空出最后一位，作为标志位，来表示后面是否跟随B，所以在这种情况下，A/2是真正的A原来的值。
如果去读Apache Lucene - Index File Formats这篇文章，会发现很多符合这种规则的：
.frq文件中的DocDelta[, Freq?]，DocSkip,PayloadLength?
.prx文件中的PositionDelta,Payload? (但不完全是，如下表分析)
当然还有一些带?的但不属于此规则的：
.frq文件中的SkipChildLevelPointer?，是多层跳跃表中，指向下一层表的指针，当然如果是最后一层，此值就不存在，也不需要标志。
.tvf文件中的Positions?, Offsets?。
在此类情况下，带?的值是否存在，并不取决于前面的值的最后一位。
而是取决于Lucene的某项配置，当然这些配置也是保存在Lucene索引文件中的。
如Position和Offset是否存储，取决于.fnm文件中对于每个域的配置(TermVector.WITH_POSITIONS和TermVector.WITH_OFFSETS)
为什么会存在以上两种情况，其实是可以理解的：
对于符合或然跟随规则的，是因为对于每一个A，B是否存在都不相同，当这种情况大量存在的时候，从一个Byte到一个Bit如此8倍的空间节约还是很值得的。
对于不符合或然跟随规则的，是因为某个值的是否存在的配置对于整个域(Field)甚至整个索引都是有效的，而非每次的情况都不相同，因而可以统一存放一个标志。
文章中对如下格式的描述令人困惑：
Positions --& &PositionDelta,Payload?&&Freq
Payload --& &PayloadLength?,PayloadData&
PositionDelta和Payload是否适用或然跟随规则呢？如何标识PayloadLength是否存在呢？
其实PositionDelta和Payload并不符合或然跟随规则，Payload是否存在，是由.fnm文件中对于每个域的配置中有关Payload的配置决定的(FieldOption.STORES_PAYLOADS) 。
当Payload不存在时，PayloadDelta本身不遵从或然跟随原则。
当Payload存在时，格式应该变成如下：Positions --& &PositionDelta,PayloadLength?,PayloadData&&Freq
从而PositionDelta和PayloadLength一起适用或然跟随规则。
4. 跳跃表规则(Skip list)&
为了提高查找的性能，Lucene在很多地方采取的跳跃表的数据结构。
跳跃表(Skip List)是如图的一种数据结构，有以下几个基本特征：
元素是按顺序排列的，在Lucene中，或是按字典顺序排列，或是按从小到大顺序排列。
跳跃是有间隔的(Interval)，也即每次跳跃的元素数，间隔是事先配置好的，如图跳跃表的间隔为3。
跳跃表是由层次的(level)，每一层的每隔指定间隔的元素构成上一层，如图跳跃表共有2层。
需要注意一点的是，在很多数据结构或算法书中都会有跳跃表的描述，原理都是大致相同的，但是定义稍有差别：
对间隔(Interval)的定义： 如图中，有的认为间隔为2，即两个上层元素之间的元素数，不包括两个上层元素；有的认为是3，即两个上层元素之间的差，包括后面上层元素，不包括前面的上层元素；有的认为是4，即除两个上层元素之间的元素外，既包括前面，也包括后面的上层元素。Lucene是采取的第二种定义。
对层次(Level)的定义：如图中，有的认为应该包括原链表层，并从1开始计数，则总层次为3，为1，2，3层；有的认为应该包括原链表层，并从0计数，为0，1，2层；有的认为不应该包括原链表层，且从1开始计数，则为1，2层；有的认为不应该包括链表层，且从0开始计数，则为0，1层。Lucene采取的是最后一种定义。
跳跃表比顺序查找，大大提高了查找速度，如查找元素72，原来要访问2，3，7，12，23，37，39，44，50，72总共10个元素，应用跳跃表后，只要首先访问第1层的50，发现72大于50，而第1层无下一个节点，然后访问第2层的94，发现94大于72，然后访问原链表的72，找到元素，共需要访问3个元素即可。
然而Lucene在具体实现上，与理论又有所不同，在具体的格式中，会详细说明。
阅读(...) 评论()