首页  思维导图  详情

Elasticsearch

2020-12-14 16:49:12   0  举报





仅支持查看

AI智能生成

ES学习总结

作者其他创作

大纲/内容

扩展

插件开发

security

analysis

alerting

api扩展

management

mapper

scripting

backup/restore

原理

lucence

每个shard都是一个最小工作单元，承载部分数据，每个shard都是一个lucene实例，都有完整的建立索引和处理请求的能力。

analysis 模块

词法分析及语言处理，也就是我们常说的分词，通过这个形成最小的存储/搜索单元

index 模块

创建index

store模块

存储

queryParse模块

语法分析

search模块

搜索

similarity模块

打分排序

核心概念

Index（索引）

Document（文档）

Sequence Number

Field（字段）

FieldType

stored: 代表是否需要保存该字段，如果为false，则lucene不会保存这个字段的值，而搜索结果中返回的文档只会包含保存了的字段。

tokenized: 代表是否做分词，在lucene中只有TextField这一个字段需要做分词。

termVector: http://makble.com/what-is-term-vector-in-lucene 很好的解释了term vector的概念，简单来说，term vector保存了一个文档内所有的term的相关信息，包括Term值、出现次数（frequencies）以及位置（positions）等，是一个per-document inverted index，提供了根据docid来查找该文档内所有term信息的能力。对于长度较小的字段不建议开启term verctor，因为只需要重新做一遍分词即可拿到term信息，而针对长度较长或者分词代价较大的字段，则建议开启term vector。Term vector的用途主要有两个，一是关键词高亮，二是做文档间的相似度匹配（more-like-this）。

omitNorms: Norms是normalization的缩写，lucene允许每个文档的每个字段都存储一个normalization factor，是和搜索时的相关性计算有关的一个系数。Norms的存储只占一个字节，但是每个文档的每个字段都会独立存储一份，且Norms数据会全部加载到内存。所以若开启了Norms，会消耗额外的存储空间和内存。但若关闭了Norms，则无法做index-time boosting（elasticsearch官方建议使用query-time boosting来替代）以及length normalization。

indexOptions: Lucene提供倒排索引的5种可选参数（NONE、DOCS、DOCS_AND_FREQS、DOCS_AND_FREQS_AND_POSITIONS、DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS），用于选择该字段是否需要被索引，以及索引哪些内容。

docValuesType: DocValue是Lucene 4.0引入的一个正向索引（docid到field的一个列存），大大优化了sorting、faceting或aggregation的效率。DocValues是一个强schema的存储结构，开启DocValues的字段必须拥有严格一致的类型，目前Lucene只提供NUMERIC、BINARY、SORTED、SORTED_NUMERIC和SORTED_SET五种类型。

dimension：Lucene支持多维数据的索引，采取特殊的索引来优化对多维数据的查询，这类数据最典型的应用场景是地理位置索引，一般经纬度数据会采取这个索引方式。

term

索引的最小存储/查询单元，一般指分词后的一个词

字典/词典 Term Dictionary

term的集合

词典需要常驻内存

字典的数据结构有很多种

排序数组

二分查找检索索引

HashMap结构

比排序数组更快，就牺牲空间

Finite-state transducer

fst 有比较好的压缩率和查询效率，默认使用这个

倒排表 Posting List

记录一个词，在原文（就是上面的field（字段）的docID即sequence number）的哪个位置出现过

原文信息

原始文档，用来排序，聚合，展示

段 segment

一个索引文件由一个或多个段组成，段具有不变性，一旦生成只能读，不能写

lucence是分段存储的

新增

创建一个新的段来存储新的数据

删除

新增一个.del文件，存储被删除数据的DocId，当查询的时候，被删除的数据还是会被查出来。
只是在文档链合并的时候，把删除的数据给过滤掉

被删除的数据只有段合并的时候才会被真正删除掉

更新

新增和删除的组合。
现在.del文件中记录旧的数据DocId，再新的段中新增一条更新后的数据

段采用延时策略，在内存中暂存1s或者段的数据量够大的时候，才会批量提交到磁盘中。
默认时间和数据量的大小可以通过参数修改。

lucence存在丢失数据的可能，为此ES添加了事务来保证数据的安全。

段合并策略

mergeFactor

每次合并时参与合并的段最少数量，当一个组的段的数量达到时，开始合并，小于此值就不合并

默认10

segmentSize

段的实际大小，为字节

minMergeSize

小于这个值的段就会被分到一组，加速小片段的合并

检索过程

见《可伸缩服务架构：框架与中间件》271页

一个查询请求在集群处理的流程

有id的查询

（1）客户端向集群发送查询请求，集群随机选择一个节点做协调节点（coordinating node）负责这次查询任务

（2）协调节点通过routing id计算文档在哪个shard上，可以指定到replica shard。

（3）协调节点将请求发送给对应的shard之后，对应的shard查询结果返回给协调节点，协调节点返回请求给客户端

普通查询，不走主键，无法知道数据在哪个分片上

深度分页问题

PUT /index/type/id 在集群处理流程

一般对应到应用程序中，每次的执行流程基本是这样的：

只有primary shard能处理写请求

我们能知道请求的数据在哪个分片上，因为我们一开始就定义了分片的数目，并且不能改动分片数目。
通过 shard = hash(routing) % number_of_primary_shards 确定是第几个分片。
集群中节点都知道集群中文档存放的位置。所以每个节点都能处理读写请求，而处理请求的节点称为协调节点（coordinating Node）
协调节点负责将请求转发到该分片的主分片上。

（1）然后发送PUT请求，到es中node1，进行全量替换

（2）通过文档的_id来确认文档在哪个分片，请求转发到对应的节点

