@[TOC](搜索（查询）性能优化
为文件系统缓存提供更多内存
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
{
"mappings": {
"_doc": {
"properties": {
"name_and_plot": {
"type": "text"
},
"name": {
"type": "text",
"copy_to": "name_and_plot"
},
"plot": {
"type": "text",
"copy_to": "name_and_plot"
}
}
}
}
}预索引数据
您应该在查询中利用模式来优化数据的索引方式。例如，如果您的所有文档都有一个price字段，并且大多数查询range在固定的范围列表上运行 聚合，则可以通过将范围预索引到索引中并使用terms来加快聚合速度。
考虑将标识映射为keyword
某些数据是数字这一事实并不意味着它应该始终映射为 数字字段。Elasticsearch 索引数字的方式针对range查询进行了优化，而keyword字段更适合term查询。通常，字段排序标识，例如ISBN或任何来自于其他数据库的数字化的标识，很少被用于range查询或聚合。这就是为什么它们可能会受益于被映射为 askeyword而不是integer或 long。
避免使用脚本
一般来说，应该避免使用脚本。如果绝对需要它们，您应该更喜欢painless和expressions引擎。
搜索四舍五入的日期
在日期字段上使用now查询通常不可缓存，因为匹配的范围一直在变化。但是，从用户体验的角度来看，切换到舍入日期通常是可以接受的，并且可以更好地利用查询缓存。
强制merger只读索引
只读索引将受益于 合并为单个段。这通常是基于时间的索引的情况：只有当前时间范围的索引正在获取新文档，而旧索引是只读的。
预加载全局序数
全局序数是一种数据结构，用于在keyword字段上运行 terms聚合。它们被延迟加载到内存中，因为 Elasticsearch 不知道哪些字段将用于terms聚合，哪些字段不会。您可以通过如下所述配置映射来告诉 Elasticsearch 在refresh时加载全局序数：
PUT index
{
"mappings": {
"_doc": {
"properties": {
"foo": {
"type": "keyword",
"eager_global_ordinals": true
}
}
}
}
}预加载文件系统缓存
如果重新启动运行 Elasticsearch 的机器，文件系统缓存将是空的，因此操作系统将索引的热点区域加载到内存中需要一些时间，以便快速搜索操作。您可以根据使用index.store.preload设置的文件扩展名明确告诉操作系统哪些文件应该立即加载到内存中 。
使用索引排序来加速关联查询
索引排序以轻微降低写入数据速度来加速关联查询
使用preference来优化缓存利用率
有多种缓存可以帮助提高搜索性能，例如 文件系统缓存、 请求缓存或查询缓存。然而，所有这些缓存都在节点级别维护，这意味着如果您连续两次运行相同的请求，有 1 个或更多副本并使用round-robin，默认路由算法，那么这两个请求将转到不同的分片副本，防止节点级缓存提供帮助。
由于搜索应用程序的用户通常会一个接一个地运行类似的请求，例如为了分析索引的更窄子集，使用识别当前用户或会话的偏好值可以帮助优化缓存的使用。
副本可能有助于提高吞吐量，但并非总是如此
除了提高弹性之外，副本还可以帮助提高吞吐量。例如，如果您有一个单分片索引和三个节点，则需要将副本数设置为 2，以便总共拥有 3 个分片副本，以便利用所有节点。
现在假设您有一个 2 分片索引和两个节点。在一种情况下，副本数为 0，这意味着每个节点拥有一个分片。在第二种情况下，副本数为 1，这意味着每个节点有两个分片。哪种设置在搜索性能方面表现最佳？通常，每个节点总共具有较少分片的设置会表现得更好。这样做的原因是它为每个分片提供了更大的可用文件系统缓存份额，而文件系统缓存可能是 Elasticsearch 的第一大性能因素。同时，请注意没有副本的设置在单个节点故障的情况下会失败，因此在吞吐量和可用性之间进行权衡。
那么正确的副本数量是多少？如果您的集群包含 num_nodes节点和num_primaries主分片，并且您希望max_failures最多同时处理节点故障，那么适合您的副本数量是 max(max_failures, ceil(num_nodes / num_primaries) - 1).
