Elasticsearch 缓存原理

一. 数据预加载

Elasticsearch在启动时会打开并读取硬盘上的部分index segment文件，并缓存数据至内存中，后续的搜索操作都会在内存中进行。如果待搜索的数据不在内存中，则会打开相应的index segment文件，并读取数据至内存。这种预加载的做法有助于提高Elasticsearch对外提供服务的响应速度，毕竟减少了打开index semgent的IO操作次数。

有两种方案能设置预加载中需要打开的segment文件:

1. 【全局配置】 在config/elasticsearch.yml中添加index.store.preload，这是一个数组，里面存放了需要预加载的文件的后缀。后缀的类别和含义如下:
   1. nvd: 该文件中存储了影响相关度分数的因素。
   2. dvd: 存储了文档的数据。
   3. tim: 文档字典。
   4. doc: 发布清单
   5. dim: 点数据
      支持通配符*，如果写成["*"]，则可以将所有的数据全部缓存到内存。

index.store.preload: ["nvd", "dvd"]

2. 【局部配置】在创建index时，指定该index需要预加载的文件。注意，不得在创建完index后更新(新增)index.store.preload，否则报错:
   Can’t update non dynamic settings… index.store.preload属于静态配置。

PUT /my_index
{
  "settings": {
    "index.store.preload": ["nvd", "dvd"]
  }
}

有些人尝到甜头后，打算在预加载时尽可能的把热门数据放到内存中，但值得注意的是，数据预加载也有其缺陷。如果预加载的数据量过大，比如几乎占满了服务器分配给Elasticsearch的最大堆内存，而后续进行冷门数据搜索时，搜索的内容恰好不在内存中，则不得不从Disk上打开index segment，此时为了避免内存溢出，ES会丢弃一部分旧的数据，断开部分index_segement文件的IO流，腾出空间存储新的数据，那么热门数据就丢失了。而热门数据的查询概率比冷门数据大得多，导致后续搜索数据时，需要进行更多的IO操作，这样反而得不偿失。

二. 缓存

Elasticsearch的缓存主要分成三类: Node Query Cache, Shard Query Cache, Fielddata Cache。 尚未写完…