（3）对应的节点node在主分片上执行成功，如果成功，则将请求转发给自己的replica，当一致性指定的replica数量以上的replica执行拱了，协调节点才会返回客户端成功了。

partial update 在集群处理流程

1）内部获取document

2）将传过来的field更新到查询的document json

3）将老的document 标记为 deleted

4）将修改后新的document创建出来

乐观锁实现

核心概念

物理视角

集群

集群的健康状况

green、yellow、red

green：每个索引的primary shard和replica shard都是active状态的

yellow：每个索引的primary shard都是active状态的，但是部分replica shard不是active状态，处于不可用的状态

red：不是所有索引的primary shard都是active状态的，部分索引有数据丢失了。

横向扩容

1. 机器越多只要不是强一致性读写，性能越好

2. 扩容的极限是一台机器一个shard
比如我有3个primary shard，6个replica shard，那么扩容的极限就是9台机器

容错

比如我有3台机器
我有3个primary shard，6个replica shard

1、图解Elasticsearch容错机制：master选举，replica容错，数据恢复

（1）9 shard，3 node，分布如下：

（2）master node宕机，自动master选举，red

master node宕机的一瞬间，P0这个primary shard就没了，此时不是active status, 就是所有的primary shard都是active的。

容错第一步： master选举，自动选举另外一个node成为新的master，承担起master得责任来。

容错第二步：新master将丢失掉的primary shard的某个replica shard提升为primary shard，此时cluster status会变成yellow，因为primary shard全都变成active了，但是，少了一个replica shard，所以不是所有的replica shard都是active的了。

容错第三步：重启宕机node，master copy replica到该node，使用原有的shard并同步宕机后的修改，green。

怎么扩容，怎么提升系统整体吞吐量的同时；怎么保证提高容错性，让尽可能多的服务器宕机，保证数据不丢失？

节点

master node

1. 创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。

2. 维护并更新 cluster state

稳定的主节点对集群的健康是非常重要的，默认情况下任何一个集群中的节点都有可能被选为主节点，索引数据和搜索查询等操作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。

使用低配置cpu，ram和磁盘

data node

保持分片数据

使用高配置cpu，ram和磁盘

ingest node

默认每个节点打开

做数据预处理，可以理解index或者布莱克 api请求

可以对数据转换重新返回给index或者bulk api

无需logstash 就可以对数据进行预处理

例如：为某个字段设置默认值，重命名某个字段的字段名，对字段值进行split，支持painless脚本，对数据的复杂加工

使用高配置cpu，中等ram，低配置磁盘

coordinating node

machine learning

特殊节点类型

Hot & Warm NOde

冷热节点

ML node

机器学习的节点

Tribe Node

部落节点

分片

primary shard

一个分片就是一个lucene实例

主分片一旦指定不能修改，除非reindex

replica shard

可以动态调整

逻辑视角

索引

文档

_all metadata的原理和作用

分布式架构

Consensus

共识性

Zen discovery共识系统

gossip传输数据，实现单播，节点间一对一通信

Concurrency

并发

es使用的乐观锁实现并发控制

乐观锁

partial update内部会自动执行乐观锁概念。

retry策略

example

Consistency

一致性

我们在发送任何一个增删改操作的时候，比如说put /index/type/id，都可以带上一个consistency参数，指明我们想要的写一致性是什么？
put /index/type/id?consistency=quorum

ES支持Quorum NWR算法

one（primary shard）

要求我们这个写操作，只要有一个primary shard是active活跃可用的，就可以执行

all（all shard）

要求我们这个写操作，必须所有的primary shard和replica shard都是活跃的，才可以执行这个写操作

quorum（default）

默认的值，要求所有的shard中，必须是大部分的shard都是活跃的，可用的，才可以执行这个写操作

分片的原理

shard

replica

集群选主的流程

Zen discovery

集群通过ping命令来保持连通，ping不通就认为master发生了故障

发生了故障之后nodeId小的会成为新的master

其他节点加入集群都是不担任master节点的角色。一旦发现master丢失，就会选出新的master节点

discovery.zen.minimum_master_nodes=1

设置最小选主的节点数，默认是1，使用默认值很容易脑裂

discovery.zen.ping.timeout: 3s 设置在集群中发现其它节点时ping连接的超时时间

避免脑裂

discovery.zen.minimum_master_nodes=（master_eligible_nodes/2）+ 1

半数的节点认为master可用才进行选举

es7之后无需配置

移除minimum_master_nodes参数，让es自己选择可以形成仲裁节点

文档读写流程

节点故障转移

分片：主分片和副本分片

master自动选primary shard转移到还存活的node上

分布式搜索

事务日志 translog

提高高可用

translog是elasticsearch的事务日志文件

translog是用来恢复数据的。

执行步骤

1）将内存中的数据刷新到一个段中，该段还在内存中，缓存在操作系统的文件缓存系统中

注意是缓存系统，而不是jvm内存

这个时候，段只能读，不能写

2）打开保存在文件系统缓存的段，让其可以被搜索

这也是es近实时的根本原因

3）清空内存，接受新的数据，日志不做清空处理

后台线程检测日志大小超过512MB或者时间超过30min，触发刷新

1）文件缓存系统创建一个新的段，并将内存中的数据写入，使其可以被搜索

2）清空内存，准备接受新的数据

3）将文件缓存中的数据通过fsync 刷新到硬盘中

4）生成提交点

5）删除旧的日志，创建一个空的日志

搜索引擎

倒排索引

example

倒排索引分两部分

Term Dictionary :词典

Posting List：倒排表

文档Id

词频TF-该单词在文档中出现的次数，用于相关性评分

位置 position

单词在文档中分词的位置，用于语句搜索

偏移量 offset

记录单词开始结束的位置，实现高亮

example

搜索相关性