Elasticsearch

Elasticsearch

Scroll Down

一、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.路由算法
$$
shard = hash(routing)\ %\ number_of_primary_shards
$$
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_replias = int((primary + number_of_replicas) / 2 + 1) + 1
$$
**说明:**当number_of_replica>1时才生效。quorun不齐全时默认等待一分钟,可设置timeout=100ms, timeout=30ms, timeout=1m

四、增删的内部原理

1.客户端选择一个节点发送请求,这个节点叫做coordinating 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" 
	}
}

六、查询的内部原理

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

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

七、filter执行原理

  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会被自动更新

八、结果跳跃

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

九、倒排索引

1. 倒排示例

...

2. 倒排索引的结构

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

倒排索引不可变的好处

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

倒排索引不可变的坏处

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

十一、TF/IDF算法

1.TF/IDF

TF: term frequency

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

2.vector space model

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