ES数十亿数据量级的场景下如何优化查询性能 | strongant的个人博客
source link: https://baiwenhui.com/2020/02/03/ES%E6%95%B0%E5%8D%81%E4%BA%BF%E6%95%B0%E6%8D%AE%E9%87%8F%E7%BA%A7%E7%9A%84%E5%9C%BA%E6%99%AF%E4%B8%8B%E5%A6%82%E4%BD%95%E4%BC%98%E5%8C%96%E6%9F%A5%E8%AF%A2%E6%80%A7%E8%83%BD/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
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 智能一页一页往后翻，天然适合微博，往下拉的时候。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK