全文搜索引擎ES的读写删除过程

1、写过程

ES一般是分布式多实例部署,大概写的过程如下图:
在这里插入图片描述

1、当客户端发送一条document过来时,会随机找一个进程,被选中的进程会成为协调节点;
2、协调节点将这条document路由到指定的节点,然后写到primary节点上;
3、primary节点写完就会同步到对应的replic节点;
4、协调节点发现primary和所有replic都处理完成后,就给客户端返回处理完成;

那么真正处理数据的shard是如何写数据的呢?

1、当某个shard被选中处理数据后,首先会把数据写到buffer中,同时写入translog日志,但是这样的性能会受到影响,所以可以设置每个5秒钟写一次到磁盘,这就可能会造成5秒钟的数据丢失问题;
2、当buffer中的数据不段增多,快满时或者到一定时间,就会把buffer中的数据写入一个segment file中,此时就会对该数据建立倒排索引。但是并不是直接写入到segment file中,而是写入到os cache中。然后把buffer中的数据删除。默认每个一秒就会从buffer中写入到segment file中,一旦数据到达了os chache中就可以对外提供服务,就能搜索到了。这就是refresh过程。
3、当translog不断变大,超过一定阈值时或者过了30分钟,就会触发commit。次操作会把os cache中的数据写到segment file中,写完后把translog日志清空,这就是flush过程。
4、当segment数量不断增多后,就会执行一次merge(合并)操作,将所有的segment合并为一个,并把之前在.del中标识为删除的数据进行物理删除,在新合并的segment中就不会出现该数据。

2、查询过程

1、当客户端发送一条读请求过来时,同样会随机选择一个进程,然后将这个进程作为一个协调节点;
2、该协调节点把请求路由到指定的节点,然后根据路由规则在所有primary和replic shard中选择一个shard,从中读取。
3、然后把读取的内容返回给协调节点; 4、最后协调节点把内容返回给客户端;

3、搜索过程

1、当客户端发送一条搜索请求,同样会随机选择一个进程,然后由这个进程作为协调节点;
2、此时协调节点会在每个进程里找一个shard,然后把这条请求广播到选择的所有shard上; 3、然后每个shard返回符合条件的doc
id返回给协调节点; 4、协调节点聚合(筛选、分页、排序等)这些结果,然后再跟聚这些doc
id去各个shard去查找具体的document,最终返回给客户端;

4、删除过程

1、将删除数据写入.del文件。标识该数据已经被删除。当客户端搜索某条数据时,当这条数据在.del中时,就不会返回。

如何提高ES性能

1、从上面的分析我们可以看出一个关键点,就是cache os(system cache)数据都会缓存在此处,并且我们在操作的时候并不会把里面的数据删除。如果给这个cache预留足够的空间,就可以缓存所有的数据,这样每次搜索数据就不需要去segment file中去寻找数据,这会很慢,但是如果去cache os能直接查到数据并返回,那么将大大提升ES的性能。 那如何才能节约cache os这部分的空间呢?当写数据到ES时就要考虑到最小化数据,当一行数据有30几个字段,并不需要把所有的数据都写入到ES,只需要把关键的需要检索的几列写入。这样能够缓存的数据就会越多。 所以需要控制每台机器写入的数据最好小于等于或者略大于cache os空间最好。 如果要搜索海量数据,可以考虑用ES+Hbase架构。用Hbase存储海量数据,然后ES搜索出doc id后,再去Hbase中根据doc id查询指定的行数据。

2、数据预热
当每台机器写入的数据大于cache os太多时,导致太多的数据无法放入缓存,那么就可以把一部分热点数据刷入缓存中。
3、冷热分离
把热数据和冷数据分开,写入不同的索引里,然后确保把热索引数据刷到cache里。
4、document模型设计
在ES里最好不要用复杂的关联表的操作。当需要这样的场景时,可以在创建索引的时候,就把数据关联好。比如在mysql中需要根据关联ID查询两张表的关联数据:select A.name ,B.age from A join B where A.id = B.id,在写入ES时直接去把相关联数据放到一个document就好。
5、分页性能优化
ES分页存在这样一个问题:
当我们查找第100页的10条数据时,会存在这样的问题。ES回去每个shard去查找1000条数据,然后聚合在一起,最后去取第100页的10条数据。所以如果你通过ES分页,翻得页数越深处理的越慢。
1)不允许深度分页;
2)scroll api 会获取index的所有数据的快照,每次翻页的时候通过游标移动定位,性能会很快,但是这个API不能跳页,只能顺序翻页。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章