ElasticSearch底层原理以及优化方法

首先我们来说一下es是什么?

简单来说,ES就是一个开源的搜索引擎,也是一个分布式文档数据库,可以在极短的时间内存储、搜索和分析大量的数据。

ES有什么基本属性呢?

1、字段
	ES中,每个文档,其实是以json形式存储的。而一个文档可以被视为多个字段的集合。
2、映射
	每个类型中字段的定义称为映射。例如,name字段映射为String。
3、索引
	索引是映射类型的容器。 一个ES的索引非常像关系型世界中的数据库,是独立的大量文档集合

ES各属性对应关系数据库

关系数据库 ->   表名 ->  表结构  ->  一条记录 -> 一个字段

ES -> 索引index - 类型type(1-n) -> 映射apping  ->  文档document  -> 字段field 

ES索引简单原理: 采用倒排索引

  1. Term(单词):一段文本经过分析器分析以后就会输出一串单词,这一个一个的就叫做Term。
  2. Term Dictionary(单词字典):顾名思义,它里面维护的是Term,可以理解为Term的集合。
  3. Term Index(单词索引):为了更快的找到某个单词,我们为单词建立索引。
  4. Posting List(倒排列表):以前是根据ID查内容,倒排索引之后是根据内容查ID,然后再拿着ID去查询出来真正需要的东西。

如果类比现代汉语词典的话,那么Term就相当于词语,Term Dictionary相当于汉语词典本身,Term Index相当于词典的目录索引)

通过 单词索引找到单词在单词字典中的位置,通过单词字典进而找Posting List倒排列表,有了倒排列表就可以根据ID找到文档.

(本质:通过单词找到对应的倒排列表,根据倒排列表中的倒排项进而可以找到文档记录)

查询结果分析:

took:本次操作花费的时间,单位为毫秒。

timed_out:请求是否超时

_shards:说明本次操作共搜索了哪些分片

hits:搜索命中的记录

hits.total : 符合条件的文档总数 hits.hits :匹配度较高的前N个文档

hits.max_score:文档匹配得分,这里为最高分

_score:每个文档都有一个匹配度得分,按照降序排列。

_source:显示了文档的原始内容。

ES聚合

桶在概念上类似于 SQL 的分组(GROUP BY),而指标则类似于 COUNT() 、 SUM() 、 MAX() 等统计方法

ES分布式架构原理

shard就是ES索引存储具体数据的地方,一个索引对应多个shard

多个shard存储在不同的机器上

每个shard只放索引的一部分数据

每个shard的副本replic放在其他机器上(shard的主体primary和副本replic分开存) 保证了一定程度的高可用

ES写入数据原理:

从客户端写入到shard的全过程:

客户端随机找一个ES集群节点当作协调节点,写数据
协调节点将数据 根据doc id的哈希路由,写入分配的主shard并同步到从shard
shard将数据写入内存buffer
内存buffer每一秒钟refresh一次将数据刷进OScache缓存,一份sagementfile,一份translog日志 (translog日志的作用 有点类似于redis的RDB文件,用于ES宕机恢复数据)
OScache缓存每5秒中刷入磁盘的translog日志文件
每30分钟执行一次flush操作,执行一次commit,强制将内存buffer和OScache数据刷入新创建一个sagmentfile文件(磁盘) 落地到磁盘,多个sagementfile会有merge操作。
数据搜索主要是从OScache中拿的,所以刚写入shard的数据要一秒后才能读到。

写入一条document数据时会产生一个doc id,查的时候根据doc id进行哈希,路由到对应的shard (doc id默认随机分配,也可以手动指定,例如订单id)

ES删除数据原理:

1.把被删除数据写入.del文件(磁盘),被.del文件标识的被认为已删除

2.当sagmentfile文件过多时ES会产生merge操作,将多个segmentfile合成一个,如果.del标识了删除的数据 merge后不会产生在新的segmentfile.

ES根据doc id读取数据过程:

选ES集群的任一台机器当作协调节点

协调节点根据要查找的doc id 哈希路由到对应的节点的shard,

查到结果返还给协调节点,协调节点返还给客户端。

ES检索数据过程:

客户端发送读取请求到任一台机器当作协调节点,协调节点发送给所有机器所有shard,

每个shard都会返回结果,协调节点拿到所有shard返回的匹配的结果,再次筛选最匹配的那些document,返还给客户端.

每次查询完都会暂时将数据存入cache中,再次

ES在数据量很大的情况下如何优化查询(保证搜索性能):

主要思想:最大限度利用cache的高效率进行查询(磁盘查询效率太低)

(1) 合理利用ES+Hbase/MySQL结合来查询(Hbase对海量数据在线存储)

把重要的检索字段存成ES索引 (例如gid,订单id,订单金额,订单时间,订单说明…)

其余不作为检索条件的字段存在Hbase/Mysql

用ES根据条件快速查出gid

再用gid去Hbase/MySQL查出全部字段

(2) 数据预热

每隔一段时间将热门关键数据写个程序去查一下,主动从磁盘写入到cache中

(3) 冷热分离

水平拆分,将很热的数据单独写进一个索引,将冷数据热数据拆成两个单独索引,放在不同机器上。

(5) 单索引查,不要join多个索引查,效率非常低 (想办法导入ES的时候直接将要Join的表直接导成一个索引)

(4) 分页性能 (深度分页,性能越差)

查第100页的10条数据/第1001-1010,由于ES分布式的存储,必须去每台机器每个shard都查1000条,全部返回到协调节点,合并排序后再取出1001-1010。

解决:合理利用Scroll游标

scroll会一次性获取所有数据的快照,每次翻页通过游标移动获取下一页,分页性能大很多。、

scroll不能乱跳,只能顺序向下翻

ES生产集群部署架构

模板:每个索引的数据大概有多少,每个索引大概分多少shard

ES集群部署5台机器,每台6核64G,总内存320G,分8个shard

ES集群每天增量2000万条,大约500M,每月大约6亿条 15G数据

你可能感兴趣的:(#,Elasticsearch,elasticsearch,搜索引擎,大数据)