亿级数据毫秒级查询，ElasticSearch是怎么做到的？

目录：

1. 一道面试题的引入：

2. 性能优化的杀手锏：Filesystem Cache

3. 数据预热

4. 冷热分离

5. ElasticSearch 中的关联查询

6. Document 模型设计

7. 分页性能优化

一道面试题的引入：

如果面试的时候碰到这样一个面试题：ElasticSearch（以下简称ES） 在数据量很大的情况下（数十亿级别）如何提高查询效率？

这个问题说白了，就是看你有没有实际用过 ES，因为啥？其实 ES 性能并没有你想象中那么好的。

很多时候数据量大了，特别是有几亿条数据的时候，可能你会懵逼的发现，跑个搜索怎么一下 5~10s，坑爹了。

第一次搜索的时候，是 5~10s，后面反而就快了，可能就几百毫秒。

然后你就很懵，每个用户第一次访问都会比较慢，比较卡么？所以你要是没玩儿过 ES，或者就是自己玩玩儿 Demo，被问到这个问题容易懵逼，显示出你对 ES 确实玩的不怎么样？

说实话，ES 性能优化是没有银弹的。啥意思呢？就是不要期待着随手调一个参数，就可以万能的应对所有的性能慢的场景。

也许有的场景是你换个参数，或者调整一下语法，就可以搞定，但是绝对不是所有场景都可以这样。

性能优化的杀手锏：Filesystem Cache

你往 ES 里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 Filesystem Cache 里面去。

整个过程，如下图所示：

ES 的搜索引擎严重依赖于底层的 Filesystem Cache，你如果给 Filesystem Cache 更多的内存，尽量让内存可以容纳所有的 IDX Segment File 索引数据文件，那么你搜索的时候就基本都是走内存的&#x