【ES实战】索引模块的主要配置

索引模块的主要配置

这些设置对所有index进行全局管理，而不是在每个index层面进行配置。

• Circuit breaker

  断路器对内存的使用设定了限制，以避免出现内存不足的异常。

• Fielddata cache

  对内存中Fielddata缓存所使用的堆的数量设置限制。

• Node query cache

  配置用于缓存查询结果的堆积量。

• Indexing buffer

  控制分配给索引写入过程的缓冲区的大小。

• Shard request cache

  控制分片级请求缓存的行为。

• Recovery

  控制分片恢复过程中的资源限制。

• Search Settings

  控制全局搜索设置。

Circuit breaker

Elasticsearch包含多个断路器，用于防止操作导致OutOfMemoryError。每个断路器都规定了它可以使用的内存数量的限制。此外，还有一个父级断路器，规定了所有断路器可使用的内存总量。以下为动态配置。

父级断路器

indices.breaker.total.limit，父级断路器的起始限制，默认为JVM堆的70%。

字段数据断路器

字段数据断路器允许Elasticsearch估计一个字段加载到内存中所需要的内存量。然后，它可以通过引发一个异常来阻止字段数据的加载。默认情况下，该限制被配置为最大JVM堆的60%。它可以通过以下参数进行配置。

indices.breaker.fielddata.limit：对Fieldddata断路器的限制，默认为JVM堆的60%。

indices.breaker.fielddata.overhead：感觉是因素值，指一个常数，所有的字段数据估计都与之相乘，以确定最终的估计值。默认为1.03。

请求断路器

请求断路器允许Elasticsearch防止每个请求的数据结构（例如，在请求期间用于计算聚合的内存）超过一定的内存量。

indices.breaker.request.limit：对请求断路器的限制，默认为JVM堆的60%。

indices.breaker.request.overhead：感觉是因素值，指一个常数，所有的请求估计都与之相乘，以确定最终的估计值。默认为1。

In flight 的请求断路器

正在传输的请求断路器允许Elasticsearch限制传输或HTTP级别上所有当前活动的传入请求的内存使用，避免超过一个节点上的特定内存量。内存使用情况取决于请求本身的内容长度。

network.breaker.inflight_requests.limit：正在传输的请求断路器的限制, 默认为JVM堆的100%. 这意味着它受到为上级断路器配置的限制的约束。

network.breaker.inflight_requests.overhead：感觉是因素值，指一个常数，所有的正在传输的请求估计都与之相乘，以确定最终的估计值。默认为1。

会计断路器

会计断路器允许Elasticsearch限制内存中的东西的使用，这些东西在请求完成后不会被释放。这包括像Lucene段内存这样的东西。

indices.breaker.accounting.limit：会计断路器的限制, 默认为JVM堆的100%. 这意味着它受到为上级断路器配置的限制的约束。

indices.breaker.accounting.overhead：感觉是因素值，指一个常数，所有的会计断路器估计都与之相乘，以确定最终的估计值。默认为1。

脚本编译断路器

与之前基于内存的断路器略有不同，脚本编译断路器限制了一段时间内内联脚本编译的数量。

script.max_compilations_rate：在一定的时间间隔内，允许编译的独特动态脚本的数量限制。默认为75/5m，即每5分钟75个。

Fielddata

字段数据缓存主要在对字段进行排序或计算聚合时使用。它将所有字段的值加载到内存中，以便提供基于文档的对这些值的快速访问。为一个字段建立字段数据缓存可能很昂贵，所以建议有足够的内存来分配它，并保持它的加载。

用于字段数据缓存的内存量可以用indices.fielddata.cache.size来控制。注意：重新加载不适合你的缓存的字段数据将是昂贵的，而且性能很差。

indices.fielddata.cache.size 静态配置

字段数据缓存的最大值，例如节点堆空间的30%，或者一个绝对值，例如12GB。默认为unbounded，不限制。

Node Query Cache

query cache负责对查询结果进行缓存。每个节点有一个查询缓存，由所有分片共享。缓存实现了LRU驱逐策略：当缓存变满时，最近使用最少的数据被驱逐，以便为新数据让路。被缓存的内容无法查看。

查询缓存只缓存在过滤器上下文中使用的查询。

必须在集群中的每个数据节点上进行配置。

• indices.queries.cache.size 静态配置

  控制过滤器缓存的内存大小，默认为10%。接受一个百分比值，如5%，或一个精确的值，如512mb。

索引级别的配置，可以在每个索引的基础上进行配置。

• index.queries.cache.enabled

  控制是否启用查询缓存。值为true（默认）或false。

Indexing Buffer

索引缓冲区用于存储新索引的文件。当它填满时，缓冲区中的文件被写入磁盘上的一个段。它被分发到节点上的所有分片中。

下面的设置是静态的，必须在集群中的每个数据节点上进行配置。

• indices.memory.index_buffer_size

  值为一个百分比或一个字节大小的值。它默认为 10%，意味着分配给节点的总堆的 10%将被用作所有分片共享的索引缓冲区大小。

• indices.memory.min_index_buffer_size

  如果index_buffer_size被指定为一个百分比，那么这个设置可以用来指定一个绝对最小值。默认为48mb。

• indices.memory.max_index_buffer_size

  如果index_buffer_size被指定为一个百分比，那么这个设置可以用来指定一个绝对的最大值。默认值为unbounded。

