ES数十亿数据量级的场景下如何优化查询性能？

Z时代
2024-01-10
分类：综合

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 智能一页一页往后翻，天然适合微博，往下拉的时候。