numbbe的博客

使用场景我现在有两个字段参与索引，文件名称和文件索引。搜索的时候，一个关键字匹配查询两个字段。思路分析众所周知，匹配查询先分词再查询。单字段查询比较简单，下边有两个例子，一个单字段，一个多字段布尔匹配查询。假如单字段查询关键字为“万里长城真伟大”。注意：在这个测试过程中，我没有使用Kibana进行测试，我是直接使用java代码测试的，结果是一样的。为什么不使用Kibana呢？原因如下：Kibana语法，每次写的时候，我都是打开Kibana文档，直接复制粘贴，改改就用，不是我吹，应该没几个

执行命令GET /_search运行结果按照从上到下的顺序，一共四个返回值，took，timed_out，_shards，hits。tooktimed_outshardstotalsuccessfulskippedfailedhitstotalmax_scorehits_index_type_id_score_source

ES搜索结果排序有两种：1、相似度匹配得分排序2、字符分值权重排序1：默认降序第一种是系统默认的排序方法。根据你所输入的关键字，与索引库中的文档进行对比，得出相关度分值，按照从大到小的顺序，降序将结果展示。进行一个简单的测试：第一次测试，制定了根据分值降序排序。第二次测试，不指定，使用默认。判断两种结果是否一致，若一致，则表示系统默认根据分值降序排序。GET /law/_search{ "query": { "match": { "fileName": "国有金融"

ES默认采用hash分片，这种方式对于查询请求要遍历所有分片，最终在master节点进行结果的汇总处理，最终返回。在这个过程中，查询在每个分片中单线程运行，并行处理多个分片。有的人说查询的时候，难道不查询副本分片吗？只查询主分片就可以了吗？副本的作用在于ES集群的高可用，当主分片丢失，该分片数据不可用时，master会将副本分片提升为主分片，这个时候可以接收查询请求。如何提高ES的查询效率？都知道，分片仅仅是对这份数据进行了切割，而不是数据分为了很多备份，多个分片，在查询的时候，并行对多个分片进行

引子我们在创建索引库的时候，要设计分片数量和副本数量，分片和副本是分布式搜索引擎的核心。如何指定分片进行增删改查操作？每个分片存储多少数据合适？我们的文档存在哪个分片中？为什么不可以修改主分片数量？一次完整的ES查询流程怎么流的？节点数量节点数量很好说，你要是只有两三个服务器，还想啥自行车呢。当然节点的数量还是有约束的。一般情况下：集群所有索引的副本最大值+1 <= 集群节点数量 <= 分片数量这个公式举个例子，你有十个节点，这十个节点中最大索引副本数量只能是9

引子绿色：主分片和副本都可用。黄色：所有主分片可用，部分副本 不可用。红色：至少一个主分片分配失败。如何解决集群健康黄色问题首先确定一下，你是否是在单节点测试ES，如果你只有一个节点，那么副本分片不可用是正常的。副本分片只有在集群中才有意义，单节点的副本，如果节点挂掉了，主分片和副本分片同时over，所以，如果你是单节点分片，那么不用管它是不是黄色，主分片能够正常工作，没问题的。如果你看黄色这个颜色不顺眼，你喜欢绿油油的颜色。你在创建索引库的时候，指定一下副本分片为0，就可以看到你喜欢的绿色

有时候，前端页面空间较小，ES搜索结果返回字段过大，放不下，或者放得下，但是很丑，所以我们如何对大字段进行处理呢？两种方法：方法一：（非常low，建议直接略过看方法二）对es搜索结果进行截取判断，然后写统计汉字个数（去除html标签）的工具类，根据字数进行截取判断。这样也能够实现页面美观的效果，但是看这些判断逻辑很丑。for (Law law : lawList) { String content = law.getContent(); if (St

引子问题一：明明索引库中文档内容上千字，为什么ES搜索出来的结果字数总是那么少？问题二：我们索引库中的文档内容是非常多的，但是我们会发现搜索出来的结果仅仅只有一两百字，恰好这个结果里边有关键字，而不是文档内容从前往后截取了一二百字。ES中为什么搜索出来的结果，高亮字段优先展示，而不是文档内容从前往后截取几百个字符串显示？看完下边三个方法介绍你就明白了。在我们高亮时使用了HighlightBuilder，创建的过程中，有三个默认值。fragmentSize高亮字段内容长度，去除html样式标

前言市场上分词器，眼花缭乱，让你一脸懵逼。Standard: 单字切分法，一个字切分成一个词。CJKAnalyzer: 二元切分法， 把相邻的两个字, 作为一个词.SmartChineseAnalyzer: 对中文支持较好, 但是扩展性差, 针对扩展词库、停用词均不好处理.paoding`: 庖丁解牛分词器, 没有持续更新, 只支持到lucene3.0。mmseg4`: 支持Lucene4.10, 且在github中有持续更新, 使用的是mmseg算法.Whitespa

两种场景，大家都用过：同一个index下，不同的type，命名名称一样的字段名。同一个数据库下，不同的表，命名名称一样的字段名。在关系型数据库中，不同的表中，包含相同的字段名是很常见的，而且它们可以做到互不干扰。在ElasticSearch中，不同的type，如果包含相同的字段名，它们是一样的，es会认为是一个字段，模糊掉不同type的概念。同志们，可以试一下，在同一个index中，不同的type，创建一个同名的字段，但是类型不要弄成一样的，看能否成功创建。答案是不可以，它会提示你，不可以将这个

节点master节点master节点是老大哥，负责维护本集群中的节点，包括节点的加入删除，索引的创建和删除。master节点不参与搜索，即master节点不用干活，是个管理者。一个集群中的任意一个节点都有成为master节点资格，有手就行。如何指定这个节点作为master节点呢在es文件夹中elasticsearch.yml文件中，将node.master设置为true即可。data节点data节点用于存储数据，负责倒排索引，比如shard的查询功能，实现全文检索，属于底层的概念，也就是打工

分片（shard）又叫主分片，最小的工作单元，存放一部分数据。一个index默认有五个分片，创建index时可以指定分片数量，后续如果需要修改分片数量，请删库跑路重新写。分片简单理解一个物理机器的性能是有瓶颈的，直接往物理机上存数据，存储数量有上限。ES采用了分片的概念，将海量数据切分成片，每一个分片，存储一部分数据。在一整个大的集群里，包含很多节点，每个节点又包含很多分片，这样，海量数据由集群来承载，分片（数据）在集群这篇大海里自由游荡。副本（replica）又叫从分片，分片的备份，防止数

和数据库进行一个类比，按照从大到小的概念，共四个，分别为：索引，类型，映射，文档。索引(index)相当于数据库。类型(type)相当于表。映射(mapping)相当于表结构。文档(document)相当于行记录。...

前言都说ES全文检索查询效率快，那么到底有多快呢？由于当时测试时，没有截屏记录下来，也不想浪费时间再去专门导入一百万数据，然后测试一下效率提升多少了，毕竟已经做过了，重复劳动没必要，导入数据是非常慢的过程。。思路ES在项目中收尾后，我想测试一下ES是否真的非常快，所以我向ES库导入了一百万数据。具体过程为，循环向MYSQL中插入数据，然后批量导入到ES库。实践一百万的数据，用两种方法进行测试，看效率有多大的提升。一：MYSQL使用Mybatis的动态sql查询。二：使用ES全文检索。首先，

最基础，最常用的几个API。QueryBuilder查询构造器，一个接口，MatchQueryBuilder，TermQueryBuilder，BoolQueryBuilder都实现了这个接口。NativeSearchQueryBuilderqueryBuilder.withQuery()：​ ES中查询方式很多，如布尔查询，匹配查询，精准查询等。这个方法用于包含某种查询，如：queryBuilder.withQuery(boolQuery);queryBuilder.withPage

一、生成索引类型1、根据MySQL中file类，构造索引类型。​ 在这个项目中，需要被分词的字段不多，一个是文件内容，一个是文件标题，可以将他们共同封装到content字段那种，也可以分开设计字段，分别索引，所需要进行的操作很简单，但是有坑。​ 我需要将后缀名为doc和docx的文件打开，获取其中所有信息。​ 进行这个操作时，报错挺多的，百度后有的说是WPS文档不行，有的说新旧版本不兼容，有的说是缺少依赖，依赖需要成套使用，说的很玄乎。​ 可惜时间太久了，忘记报错信息了，都是常见的报错，但是网上

一、MySQL中文件表业务字段如下，公共字段如创建人，修改时间等随自己需求增加。file_id_：file表主键。file_name_：文件名称（中文原名称）。new_name_：文件新名称（时间戳数字），文件名称在服务器保存时，有可能会重复，所以使用时间戳。path_：文件在服务器地址。ext_：文件扩展名，标识文件是docx,pdf,img等格式。desc_：文件描述。total_bytes_：总字节数。record_status_：归档状态。二、ES中索引库我创建的索引库名为Gr

一、导入依赖，但是无法使用相应API实际开发过程中，项目本身已经导入了非常多的依赖，当我们导入新的依赖时，容易发生依赖冲突及依赖覆盖。首先要知道Maven依赖pom文件中有三个原则：一、路径不同，依赖路径最短优先原则。二、路径相同，从上向下，就近原则。三、子pom优先父pom。二、解决思路首先检查依赖是否成功导入，重新导入依赖后，经检查，已经导入项目中，依然没有相应API。​之后怀疑是不是自己记错了，该API并不存在，新建一个项目demo，进行同样操作，可以使用该API。那么问题就锁定在了项

一、ES业务需求系统中，每日都会上传大量的文件，对这些文件进行全文检索，创建内部知识库。二、实现功能1.用户可以输入关键词搜索找到自己想要的文件。2.搜索列表中关键词高亮显示。3.可以进行预览及下载操作。三、实现步骤1.设计MySQL表结构，file表以及每张主表里有file表形式外键。2.安装ES，安装Kibana，安装ES谷歌插件，项目中导入依赖。3.设计索引库并将MySQL数据迁移到ES库中。4.写搜索逻辑带有关键字高亮功能。5.预览，下载功能。6.效率测试。四、注项目结束