ES基本原理

更新时间:2023-05-12 08:46:22 阅读：评论：0

ES基本原理

⼀、ES的适⽤场景

1、ES的主要应⽤分为两⼤类：

搜索类(带上聚合)，考虑事务性，频繁更新，与现有数据库进⾏同步，通过ES进⾏查询聚合。

⽇志类，包括⽇志收集，指标性收集，通过beats等⼯具收集到kafka等Q中，通过logstash进⾏转换，输送到ES中，然后通过Kibana 进⾏展⽰。

MySQL作为开源关系型数据库，应⽤范围⾮常⼴泛，⾮常适合于结构化数据存储和查询。在数据查询场景下，默认返回所有满⾜匹配条件的记录；如果业务数据为结构化数据，同时不需要特别关注排名和智能分词模糊匹配查询等特性，则建议采⽤关系型数据库如MySQL。

ES作为新⽣代NoSQL数据库代表之⼀，⾮常适合于⾮结构化⽂档类数据存储、更创新⽀持智能分词匹配模糊查询。如果业务数据为⾮结构化数据，同时更关注排名和需要智能分词模糊匹配的特性，则建议采⽤⾮关系型数据库如ES作为数据存储介质并使⽤配套搜索引擎。 ES 可以实现⼀些关系型数据库难以实现的功能，⽐如全⽂检索，ES 可以作为关系型数据库的补充，⽤来弥补关系型数据中的不⾜，也可能在某些情况下替代关系型数据库。

在⾯对⼤数据量简单计算的时候es的效率原⾼于mysql等传统数据库，对于数据量⼤、数据结构不固定的数据可采⽤全⽂检索⽅式搜索，利⽤全⽂检索技术建⽴索引，供⽤户查询；对于相对数量较少，多表join 时，mysql优势更⾼。

第⼀，⾼效率：Elasticarch对模糊搜索⾮常擅长

第⼆，查询结果排序：从Elasticarch搜索到的数据可以根据评分过滤掉⼤部分的，只要返回评分⾼的给⽤户就好了

第三，模糊查询：没有那么准确的关键字也能搜出相关的结果

2、⾮结构化数据存储⽅式

⾮结构化数据⼜可称为全⽂数据，不定长或⽆固定格式，不适于由数据库⼆维表来表现，包括所有格式的办公⽂档、XML、HTML、Word ⽂档，邮件，各类报表、图⽚和咅频、视频信息等。对于⾮结构化数据，主要有两种⽅法：顺序扫描、全⽂检索。

顺序扫描：按照顺序扫描的⽅式查询特定的关键字。（这种⽅式⽆疑是耗时切低效的）

全⽂检索：将⾮结构化数据中的⼀部分元信息提取出来，重新组织，使其变得有⼀定结构，然后对此

有⼀定结构的数据进⾏搜索，从⽽达到搜索相对较快的⽬的。这种⽅式的主要⼯作量在前期索引的创建，但是对于后期搜索却是快速⾼效的。从⾮结构化数据中提取出的然后重新组织的信息，我们称之索引。

索引创建：将现实世界中所有的结构化和⾮结构化数据提取信息，创建索引的过程。

搜索索引：就是得到⽤户的查询请求，搜索创建的索引，然后返回结果的过程。

⼆、ES的基本概念

⽂档： Elasticarch最⼩的数据存储单元，JSON数据格式，类似于关系型数据库的表记录（⼀⾏数据），结构定义多样化，同⼀个索引下的document，结构尽可能相同。

索引： es索引，其保存具有相同结构的⽂档集合，类似于关系型数据库的数据库实例（6.0.0版本type废弃后，索引的概念下降到等同于数据库表的级别）。⼀个集群⾥可以定义多个索引。

类型：类型⽤于区分同⼀个索引的不同数据类型，相当于关系型数据库中表。

分⽚：因为 ES 是个分布式的搜索引擎, 所以索引通常都会分解成不同部分, ⽽这些分布在不同节点的数据就是分⽚。ES⾃动管理和组织分⽚, 并在必要的时候对分⽚数据进⾏再平衡分配, 所以⽤户基本上不⽤担⼼分⽚的处理细节。

副本(replica): ES 默认为⼀个索引创建 5 个主分⽚, 并分别为其创建⼀个副本分⽚. 也就是说每个索引都由 5 个主分⽚成本, ⽽每个主分⽚都相应的有⼀个 copy。对于分布式搜索引擎来说, 分⽚及副本的分配将是⾼可⽤及快速搜索响应的设计核⼼.主分⽚与副本都能处理查询请求，它们的唯⼀区别在于只有主分⽚才能处理索引请求.副本对搜索性能⾮常重要，同时⽤户也可在任何时候添加或删除副本。额外的副本能给带来更⼤的容量, 更⾼的呑吐能⼒及更强的故障恢复能⼒。

节点：单个的ElasticSearch服务实例被称为节点（node）。⼀个数据节点上承载⼀个或多个分⽚。

集群：集群是⼀个或多个节点（服务器）的集合，这些节点共同保存整个数据，并在所有节点上提供联合索引和搜索功能。⼀个集群由⼀个唯⼀集群ID确定，并指定⼀个集群名（默认为“elasticarch”）。

三、ES的查询操作

1、全⽂检索

