ElasticSearch原理总结

ES原理总结

—ES写数据:
ES里写的流程,有四个底层的核心概念:refresh、flush、translog、merge

—ES读数据的过程

查询—GET到某一条数据
(1)可以通过 doc id 来查询,会根据 doc id 进行 hash,判断出来当时把 doc id 分配到了哪个 shard 上面去,从那个 shard 去查询。
(2)客户端发送请求到任意一个 node,成为 coordinate node 。
(3)coordinate node 对 doc id 进行哈希路由,将请求转发到对应的 node,此时会使用 round-robin 随机轮询算法,在 primary shard 以及其所有 replica 中随机选择一个,让读请求负载均衡。
(4)接收请求的 node 返回 document 给 coordinate node 。
(5)coordinate node 返回 document 给客户端。

—搜索 全文检索
客户端发送请求到协调节点
协调节点将搜索请求转发到所有的shard对应的primary shard 或 replica shard ,都可以。

query phase:每个 shard 将自己的搜索结果(其实就是一些 doc id )返回给协调节点,由协调节点进行数据的合并、排序、分页等操作,产出最终结果。

fetch phase:接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据,最终返回给客户端。

–ES在数据量很大的情况下如何提高查询效率

(1)性能优化的杀手锏 – filesystem cache
减少数据量仅仅放要用于搜索的几个关键词即可,尽量写入的数据跟es机器的filesystem cache是差不多的就可以了。

(2)数据预热
把搜索频率比较高的数据定时放到filesystem cache中。

(3)冷热分离
做类似mysql的水平拆分,就是将大量的访问很少,单独写一个索引,然后将很频繁热数据单独写一个索引,频繁热数据全部放到缓存中,冷数据放到磁盘上。

(4)document模型设计
设计es中的数据模型

(5)分页的性能优化

a、不允许深度分页(默认深度分页性能很差)
b、类似于app中的不断一页一页的,不能挑选页跳转,也可以用 search_after 来做, search_after 的思想是使用前一页的结果来帮助检索下一页的数据
可以用scroll api

简单介绍下生产环境es集群的架构情况

(1)es生产集群部署了5台数据,每台机器是6核64G的,集群总内存是320G
(2)es集群的日增量数据大概是2000万条数据,每天日增量数据大概是500MB,每月增量数据大概是6亿15G,系统已经几个月,大概数据总量是100G左右。
(3)目前线上大概是有5个索引。每个索引的数据量大概是20G,所以这个数据量之内,每个索引分配的是8个shard,比默认的5个shard多个3个shard。

你可能感兴趣的:(ElasticSearch,elasticsearch)