Shard request cache

当针对一个索引或许多索引运行搜索请求时，每个参与的分片在本地执行搜索，并将其本地结果返回给协调节点，后者将这些分片级的结果合并为一个 "全局"结果集。

分片级请求缓存模块将本地结果缓存在每个分区内。这使得经常使用的（和潜在的大量）搜索请求几乎可以立即返回结果。请求缓存非常适用于日志的使用情况，在这种情况下，只有最近的索引被主动更新–来自较早索引的结果将直接从缓存中提供。

Cache invalidation

缓存很聪明–它保持了与未缓存搜索相同的近实时承诺。

每当分片区刷新时，缓存的结果就会自动失效，但只有当分片区的数据确实发生了变化。换句话说，你从缓存中得到的结果总是与未缓存的搜索请求相同。

刷新间隔时间越长，缓存条目保持有效的时间就越长。如果缓存已满，最近使用最少的缓存键将被驱逐。

缓存可以通过[clear-cache API]手动过期。

curl -X POST "localhost:9200/kimchy,elasticsearch/_cache/clear?request=true&pretty"

Enabling and disabling caching

缓存在默认情况下是启用的，但在创建新的索引时可以禁用，方法如下:

curl -X PUT "localhost:9200/my_index?pretty" -H 'Content-Type: application/json' -d'
{
  "settings": {
    "index.requests.cache.enable": false
  }
}
'

它也可以通过[update-settings API]在一个现有的索引上动态地启用或禁用。

curl -X PUT "localhost:9200/my_index/_settings?pretty" -H 'Content-Type: application/json' -d'
{ "index.requests.cache.enable": true }
'

Enabling and disabling caching per request

The request_cache query-string parameter can be used to enable or disable caching on a per-request basis. If set, it overrides the index-level setting:

request_cache查询字符串参数可以用来启用或禁用per-request的缓存。如果设置，它将覆盖索引级的设置。

curl -X GET "localhost:9200/my_index/_search?request_cache=true&pretty" -H 'Content-Type: application/json' -d'
{
  "size": 0,
  "aggs": {
    "popular_colors": {
      "terms": {
        "field": "colors"
      }
    }
  }
}
'

如果你的查询使用了一个结果不确定的脚本（例如，它使用了一个随机函数或引用了当前时间），你应该把request_cache标志设置为false，以禁止对该请求进行缓存。

即使在索引设置中启用了请求缓存，size大于0的请求也不会被缓存。为了缓存这些请求，你需要使用这里详述的query-string参数。

Cache key

整个JSON主体被用作缓存密钥。这意味着，如果JSON发生变化–例如，如果键以不同的顺序输出–那么缓存键将无法被识别。

大多数JSON库支持规范模式，确保JSON键总是以相同的顺序排放。这种规范模式可以在应用程序中使用，以确保请求总是以相同的方式被序列化。

Cache settings

缓存是在节点级别管理的，默认的最大大小为堆的1%。这可以在config/elasticsearch.yml文件中修改。

indices.requests.cache.size: 2%

另外，你可以使用indices.requests.cache.expire设置来指定缓存结果的TTL，但应该没有理由这样做。记住，当索引被刷新时，过期的结果会自动失效。这个设置仅仅是为了完整起见而提供的。

Monitoring cache usage

缓存的大小（以字节为单位）和驱逐的数量可以通过索引查看，使用[indices-stats]API。

curl -X GET "localhost:9200/_stats/request_cache?human&pretty"

或用[nodes-stats]API按节点进行统计。。

curl -X GET "localhost:9200/_nodes/stats/indices/request_cache?human&pretty"

Indices Recovery

对等恢复（Peer recovery）将数据从一个主分片同步到一个新的或现有的分片副本。

在Elasticsearch中，对等恢复会自动发生。

• 重新创建一个在节点故障中丢失的分片
• 由于集群的重新平衡或对分片分配设置的改变，将一个分片重新定位到另一个节点上

你可以使用cat recovery API查看正在进行和已经完成的恢复的列表。

Peer recovery settings

• indices.recovery.max_bytes_per_sec ([动态])

  限制每个节点的入站和出站恢复总流量。默认为40mb。此限制只适用于节点。如果集群中的多个节点同时执行恢复，集群的总恢复流量可能会超过这个限制。如果这个限制太高，正在进行的恢复可能会消耗过多的带宽和其他资源，这可能会破坏集群的稳定。

Expert peer recovery settings

你可以使用以下专家设置来管理对等恢复的资源。

• indices.recovery.max_concurrent_file_chunks（[动态], Expert）

  每次恢复时并行发送的文件块请求的数量。默认为2。当单个分片的恢复没有达到indices.recovery.max_bytes_per_sec设置的流量限制时，你可以增加这个设置值。

Search Settings

可以设置以下专家*设置来管理全局搜索限制。

• indices.query.bool.max_clause_count

  Defaults to 1024.

这个设置限制了Lucene BooleanQuery的子句数量。默认的1024是相当高的，通常应该是足够的。这个限制不仅影响Elasticsearch的bool查询，而且许多其他查询在内部被改写为Lucene的BooleanQuery。这个限制的存在是为了防止搜索变得过大，占用过多的CPU和内存。如果你考虑增加这个设置，请确保你用尽了所有其他的选项，以避免不得不这样做。更高的值可能导致性能下降和内存问题，特别是在高负载或资源少的集群中。