当⼀个搜索请求被发送到某个节点时，这个节点就变成了协调节点。这个节点的任务是⼴播查询请求到所有相关分⽚并将它们的响应整合成全局排序后的结果集合，这个结果集合会返回给客户端。多索

引搜索恰好也是⽤相同的⽅式-只是会涉及到更多的分⽚。在查询的时候因为不知道要查询的数据具体在哪个分⽚上，所以整个过程分为 2 个步骤。

分发：请求到达协调节点后，协调节点将查询请求分发到每个分⽚上。

聚合: 协调节点搜集到每个分⽚上查询结果，在将查询的结果进⾏排序，之后给⽤户返回结果。

客户端发送⼀个 arch 请求到 Node 3 ， Node 3 会创建⼀个⼤⼩为 from + size 的空优先队列。

Node 3 将查询请求转发到索引的每个主分⽚或副本分⽚中。每个分⽚在本地执⾏查询并添加结果到⼤⼩为 from + size 的本地有序优先队列中。

每个分⽚返回各⾃优先队列中所有⽂档的 ID 和排序值给协调节点，也就是 Node 3 ，它合并这些值到⾃⼰的优先队列中来产⽣⼀个全局排序后的结果列表。

相关restful:

GET twitter/_doc/0 //指定⽂档ID

三、ES的写操作

1、插⼊⽂档

在主副分⽚和任何副本分⽚上⾯成功新建，索引和删除⽂档所需要的步骤顺序：

客户端向 Node 1 发送新建、索引或者删除请求。coodinate（协调）节点通过hash算法可以计算出是在哪个主分⽚上，然后路由到对应的节点shard = hash(document_id) % (num_of_primary_shards)

节点使⽤⽂档的 _id 确定⽂档属于分⽚ 0 。请求会被转发到 Node 3，因为分⽚ 0 的主分⽚⽬前被分配在 Node 3 上。

Node 3 在主分⽚上⾯执⾏请求。如果成功了，它将请求并⾏转发到 Node 1 和 Node 2 的副本分⽚上。⼀旦所有的副本分⽚都报告成功, Node 3 将向协调节点报告成功，协调节点向客户端报告成功。

在客户端收到成功响应时，⽂档变更已经在主分⽚和所有副本分⽚执⾏完成，变更是安全的。

相关restful：PUT /index/type/_id和POST /index/type

PUT/province/citys/1/_create //指定ID，_create可去掉

POST/province/citys///由elasticarch⾃动⽣成ID

2、更新⽂档

客户端向node1 发送⼀个请求，node1作为协调节点。coodinate（协调）节点通过hash算法可以计算出是在哪个主分⽚上，然后路由到对应的节点shard = hash(document_id) % (num_of_primary_shards).

它将请求转发到主分⽚这个⽂档所在的Node 3.

node 3从主分⽚检索⽂档，修改_Source json ，并且尝试重新索引主分⽚的⽂档。如果⽂档被另⼀个进程修改，他会重复步骤3 ，直到超过retry_on_conflict 次后放弃。

node 3 成功更新⽂档，它将新版本的⽂档并⾏转发到node 1 和node 2 的副本分⽚，重新建⽴索引。

所有副本分⽚都返回成功，node 3 向协调节点也返回成功，协调节点向客户端返回成功

update 操作也⽀持新建索引的时的那些参数 routing 、 replication 、 consistency 和 timeout

相关restful: PUT /index/type/_id和POST /index/type/_id

PUT/province/citys/1//替换，PUT只会将json数据都进⾏替换

POST/province/citys/1/_update //更新，POST只会更新相同字段的值, _update可去掉

3、删除⽂档

该过程可以分为四个阶段来描述：

客户端向node 1发送⼀个⽂档删除的请求。

同样的node 1通过请求中⽂档的 _id 值判断出该⽂档应该被存储在shard 0 这个分⽚中，并且node 1知道shard 0的primary shard 位于node3这个节点上。因此node1会把这个请求转发到node3。

node3接收到请求后，在主分⽚上⾯执⾏删除请求

如果node3成功地删除了⽂档，node3将会请求并⾏地发给其余所有的副本所在node中。

这些node也同样操作删除，执⾏后则向node3发送⼀个成功确认，当node 3接收到所有的成功确认之后，再向客户端发送⼀个删除成功的信息。

Elasticarch是建⽴在Apache Lucene 基础上的实时分布式搜索引擎，Lucene为了提⾼搜索的实时性，采⽤不可再修改（immutable）⽅式将⽂档存储在⼀个个gment中。也就是说，⼀个gment在写⼊到存储系统之后，将不可以再修改。那么Lucene是如何从⼀个gment中删除⼀个被索引的⽂档呢？简单的讲，当⽤户发出命令删除⼀个被索引的⽂档#ABC时，该⽂档并不会被马上从相应的存储它的gment中删除掉，⽽是通过⼀个特殊的⽂件来标记该⽂档已被删除。当⽤户再次搜索到#ABC时，Elasticarch在gment中仍能找到#ABC，但由于#ABC⽂档已经被标记为删除，所以Lucene会

从发回给⽤户的搜索结果中剔除#ABC，所以给⽤户感觉的是#ABC已经被删除了。 Elasticach会有后台线程根据Lucene的合并规则定期进⾏gment merging合并操作，⼀般不需要⽤户担⼼或者采取任何⾏动。被删除的⽂档在gment合并时，才会被真正删除掉。