lucene 版本变动总结

合集下载

Lucene3.0原理与代码分析

Lucene3.0原理与代码分析
本系列⽂章将详细描述⼏乎最新版本的Lucene的基本原理和代码分析。

其中总体架构和索引⽂件格式是Lucene 2.9的，索引过程分析是Lucene 3.0的。

鉴于索引⽂件格式没有太⼤变化，因⽽原⽂没有更新，原理和架构的⽂章中引⽤了前辈的⼀些图，可能属于早期的Lucene，但不影响对原理和架构的理解。

本系列⽂章尚在撰写之中，将会有分词器，段合并，QueryParser，查询语句与查询对象，搜索过程，打分公式的推导等章节。

提前给⼤家分享，希望⼤家批评指正。

本系列⽂章已在javaeye制作成电⼦书，可提供下载，谢谢关注。

/blog/pdf。

lucene学习

lucene学习1.基本概念信息检索(IR)是指文档搜索、文档内信息搜索或者文档相关的元数据搜索等操作。

文档：用于搜索的内容部件。

词汇单元：即分词。

词干提取器，如Snowball。

搜索质量主要由查准率(Preciion)和查全率(Recall)来衡量。

[1]P13语法检查器:Lucene的contrib目录提供了两个模块完成此功能。

查询对象:Lucene提供了一个称之为查询解析器(QueryParer),用它可以根据通用查询语法将用户输入的文本处理成查询对象。

查询搜索：査询检索索引并返回与査询语句匹配的文档，结果返回时按照査询请求来排序。

搜索查询组件涵盖了搜索引擎内部复杂的工作机制，Lucene正是如此，它为你完成这一切。

倒排索引：invertedinde某常见的搜索理论模型有如下3种。

■纯布尔模型（PureBooleanmodel)文档不管是否匹配查询请求，都不会被评分.在该模型下，匹配文档与评分不相关，也是无序的；一条查询仅获取所有匹配文档集合的一个子集。

■向量空间模型（Vectorpacemodel)查询语句和文档都是高维空间的向量模型，这里每一个独立的项都是一个维度。

查询语句和文档之间的相关性或相似性由各自向量之间的距离计算得到.■概率模型（Probabiliticmodel)在该模型中，采用全概率方法来计算文档和查询语句的匹配概率。

Lucene在实现上采用向量空间模型和纯布尔模型，并能针对具体搜索让你决定采用哪种模型。

最后，Lucene返回的文档结果必须用比较经济的方式展现给用户。

搜索范围：涉及分布式搜索，ApacheLucene项目下的Solr和Nutch 项目提供了对索引拆分和复制的支持，另Katta和Elaticearch。

