elasticsearch

ElasticSearch查询流程详解

前面已经介绍了ElasticSearch的写入流程，了解了ElasticSearch写入时的分布式特性的相关原理。ElasticSearch作为一款具有强大搜索功能的存储引擎，它的读取是什么样的呢？读取相比写入简单的多，但是在使用过程中有哪些需要我们注意的呢？本篇文章会进行详细的分析。 在前面的文章我们已经知道ElasticSearch的读取分为两种GET和SEARCH。这两种操作是有一定的差异的，下面我们先对这两种核心的数据读取方式进行一一分析。 （图片来自官网） 以下是从主分片或者副本分片检索文档的步骤顺序： 注意： 在协调节点有个http_server_worker线程池。收到读请求后它的具体过程为： 数据节点上有一个get线程池。收到了请求后，处理过程为： 注意： get过程会加读锁。处理realtime选项，如果为true，则先判断是否有数据可以刷盘，然后调用Searcher进行读取。Searcher是对IndexSearcher的封装在早期realtime为true则会从tranlog中读取，后面只会从index的lucene读取了。即实时的数据只在lucene之中。 对于Search类请求，ElasticSearch请求是查询lucene的Segment，前面的写入详情流程也分析了，新增的文档会定时的refresh到磁盘中，所以搜索是属于近实时的。而且因为没有文档id，你不知道你要检索的文档在哪个分配上，需要将索引的所有的分片都去搜索下，然后汇总。ElasticSearch的search一般有两个搜索类型 所有的搜索系统一般都是两阶段查询： 第一阶段查询到匹配的docID，第二阶段再查询DocID对应的完整文档。这种在ElasticSearch中称为query_then_fetch，另一种就是一阶段查询的时候就返回完整Doc，在ElasticSearch中叫query_and_fetch，一般第二种适用于只需要查询一个Shard的请求。因为这种一次请求就能将数据请求到，减少交互次数，二阶段的原因是需要多个分片聚合汇总，如果数据量太大那么会影响网络传输效率，所以第一阶段会先返回id。 除了上述的这两种查询外，还有一种三阶段查询的情况。 搜索里面有一种算分逻辑是根据TF和DF来计算score的，而在普通的查询中，第一阶段去每个Shard中独立查询时携带条件算分都是独立的，即Shard中的TF和DF也是独立的。虽然从统计学的基础上数据量多的情况下，每一个分片的TF和DF在整体上会趋向于准确。但是总会有情况导致局部的TF和DF不准的情况出现。 ElasticSearch为了解决这个问题引入了DFS查询。 比如DFS_query_then_fetch，它在每次查询时会先收集所有Shard中的TF和DF值，然后将这些值带入请求中，再次执行query_then_fetch，这样算分的时候TF和DF就是准确的，类似的有DFS_query_and_fetch。这种查询的优势是算分更加精准，但是效率会变差。 另一种选择是用BM25代替TF/DF模型。 在ElasticSearch7.x，用户没法指定以下两种方式： DFS_query_and_fetch 和 query_and_fetch 。 注：这两种算分的算法模型在《ElasticSearch实战篇》有介绍： 这里query_then_fetch具体的搜索的流程图如下： （图片来自官网） 查询阶段包含以下四个步骤: 以上就是ElasticSearch的search的详细流程，下面会对每一步进行进一步的说明。 协调节点处理query请求的线程池为： http_server_work 负责该解析功能的类为： org.elasticsearch.rest.action.search.RestSearchAction 主要将restquest的参数封装成SearchRequest 这样SearchRequest请求发送给TransportSearchAction处理 将索引涉及到的shard列表或者有跨集群访问相关的shard列表合并 如果有多个分片位于同一个节点，仍然会发送多次请求 shardsIts为搜索涉及的所有分片，而shardRoutings.nextOrNull()会从分片的所有副本分片选出一个分片来请求。 onShardSuccess对收集到的结果进行合并，这里需要检查所有的请求是否都已经有了回复。 然后才会判断要不要进行executeNextPhase 当返回结果的分片数等于预期的总分片数时，协调节点会进入当前Phase的结束处理，启动下一个阶段Fetch Phase的执行。onPhaseDone()会executeNextPhase来执行下一个阶段。 当触发了executeNextPhase方法将触发fetch阶段 上一步的executeNextPhase方法触发Fetch阶段，Fetch阶段的起点为FetchSearchPhase#innerRun函数，从查询阶段的shard列表中遍历，跳过查询结果为空的 shard。其中也会封装一些分页信息的数据。 使用了countDown多线程工具，fetchResults存储某个分片的结果，每收到一个shard的数据就countDoun一下，当都完毕后，触发finishPhase。接着会进行下一步： CountedCollector: finishPhase: 执行字段折叠功能，有兴趣可以研究下。即ExpandSearchPhase模块。ES 5.3版本以后支持的Field Collapsing查询。通过该类查询可以轻松实现按Field值进行分类，每个分类获取排名前N的文档。如在菜单行为日志中按菜单名称（用户管理、角色管理等）分类，获取每个菜单排名点击数前十的员工。用户也可以按Field进行Aggregation实现类似功能，但Field Collapsing会更易用、高效。 ExpandSearchPhase执行完了，就返回给客户端结果了。 处理数据节点请求的线程池为：search 根据前面的两个阶段，数据节点主要处理协调节点的两类请求：query和fetch 这里响应的请求就是第一阶段的query请求 executeQueryPhase: executeQueryPhase会执行loadOrExecuteQueryPhase方法 这里判断是否从缓存查询，默认启用缓存，缓存的算法默认为LRU，即删除最近最少使用的数据。如果不启用缓存则会执行queryPhase.execute(context);底层调用lucene进行检索，并且进行聚合。 关键点： ElasticSearch查询分为两类，一类为GET，另一类为SEARCH。它们使用场景不同。 本文主要分析了ElasticSearch分布式查询主体流程，并未对lucene部分进行分析，有兴趣的可以自行查找相关资料。

