ElasticSearch原理

Y 且不是本节点

修改field

doc 1（deleted）

primary shard 03（Lucene实例）

每隔5秒落磁盘可以设置translog异步刷磁盘（注意：最多可能丢掉5秒的数据）

N

4、清空buffer

caching机制

client

translog文件（不断增大）

聚合需要知道每个term的完整value，所以倒排索引先天不满足，需要扫描全部倒排索引才可能找到一个term的完整value，性能极差。所以需要倒排+正排提升聚合性能，先通过倒排确定doc，然后通过doc正排完成聚合。

所有ping通的node都加入activeNodes列表

primary shard 02（Lucene实例）

根据filter条件，查询倒排索引，构建bitset

discovery.zen.ping.unicast.hosts: [\"host1\

Y

segment merge

刷入

DELETE

Node 03

1、根据聚合field搜索到doc id

增删改doc原理

宕机恢复translog中保留了上次commit之后到现在的数据，所以直接将translog的数据回放，即可恢复数据

和全量替换逻辑一样，优点是只有一次请求，剩下的操作都在es内部的某个shard完成

replic shard 03（Lucene实例）

deep paging问题

2 PingResponse

replic shard 01（Lucene实例）

doc 双写

1、Ping

基于doc value正排索引的聚合原理

_all metadata搜索

PUT 创建doc的时候，包含多个field，es会创建_all metadata字段，将所有field的value串联成一个字符串，同时建立倒排索引。在搜索不指定field搜索时 GET /index/type/_search?q=test会查询_all索引

排序query phase和fetch phase性能

bouncing results，不同shard排序不一致的问题

4 清空buffer

是field的type mapping决定的搜索exact value时是精准匹配，搜索full text时是全文搜索。手动和自动dynamic mapping（field元数据）1、创建index时，若没有指定mapping，es会自动根据field创建其type的mapping2、mapping中就自动定义了每个field的数据类型不同的数据类型（比如说text和date），可能有的是exact value，有的是full text3、exact value，在建立倒排索引的时候，分词的时候，是将整个值一起作为一个关键词建立到倒排索引中的；full text，会经历各种各样的处理，分词，normaliztion（时态转换，同义词转换，大小写转换），才会建立到倒排索引中4、exact value和full text类型的field就决定了，在一个搜索过来的时候，对exact value field或者是full text field进行搜索的行为也是不一样的，会跟建立倒排索引的行为保持一致；比如exact value搜索的时候，就是直接按照整个值进行匹配，full text query string，也会进行分词和normalization再去倒排索引中去搜索，以便提升recall召回率

delete文件标记删除的数据

并发控制，失败重试post /index/type/id/_update?retry_on_conflict=5

GET /test_index/test_type/_mget{ \"ids\

必须保证大部分shard是active状态才能写成功quroum =  (primary + number_of_replicas) / 2  + 1

version比较

ES documentrefresh过程

2 Ping

排序

activeNodes否满足quorum

搜索请求路由

shard = hash(routing) % number_of_primary_shards默认routing=_id 手动routing=user_id

transport module

遍历

primary shard 01（Lucene实例）

7、清空translog

加入有效ping节点列表pingResponses

partial update

replic shard 02（Lucene实例）

更新doc的部分field

排序 sort:age

document路由算法

选举masterelectMaster.electMaster(joinedOnceActiveNodes);

是否有bitset缓存？

分页查询

OS Cache

重新投票选举

3、返回结果

master宕机后，集群状态暂时变为red，会选举出新的master，若缺少replic shard时，集群状态变为yellow，恢复宕机实例后，每个primary shard都有replic shard，状态变为green

如果pingMasters列表为空个，也就是还没有选出master

写一致性consistency策略

近似聚合

node2 master eligiblenetwork.host：host2

relevance score不准确问题

5、写入commit point file（本次刷入 3 ~15 segment到磁盘）

并发控制

master（eligible）

根据每个filter使用频率，选择性的缓存bitset

1、将buffer中的数据刷入新的segment file

preference设置为user_id，打到同一个shard上修改search_type提高精准度default：query_then_fetchdfs_query_then_fetch，可以提升revelance sort精准度

PUT全量替换

2.2、传播投票结果pingResponse

排序是通过doc value

后台合并segment，提高search性能每秒一个segment file，文件过多，而且每次search都要搜索所有的segment，很耗时默认会在后台执行segment merge操作，在merge的时候，被标记为deleted的document也会被彻底物理删除每次merge操作的执行流程：（1）选择一些有相似大小的segment，merge成一个大的segment（2）将新的segment flush到磁盘上去（3）写一个新的commit point，包括了新的segment，并且排除旧的那些segment（4）将新的segment打开供搜索（5）将旧的segment删除

2、刷入

TF&IDF算法

2、doc id找到正排索引，完成聚合

index segment文件

优先查找稀疏的bitset，目的是为了缩小结果集，提高性能

写入

设定超时时间，返回各shard部分数据GET /_search?timeout=10m

1、刚启动一直寻找masterwhile循环findMaster()ping其他节点找到master为止

从第10000页开始取前10GET /test_index/test_type/_search?from=1000&size=10各节点会各自返回10010条记录给coordinator节点，coordinator节点合并30030条记录，取10000~10010的10条记录数据

1 写os cache

mget

3 fsync disk文件

写document

还未刷入os cache的内存buffer中的doc不开放搜索，1秒写入os cache才能搜索

精准匹配和全文搜索的根本原因

1、搜索文本中在field文本中出现了多少次，出现次数越多，就越相关2、搜索文本中的各个词条在整个索引的所有文档中出现了多少次，出现的次数越多，就越不相关3、Field-length norm：field越长，相关度越弱

2.1、过滤 PingResponse排除client节点和纯DataNode节点

1、不用计算relevance score2、不用进行score排名3、有caching（缓存）机制

bitset自动更新机制

写入内存buffer

id = 1 和 2 的数据

加入pingMasters列表

1 查询出doc2、PUT完整doc

如何触发一次选举当满足如下条件是，集群内就会发生一次master选举1、当前master eligible节点不是master2、当前master eligible节点与其它的节点通信无法发现master3、集群中无法连接到master的master eligible节点数量已达到 discovery.zen.minimum_master_nodes 所设定的值超半数选举出masterdiscovery.zen.minimum_master_nodes 属性设置quorum，这个属性一般设置为 eligibleNodesNum / 2 + 1如何选举当某个节点决定要进行一次选举是，它会实现如下操作1、寻找clusterStateVersion比自己高的master eligible的节点，向其发送选票2、如果clusterStatrVersion一样，则计算自己能找到的master eligible节点（包括自己）中节点id最小的一个节点，向该节点发送选举投票3、如果一个节点收到足够多的投票（即 minimum_master_nodes 的设置），并且它也向自己投票了，那么该节点成为master开始发布集群状态下面我们用一个实际的例子来解释选举流程，假设有node_a和node_b，node_a向node_b发送选票。1、如果node_b已经是master，则node_b就把node_a加入集群，之后node_b发布最新的集群状态，此时node_a会被包含在最新的集群状态里面。2、如果node_b正在进行选举，则node_b会把这次投票记录下来，之后node_b可能成为master或者继续等待选票。node_a等待node_b发送最新的集群状态或者超时触发下一次投票。3、如果node_b认为自己不会成为master，则拒绝这次投票，node_a将触发下一次投票。

1、增删改document

查询doc

如果有doc的新增和修改匹配到了缓存的filter条件，那么会自动将docId添加或更新到bitset

1 doc双写

filter查询

2、node2启动while循环findMaster()发现有可以ping通的节点

每1秒buffer刷新到一个新的segment这也是为什么ES是近实时查询NRT其实是先到os cache

乐观锁

易并行聚合算法：每个shard都可以同时计算：max不易并行：都需要将shard数据汇总到coordinator上再次计算：count(discount)近似聚合，将不易并行的算法采用近似估计的方式，提高性能，牺牲准确度

在多shard情况下，对一个字符串计算TF/IDF分数时，都是在本地shard（Lucene实例）计算的，所以同一字符串在本地shard的出现频率会直接影响relevance score，由于各shard的doc数量不同，分数也不同，但是放到大数据场景下，概率学的角度这个不准确问题可以忽略搜索附带search_type=dfs_query_then_fetch参数，会将local IDF取出来计算global IDF，但性能很差

后台线程定时删除标记deleted的doc

Master选举机制Zen discovery的unicast 机制gossip协议

Node 01

修改

（正排索引）来完成的，doc value在内存不足的情况下会存储到磁盘document    name  agedoc1              jack     33doc2               hm     23

one、all、quorum(default)

ElasticSearch集群

masterNodedataDode

3、新的segment（包含buffer中剩余所有的数据）

node1master（eligible）

删除老doc

2、根据doc id路由到对应的primary shard（若是查询请求，会使用round-robin随机轮询算法路由到replic shard上）

加入其他node选出的master

new doc 1重建索引

创建新doc

触发flush1、translog达到阈值2、定时30分钟

network.host：host1

segment写入OS cache后，就放开搜索

是否存在master？

，类似deep paging1、coordinator node和数据所在的node 全部都要创建一个priority queue，各node查询完数据后将queue返回给coordinator构建merge全局queue，然后根据from和size拿到正确的根据score排序的数据2、fetch phase，根据获取到的数据id，去mget获取实际数据

同时写入translog

宕机failover流程 

network.host：host3

version_type=external时version必须 > 当前version

bitset机制

6、fsync

根据docId查找doclist并返回