1.1Lucene核心类概貌执行简单的索引过程需要用到以下几个类：■Inde某Writer■Directory■Analyzer■Document■FieldInde某Writer(写索引）是索引过程的核心组件。

Elasticsearch为何要在7.X版本中去除type的概念

Elasticsearch为何要在7.X版本中去除type的概念背景说明Elasticsearch是⼀个基于的开源搜索引擎。

⽆论在开源还是专有领域，Lucene可以被认为是迄今为⽌最先进、性能最好的、功能最全的搜索引擎库。

Elasticsearch 是⼀种NoSQL数据库（⾮关系型数据库），和常规的关系型数据库（⽐如：MySQL，Oralce等）的基本概念，对应关系如下：Elasticsearch：index --> type --> doc --> fieldMySQL: 数据库 --> 数据表 --> ⾏ --> 列因为关系型数据库⽐⾮关系型数据库的概念提出的早，⽽且很成熟，应⽤⼴泛。

所以，后来很多NoSQL（包括：MongoDB，Elasticsearch等）都参考并延⽤了传统关系型数据库的基本概念。

⼀个客观的现象和事实如下：Elasticsearch 官⽹提出的近期版本对 type 概念的演变情况如下：在5.X版本中，⼀个 index下可以创建多个 type；在6.X版本中，⼀个 index下只能存在⼀个 type；在7.X版本中，直接去除了 type的概念，就是说index 不再会有 type。

为何要去除 type 的概念？为何不是在 6.X 版本开始就直接去除 type，⽽是要逐步去除type？Why？!原因分析1、为何要去除 type 的概念？答：因为 Elasticsearch 设计初期，是直接查考了关系型数据库的设计模式，存在了 type（数据表）的概念。

但是，其搜索引擎是基于 Lucene的，这种 “基因”决定了 type 是多余的。

Lucene 的全⽂检索功能之所以快，是因为倒序索引的存在。

⽽这种倒序索引的⽣成是基于 index 的，⽽并⾮ type。

多个type反⽽会减慢搜索的速度。

为了保持 Elasticsearch “⼀切为了搜索” 的宗旨，适当的做些改变（去除 type）也是⽆可厚⾮的，也是值得的。

Lucene 3.0 的几种分词系统

1、 StopAnalyzer
StopAnalyzer能过滤词汇中的特定字符串和词汇，并且完成大写转小写的功能。
2、 StandardAnalyzer
StandardAnalyzer根据空格和符号来完成分词，还可以完成数字、字母、E-mail地址、IP地址以及中文字符的分析处理，还可以支持过滤词表，用来代替StopAnalyzer能够实现的过滤功能。
3、 SimpleAnalyzer
SimpleAnalyzer具备基本西文字符词汇分析的分词器，处理词汇单元时，以非字母字符作为分割符号。分词器不能做词汇的过滤，之进行词汇的分析和分割。输出地词汇单元完成小写字符转换，去掉标点符号等分割符。
在全文检索系统开发中，通常用来支持西文符号的处理，不支持中文。由于不完成单词过滤功能，所以不需要过滤词库支持。词汇分割策略上简单，使用非英文字符作为分割符，不需要分词词库的支持。
13、 Paoding Analysis
Paoding Analysis中文分词具有极高效率和高扩展性。引入隐喻，采用完全的面向对象设计，构思先进。其效率比较高，在PIII 1G内存个人机器上，1秒可准确分词100万汉字。采用基于不限制个数的词典文件对文章进行有效切分，使能够将对词汇分类定义。能够对未知的词汇进行合理解析。
7、 ChineseAnalyzer
ChineseAnalyzer功能与StandardAnalyzer分析器在处理中文是基本一致，都是切分成单个的双字节中文字符。在Lucene3.0版本中已经弃用。
8、 PerFieldAnalyzerWrapper
PerFieldAnalyzerWrapper功能主要用在针对不同的Field采用不同的Analyzer的场合。比如对于文件名，需要使用KeywordAnalyzer，而对于文件内容只使用StandardAnalyzer就可以了。通过addAnalyzer()可以添加分类器。

antlr4 lucene 语法解析

antlr4 lucene 语法解析ANTLR (ANother Tool for Language Recognition) 是一个强大的语法分析器生成器，它可以用来解析各种语言的语法。

它广泛用于构建编译器、解释器、数据提取工具等。

Lucene 是一个高性能的开源全文搜索引擎，它提供了全文搜索和信息检索的功能。

将 ANTLR 和 Lucene 结合使用，可以创建一个强大的文本解析和搜索工具。

下面是一个简单的示例，展示如何使用 ANTLR4 和 Lucene 来解析和搜索文本。

1. 创建 ANTLR 语法文件首先，你需要创建一个 ANTLR 语法文件来定义你要解析的文本的语法。

例如，你可以创建一个简单的语法文件来解析英文句子。

```antlrgrammar Sentence;sentence : word (space word);word : [a-zA-Z]+;space : ' ';```这个语法文件定义了一个 `sentence` 规则，它是由一个或多个 `word` 组成的，其中 `word` 是由一个或多个字母组成的序列。

`space` 规则表示一个空格字符。

2. 生成 ANTLR 解析器使用 ANTLR 工具生成 Java 代码。

你需要安装 ANTLR 工具并运行以下命令：```bashantlr4 -o output_directory -package```这将生成一个名为 `SentenceLexer` 和 `SentenceParser` 的 Java 类。

3. 使用 Lucene 进行搜索现在，你可以使用 Lucene 来索引和搜索解析后的文本。

首先，你需要创建一个 `IndexWriter` 来索引文本：```javaimport ;import ;import ;import ;import ;...RAMDirectory directory = new RAMDirectory(); IndexWriterConfig config = new IndexWriterConfig(_4_10_4, new StandardAnalyzer());IndexWriter writer = new IndexWriter(directory, config);... // 索引文本到 writer 中();```然后，你可以使用 `IndexSearcher` 和 `QueryParser` 来搜索文本：```javaimport ;import ;import ;import ;import ;import ;import ;import ;import ;import ;... // 加载已索引的目录到 IndexSearcher 中QueryParser parser = new QueryParser(_4_10_4, "sentence", new StandardAnalyzer());Query query = ("your search query"); // 例如 "hello world" TopDocs results = (query, 10, new Sort(new SortField("sentence", ))); ... // 处理搜索结果```这是一个简单的示例，展示了如何使用 ANTLR 和 Lucene 来解析和搜索文本。

lucense详解

另外，如果是在选择全文引擎，现在也许是试试Sphinx的时候了：相比Lucene速度更快，有中文分词的支持，而且内置了对简单的分布式检索的支持；基于Java的全文索引/检索引擎——LuceneLucene不是一个完整的全文索引应用，而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。

Lucene的作者：Lucene的贡献者Doug Cutting是一位资深全文索引/检索专家，曾经是V-Twin搜索引擎(Apple的Copland操作系统的成就之一)的主要开发者，后在Excite担任高级系统架构设计师，目前从事于一些INTERNET底层架构的研究。

他贡献出的Lucene的目标是为各种中小型应用程序加入全文检索功能。

Lucene的发展历程：早先发布在作者自己的，后来发布在SourceForge，2001年年底成为APACHE基金会jakarta的一个子项目：/lucene/已经有很多Java项目都使用了Lucene作为其后台的全文索引引擎，比较著名的有：对于中文用户来说，最关心的问题是其是否支持中文的全文检索。

但通过后面对于Lucene 的结构的介绍，你会了解到由于Lucene良好架构设计，对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。

全文检索≠ like "%keyword%"通常比较厚的书籍后面常常附关键词索引表（比如：北京：12, 34页，上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。

而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。

对于检索系统来说核心是一个排序问题。

由于数据库索引不是为全文索引设计的，因此，使用like "%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。

ELasticSearch几个大版本之间的差异

ELasticSearch⼏个⼤版本之间的差异简单说说关于elasticsearch各个⼤版本之间的区别初始版本0.7发布时间：2010.05.14主要特性Zen Discovery ⾃动发现模块Groovy Client⽀持简单的插件管理机制更好⽀持ICU分词器更多的管理API1.0.0版本发布时间：2014.02.14主要特性⽀持聚合分析AggregationsSnapshot/Restore API 备份恢复APICAT API ⽀持⽀持联合查询Doc values 引⼊2.0.0版本发布时间：2015.10.28主要特性增加了 pipleline Aggregationsquery/filter 查询合并，都合并到query中，根据不同的上下⽂执⾏不同的查询存储压缩可配置Rivers 模块被移除Multicast 组播发现被移除，成为⼀个插件，⽣产环境必须配置单播地址⽀持root⽤户启动5.0.0版本(⼤转折)发布时间：2016.10.26主要特性Lucene 6.x 的⽀持，磁盘空间少⼀半；索引时间少⼀半；查询性能提升25%；⽀持IPV6。

Internal engine级别移除了⽤于避免同⼀⽂档并发更新的竞争锁，带来15%-20%的性能提升提供了第⼀个Java原⽣的REST客户端SDK IngestNode提供了 Painless 脚本，代替Groovy脚本新增了Profile API新增了Rollover API新增Reindex提供了第⼀个Java原⽣的REST客户端SDK，基于HTTP协议的客户端对Elasticsearch的依赖解耦，没有jar包冲突，提供了集群节点⾃动发现、⽇志处理、节点请求失败⾃动进⾏请求轮询，充分发挥Elasticsearch的⾼可⽤能⼒引⼊新的字段类型 Text/Keyword 来替换 String限制索引请求⼤⼩，避免⼤量并发请求压垮 ES限制单个请求的 shards 数量，默认 1000 个仅⽀持⾮root⽤户启动6.0.0版本发布时间：2017.08.31主要特性稀疏性 Doc Values 的⽀持Index sorting，即索引阶段的排序Removal of types，在 6.0 ⾥⾯，开始不⽀持⼀个 index ⾥⾯存在多个 type已经关闭的索引将也⽀持 replica 的⾃动处理，确保数据可靠Load aware shard routing，基于负载的请求路由，⽬前的搜索请求是全节点轮询，那么性能最慢的节点往往会造成整体的延迟增加，新的实现⽅式将基于队列的耗费时间⾃动调节队列长度，负载⾼的节点的队列长度将减少，让其他节点分摊更多的压⼒，搜索和索引都将基于这种机制。

lucene索引优化

这篇文章主要介绍了如何提高Lucene的索引速度。

介绍的大部分思路都是很容易尝试的，当然另外一部分可能会加大你程序的复杂度。

所以请确认索引速度确实很慢，而且很慢的原因确实是因为Lucene自身而造成的。

推荐姐妹篇：如何提高和优化Lucene搜索速度• 确认你在使用最新的Lucene版本。

• 尽量使用本地文件系统远程文件系统一般来说都会降低索引速度。

如果索引必须分布在远程服务器，请尝试先在本地生成索引，然后分发到远程服务器上。

• 使用更快的硬件设备，特别是更快的IO设备• 在索引期间复用单一的IndexWriter实例• 使用按照内存消耗Flush代替根据文档数量Flush在Lucene 2.2之前的版本，可以在每次添加文档后调用ramSizeInBytes方法，当索引消耗过多的内存时，然后在调用flush()方法。

这样做在索引大量小文档或者文档大小不定的情况下尤为有效。

你必须先把maxBufferedDocs参数设置足够大，以防止writer基于文档数量flush。

但是注意，别把这个值设置的太大，否则你将遭遇Lucene-845号BUG。

不过这个BUG已经在2.3版本中得到解决。

在Lucene2.3之后的版本。

IndexWriter可以自动的根据内存消耗调用flush()。

你可以通过writer.setRAMBufferSizeMB()来设置缓存大小。

当你打算按照内存大小flush后，确保没有在别的地方设置MaxBufferedDocs值。

否则flush条件将变的不确定（谁先符合条件就按照谁）。

• 在你能承受的范围内使用更多的内存在flush前使用更多的内存意味着Lucene将在索引时生成更大的segment，也意味着合并次数也随之减少。

在Lucene-843中测试，大概48MB内存可能是一个比较合适的值。

但是，你的程序可能会是另外一个值。

这跟不同的机器也有一定的关系，请自己多加测试，选择一个权衡值。

lucene-Android

Lunene在Android sqlite数据库搜索中的应用Lucene是一套用于全文检索和搜寻的开源程式库,供了一个简单却强大的应用程式接口，能够做全文索引和搜寻。

在Java开发环境里Lucene是一个成熟的免费开源工具,Lucene 使用Java语言写成的，因而就可以应用到Android开发上。

此处采用的Lucene版本为3.0.3。

一.在项目下导入需要的包（一开始我分别采用4.2和4.0版本，发现调试时连接不上模拟器或手机，对比一下4.2,4.0的包对于3.0大了一倍多，有一个达到了2M多，3.0的包没有一个超过1M。

难道是libs 下的包大小有限制吗?或者其他原因，当时搞了很久都没想清楚。

总之换成3.0.3的就好了,其他的版本没有试过）.二.为sqlite数据库创建索引public class Search {private MySQLiteHelper databaseHelper;private SQLiteDatabase db;private Directory dir;private String path;public Search(Context context) {this.context = context;try {path=android.os.Environment.getExternalStorageDirectory() + "/"+ context.getPackageName() + "/files/";//在SD卡上创建文件,如果没有SD卡则不会成功。

dir = new SimpleFSDirectory(new File(path));//获取路径下的目录new Thread(new Runnable() {public void run() {index();}}).start();} catch (IOException e) {e.printStackTrace();}}private void index() {/*** 在sd卡上创建与数据库相关的索引* */try {databaseHelper = new MySQLiteHelper(this.context);db = databaseHelper.getWritableDatabase();Cursor cursor = db.rawQuery("select * from "+ MySQLiteHelper.SEARCH_TABLE+ " where 1=1", null);IndexWriter indexWriter = new IndexWriter(dir,new StandardAnalyzer(Version.LUCENE_30), true,IndexWriter.MaxFieldLength.UNLIMITED);while (cursor.moveToNext()) {//创建索引,保存到SD卡path路径下Document doc = new Document();doc.add(new Field("title", cursor.getString(cursor.getColumnIndex("title")), Field.Store.YES,Field.Index.ANALYZED));doc.add(new Field("content", cursor.getString(cursor.getColumnIndex("content")), Field.Store.YES,Field.Index.ANALYZED));indexWriter.addDocument(doc);}indexWriter.optimize();indexWriter.close();cursor.close();db.close();databaseHelper.close();} catch (CorruptIndexException e) {e.printStackTrace();} catch (LockObtainFailedException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();}}三.搜索文本内容/*** 在索引上搜索最佳文本.field表示要搜索的数据库字段,content表示搜索的内容* */private void doSearch(String field, String content) { IndexSearcher indexSearch;TopDocs hits = null;Document doc = null;ScoreDoc sdoc;try {indexSearch = new IndexSearcher(dir);// 创建QueryParser对象,第一个参数表示Lucene的版本,第二个表示搜索Field的字段,第三个表示搜索使用分词器QueryParser queryParser=new QueryParser(Version.LUCENE_30, field,new StandardAnalyzer(Version.LUCENE_30));Query query = queryParser.parse(content);// 搜索结果 TopDocs里面有scoreDocs[]数组，里面保存着索引值hits = indexSearch.search(query, 10);// hits.totalHits表示一共搜到多少个Log.i("search", Integer.toString(hits.totalHits));// 循环hits.scoreDocs数据，并使用indexSearch.doc方法把Document还原，再拿出对应的字段的值for (int i=0;i<hits.scoreDocs.length-1;i++) {sdoc = hits.scoreDocs[i];doc = indexSearch.doc(sdoc.doc);Log.i("title",doc.get("title").toString());Log.i("content",doc.get("content").toString());}indexSearch.close();} catch (CorruptIndexException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();} catch (ParseException e) {e.printStackTrace();}}例如，我要搜索内容为“大家好！”的字段则调用doSearch("content","大家好"); 在Log中可以看到与内容为“大家好！”相关分词搜索的结果。

lucene4NET详细使用与优化详解

详细使用与优化详解1 lucene简介1.1 什么是luceneLucene是一个全文搜索框架，而不是应用产品。

因此它并不像或者googl e Desktop那么拿来就能用，它只是提供了一种工具让你能实现这些产品。

1.2 lucene能做什么要回答这个问题，先要了解lucene的本质。

实际上lucene的功能很单一，说到底，就是你给它若干个字符串，然后它为你提供一个全文搜索服务，告诉你你要搜索的关键词出现在哪里。

知道了这个本质，你就可以发挥想象做任何符合这个条件的事情了。

你可以把站内新闻都索引了，做个资料库；你可以把一个数据库表的若干个字段索引起来，那就不用再担心因为“%like%”而锁表了；你也可以写个自己的搜索引擎……1.3 你该不该选择lucene下面给出一些测试数据，如果你觉得可以接受，那么可以选择。

测试一：250万记录，300M左右文本，生成索引380M左右，800线程下平均处理时间300 ms。

测试二：37000记录，索引数据库中的两个varchar字段，索引文件2.6M，800线程下平均处理时间1.5ms。

2 lucene的工作方式lucene提供的服务实际包含两部分：一入一出。

所谓入是写入，即将你提供的源（本质是字符串）写入索引或者将其从索引中删除；所谓出是读出，即向用户提供全文搜索服务，让用户可以通过关键词定位源。

2.1写入流程源字符串首先经过analyzer处理，包括：分词，分成一个个单词；去除stopword（可选）。

将源中需要的信息加入document．各个Field中，并把需要索引的Field索引起来，把需要存储的Field存储起来。

将索引写入存储器，存储器可以是内存或磁盘。

2.2读出流程用户提供搜索关键词，经过analyzer处理。

对处理后的关键词搜索索引找出对应的document．用户根据需要从找到的document．提取需要的Field。

3 一些需要知道的概念lucene用到一些概念，了解它们的含义，有利于下面的讲解。

lucene版本对比

lucene版本对比一、为什么使用lucene1、Lucene不是一个完整的全文索引应用，而是是一个用JAVA写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。

这样的定位，使得lucene有很高的抽象层次，便于扩展和整合到已有的系统。

因为对于大多数的全文搜索应用来说，我们需要的是一个开发工具包而不是最终产品（虽然很多搜索引擎也可以扩展特性功能）。

这也是程序员最愿意接受的封装层次。

2、Lucene的API接口设计的比较通用，输入输出结构都很像数据库的表==>记录==>字段，所以很多传统的应用的文件、数据库等都可以比较方便的映射到Lucene的存储结构/接口中。

（上面语句有些来自在应用中加入全文检索功能——基于JAVA的全文索引引擎Lucene简介）。

二、lucene4.0新特性较重要部分1、全部使用字节( utf-8 tytes )替代string来构建 term directory 。

带来的好处是：索引文件读取速度30 倍的提升；占用原来大约10%的内存；搜索过程由于去掉了字符串的转化速度也会明显提升；但是如果说这上面的好处只是一个副产品，你会怎么想？没错，Mysql有MyIsam，Innodb等诸多引擎供我们选择的，Lucene为什么不能向这个方向发展呢？实现这个机制的模块叫：Codec （编码器），你可以实现自己的Codec 来进行自定义的扩展，很显然Codec的操作对象是Segment 。

2、支持多线程建索引，支持：concurrent flushing。

了解过Lucene 3.X的同学们都知道，诸如XXXPerThread 的类在建索引的时候已经支持多线程了，但是当每个线程的内存达到指定上限(maxBufferedDocs or ramMaxBufferSizeMB)的时候就需要写到硬盘上，而这个过程仍然不是多线程的，仍然需要一个个排队Flush到硬盘。

基于 Lucene 搜索引擎的研究与改进

基于 Lucene 搜索引擎的研究与改进摘要Lucene 是目前已经几年，最受欢迎的免费 Java 的全文检索库。

首先，本文分析了珠光体系结构、索引机制、搜索机制；其次，它研究排序技术和如何调整索引的性能；最后，文章提出了新的检索排序算法。

关键字：索引；搜索；条款；因子；maxMergeDocs；满意程度；;新的算法一、引言Lucene 是优秀的全文搜索引擎工具软件包和一个成熟的、免费的、开源的项目，在Java 中实现。

然而，它不是一个完整的全文搜索引擎，而是全文搜索引擎的体系结构。

Lucene 提供完整的搜索引擎，完整的索引引擎，部分文本分析引擎 (两种西方语言：英语和德语)[1]。

它是项目 Apache 雅加达家庭成员。

本文的结构如下：第二部分我们分析 Lucene 系统结构；第三部分研究 Lucene 运行机制 (索引和搜索)；第四部分讨论如何调整索引的性能；第五部分我们对分类技术的研究，提出新的检索排序算法。

在第六部分我们进行有关的新算法的可行性分析；最后在第七部分得出结论。

二、LUCENE 系统结构作为一个优秀的全文搜索引擎，Lucene 系统结构具有强烈的面向对象特征。

首先，Lucene 系统定义一个索引文档格式已无关平台；第二，该系统的核心部件旨在抽象类，和混凝土平台实现设计用来抽象类实现;最后，它穿过层面向对象处理，实现一种低耦合，高效率，便于二次开发的搜索引擎系统。

Lucene 体系结构如图 1 所示：图1 Lucene索引结构从图 1，我们可以看到，Lucene 系统由3个主要部分，即基本的封装结构、索引核心、外部接口组成。

索引核心也是系统的关键所在。

Lucene 系统所有源代码都划分成 7个模块 (在Java包来表示)，并且每包完成特定的功能。

其核心类软件包是组织 Apache.Lucene.analysis，org.apache lucene.index，org.apache lucene.search。

开源项目Lucene的架构详细解析

开源项目Lucene的架构详细解析作者：华南理工大学软件学院吴英骏LUCENE简介Lucene是apache软件基金会jakarta项目组的一个子项目，是一个开放源代码的全文检索引擎工具包，即它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。

Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。

作为一个开放源代码项目，Lucene从问世之后，引发了开放源代码社群的巨大反响，程序员们不仅使用它构建具体的全文检索应用，而且将之集成到各种系统软件中去，以及构建Web应用，甚至某些商业软件也采用了Lucene作为其内部全文检索子系统的核心。

apache 软件基金会的网站使用了Lucene作为全文检索的引擎，IBM的开源软件eclipse的2.1版本中也采用了Lucene作为帮助子系统的全文索引引擎，相应的IBM的商业软件Web Sphere中也采用了Lucene。

Lucene以其开放源代码的特性、优异的索引结构、良好的系统架构获得了越来越多的应用。

Lucene是一个高性能、可伸缩的信息搜索(IR)库。

它使你可以为你的应用程序添加索引和搜索能力。

Lucene是用java实现的成熟的、免费的开源项目，是著名的Apache Jakarta 大家庭的一员，并且基于在Apache软件许可[ASF, License]。

同样，Lucene是当前与近几年内非常流行的免费的Java信息搜索(IR)库。

LUCENE优点Lucene作为一个全文检索引擎，其具有如下突出的优点：（1）索引文件格式独立于应用平台。

Lucene定义了一套以8位字节为基础的索引文件格式，使得兼容系统或者不同平台的应用能够共享建立的索引文件。

（2）在传统全文检索引擎的倒排索引的基础上，实现了分块索引，能够针对新的文件建立小文件索引，提升索引速度。

Lucene4.3学习笔记

Lucene4.3进阶Lucene在最近的几个月里已经频繁更新了好几个版本了，越是更新的频繁，就越证明一件事，这个东西越来越流行，越来越火，就在散仙写此篇文章时候，Lucene官方已经更新到4.6的版本了，在此，散仙，不得不力赞一下开源界的力量。

好了，言归正传，散仙今天就从源码的角度来分析下Lucene的根基Directory的实现，在此之前，我们先来看下Directory家族的层级分布图。

从上图中，我们可以看出Directory共有11个直接或者间接的子类，不同的子类的作用和功能不一样，那么Directory作为此继承图的顶级父类，在Lucene中确实发挥重要的根基作用，就像Hadoop的根基是HDFS一样，Directory肩负着索引存储的重任，如果没有存储，那么检索就无从谈起了，虽然我们经常称全文检索，搜索引擎什么的，其实它们的背后，Directory才是默默无闻的”雷锋“。

下面，散仙就来详细的剖析下Directory的核心实现。

Directory是由lucene中的一些列索引文件组成的目录，一个典型索引文件结构图的截图如下：而Directory的作用，就是负责管理这些索引文件，包括数据的读取和写入，以及索引文件的添加，删除和合并。

从这样的角度来分析，Directory更像一个系统的管理员，下面，散仙再具体的分析下一些核心方法的作用。

我们都知道Lucene的索引体系，支持读共享，写独占的方式来访问索引目录，也就是说，它允许多个线程实例同时并发的读取，而不允许多个线程同时写入，大家可能会有疑问，为什么不支持多线程写入呢？这其实是因为索引目录有自己的某一时刻的内部状态，比如说文件指针，而多线程写入时，会造成指针混乱，从而引起索引结构损坏或某些数据丢失，所以lucene任何时候都禁止有多个线程并发的写入索引，即使是多线程写，每次也只能通过队列的方式，一次只允许一个线程操作索引，按这样的情况分析，多线程写入与单线程写入，在性能上的提升，并不是明显的，那么lucene又是怎么控制一次只能有一个线程写入呢，打开Directory的源码，我们就会发现，它其实是在内部维护了一个锁的实例，通过加锁方式，来禁止后来线程的写入操作，当然锁的作用不仅仅是防止并发写入，它还可以通过锁名字来判断，这两份索引是否为同一份索引，那么如果我们想使用多线程来提升写入速度，一个折中的办法就是，每个线程写一份目录，最后在对这些目录，进行合并，下面散仙给出了一些源码中锁的实现方法Java代码下面我们来分析下Directory源码中另外一个变量isOpen的作用isOpen是用来判断当前的Directory实例，在内存中的状态，它使用的是volatile 关键字修饰的，被此变量修饰的内容，JVM虚拟机读取的时候会直接在主存中读取该变量的值，而不会在各个线程的本地内存中读，这样一来，当并发读的时候，如果Directory实例关闭了，那么各个读的线程会立即获取最新的状态，如果不做处理的话，将会抛出一个目录实例关闭的异常。

65全文检索-配置

全文检索Lucene（NC65版本）
一、具体配置
点击Nchome\bin\sysconfig.bat，会出现以下界面。

在NC63中，我们使用的是档案索引这个页签的配置，到了NC65，配置移到了搜索引擎下。

1、搜索源分组
此页签为具体配置档案索引的地方，通过搜索分组指定具体的搜索源类型，通过搜索源配置具体的数据库表，并配置具体的支持索引的字段。

使用时必须设置正确的数据源。

支持新增搜索分组和数据源。

2、搜索管理
支持重建索引、优化索引、更新索引、定时建立索引等功能。

二、已经配置了全文检索，但实际使用时不生效，都有哪些原因？
a、检查数据源配置的是否正确。

项目上出现过配置为其他数据源或者修改数据源名称
后，没有同步修改此处的数据源的现象。

后续这一块有望实现自动配置正确的数据源。

b、检查nchome\anteindex\server下面是否已经生成了索引。

如果没有生成，需要检查下搜索管理中的具体定时配置是否正确，在中间件启动的情况下，可以尝试使用重爬全部、重建索引等功能。

c、有时候索引创建过程中会出现错误，后续增量创建索引时无法再创建此档案的索引，导致通过全文检索检索不到某部分档案，尤其是在升级或者大批量导入数据后的场景下。

这时可以尝试删除anteindex文件夹，重爬全部。

在重爬的过程中，给爬虫足够的服务器、数据库资源。

d、集群中，每个NChome中都要配置正确。

如果还有问题，建议找开发人员解决。

kubernetes各版本之间的变化

Kubernetes各版本之间的变化有：
v1.0 - v1.6：这是Kubernetes最初的几个版本，相对较简单，缺乏一些现在已经成为核心特性的功能，例如StatefulSet和DaemonSet。

v1.7 - v1.12：这些版本引入了一些重要的新功能，例如StatefulSet、DaemonSet、自适应容量和本地存储卷。

此外，这些版本具有更好的扩展性和可用性，以及更多的安全性和稳定性改进。

v1.13 - v1.18：这些版本增强了Kubernetes的自动化能力、网络支持和用户友好性。

此外，它们还引入了一些新的组件和工具，如Kubeadm、CoreDNS、CRDs、PodSecurityPolicy、Ingress和CRI-O等。

v1.19 - v1.22：这些版本增强了Kubernetes的通用性、可观测性和调试功能。

例如，v1.19引入了IPv6支持和EndpointSlice API，v1.20引入了VolumeSnapshot API，v1.21引入了Kubelet TLS Bootstrapping、pod资源限制等功能，v1.22引入了容器存储接口CSI 的默认实现等。

v1.23及以上版本：这些版本引入了更多的自动化和可观测性特性、更好的网络功能以及更好的安全性。

例如，v1.23引入了PodPresets、CronJob并行和Job终止信息等功能。

python elasticsearch历史版本

Python Elasticsearch历史版本近年来，Elasticsearch已经成为了一种非常流行的全文搜索引擎，在大数据分析和搜索领域得到了广泛的应用。

而Python是一种简单易学的编程语言，由于其丰富的库和模块，使得它成为了Elasticsearch 的一个非常重要的开发语言。

Python Elasticsearch历史版本的演进，也是一个非常值得关注的话题。

随着时间的推移，Elasticsearch不断地进行了更新和改进，而Python作为其重要的开发语言之一，其相应的版本也在不断的演进。

本文将通过详细介绍Python Elasticsearch的历史版本，来帮助读者更好地了解其发展历程和功能特性。

一、Python Elasticsearch 1.x版本1. 在早期的Python Elasticsearch版本中，主要集中在实现与Elasticsearch的连接和基本的搜索功能。

这个阶段的Python Elasticsearch版本主要是为了满足基本的搜索需求，并且在实现上相对简单。

2. Python Elasticsearch 1.x版本的主要特点是稳定性较高，但功能相对较为简单。

在这个阶段，Python主要是通过HTTP协议与Elasticsearch进行通信，实现了基本的索引、搜索和删除等功能。

3. 由于Python Elasticsearch 1.x版本的局限性，很多开发者在实际项目中需要更复杂的搜索功能，因此随着时间的推移，Elasticsearch 和Python的发展也逐渐趋向于更加复杂和多样化的功能需求。

二、Python Elasticsearch 2.x版本1. 随着Elasticsearch2.x版本的发布，Python Elasticsearch也迎来了新的发展时期。

在这个阶段，Python Elasticsearch开始支持更多复杂的搜索功能，比如聚合、过滤、排序等。

lucene 2.2.0 版本

package demo;import java.io.BufferedReader;import java.io.File;import java.io.FileReader;import java.io.IOException;import org.apache.lucene.analysis.Analyzer;import org.apache.lucene.analysis.standard.StandardAnalyzer;import org.apache.lucene.document.Document;import org.apache.lucene.document.Field;import org.apache.lucene.index.CorruptIndexException;import org.apache.lucene.index.IndexWriter;import org.apache.lucene.queryParser.QueryParser;import org.apache.lucene.search.Hits;import org.apache.lucene.search.IndexSearcher;import org.apache.lucene.search.Query;import org.apache.lucene.store.FSDirectory;import org.apache.lucene.store.LockObtainFailedException;public class CcicUtils {/*** 建立索引** @param filePath* 被索引的文件* @param indexPath* 索引文件* @throws CorruptIndexException* @throws LockObtainFailedException* @throws IOException*/public static void createIndex(String filePath, String indexPath)throws CorruptIndexException, LockObtainFailedException,IOException {File ccidFile = new File(filePath); // 文件路径Analyzer luceneAnalyzer = new StandardAnalyzer();FSDirectory directory = FSDirectory.getDirectory(indexPath, true);IndexWriter indexWriter = new IndexWriter(directory, luceneAnalyzer, true);indexWriter.WRITE_LOCK_TIMEOUT = 1000;BufferedReader reader = new BufferedReader(new FileReader(new File( ccidFile.getCanonicalPath())));String line = new String();while ((line = reader.readLine()) != null) {Document document = new Document();document.add(new Field("name", line, Field.Store.YES,Field.Index.TOKENIZED));indexWriter.setMaxFieldLength(50);indexWriter.addDocument(document);}reader.close();indexWriter.flush();indexWriter.optimize();indexWriter.close();}/*** 检索索引** @param filePath* @param name* @return* @throws Exception*/public static String searchIndex(String filePath, String name)throws Exception {String indexPath = "D:/luceneData/checkIndex"; // 索引保存位置IndexSearcher searcher = new IndexSearcher(indexPath);Hits hits = null;Query query = null;QueryParser qp = new QueryParser("name", new StandardAnalyzer());query = qp.parse(name);hits = searcher.search(query);int nameCount = hits.length();searcher.close();if (nameCount == 0) {return "-1";} else {System.out.println("“"+name+"”字的个数："+nameCount);return name;}}public static void main(String[] args) throws Exception {// createIndex("D:/luceneData/date", "D:/luceneData/checkIndex");searchIndex("a.txt", "中");}}本实例应用的lucene2.2.0 版本，高版本方法有出入// 以下是要索引的文件（a.txt）内容中华人民共和国中华人民共和国需要jar 包的可以和我联系Ls_shang@。

lucene 版本变动总结

3.11. 性能提升2. ReusableAnalyzerBase使得跟容易让TokenStreams 可重用3. 改进分析器的功能，包括对Unicode的支持(Unicode 4)、CharTermAttribute、对象重用等4. ConstantScoreQuery允许直接封装Query 对象5. 可通过IndexWriterConfig 对IndexWriter 进行配置6. IndexWriter.getReader 被IndexReader.open(IndexWriter) 所替换.7. 废弃了MultiSearcher；ParallelMultiSearcher被直接吸收到IndexReader 类中8. 在64位的Windows 和Solaris JVMs, MMapDirectory 作为默认的FSDirectory.open 的实现9. 新的TotalHitCountCollector用来获取索引的命中数10. ReaderFinishedListener API 用来清除外部缓存3.21、全新的分组模块，位于lucene/contrib/grouping 使得搜索结果可通过单值的索引域进行分组2、新的IndexUpgrader 工具，用来转换老格式的索引到当前的版本3、实现一个新的Directory ——NRTCachingDirectory ，用来在内存中缓存一些小的segments，以减少应用对IO的负载过高，更快速的NRT 再次打开的效率4、新的Collector 实现——CachingCollector，用来收集搜索命中率（文档ID和分值）5、可使用IndexWriter 新的addDocuments 和updateDocuments 来批量创建和更新文档的索引6、新的默认索引合并策略——TieredMergePolicy，更高效的合并非连续的segments，详见/merging7、修复了NumericField 在加载已存储文档时没正确返回的问题Deleted terms are now applied during flushing to the newly flushed segment, which is more efficient than having to later initialize a reader for that segment.3.31、固定打开的文件句柄泄漏在很多地方代码。

Lucene3.0的主要变化

一、概述Lucene3.0（以下简称3.0）已于2009-11-25发布，3.0版本是重大的版本，改动很大。

在API上做了很多的调整，已经删除了很多之前废弃的方法以及类，并支持了很多Java5 的新特性：包括泛型、可变参数、枚举和autoboxing等。

因此，此版本和2.x版本不能兼容，如要使用3.0版本，最好是在新项目中去使用，而不是去升级2.x或之前的版本！二、2.9版本介绍由于新版本变动很大，官方是不推荐从旧版本升级到新版本的。

因为改动会很大。

其实在2.9版本时改动就很大，因为2.9版本就是为3.0做准备的，但是为了向下兼容，2.9并没有抛弃之前的旧方法，所以可以直接向下兼容。

2.9版本主要是在性能方面的优化，包括在Lucene对Lucene底层的内部结构改进、索引的管理方式等多个方面。

1、索引文件改进Lucene的索引数据是存放在独立的文件中的，这些文件就是存储着索引数据库一些列分离的“片段”。

当我们想索引中增加文档时，便会不断的创建一些可以合并的新片段，因为读写文件的开销比较大，因此这些字段信息Lucene并非每次都直接加到索引文件里面去，而是先缓存，等到一定量的时候再一次写到文件中。

在2.9以后，Lucene会为每个片段分别管理FieldCache以此避开跨片段加载FieldCatch的需求，这样就解决了Lucene跨片段加载FieldCatch的效率很低下问题，这个改动大为提高了性能。

Lucid Imagination的Mark Miller 运行了一个简单的性能测试，表明在5,000,000个不同字符串下的情况下，Lucene 相对于2.4版本会获得15倍左右的性能提高： Lucene 2.4: 150.726s Lucene 2.9: 9.695s2、重开搜索新版本引入了IndexWriter.getReader()方法，它可用于搜索目前完整的索引，包括当前 IndexWriter会话中还没有提交的改变，这带来了接近于实时搜索的能力。