ES 客户端读取数据的流程

客户端 -> shard -> filesystem cache -> 磁盘文件

海量数据检索查询性能优化思路

 

如果内存足够大, filesystem cache 会缓存,如果查询走filesystem cache 则速度耗时在毫秒级别,如果查询请求走磁盘文件,则最少查询耗时都在秒级别。

如果整个磁盘上索引数据文件在3台机器上,一共占用了1T的磁盘容量,ES数据量是1T,每台机器的数据量是300G。ES性能最佳情况,你的机器内存至少可以容纳总数据量的一半。

生产环境试验,最好用ES存储少量的数据,用来搜索的那些索引,内存留给filesystem cache , 100G。数据量控制在100G以内,相当于查询的数据几乎全部走内存来搜索,性能非常高,几乎搜索结果在1秒以内就可以出结果。

另外还有注意的一点,就是在ES中真正存储的记录字段都应该是你需要查询的字段,不应该把整条记录中的所有字段都放在ES中,如果全部字段都放到ES中,则会导致你机器的filesystem chche 占据空间很大,很多记录其实查询都要走硬盘文件,这样会导致查询性能会很低。

数据预热

后台系统自动搜索一下热数据,提前让数据加载到filesystem cache 中,当客户端查询时,直接从 filesystem cache中找到,性能非常高。

冷热分离

 

类似于MySQL的冷热分离,将大量访问不频繁的数据放到单独的一个索引。将查询频繁的放到一个索引,提高查询的性能。

模型设计

写入索引的时候,就将关联的数据直接写入进去,不要在搜索的时候进行join,因为ES中的复杂查询都很耗费性能。

分页查询

分布式的,查100页的10条数据,必须从每个shard,都查询一批数据过来,然后拿过来在内存里面分页,页翻得越深,基本查询性能很差。

优化策略:

1.不允许深度分页

2.类似于下拉分页的话,可以使用 scroll api 进行查询。它的分页原理,会一次性生成快照,然后通过游标一次一次往下翻,无论翻多少页,性能就是毫秒级的,scroll 智能一页一页往后翻,天然适合微博,往下拉的时候。