lucene

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> BinaryDocValuesField与SortedDocValuesField相似，但又有不同之处，当字段的值重复项较少且共同前缀较少时使用BinaryDocValuesField存储较好。 该字段的存储在代码实现较简单主要过程就是两步： 1、写入字段原始字节数组没有采用任何压缩算法； 2、采用Monotonic算法对每个字段值在文件中的指针进行压缩存储，该算法对于这种近似于线性的序列值压缩非常有效。有兴趣的可以看看 结合lucene谈谈整形值压缩--上篇 。 原始代码中除了这两个关键步骤，还有一个重要的优化类IndexedDISI将放在下一篇单独说明！ 来源： oschina 链接： https://my.oschina.net/u/1268334/blog/3043644

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> SortedSetDocValuesField与SortedDocValuesField类似但它是一键多值的（注意：lucene的数据模型是支持一键多值的即key-values模型），lucene在实现时会判断是一键一值还是多值，如果单值就调用SortedDocValuesField的存储方式（前面已经说过），否则按照多值情况进行存储。存储方式为： 1、写入每个值对应的字典序号； 2、写入过个key对应的值的个数； 3、与SortedDocValuesField一样写入每个字典值； 4、与SortedDocValuesField一样写入字典索引； 总结：就像SortedNumericDocValuesField一样对于这种一键多值的情况，lucene在处理的时候是在一键一值存储的基础上然后按照实际情况额外记录相应的信息实现的，所以有可以复用一键一值的代码。 来源： oschina 链接： https://my.oschina.net/u/1268334/blog/3053819

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 摘要 先自上而下，后自底向上的介绍ElasticSearch的底层工作原理，试图回答以下问题： 为什么我的搜索 *foo-bar* 无法匹配 foo-bar ？ 为什么增加更多的文件会压缩索引（Index）？ 为什么ElasticSearch占用很多内存？ 版本 elasticsearch版本: elasticsearch-2.2.0 内容 图解ElasticSearch 云上的集群 集群里的盒子 云里面的每个白色正方形的盒子代表一个节点——Node。 节点之间 在一个或者多个节点直接，多个绿色小方块组合在一起形成一个ElasticSearch的索引。 索引里的小方块 在一个索引下，分布在多个节点里的绿色小方块称为分片——Shard。 Shard＝Lucene Index 一个ElasticSearch的Shard本质上是一个Lucene Index。 Lucene是一个Full Text 搜索库（也有很多其他形式的搜索库），ElasticSearch是建立在Lucene之上的。接下来的故事要说的大部分内容实际上是ElasticSearch如何基于Lucene工作的。 图解Lucene Mini索引——segment 在Lucene里面有很多小的segment，我们可以把它们看成Lucene内部的mini

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前面已经介绍过NumericDocValuesField，这里想强调一下SortedNumericDocValuesField是针对同一篇文档中一键多值的情况进行排序的，换句话说不同文档的同一字段值可以乱序。核心的写入流程与 谈谈lucene的DocValues特性之NumericDocValuesField 中是一样的，但在此例中由于一键多值的情况，会额外记录每篇文档该键包含值的个数！ 来源： oschina 链接： https://my.oschina.net/u/1268334/blog/3053345

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 最近利用晚上下班还有周末的时间自己捣腾的封装了一个我自己的全文检索引擎(基于lucene和solr).现在将大概的思路给写出来,分享下: 1.首先是索引对象,也可以说是查询的VO对象.封装了几个常用字段(如:主键,所属者ID,所属者姓名,进入详情页面的link,创建时间等),其他各个模块的字段(如:标题,内容,邮箱等) SearchBean.java 字段的代码如下: /********以下 共有字段***********/ /** * 检索的内容 */ protected String keyword; /** * 拥有者ID */ protected String owerId; /** * 拥有者name */ protected String owerName; /** * 检索对象的唯一标识位的值 */ protected String id; /** * 检索出对象后进入详情页面的链接 */ protected String link; /** * 创建时间 */ protected String createDate; /** * index类型 */ protected String indexType; //setter,getter方法省略 /********以上 共有字段*********

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> lucene的DocValues不同于document文档级别的存储，它是一个面向列的存储结构，提供从文档编号到值的映射功能。根据不同的数据类型和应用场景支持多个DocValuesField类型，SortedDocValuesField便是其中之一，主要的作用是提供字符串值的排序功能（如根据检索条件筛选出结果集后根据某个 字符类型的字段进行排序 ）。 先说明一下SortedDocValuesField存储的逻辑结构： 给定三个文档doc[0]='abc'，doc[1]='abd'，doc[2]='abc'，值经过排序去重后变成'abc'=0，'abd'=1,那么原始的三篇文档会变成doc[0]=0，doc[1]=1，doc[2]=0。在这样的结构下排序尤其是海量数据时候，无需将原始数据读取到内存中进行排序，只需根据文档的ID号从磁盘中读取排序字段的序号，然后通过优先级队列取前N条记录即可。 SortedDocValuesField存储的物理结构主要包含以下几个步骤： 1、首先dvd数据文件会写入文档->序号的对应关系，dvm索引文件会记录相应的文件指针（代表dvd文件的XXX-XXX部分记录的是对应关系） 2、然后dvd数据文件会写入已去重并排好序的具体的值，由于排好序，因此采用了前缀压缩算法

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Lucene的文件结构是一个层次结构。 Lucene文件层次结构包含： 如果非要打一个比方： 这里的索引相当于数据库中的表，当表中的记录达到一定的量之后，我们要对表进行分区操作。 这里的段就相当于表的分区。 也就是说，索引可以分解成多个段。 数据表中的记录又保存不同的分区中内，这里的文档就相当于数据库表中的记录。不同的文档保存在不同的段中。 与表的分区略有不同的是，这里的段可以合并成一个新段。 一个索引包含多个段，每个段包含一个或多个文档，文档中包含多个域，域可以进行分词划分成一个或多个词元。 Lucene索引中保存了正向信息和反向信息。 正向信息：按层次保存了索引到词的包含关系。 索引-段-文档-域-词 一个索引包含哪些段，每个段包含 哪些 文档，文档中包含 哪些 域，域划分成 哪些 词元。 反向信息：词到文档的映射关系。 在本系列前面的文章（1）中，我们将这种从词到文档的映射关系，定义为倒排表。通过倒排表，我们可以看到每一个词分别在哪些文档中出现。 来源： oschina 链接： https://my.oschina.net/u/1156339/blog/494693