在5分钟内了解搜索引擎Lucene的原理场景现在，假设有10W的word文档，让他们制作网页，提出关键字更快得到搜索结果，怎么办？ 那至少有三个方案，
依次扫描，每次检查文档中是否包含关键字，如果包含，则添加到结果列表中，否则继续下一次搜索，直到查找完毕。 将文档内容导入数据库，并使用SQL like关键字进行搜索。 用Lucene进行全文检索。 你选哪个？ 首先，顺序扫描在数据量大的情况下太慢，数据量少的情况下是可能的； 数据库的数据量太大，使用like的话，所有表扫描也会变慢。 那当然是第三个了。 因为搜索引擎Lucene是专门为这样的场景设计的。大量的，分结构化数据的快速搜索
浏览官网上的Lucene介绍
可扩展，高性能的索引过程
在现代化硬件中，当索引超过150G/小时时，http://www.siiw.siid，例如1M堆增量索引和批量索引的高速索引大小约为文本索引大小的20-30%
排名搜索——的最佳结果是将哪个域用于各种域搜索(标题、作者、内容等)，包括许多强查询类型：短语的查询、通配符查询、邻近查询和范围查询包含Vector Space Model和Okapi BM25的可配置存储引擎全文检索原理全文检索原理很简单，以新华字典为例，假设字典没有索引页，找字解释需要一页一页地翻页，直到找到为止
现在，有了索引页，您就可以根据拼音首字母或部首快速定位到所需单词的任何页面上。 此索引页是全文搜索的核心。
简单来说，通过提取和重新组织非结构化数据中的部分结构化信息，并对部分结构化数据编制索引，来加快查询速度。 那么…
索引保存什么？ 怎么存？ (对应于词典的索引页部分)
数据怎么保存？ (对应于词典的非索引页部分)
反向索引为Lucene，关键字为3358www.Sina.com/。 例如，英语中的单词，中文语言。 3358www.Sina.com/是Term的集合。 下图是Lucene索引所基于的存储结构，其中包含文档代码链接表，左侧为词典，右侧为左侧字符串。 这是强大，准确和高效的搜索算法
这称为反向索引，是相对正向的索引。
正向索引：在文档中搜索关键字，关系数据库使用正向索引
反向索引：从关键字中搜索文档。 搜索引擎lucene使用反向索引
例如，包含上图中关键字“lucene”的文档代码是3、7、15、30、35和67。 其他也一样
当单个单词查询查询时，只需要基于关键字返回相应的转置表。
多个单词查询将所查询字符串分割为多个关键字，根据关键字返回转置表，根据逻辑条件(且非)合并转置表
另外，很简单。 是多个转置表直接进行交叉运算，还是进行并行运算？ 差集运算词典的数据量大时，词典的数据量会变大。 仔细想想，你就会发现一篇文章的关键词很多。 词典的数据结构对于将词典放入内存中以便随时阅读非常重要。 太大了，既不能占用空间，也不能降低效率。 下图显示了一般词典的优缺点。
FST是Lucene当前使用的索引结构
理论基础： 《Direct construction of minimal acyclic subsequential transducers》，通过输入规则字符串构建最小有向图。
优点：内存利用率低，压缩率通常在3倍~20倍之间，模糊查询支持好，查询快
缺点：在结构复杂、输入要求有序、更新困难的Lucene上有FST实现，从对外界面来看，与Map结构非常相似，有搜索，有迭代
百万数据性能测试：
调查数据结构HashMapTreeMapFST构建时间(ms ) 1855001512所有key ) ms ) 106218890，FST的性能几乎与HaspMap相差无几，但FST具有无法比较的优点，占用内存小，且
1 .查询速度。
2 .内存使用量。
3 .内存磁盘合并。
所以最终情况如下。 Term dict index通过FST机制在内存中缓存Term dict index，从Term dict index中查找与关键字相对应的term dic的块位置，然后在磁盘中查找term，大大减少了磁盘的IO次数。
在对数据进行分段和索引之后，让我们看看数据是如何存储的。 如果所有数据(新华字典中的所有单词)都存在于一个文件中，则更新或删除数据) (例如，添加新单词或删除单词) )，则必须重新创建所有索引这在数据量大的情况下效率低，而且编制索引的成本高，因此数据更新频繁
Lucene在检索中引入了分段(Segment )的概念(将一个索引文件分割为多个)
个子文件，每个子文件叫作段），每个段都是一个独立的可被搜索的数据集，并且段具有不变性，一旦索引的数据被写入硬盘，就不可再修改。在分段的思想下，对数据写操作的过程如下。
新增。当有新的数据需要创建索引时，由于段的不变性，所以选择新建一个段来存储新增的数据。删除。当需要删除数据时，由于数据所在的段只可读，不可写，所以Lucene在索引文件下新增了一个.del的文件，用来专门存储被删除的数据id。当查询时，被删除的数据还是可以被查到的，只是在进行文档链表合并时，才把已经删除的数据过滤掉。被删除的数据在进行段合并时才会真正被移除。更新。更新的操作其实就是删除和新增的组合，先在.del文件中记录旧数据，再在新段中添加一条更新后的数据。 段不可变的优点段不变性的优点如下：
不需要锁。因为数据不会更新，所以不用考虑多线程下的读写不一致情况。可以常驻内存。段在被加载到内存后，由于具有不变性，所以只要内存的空间足够大，就可以长时间驻存，大部分查询请求会直接访问内存，而不需要访问磁盘，使得查询的性能有很大的提升。缓存友好。在段的生命周期内始终有效，不需要在每次数据更新时被重建。增量创建。分段可以做到增量创建索引，可以轻量级地对数据进行更新，由于每次创建的成本很低，所以可以频繁地更新数据，使系统接近实时更新。 段不可变的缺点 当对数据进行删除时，旧数据不会被马上删除，而是在.del文件中被标记为删除。而旧数据只能等到段更新时才能真正被移除，这样会有大量的空间浪费。更新。更新数据由删除和新增这两个动作组成。若有一条数据频繁更新，则会有大量的空间浪费。由于索引具有不变性，所以每次新增数据时，都需要新增一个段来存储数据。当段的数量太多时，对服务器的资源（如文件句柄）的消耗会非常大，查询的性能也会受到影响。在查询后需要对已经删除的旧数据进行过滤，这增加了查询的负担。 延迟写策略为了提升写的性能，Lucene并没有每新增一条数据就增加一个段，而是采用延迟写的策略，每当有新增的数据时，就将其先写入内存中，然后批量写入磁盘中。若有一个段被写到硬盘，就会生成一个提交点，提交点就是一个用来记录所有提交后的段信息的文件。一个段一旦拥有了提交点，就说明这个段只有读的权限，失去了写的权限
相反，当段在内存中时，就只有写数据的权限，而不具备读数据的权限，所以也就不能被检索了。从严格意义上来说，Lucene或者Elasticsearch并不能被称为实时的搜索引擎，只能被称为准实时的搜索引擎。
写索引的流程如下：
新数据被写入时，并没有被直接写到硬盘中，而是被暂时写到内存中。Lucene默认是一秒钟，或者当内存中的数据量达到一定阶段时，再批量提交到磁盘中，当然，默认的时间和数据量的大小是可以通过参数控制的。通过延时写的策略，可以减少数据往磁盘上写的次数，从而提升整体的写入性能。如下图所示。
在达到触发条件以后，会将内存中缓存的数据一次性写入磁盘中，并生成提交点。清空内存，等待新的数据写入。如图8所示。
分段合并合并原因：虽然分段比每次都全量创建索引有更高的效率，但由于在每次新增数据时都会新增一个段，所以经过长时间的积累，会导致在索引中存在大量的段，当索引中段的数量太多时，不仅会严重消耗服务器的资源，还会影响检索的性能。
因为索引检索的过程是：查询所有段中满足查询条件的数据，然后对每个段里查询的结果集进行合并，所以为了控制索引里段的数量，我们必须定期进行段合并操作。但是如果每次合并全部的段，则将造成很大的资源浪费，特别是"大段"的合并。
所以Lucene现在的段合并思路是：根据段的大小先将段进行分组，再将属于同一组的段进行合并。但是由于对超级大的段的合并需要消耗更多的资源，所以Lucene会在段的大小达到一定规模，或者段里面的数据量达到一定条数时，不会再进行合并。所以Lucene的段合并主要集中在对中小段的合并上，这样既可以避免对大段进行合并时消耗过多的服务器资源，也可以很好地控制索引中段的数量。
总结反向索引：Lucene 采用了基于反向索引的设计原理，可以非常高效地实现文本查找
数据分段：在底层采用了数据分段的存储模式，分段是只读的，使它在读写时几乎完全避免了锁的出现，大大提升了读写性能。
参考 Apache Lucene Core5分钟了解lucene全文索引Lucene段概念lucene搜索原理ElasticSearch底层搜索引擎Lucene原理剖析Lucene底层原理和优化经验分享(1)-Lucene简介和索引原理掌握它才说明你真正懂 Elasticsearch - Lucene (一)使用Lucene在知识图谱上构建索引