Elasticsearch：全文搜索的利器

1. 简介

Elasticsearch是一个基于Lucene的分布式搜索引擎，能够支持准实时的数据检索NRT(near real-time),支持海量数据的处理，包括结构化和非结构化数据，提供强大的全文搜索能力，但是ES不仅仅是一个全文搜索引擎，他能够解决传统数据库解决不了的复杂查询，计算，聚合等操作，还有时序数据的处理，比如日志处理、监控数据的存储、分析和可视化等

2. 基本概念

2.1 架构

2.1.1 架构图

2.1.2 集群

在一个分布式系统里面,可以通过多个elasticsearch运行实例组成一个集群,这个集群里面有一个节点叫做主节点(master),elasticsearch是去中心化的,所以这里的主节点是动态选举出来的,不存在单点故障。

在同一个子网内，只需要在每个节点上设置相同的集群名,elasticsearch就会自动的把这些集群名相同的节点组成一个集群。节点和节点之间通讯以及节点之间的数据分配和平衡全部由elasticsearch自动管理。

2.2 索引

在使用传统的关系型数据库时，如果对数据有存取和更新操作，需要建立一个数据库。相应地，在ES中则需要建立索引。用户的数据新增、搜索和更新等操作的对象全部对应索引。但是，ES中的索引和Lucene中的索引不是一一对应的。ES中的一个索引对应一个或多个Lucene索引，这是由其分布式的设计方案决定的。

2.2.1 mapping

ES中的mapping有点类似与RDB中“表结构”的概念，在MySQL中，表结构里包含了字段名称，字段的类型还有索引信息等。在Mapping里也包含了一些属性，比如字段名称、类型、字段使用的分词器、是否评分、是否创建索引等属性，并且在ES中一个字段可以有多个类型。

2.3 文档

在使用传统的关系型数据库时，需要把数据封装成数据库中的一条记录，而在ES中对应的则是文档。ES的文档中可以有一个或多个字段，每个字段可以是各种类型。用户对数据操作的最细粒度对象就是文档。ES文档操作使用了版本的概念，即文档的初始版本为1，每次的写操作会把文档的版本加1，每次使用文档时，ES返回给用户的是最新版本的文档。另外，为了减轻集群负载和提升效率，ES提供了文档的批量索引、更新和删除功能。

2.4 字段

一个文档可以包含一个或多个字段，每个字段都有一个类型与其对应。除了常用的数据类型（如字符串型、文本型和数值型）外，ES还提供了多种数据类型，如数组类型、经纬度类型和IP地址类型等。ES对不同类型的字段可以支持不同的搜索功能。例如，当使用文本类型的数据时，可以按照某种分词方式对数据进行搜索，并且可以设定搜索后的打分因子来影响最终的排序。再如，使用经纬度的数据时，ES可以搜索某个地点附近的文档，也可以查询地理围栏内的文档。在排序函数的使用上，ES也可以基于某个地点按照衰减函数进行排序。

2.4.1 自动映射和手动映射

2.5 分片

在分布式系统中，为了能存储和计算海量的数据，会先对数据进行切分，然后再将它们存储到多台计算机中。这样不仅能分担集群的存储和计算压力，而且在该架构基础上进一步优化，还可以提升系统中数据的高可用性。在ES中，一个分片对应的就是一个Lucene索引，每个分片可以设置多个副分片，这样当主分片所在的计算机因为发生故障而离线时，副分片会充当主分片继续服务。索引的分片个数只能设置一次，之后不能更改。在默认情况下，ES的每个索引设置为5个分片。

2.6 DSL

ES使用DSL（Domain Specific Language，领域特定语言），来定义查询。与编程语言不同，DSL是在特定领域解决特定任务的语言，它可以有多种表达形式，如我们常见的HTML、CSS、SQL等都属于DSL。ES中的DSL采用JSON进行表达，相应地，ES也将响应客户端请求的返回数据封装成了JSON形式。这样不仅可以简单明了地表达请求/响应内容，而且还屏蔽了各种编程语言之间数据通信的差异。

2.6 应用场景

• 搜索引擎
• 推荐系统
• 二级索引
• 日志系统

3. 实践应用

3.1 索引创建

3.2 查询文档

