Elasticsearch搜索（查询）性能优化

为文件系统缓存提供更多内存

Elasticsearch 严重依赖文件系统缓存来加快搜索速度。通常，您应该确保至少有一半的可用内存进入文件系统缓存，以便 Elasticsearch 可以将索引的热点区域保留在物理内存中。

Elasticsearch的搜索严重依赖于底层的 filesystem cache，你如果给 filesystem cache 更多的内存，尽量让内存可以容纳所有的 idx segment file 索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。

如果内存不够，可以只将被搜索的字段放入Elasticsearch中，全部数据放于其他集群或者其他类型数据库，然后依据搜索结果中的id值，去查询全量数据。

使用更快的硬件

更快的CPU，更大的内存，更快的硬盘（SSD）

数据预热

在文件系统缓存空间不足的情况下，可以定时访问热点数据，以防缓存失效

冷热分离

热数据通常只占总体数据的一小部分，分离之后，热数据很可能都在文件系统缓存中。

分页查询性能优化

不允许深度分页，深度分页性能很差。可以使用scroll 或 search after。

scroll 会一次性给你生成所有数据的一个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动，获取下一页。缺点是无法跳转至任何一页，只能一页接着一页翻。scroll会消费大量资源，不建议用于实时查询。

初始化时必须指定 scroll 超时参数， 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。

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

文档建模

应该对文档进行建模，以便搜索时间操作尽可能短。

尤其应该避免连接。nested可以使查询慢几倍，父子关系可以使查询慢数百倍。因此，如果可以通过非规范化文档在没有连接的情况下回答相同的问题，则可以预期显着的加速。

搜索尽可能少的字段

query_string或 multi_match查询目标的字段越多，速度越慢。提高多个字段搜索速度的常用技术是在索引时将它们的值复制到单个字段中，然后在搜索时使用该字段。这可以通过copy-to映射指令自动化，而无需更改文档源。下面是一个包含电影的索引示例，该索引通过将两个值都索引到name_and_plot 字段中来优化搜索电影的名称和情节的查询。

PUT movies
{