一、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
可以基于你自己维护的一个版本号来进行并发控制。举个列子，加入你的数据在mysql里也有一份，然后你的应用系统本身就维护了一个版本号，无论是什么自己生成的，程序控制的。这个时候，你进行乐观锁并发控制的时候，可能并不是想要用es内部的_version来进行控制，而是用你自己维护的那个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，那么就是线性代数来计算，无法用图表示
转自：https://blog.csdn.net/zhou870498/article/details/80516692
