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


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

内部_version版本号

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

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

 retry_on_conflict,版本冲突时重试次数。

external version



二、document路由原理


①路由算法:shard = hash(routing) % number_of_primary_shards

②决定一个document在哪个shard上,最重要的一个值就是routing值,默认是_id,也可手动指定,相同的routing值,每次过来,从hash函数中,产出的hash值一定是相同的

 例:手动指定一个routing value,比如 put /index/type/id?routing=user_id

③这就是primary shard数量不可变的原因。


三、写一致性原理


put /index/type/id?consistency=quorum

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

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

quorum(默认):默认的值,要求所有的shard中,必须是大部分的shard都是活跃的,可用的,才可以执行这个写操作(1个节点例外)

算法:number_of_replicas = int((primary + number_of_replicas) / 2 ) + 1,当number_of_replicas>1时才生效

quorum不齐全时,默认等待1分钟,可设置timeout=100ms,timeout=30s,timeout=1m


四、增删改内部原理


①客户端选择一个节点发送请求,这个节点叫coordinating node(协调节点)

②coordinating node,对document进行路由,将请求转发给对应的node(有primary shard)

③实际的node上的primary shard处理请求,然后将数据同步到replica node

④coordinating node,如果发现primary node和所有replica node都完成操作之后,就返回响应结果给客户端


五、document写入机制原理


①数据写入内存buffer缓冲和translog日志文件

②每隔一秒钟,buffer中的数据被写入新的segment file,并进入os cache,此时segment被打开并供search使用

③buffer被清空

④重复1~3,新的segment不断添加,buffer不断被清空,而translog中的数据不断累加

⑤当translog长度达到一定程度的时候,commit操作发生

(5-1)buffer中的所有数据写入一个新的segment,并写入os cache,打开供使用

(5-2)buffer被清空

(5-3)一个commit ponit被写入磁盘,标明了所有的index segment

(5-4)filesystem cache中的所有index segment file缓存数据,被fsync强行刷到磁盘上

(5-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" 
   }
 }


①客户端发送请求到任意一个node,成为coordinate node

②coordinate node对document进行路由,将请求转发到对应的node,此时会使用round-robin随机轮询算法,在primary shard以及其所有replica中随机选择一个,让读请求负载均衡

③接收请求的node返回document给coordinate node

④coordinate node返回document给客户端

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


七、filter执行原理


为每个在倒排索引中搜索到的结果,构建一个bitset,如[0, 0, 0, 1, 0, 1]

遍历每个过滤条件对应的bitset,优先从最稀疏的开始搜索,查找满足所有filter条件的document,直到bitset遍历完

caching bitset,跟踪query,在最近256个query中超过一定次数的过滤条件,缓存其bitset。对于小segment(<1000,或<3%),不缓存bitset。

如果document有新增或修改,那么cached bitset会被自动更新


八、结果跳跃(Bouncing Results)


preference决定了哪些shard会被用来执行搜索操作

两个document排序,field值相同;不同的shard上,可能排序不同;每次请求轮询打到不同的replica shard上;

每次页面上看到的搜索结果的排序都不一样,这就是bouncing result,也就是跳跃的结果。

解决方案就是将preference设置为一个字符串,比如说user_id,让每个user每次搜索的时候,都使用同一个replica shard去执行,就不会看到bouncing results了


九、倒排索引


1.倒排示例

doc1:I really liked my small dogs, and I think my mom also liked them.

doc2:He never liked any dogs, so I hope that my mom will not expect me to liked him.

倒排索引的建立:

word doc1 doc2



I * *

really *

like * * liked --> like

my * *

little * small --> little

dog * * dogs --> dog

and *

think *

mom * *

also *

them *

He *

never *

any *

so *

hope *

that *

will *

not *

expect *

me *

to *

him *



搜索:mother like little dog

结果:doc1和doc2,都会搜索出来


2.倒排索引的结构

①包含这个关键词的document list

②包含这个关键词的所有document的数量:IDF(inverse document frequency)

③这个关键词在每个document中出现的次数:TF(term frequency)

④这个关键词在这个document中的次序

⑤每个document的长度:length norm

⑥包含这个关键词的所有document的平均长度

3.倒排索引不可变的好处

①不需要锁,提升并发能力,避免锁的问题

②数据不变,一直保存在os cache中,只要cache内存足够

③filter cache一直驻留在内存,因为数据不变

④可以压缩,节省cpu和io开销

4.倒排索引不可变的坏处

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


十、正排索引(待续)



十一、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,那么就是线性代数来计算,无法用图表示