本文主要讨论es加载速度的优化。
网络中大部分的性能优化方案基本源于官网，如下位置:

官网查询速度优化建议

1. 文档进行建模

避免使用nested和parent child类型
尽量先计算再将计算结果存储进es
尽量使用filter context查询
结合profile explain api分析查询慢的问题
严禁使用*开头的terms查询
谨慎使用通配符匹配和agg聚合

2. 定期对不再更新的索引做force merge

段数目太多会带来较大的麻烦。
1.消耗资源：每一个段都会消耗文件句柄、内存和cpu运行周期；
2.搜索变慢：每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢

段合并的时候会将那些旧的已删除文档从文件系统中清除。
被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。
forcemerge非常耗时！对read only索引进行merge。

设置merge时最大的线程数：
index.merge.scheduler.max_thread_count。
固态硬盘——默认最大值 Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))
机械磁盘——设置为1

1.运行merge任务

POST /test/_forcemerge?max_num_segments=1//每个分片一个段

注：可以从10-5-1逐步将段合并到1个，防止一次合并任务占用资源时间过长
2.查看merge情况

GET /_cat/indices/?s=segmentsCount:desc&v&h=index,segmentsCount,segmentsMemory,memoryTotal,mergesCurrent,mergesCurrentDocs,storeSize,p,r

3. 自定义路由机制Routing

默认会将文档的ID值作为依据将其哈希到相应的主分片上，这种算法基本上会保持所有数据在所有分片上的一个平均分布，而不会产生数据热点。
指定Routing：告诉Elasticsearch我们的数据存哪个分片上，查询的时候指定某个分片查询，这样还有一个好处就是聚合结果会准确。

4. Query cache相关设置

查看cache：

curl 'localhost:9200/<indexname>/_stats/query_cache?pretty&human'
curl 'localhost:9200/_nodes/stats/indices/query_cache?pretty&human'

返回结果：
memory_size
（字节值）跨分配给节点的所有分片用于查询缓存的内存总量。
memory_size_in_bytes
（整数）用于分 配给该节点的所有分片上的查询缓存的内存总量（以字节为单位）。
total_count
（整数）查询缓存中的命中，未命中和缓存的查询的总数。
hit_count
（整数）查询缓存命中数。
miss_count
（整数）查询高速缓存未命中的数量。
cache_size
（整数）查询缓存的大小（以字节为单位）。
cache_count
（整数）查询缓存中的查询计数。
evictions
（整数）查询缓存逐出的数量。

5. 打开自适应副本

应打开自适应副本选择。该请求将被重定向到响应最快的节点。当存在多个数据副本时，elasticsearch可以使用一组称为自适应副本选择的标准，根据包含每个分片副本的节点的响应时间，服务时间和队列大小来选择数据的最佳副本。这样可以提高查询吞吐量并减少搜索量大的应用程序的延迟。
这个配置默认是关闭的，实战打开方法：

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.use_adaptive_replica_selection": true
  }
}