Elasticsearch性能优化指南（十）
使用近似聚合
近似聚合以牺牲少量的精确度为代价，大幅提高了执行效率，降低了内存使用。近似聚合的使用方式可以参考官方手册
深度优化还是广度优先
ES有两种不同的聚合方式：深度优先和广度优先。深度优先是默认设置，先构建完整的树，然后修剪无用节点。大多数情况下深度聚合都能正常工作，但是有些特殊的场景更适合广度优先，先执行第一层聚合，再继续下一层聚合之前会先做修剪，官方例子：https：／／www．elastic．co／guide／cn／elasticsearch／guide／current／＿preventing＿combinatorial＿explosions．html。
限制搜索请求分片数
一个搜索请求涉及的分片数量越多，协调节点的CPU和内存压力就越大。默认情况下，ES会拒绝超过1000个分片的搜索请求。我们应该更好地组织数据，让搜索请求的分片数更少。如果想调节这个值，则可以通过action．search．shard＿count配置项进行修改。虽然限制搜索的分片数并不能直接提升单个搜索请求的速度，但协调节点的压力会间接影响搜索速度，例如，占用更多内存会产生更多的GC压力，可能导致更多的stop－the－world时间等，因此间接影响了协调节点的性能
利用自适应副本选择ARS提升ES响应速度
为了充分利用计算资源和负载均衡，协调节点将搜索请求轮询转发到分片的每个副本，轮询策略是负载均衡过程中最简单的策略，任何一个负载均衡器都具备这种基础的策略，缺点是不考虑后端实际系统压力和健康水平。
ES希望这个过程足够智能，能够将请求路由到其他数据副本，直到该节点恢复到足以处理更多搜索请求的程度。在ES中，此过程称为“自适应副本选择”。
搜索尽可能少的字段
query＿string或multi＿match查询目标的字段越多，它的速度就越慢。提高多个字段搜索速度的常用技术是在索引时间将其值复制到单个字段中，然后在搜索时使用此字段。可以使用映射的“copy＿to”指令来自动执行此操作，而不必更改文档的来源。
PUT movies｛＂mappings＂： ｛＂properties＂： ｛＂name＿and＿plot＂： ｛＂type＂： ＂text＂ ｝，＂name＂： ｛＂type＂： ＂text＂，＂copy＿to＂： ＂name＿and＿plot＂ ｝，＂plot＂： ｛＂type＂： ＂text＂，＂copy＿to＂： ＂name＿and＿plot＂ ｝ ｝ ｝｝
避免脚本
如果可能，请避免在搜索中使用脚本或脚本字段。由于脚本无法利用索引结构，因此在搜索查询中使用脚本会导致搜索速度降低。
如果您经常使用脚本来转换索引数据，则可以通过在摄取期间进行这些更改来加快搜索速度。但是，这通常意味着较慢的索引速度。
如果一定要用，则应该优先考虑painless和expressions。
预热文件系统缓存
如果重新启动运行Elasticsearch的计算机，则文件系统缓存将为空，因此，操作系统需要一些时间才能将索引的热区加载到内存中，以便快速进行搜索操作。您可以使用index．store．preload设置明确告诉操作系统哪些文件应该预先地加载到内存中，具体取决于文件扩展名。
如果文件系统高速缓存的大小不足以容纳所有数据，则将索引过多或文件过多的数据预加载到文件系统高速缓存中，会使搜索速度变慢。请谨慎使用。
使用索引排序以加快连接速度
索引排序可能有用，以便使连接更快，但以稍微慢一些的索引写入为代价。索引排序文档 index sorting documentation．
使用preference优化缓存利用率
有多个可以帮助提高搜索性能的缓存，例如文件系统缓存，请求缓存或查询缓存。但是所有这些缓存都在节点级别维护，这意味着如果您连续两次运行相同的请求，具有一个或多个副本，并使用默认路由算法“轮询”，则这两个请求将转到不同的分片副本 ，节点级缓存不起作用。
由于搜索应用程序的用户通常会依次运行类似的请求（例如为了分析索引的较窄子集），因此使用标识当前用户或会话的preference值可以帮助优化缓存的使用。
