美文网首页
ElasticSearch底层原理探秘

ElasticSearch底层原理探秘

作者: timothyue1 | 来源:发表于2018-09-20 14:35 被阅读0次

    一、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

    相关文章

      网友评论

          本文标题:ElasticSearch底层原理探秘

          本文链接:https://www.haomeiwen.com/subject/fafnnftx.html