Elastic Search相关

es 怎么解决查询慢的问题?

1、只存关键数据,其他数据存入hbase,查询的时候根据id 查询一批数据,然后根据id的范围去hbase中查询,效率会相当高。

2、因为es有一个file system cache ,第一次查询数据时,其实是去磁盘读,然后刷进缓存的,所以缓存要存热点数据,内存容量有限,,我们可以先预热一下,比如后台有一个刷到缓存的数据进程,,这样每次查询都会去缓存中查询。。

倒排索引?

字典表(内存中 hash表形式存储)

倒排列表 磁盘中以跳表的形式存储(链表+索引的形式)

es 写数据过程:

1、写数据过程

  1. 客户端通过hash选择一个node发送请求,这个node被称做coordinating node(协调节点),

  2. 协调节点对docmount进行路由,将请求转发给到对应的primary shard

  3. primary shard 处理请求,将数据同步到所有的replica shard

  4. 此时协调节点,发现primary shard 和所有的replica shard都处理完之后,就反馈给客户端。

2、写数据的底层原理

  1. 在到达primary shard的时候 ,数据先写入内存buffer , 此时,在buffer里的数据是不会被搜索到的同时生成一个translog日志文件 , 将数据写入translog里

  2. 如果内存buffer空间快man满了,就会将数据refresh到一个新的segment file文件中,而且es里每隔1s就会将buffer里的数据写入到一个新的segment file中,这个segment file就存储最最近1s中buffer写入的数据,如果buffer里面没有数据,就不会执行refresh操作,当建立segment file文件的时候,就同时建立好了倒排索引库

  3. 在buffer refresh到segment之前 ,会先进入到一个叫os cache中,只要被执行了refresh操作,就代表这个数据可以被搜索到了。数据被输入os cache中,buffer就会被清空了,所以为什么叫es是准实时的?NRT,near real-time,准实时。默认是每隔1秒refresh一次的,所以es是准实时的,因为写入的数据1秒之后才能被看到。还可以通过es的restful api或者java api,手动执行一次refresh操作,就是手动将buffer中的数据刷入os cache中,让数据立马就可以被搜索到。

  4. 就这样新的数据不断进入buffer和translog,不断将buffer数据写入一个又一个新的segment file中去,每次refresh完buffer清空,translog保留。随着这个过程推进,translog会变得越来越大。当translog达到一定长度的时候,就会触发commit操作。translog也是先进入os cache中,然后每隔5s持久化到translog到磁盘中,

  5. commit操作,第一步,就是将buffer中现有数据refresh到os cache中去,清空buffer 每隔30分钟flush

  6. es也有可能会数据丢失 ,有5s的数据停留在buffer、translog os cache, segment file os cache中,有5s的数据不在磁盘上,如果此时宕机,这5s的数据就会丢失,如果项目要求比较高,不能丢失数据,就可以设置参数,每次写入一条数据写入buffer,同时写入translog磁盘文件中,但这样做会使es的性能降低。

  7. 如果是删除操作,commit操作的时候就会生成一个.del文件,将这个document标识为deleted状态,在搜索的搜索的时候就不会被搜索到了。

  8. 如果是更新操作,就是将原来的document标识为deleted状态,然后新写入一条数据

  9. buffer每次refresh一次,就会产生一个segment file,所以默认情况下是1秒钟一个segment file,segment file会越来越多,当躲到一定程度的时候,es就会自动触发merge(合并)造作,将所有segment file文件 merge成一个segment file,并同时物理删除掉标识为deleted的doc,

3、es读取过程

  1. 客户端发送get请求到任意一个node节点,然后这个节点就称为协调节点,

  2. 协调节点对document进行路由,将请求转发到对应的node,此时会使用随机轮询算法,在primary shard 和replica shard中随机选择一个,让读取请求负载均衡,

  3. 接收请求的node返回document给协调节点,

  4. 协调节点,返回document给到客户端

4、 搜索过程

  1. 客户端发送请求到协调节点,

  2. 协调节点将请求大宋到所有的shard对应的primary shard或replica shard ;

  3. 每个shard将自己搜索到的结果返回给协调节点,返回的结果是dou.id或者自己自定义id,然后协调节点对数据进行合并排序操作,最终得到结果。

  4. 最后协调节点根据id到个shard上拉取实际 的document数据,左后返回给客户端。

es 怎么保证高可用?

index -> type -> mapping -> document -> field

类比Mysql:

index:类比mysql里的一张表

type:类比Hibernate 中多个同类Class同时映射到一个表中的情境,type就是各个Class。index里可以有多个type。

mapping:类比Hibernate的映射。这个type的表结构的定义,定义了这个type中每个字段名称,字段是什么类型的,然后还有这个字段的各种配置

document:类比表中的一条条记录。

field: 类比一条记录的各个字段。

 

shard

一个索引,这个索引可以拆分成多个shard,每个shard存储部分数据。

这个shard的数据实际是有多个备份,就是说每个shard都有一个primary shard,负责写入数据,但是还有几个replica shard。

primary shard写入数据之后,会将数据同步到其他几个replica shard上去。

 

Master

es集群多个节点,会自动选举一个节点为master节点。

这个master节点其实就是干一些管理的工作的,比如维护索引元数据拉,负责切换primary shard和replica shard身份 之类的。

要是master节点宕机了,那么会重新选举一个节点为master节点。

 如果是非master节点宕机了,那么会由master节点,让那个宕机节点上的primary shard的身份转移到其他机器上的replica shard。

急着你要是修复了那个宕机机器,重启了之后,master节点会控制将缺失的replica shard分配过去,同步后续修改的数据之类的,让集群恢复正常

Elastic Search相关

 

上一篇:Logstash接收Kafka数据写入至ES


下一篇:使用 WebView2 封装一个生成 PDF 的 WPF 控件