一、ES基于_version 进行乐观锁并发控制

post /index/type/id/_update?retry_on_conflict=5&version=6

1.内部版本号

第一次创建document的version版本号为1，以后每次对这个document修改或删除操作，version自动加1。

同时带上数据的版本号，确保es中数据的版本号，跟客户端中的数据的版本号是相同的，才能修改。

可以指定更新失败之后的重试次数：retry_on_conflict，版本冲突时重试次数

## 2.external version

可以基于你自己维护的一个版本号来进行并发控制。举个列子，加入你的数据在mysql里也有一份，然后你的应用系统本身就维护了一个版本号，无论是什么自己生成的，程序控制的。这个时候，你进行乐观锁并发控制的时候，可能并不是想要用es内部的_version来进行控制，而是用你自己维护的那个version来进行控制。

 

二、document路由原理

1.路由算法

 

2.决定document在哪个shard上，最主要的就是routing的值，默认是id，也可以手动指定。

3.这就是primary shard 不可变的原因

 

三、写一致性原理

put /index/type/id?consistency=quorum

1.one

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

2.all

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

3.quorun

默认

要求我所有的shard中，大部分的都是活跃可用的，才可以执行。 （1个节点除外）

算法

 

说明：当number_of_replica>1时才生效。quorun不齐全时默认等待一分钟，可设置timeout=100ms, timeout=30ms, timeout=1m

 

四、增删的内部原理

1.客户端选择一个节点发送请求，这个节点叫做coordinnating node（协调节点）

2.coordinate node 对document进行路由，将请求发送给对应的node，（有primary node 的节点）

3.实际的node的primary shard 处理请求，然后将数据同步到replica node。

4.coordinate node 如果发现所有的node（primary 和 replica） 都完成操作之后，就返回响应结果给客户端

 

五、document 写入机制原理

  1. 数据写入内存buffer缓冲和translog日志文件
  2. 每隔一秒钟，buffer中的数据被写入新的segment file，并进入os cache，此时segment被打开并供search使用
  3. buffer被清空
  4. 重复1~3，新的segment不断添加，buffer不断被清空，而translog中的数据不断累加
  5. 当translog长度达到一定程度的时候，commit操作发生
  1. buffer中的所有数据写入一个新的segment，并写入os cache，打开供使用
  2. buffer被清空
  3. 一个commit ponit被写入磁盘，标明了所有的index segment
  4. filesystem cache中的所有index segment file缓存数据，被fsync强行刷到磁盘上
  5. 现有的translog被清空，创建一个新的translog

 

注意点：

每秒一个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删除

POST /my_index/_optimize?max_num_segments=1，尽量不要手动执行，让它自动默认执行就可以了

 

近实时：

数据写入os cache，并被打开供搜索的过程，叫做refresh，默认是每隔1秒refresh一次。也就是说，每隔一秒就会将buffer中的数据写入一个新的index segment file，先写入os cache中。所以，es是近实时的，数据写入到可以被搜索，默认是1秒。

手动refresh：

PUT /my_index
 {
   "settings": {
     "refresh_interval": "30s" 
   }
 }

多个term对一个doc的总分数，计算出一个query vector（向量）每个doc vector计算出对query vector的弧度，最后基于这个弧度给出一个doc相对于query中多个term的总分数弧度越大，分数越底; 弧度越小，分数越高如果是多个term，那么就是线性代数来计算，无法用图表示

2.vector space model

一个term在一个doc中，出现的次数越多，那么最后给的相关度评分就会越高IDF：inversed document frequency一个term在所有的doc中，出现的次数越多，那么最后给的相关度评分就会越低length normhello搜索的那个field的长度，field长度越长，给的相关度评分越低; 最后，会将hello这个term，对doc1的分数，综合TF，IDF，length norm，计算出来一个综合性的分数

TF: term frequency

1.TF/IDF

十一、TF/IDF算法

 

  • 每次都要重新构建整个索引

倒排索引不可变的坏处

  • 不需要锁，提升并发能力，避免锁的问题
  • 数据不变，一直保存在os cache中，只要cache内存足够
  • filter cache一直驻留在内存，因为数据不变
  • 可以压缩，节省cpu和io开销

倒排索引不可变的好处

  • 包含这个关键词的document list
  • 包含这个关键词的所有document的数量：IDF（inverse document frequency）
  • 这个关键词在每个document中出现的次数：TF（term frequency）
  • 这个关键词在这个document中的次序
  • 每个document的长度：length norm
  • 包含这个关键词的所有document的平均长度

2. 倒排索引的结构

...

1. 倒排示例

九、倒排索引

  1. preference决定了哪些shard会被用来执行搜索操作
  2. 两个document排序，field值相同；不同的shard上，可能排序不同；每次请求轮询打到不同的replica shard上；
  3. 每次页面上看到的搜索结果的排序都不一样，这就是bouncing result，也就是跳跃的结果。
  4. 解决方案就是将preference设置为一个字符串，比如说user_id，让每个user每次搜索的时候，都使用同一个replica shard去执行，就不会看到bouncing results了

八、结果跳跃

 

  1. 为每个在倒排索引中搜索到的结果，构建一个bitset，如[0, 0, 0, 1, 0, 1]
  2. 过滤器不对文档打分——仅仅是包含或者拒绝。如果文档匹配了一个过滤器，则在bitset中会置成1；否则置为0.于是ES就可以在一个紧致的bitset中存储整个分段的过滤信息。
  3. 遍历每个过滤条件对应的bitset，优先从最稀疏的开始搜索，查找满足所有filter条件的document，直到bitset遍历完caching bitset
  4. 跟踪query，在最近256个query中超过一定次数的过滤条件，缓存其bitset。对于小segment（<1000，或<3%），不缓存bitset。
  5. 如果document有新增或修改，那么cached bitset会被自动更新

七、filter执行原理

 

特殊情况：document如果还在建立索引过程中，可能只有primary shard有，任何一个replica shard都没有，此时可能会导致无法读取到document，但是document完成索引建立之后，primary shard和replica shard就都有了

  1. 客户端发送请求到任意一个node，成为coordinate node
  2. oordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡
  3. 接收请求的node返回document给coordinate node
  4. coordinate node返回document给客户端

 

六、查询的内部原理

 

即使是一粒尘土，我也要漫天飞舞