Elasticsearch如何做到亿级数据查询毫秒级返回？

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

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

性能优化的杀手锏：Filesystem Cache

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

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

性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能绝对是秒级别的，1 秒、5 秒、10 秒。

如果是走 Filesystem Cache，是走纯内存的，那么一般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。

归根结底，你要让 ES 性能好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半。

一般是建议用 ES + HBase 这么一个架构。

        HBase 的特点是适用于海量数据的在线存储，就是对 HBase 可以写入海量数据，但是不要做复杂的搜索，做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。

数据预热

        对于那些你觉得比较热的、经常会有人访问的数据，最好做一个专门的缓存预热子系统。就是对热数据每隔一段时间，就提前访问一下，让数据进入 Filesystem Cache 里面去。这样下次别人访问的时候，性能一定会好很多。

冷热分离

        ES 可以做类似于 MySQL 的水平拆分，就是说将大量的访问很少、频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引,最好是将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在 Filesystem OS Cache 里，别让冷数据给冲刷掉。

Document模型设计

        Document 模型设计是非常重要的，很多操作，不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。另外对于一些太复杂的操作，比如 join/nested/parent-child 搜索都要尽量避免，性能都很差的。

分页性能优化

    可以用 Scroll API，关于如何使用，自行上网搜索。

Scroll 会一次性给你生成所有数据的一个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动，获取下一页、下一页这样子，性能会比上面说的那种分页性能要高很多很多，基本上都是毫秒级的。

所以现在很多产品，都是不允许你随意翻页的，App，也有一些网站，做的就是你只能往下拉，一页一页的翻。初始化时必须指定 Scroll 参数，告诉 ES 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。

除了用 Scroll API，你也可以用 search_after 来做。search_after 的思想是使用前一页的结果来帮助检索下一页的数据。显然，这种方式也不允许你随意翻页，你只能一页页往后翻。初始化时，需要使用一个唯一值的字段作为 Sort 字段。

参考：https://mp.weixin.qq.com/s/JXpKf7bjiPkIU11EqcJEMw