ElasticSearch常用查询方法总结

基于词项的查询：不需要分析阶段，对单个词项进行操作，在倒排索引中查找准确词项。 Terms Query：在给定字段内查询并返回准确符合一个或多个词项的查询结果。 Fuzzy Query：返回与给定词项 相似 的结果。相似程度用Levenshtein编辑距离来衡量。 1编辑距离指一个字符的变化，包括： Fuzzy Query会创建一系列可能出现的，编辑距离为1的变化后的词项，然后用这些词项进行精确查询以获得最终结果。 Wildcard Query：返回符合通配符表达式的查询结果。使用？代替单个字符，*代替零个或几个字符。 基于全文的查询：高层查询，要先了解字段映射的信息。如果查询一个未分析的精确值字符串字段，会将整个查询字符串作为单个词项对待。如果查询一个已分析的精确值字符串字段，会先将查询字符串传递到一个合适的分析器， 然后生成一个供查询的词项列表。 Match Query：是一个高级全文查询，它既能处理全文字段，又能处理精确字段。Match Query主要的应用场景就是进行全文搜索，但无论需要查询什么字段， Match Query都应该会是首选的查询方式。 Query String Query：使用句法将给定的查询条件按And或Or的方式进行分析和拆分，返回包含查询字符串的结果。 Match Phrase Query：会分析文本，再从分析后的文本中生成phrase查询。 复合查询：组合查询语句，使查询结果符合多项标准，支撑更复杂的查询条件。 Bool Query：对查询语句进行与或非的组合。包含关键词must(and), should(or), must_not(not)。 Table1 Comparison of ES Query Methods Reference List: https://www.elastic.co/guide/en/elasticsearch/reference/current/search-your-data.html https://stackoverflow.com/questions/23150670/elasticsearch-match-vs-term-query https://godoc.org/gopkg.in/olivere/elastic.v3

Elasticsearch是什么?

Elasticsearch是位于ElasticStack核心的分布式搜索和分析引擎。Logstash和Beats有助于收集、聚合和丰富您的数据并将其存储在Elasticsearch中。Kibana使您能够以交互方式探索、可视化和分享对数据的见解，并管理。Elasticsearch是一个分布式文档存储。Elasticsearch存储的是序列化为JSON文档的复杂数据结构，而不是以列行数据的形式存储信息。当集群中有多个Elasticsearch节点时，存储的文档分布在整个集群中，可以立即从任何节点访问。Elasticsearch是由ShayBanon发起的一个开源搜索服务器项目，2010年2月发布。迄今，该项目已发展成为搜索和数据分析解决方案领域的主要一员，广泛应用于声名卓著或鲜为人知的搜索应用程序。Elasticsearch是一个高度可扩展的开源全文搜索和分析引擎。它可以在很短的时间内存储，搜索和分析大量的数据。它通常作为具有复杂搜索场景情况下的核心发动机。搜索引擎，不支持join表等操作。主要用于全文检索。不适合做数据库。

elasticsearch

首先准备环境 ElasticSearch : https://mirrors.huaweicloud.com/elasticsearch/?C=N&O=D logstash : https://mirrors.huaweicloud.com/logstash/?C=N&O=D kibana : https://mirrors.huaweicloud.com/kibana/?C=N&O=D ik : https://github.com/medcl/elasticsearch-analysis-ik/tree/v7.8.0 ElasticSearch 是一个实时分布式搜索和分析引擎，主要用于全文搜索，结构化搜索，分析以及将这三者混合使用。 Lucene 是一个全文检索引擎的架构。 ElasticSearch vs Solr 总结 （1）es基本是开箱即用，非常简单。Solr安装略微复杂一丢丢，可关注（ solr6.6教程-基础环境搭建(一) ） （2）Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能。 （3）Solr 支持更多格式的数据，比如JSON、XML、CSV，而 Elasticsearch 仅支持json文件格式。 （4）Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供，例如图形化界面需要kibana友好支撑 （5）Solr 查询快，但更新索引时慢（即插入删除慢），用于电商等查询多的应用； ES建立索引快（即查询慢），即实时性查询快，用于facebook新浪等搜索。 Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。 （6）Solr比较成熟，有一个更大，更成熟的用户、开发和贡献者社区，而 Elasticsearch相对开发维护者较少，更新太快，学习使用成本较高。 ik分词器： ik提供了两个分词算法：ik_smart和ik_max_word,其中ik_smart为最少切分，ik_max_word为最细粒度切分。 ik_smart： ik_max_word： ik分词器可以增加自己的配置，自己配置词典。