ElasticSearch 搜索性能调优

#提供更多的内存给文件系统缓存 ES 的查询速度非常依赖于文件系统缓存，一般情况下，你应该确保分配一半的系统内存给 ES，这样它能够把热数据都放到内存里面

#使用更快的硬件如果你的查询是高 I/O 的话，你应该给更多的内存用以缓存或者买更好的设备，SSD 是一个非常不错的选择，尽量使用本地文件系统而不是 NFS 和 SMB。虚拟存储也最好避开。虽然 ES 在虚拟存储上跑也没什么问题，但是始终还是没物理设备好。另外如果你的查询对 CPU 要求高的话，你应该买更快的 CPU

#良好的文档模型建立一个比较合适实际使用常见的模型，避免 join 的出现。join 操作会比父子关系操作慢几倍。

#预索引数据

也就是索引进去的时候为后续的查询做点预处理的事情啦，不过这个。。好取巧的感觉。例如，有一份文档

PUT index/type/1
{ "designation": "spoon", "price": 13
}

查询是对 price 进行范围聚合

GET index/_search
{ "aggs": { "price_ranges": { "range": { "field": "price", "ranges": [ { "to": 10 }, { "from": 10, "to": 100 }, { "from": 100 } ] } } }
}

那为了提高查询速度，我们可以做一些预处理

PUT index
{ "mappings": { "type": { "properties": { "price_range": { "type": "keyword"
        }
      }
    }
  }
}

索引的数据也放多一个属性，用作后面的聚合

PUT index/type/1
{ "designation": "spoon", "price": 13, "price_range": "10-100"
}

查询语句就变成这样了

GET index/_search
{ "aggs": { "price_ranges": { "terms": { "field": "price_range"
      }
    }
  }
}

#Mapping 有些数值类型的字段不一定需要数值类型来存，这种内容可以 mapped 成 keyword 而不是数值型

#避免使用脚本尽量少使用脚本，需要的话使用 painless

#使用开始和结束时间来搜索结果使用日期字段来搜索的时候，使用 now 作为结束时间，ES 基本上是不会缓存的，因为这个时间总是在变。而使用一个指定的时间则好的多，例如

PUT index/type/1
{ "my_date": "2016-05-11T16:30:55.328Z"
} GET index/_search
{ "query": { "constant_score": { "filter": { "range": { "my_date": { "gte": "now-1h", "lte": "now"
          }
        }
      }
    }
  }
}

最好替换成

GET index/_search
{ "query": { "constant_score": { "filter": { "range": { "my_date": { "gte": "now-1h/m", "lte": "now/m"
          }
        }
      }
    }
  }
}

我们把时间转成了分钟，假如当前时间是 16:31:29 那么过滤条件就是 15:31:00 到 16:31:59 假如有多个用户同时在查的话，那么这个缓存就可以被利用上了

#对只读索引进行强制段合并把只读索引强制段合并成一个索引，例如时序的索引

#预热 global ordinals Global ordinals 是一个用于在 keyword 类型上做 term agg 的数据结构，它是延迟加载的，因为它不知道哪些字段会被用作 terms agg，所以你可以让它进行适当的预热

PUT index
{ "mappings": { "type": { "properties": { "foo": { "type": "keyword", "eager_global_ordinals": true
        }
      }
    }
  }
}

#预热文件系统缓存如果 ES 重启了，文件系统缓存也会被清空，所以你可以使用 index.store.preload 来告诉 ES 要预先加载哪些数据。如果你的缓存不够多但是又预加载了很多数据的话，反倒会使得 ES 变慢