【ES实战】索引模块的主要配置-创新互联
- 索引模块的主要配置
- Circuit breaker
- 父级断路器
- 字段数据断路器
- 请求断路器
- In flight 的请求断路器
- 会计断路器
- 脚本编译断路器
- Fielddata
- Node Query Cache
- Indexing Buffer
- Shard request cache
- Cache invalidation
- Enabling and disabling caching
- Enabling and disabling caching per request
- Cache key
- Cache settings
- Monitoring cache usage
- Indices Recovery
- Peer recovery settings
- Expert peer recovery settings
- Search Settings
这些设置对所有index进行全局管理，而不是在每个index层面进行配置。
Circuit breaker
断路器对内存的使用设定了限制，以避免出现内存不足的异常。
Fielddata cache
对内存中Fielddata缓存所使用的堆的数量设置限制。
Node query cache
配置用于缓存查询结果的堆积量。
Indexing buffer
控制分配给索引写入过程的缓冲区的大小。
Shard request cache
控制分片级请求缓存的行为。
Recovery
控制分片恢复过程中的资源限制。
Search Settings
控制全局搜索设置。
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。
正在传输的请求断路器允许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个。
字段数据缓存主要在对字段进行排序或计算聚合时使用。它将所有字段的值加载到内存中，以便提供基于文档的对这些值的快速访问。为一个字段建立字段数据缓存可能很昂贵，所以建议有足够的内存来分配它，并保持它的加载。
用于字段数据缓存的内存量可以用indices.fielddata.cache.size来控制。注意：重新加载不适合你的缓存的字段数据将是昂贵的，而且性能很差。
indices.fielddata.cache.size静态配置
字段数据缓存的大值，例如节点堆空间的30%，或者一个绝对值，例如12GB。默认为unbounded，不限制。
query cache负责对查询结果进行缓存。每个节点有一个查询缓存，由所有分片共享。缓存实现了LRU驱逐策略：当缓存变满时，最近使用最少的数据被驱逐，以便为新数据让路。被缓存的内容无法查看。
查询缓存只缓存在过滤器上下文中使用的查询。
必须在集群中的每个数据节点上进行配置。
indices.queries.cache.size静态配置控制过滤器缓存的内存大小，默认为
10%。接受一个百分比值，如5%，或一个精确的值，如512mb。
索引级别的配置，可以在每个索引的基础上进行配置。
index.queries.cache.enabled控制是否启用查询缓存。值为
true（默认）或false。
索引缓冲区用于存储新索引的文件。当它填满时，缓冲区中的文件被写入磁盘上的一个段。它被分发到节点上的所有分片中。
下面的设置是静态的，必须在集群中的每个数据节点上进行配置。
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。
当针对一个索引或许多索引运行搜索请求时，每个参与的分片在本地执行搜索，并将其本地结果返回给协调节点，后者将这些分片级的结果合并为一个 "全局"结果集。
分片级请求缓存模块将本地结果缓存在每个分区内。这使得经常使用的（和潜在的大量）搜索请求几乎可以立即返回结果。请求缓存非常适用于日志的使用情况，在这种情况下，只有最近的索引被主动更新–来自较早索引的结果将直接从缓存中提供。
Cache invalidation缓存很聪明–它保持了与未缓存搜索相同的近实时承诺。
每当分片区刷新时，缓存的结果就会自动失效，但只有当分片区的数据确实发生了变化。换句话说，你从缓存中得到的结果总是与未缓存的搜索请求相同。
刷新间隔时间越长，缓存条目保持有效的时间就越长。如果缓存已满，最近使用最少的缓存键将被驱逐。
缓存可以通过[clear-cacheAPI]手动过期。
curl -X POST "localhost:9200/kimchy,elasticsearch/_cache/clear?request=true&pretty"缓存在默认情况下是启用的，但在创建新的索引时可以禁用，方法如下:
curl -X PUT "localhost:9200/my_index?pretty" -H 'Content-Type: application/json' -d'
{
"settings": {
"index.requests.cache.enable": false
}
}
'它也可以通过[update-settingsAPI]在一个现有的索引上动态地启用或禁用。
curl -X PUT "localhost:9200/my_index/_settings?pretty" -H 'Content-Type: application/json' -d'
{ "index.requests.cache.enable": true }
'Therequest_cachequery-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参数。
整个JSON主体被用作缓存密钥。这意味着，如果JSON发生变化–例如，如果键以不同的顺序输出–那么缓存键将无法被识别。
大多数JSON库支持规范模式，确保JSON键总是以相同的顺序排放。这种规范模式可以在应用程序中使用，以确保请求总是以相同的方式被序列化。
Cache settings缓存是在节点级别管理的，默认的大大小为堆的1%。这可以在config/elasticsearch.yml文件中修改。
indices.requests.cache.size: 2%另外，你可以使用indices.requests.cache.expire设置来指定缓存结果的TTL，但应该没有理由这样做。记住，当索引被刷新时，过期的结果会自动失效。这个设置仅仅是为了完整起见而提供的。
缓存的大小（以字节为单位）和驱逐的数量可以通过索引查看，使用[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"对等恢复（Peer recovery）将数据从一个主分片同步到一个新的或现有的分片副本。
在Elasticsearch中，对等恢复会自动发生。
- 重新创建一个在节点故障中丢失的分片
- 由于集群的重新平衡或对分片分配设置的改变，将一个分片重新定位到另一个节点上
你可以使用cat recovery API查看正在进行和已经完成的恢复的列表。
Peer recovery settingsindices.recovery.max_bytes_per_sec([动态])限制每个节点的入站和出站恢复总流量。默认为
40mb。此限制只适用于节点。如果集群中的多个节点同时执行恢复，集群的总恢复流量可能会超过这个限制。如果这个限制太高，正在进行的恢复可能会消耗过多的带宽和其他资源，这可能会破坏集群的稳定。
你可以使用以下专家设置来管理对等恢复的资源。
indices.recovery.max_concurrent_file_chunks（[动态], Expert）每次恢复时并行发送的文件块请求的数量。默认为
2。当单个分片的恢复没有达到indices.recovery.max_bytes_per_sec设置的流量限制时，你可以增加这个设置值。
可以设置以下专家*设置来管理全局搜索限制。
indices.query.bool.max_clause_countDefaults to
1024.
这个设置限制了Lucene BooleanQuery的子句数量。默认的1024是相当高的，通常应该是足够的。这个限制不仅影响Elasticsearch的bool查询，而且许多其他查询在内部被改写为Lucene的BooleanQuery。这个限制的存在是为了防止搜索变得过大，占用过多的CPU和内存。如果你考虑增加这个设置，请确保你用尽了所有其他的选项，以避免不得不这样做。更高的值可能导致性能下降和内存问题，特别是在高负载或资源少的集群中。
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
文章标题：【ES实战】索引模块的主要配置-创新互联
本文网址：http://scyanting.com/article/eeddi.html
