lucene如何索引文件？
我读了一些关于Lucene的文档; 我也读过这个链接文档（ http://lucene.sourceforge.net/talks/pisa ）。
我不太了解Lucene如何索引文档，也不明白Lucene使用哪种algorithm进行索引？
在上面的链接，它说，Lucene使用这个algorithm进行索引：
- 增量algorithm：
- 维护一堆段索引
- 为每个传入文档创build索引
- 将新索引推入堆栈
- 让b = 10为合并因子; M = 8
for (size = 1; size < M; size *= b) { if (there are b indexes with size docs on top of the stack) { pop them off the stack; merge them into a single index; push the merged index onto the stack; } else { break; } } 这个algorithm如何提供优化的索引？
Lucene是否使用B-树algorithm或任何其他类似的索引algorithm？还是它有一个特定的algorithm？
这里有一篇相当不错的文章： https : //web.archive.org/web/20130904073403/http : //www.ibm.com/developerworks/library/wa-lucene/
编辑12/2014：由于原来被删除，已更新为归档版本，可能最好的更新的替代是http://lucene.apache.org/core/3_6_2/fileformats.html
简而言之，当lucene索引一个文档时，会将其分解成若干项。 然后将这些条款存储在索引文件中，其中每个条款与包含它的文件相关联。 你可以认为它有点像一个哈希表。
术语是使用分析器生成的，每个词都是根据其forms。 最stream行的英语干扰algorithm是Porter干扰algorithm： http : //tartarus.org/~martin/PorterStemmer/
当发出查询时，它将通过用于构build索引的相同分析器进行处理，然后用于查找索引中的匹配项。 这提供了与查询匹配的文档列表。
看起来你的问题更多的是索引合并而不是索引本身。
如果忽略低级细节，索引过程非常简单。 Lucene从文档中形成所谓的“倒排索引”。 所以如果带有文本“To be or not to be”和id = 1的文档进入，倒排索引看起来像：
[to] → 1 [be] → 1 [or] → 1 [not] → 1
这基本上就是它 – 从单词到包含给定单词的文档列表的索引。 这个索引（单词）的每一行称为发布列表。 这个指标是坚持长期存储的。
事实上当然事情更复杂：
- Lucene可能会根据给定的特定分析器跳过一些单词;
- 可以使用词干algorithm对单词进行预处理以降低语言的灵活性;
- 发布列表不仅可以包含文档的标识符，还可以包含文档中给定单词（可能有多个实例）的偏移以及其他附加信息。
对于基本理解来说，还有许多并不那么重要的复杂因素。
尽pipe如此，理解Lucene索引只是附加的 ，这一点很重要。 在某些时候，应用程序决定提交（发布）索引中的所有更改。 Lucene使用索引完成所有服务操作并closures它，因此可用于search。 提交索引后基本上是不可变的。 这个索引（或索引部分）被称为段 。 当Lucene执行search查询时，它会search所有可用的段。
所以出现这个问题 – 我们如何改变已经索引的文档呢？
已编入索引的文档的新文档或新版本将使用所谓的“ 终止列表”在以前的段中失效的新分段和旧版本中编入索引。 杀死列表是可以改变的承诺索引的唯一部分。 您可能会猜到，索引效率会随着时间而下降，因为旧索引可能包含大部分已删除的文档。
这就是合并的地方。合并 – 是将多个索引合并为一个更高效的索引的过程。 在合并过程中，基本上发生的情况是将活动文档复制到新的分段，而将旧的分段完全删除。
使用这个简单的过程Lucene能够在search性能方面保持良好的索引。
希望它会有所帮助。
它是倒排索引 ，但是没有指定它使用的结构。 在lucene中的索引格式有完整的信息。
从“文件扩展名摘要”开始。
你会首先注意到它谈到了各种不同的索引。 据我所知，这些都没有严格使用B树 ，但也有相似之处 – 上述结构的确像树。
简而言之，Lucene使用Skip-Lists 在磁盘上构build倒排索引，然后使用有限状态转换器 （FST）将索引项的映射加载到内存中 。 但是请注意，Lucene 并没有（必然）将所有的索引条目加载到RAM中 ，正如Lucene索引系统本身的作者Michael McCandless所描述的那样。 请注意，通过使用Skip-Lists，可以将索引从一个索引遍历到另一个索引，使得类似set ，特别是范围查询成为可能（就像B-Tree一样）。 而关于索引跳过列表的维基百科条目也解释了为什么将Lucene的跳过列表实现称为多级跳过列表 – 本质上是为了使O(log n)查找成为可能（再次，很像B树）。
因此，一旦从文档构build了基于跳过列表数据结构的反转（术语）索引，索引就存储在磁盘上。 然后Lucene将这些条件加载到有限状态转换器中（ 如前所述 ：可能只是其中的一部分），在FST实现中由Morfologick 松散地启发 。
Michael McCandless（也）在解释Lucene如何以及为什么使用（最小非循环）FST来索引Lucene在内存中存储的术语方面做了相当不错的工作，实质上就是一个SortedMap<ByteSequence,SomeOutput> ，并给出了一个基本的想法FST是如何工作的（即，FST如何压缩字节序列（即索引项）以使存储器使用这种映射增长为亚线性）。 他指出了描述 Lucene使用的特定FSTalgorithm的论文 。
对于那些好奇的人，为什么Lucene使用Skip-Lists，而大多数数据库使用（B +） – 和/或（B）-Trees，请看看这个问题的正确答案 （Skip-Lists vs. B-Trees）。 这个答案给出了一个相当不错的深层次的解释 – 实质上， 并不是让索引的并发更新更“舒适”（因为您可以决定不要立即重新平衡B树，从而获得大致相同的并发性能跳过列表），而是跳过列表让您不必处理 （最终）B-Trees所需的 （延迟或不） 平衡操作 （实际上，因为答案显示/引用，可能很lessB-Trees和[多级]跳过列表之间的性能差异，如果其中任何一个都“正确”。）