查询方式	详情
term	term查询是结构化精准查询的主要查询方式，用于查询待查字段和查询值是否完全匹配
terms	terms查询是term查询的扩展形式，用于查询一个或多个值与待查字段是否完全匹配
range	range查询用于范围查询，一般是对数值型和日期型数据的查询。使用range进行范围查询时，用户可以按照需求中是否包含边界数值进行选项设置，可供组合的选项如下：gt---大于；lt---小于；gte---大于或等于；lte---小于或等于。
exists	在某些场景下，我们希望找到某个字段不为空的文档，则可以用exists搜索。
must	当查询中包含must查询时，相当于逻辑查询中的“与”查询。命中的文档必须匹配该子查询的结果，并且ES会将该子查询与文档的匹配程度值加入总得分里。must搜索包含一个数组，可以把其他的term级别的查询及布尔查询放入其中。
should	当查询中包含should查询时，表示当前查询为“或”查询。命中的文档可以匹配该查询中的一个或多个子查询的结果，并且ES会将该查询与文档的匹配程度加入总得分里。should查询包含一个数组，可以把其他的term级别的查询及布尔查询放入其中。
must not	当查询中包含must not查询时，表示当前查询为“非”查询。命中的文档不能匹配该查询中的一个或多个子查询的结果，ES会将该查询与文档的匹配程度加入总得分里。must not查询包含一个数组，可以把其他term级别的查询及布尔查询放入其中
filter	filter查询即过滤查询，该查询是布尔查询里非常独特的一种查询。其他布尔查询关注的是查询条件和文档的匹配程度，并按照匹配程度进行打分；而filter查询关注的是查询条件和文档是否匹配，不进行相关的打分计算，但是会对部分匹配结果进行缓存。
Constant Score	如果不想让检索词频率TF（Term Frequency）对搜索结果排序有影响，只想过滤某个文本字段是否包含某个词，可以使用Constant Score将查询语句包装起来。

4. 性能优化

介绍如何优化 Elasticsearch 的性能，例如索引优化、查询优化等。

5. 常见问题解答

5.1 Elasticsearch和关系型数据库的对比

对比项	详情
索引方式	关系型数据库的索引大多是B-Tree结构，而ES使用的是倒排索引，两种不同的数据索引方式决定了这两种产品在某些场景中性能和速度的差异。例如，对一个包含几亿条数据的关系型数据表执行最简单的count查询时，关系型数据库可能需要秒级的响应时间，如果数据表的设计不合理，甚至有可能把整个关系型数据库拖垮，影响其他的数据服务；而ES可以在毫秒级别进行返回，该查询对整个集群的影响微乎其微。再例如，一个需求是进行分词匹配，关系型数据库需要依靠其他的组件才能完成这种查询，查询的结果只能是满足匹配，但是不能按照匹配程度进行打分排序；ES建立在Lucene基础之上，与生俱来就能完成分词匹配，并且支持多种打分排序算法，还支持用户自定义排序脚本。 【补充】B+Trees做全文检索的弊端 索引往往字段很长，如果使用B+trees，树可能很深，IO很可怕 性能无法保证并且索引会失效 精准度差（相关度低），并且无法和其他属性产生相关性
事务支持	事务是关系型数据库的核心组成模块，而ES是不支持事务的。ES更新文档时，先读取文档再进行修改，然后再为文档重新建立索引。如果同一个文档同时有多个并发请求，则极有可能会丢失某个更新操作。为了解决这个问题，ES使用了乐观锁，即假定冲突是不会发生的，不阻塞当前数据的更新操作，每次更新会增加当前文档的版本号，最新的数据由文档的最新版本来决定，这种机制就决定了ES没有事务管理。
SQL和DSL	SQL和DSL都有自己的语法结构，都是各自和用户之间进行交互的一种语言表达方式。
扩展方式	关系型数据库的扩展，需要借助第三方组件完成分库分表的支持。 ES本身就是支持分片的，只要初期对分片的个数进行了合理的设置，后期是不需要对扩展过分担心的，即使现有集群负载较高，也可以通过后期增加节点和副分片的方式来解决。
数据的查询速度	在少量字段和记录的情况下，传统的关系型数据库的查询速度非常快。如果单表有上百个字段和几十亿条记录，则查询速度是比较慢的。虽然可以通过索引进行缓解，但是随着数据量的增长，查询速度还是会越来越慢。 ES是基于Lucene库的搜索引擎，可以支持全字段建立索引。在ES中，单个索引存储上百个字段或几十亿条记录都是没有问题的，并且查询速度也不会变慢。
数据的实时性	关系型数据库存储和查询数据基本上是实时的。 ES的数据写入不是实时的，而是准实时的。

5.2 数据一致性

5.3 Master选举

6. 总结

总结 Elasticsearch 的关键知识点，并提供学习资源和进一步研究方向。