ES性能调优权威指南（篇二）

原文链接： https://qbox.io/blog/elasticsearch-performance-tuning-part-2-zen

ES性能调优权威指南（篇二）

注：本文是ES性能调优权威指南三篇中的第二篇，第一篇翻译参考这里http://blog.youkuaiyun.com/kimichen123/article/details/77477812。

如果我们使用ES做主要搜索，或者我们组织搜索是面向用户的特征，我们应该监视查询延迟，并在超过阈值的情况下采取行动。

Zen发现

    Zen发现是ES状态改变时使用的算法。它可以坐主节点选举、故障检测、集群状态维护和发布。它是ES集群发现和通信的默认机制。另外Azure,EC2和GCE还有其他的发现机制。

    ES是基于P2P的，如果操作被代理/广播那么节点之间就会直接通信。索引的主API（索引、删除、搜索）不会与主节点通信。主节点的责任是管理全局集群状态，并通过重新分配分片来执行节点加入或离开集群。每当集群状态发生变化时，集群中的其他节点会被通知新的状态。

    cluster.name允许建立隔离的集群。默认的集群名是elasticsearch，建议更改它以反映集群的逻辑组名称。

    在0.x和1.x版本都支持单播和多播，多播是默认设置。这两个版本要使用单播或者禁用多播，我们可以设置 discovery.zen.ping.multicast.enabled 为false。从2.0版本单播是Zen发现的唯一选择。

    数据节点和主节点通过两种不同的方式去侦察对方：

    1、Ping -它是一个节点使用发现机制发现其他节点的过程，主节点通过ping集群中所有的其他节点以验证其是否正在运行。

     2、单播-单播发现需要一个主角列表来使用它作为绯闻路由器。可以设置discovery.zen.ping.unicast.hosts

为数组或者逗号分隔。节点也会ping主节 点以验证它们是否已启动并运行，或者是否需要启动一个选举过程。

    Zen发现配置可以使用Cluster Update Settings API更新：

主节点选举

    discovery.zen.ping_timeout （默认3s）允许调整选举时间来应对缓慢或者拥挤的网络环境（更高的值以降低失败可能）。一旦一个节点加入，它将向主节点发送一个默认为ping（discovery.zen.join_timeout）超时时间20倍的加入请求。如果网络较慢，就把值设大一些。值越大，发现失败的可能就越小。

    如果discovery.zen.master_election.filter_client是true，主节点选举期间客户端的ping会被忽略；这个设置默认是true；如果discovery.zen.master_election.filter_data是true，非主候选节点（node.data为ture，node.master为false的节点）在选举期间会被忽略；默认值为false。

    discovery.zen.minimum_master_nodes 控制一个节点应该“看到”的候选主节点的最小数量。当集群运行炒个两个节点时建

错误检测

   有两个错误检测进程正在运行。第一种是主节点ping集群中的所有其他节点，并验证它们是否存在。另外每个节点都要对ping主节点，以验证其是否仍然存在，或者是否需要启动一个选举过程。

以下以 discovery.zen.fd 为前缀的设置可以改变错误检测过程:

• ping_interval -  节点ping的频率，默认是1s.

• ping_timeout - 等待ping的响应时间，默认是 30s.

• ping_retries - 多少次失败/超时判断为节点失败，默认是3.

通知所有节点集群变更

    主节点是集群中唯一可以对集群状态进行更改的节点。主节点一次处理一个集群状态更新，应用必要的更改，并将更新后的集群状态发布到集群中的所有其他节点。每个节点接收已发布的消息，更新它自己的集群状态，并对主节点进行应答，主节点等待所有节点响应，直到超时，然后继续处理队列中的下一个更新。discovery.zen.publish_timeout默认设置为30 seconds，可以通过集群更新设置api动态更改。

无存活主节点

discovery.zen.no_master_block设置控制在无存活主节点时应该拒绝哪些操作。discovery.zen.no_master_block设置有两个有效选项:

1. all - 该节点的所有操作—包括读写—都会被拒绝。

2. write - 写操作会拒绝 (默认)。基于最后一个已知的集群配置的读取操作可以执行。

基础的  ES   discovery.zen  配置如下：

discovery.zen.fd.ping_timeout: 10sdiscovery.zen.minimum_master_nodes: 2
Discovery.zen.ping.unicast.hosts: ["master_node_01″,"master_node_02″,"master_node_03″]

discovery.zen.fd.ping_timeout表明节点超时时间是10秒。单播主机是 "master_node_01 ","master_node_02", "master_node_03"。此外，完成一个选举至少需要两个主节点加入，并让当选的节点作为主控节点。我们有3个主节点。

允许Doc Values 或者列存储压缩

    对字段排序时，ES需要访问每一个匹配查询的文档的值。倒排索引在搜索时表现得很好，但它不是对字段值进行排序的理想结构:

    当搜索时,我们需要能够将词匹配到文档列表，但是在排序和聚合时或者脚本访问字段时，我们需要匹配文档的词。换言之，我们需要 ”uninvert“倒排索引。这个“uninverted” 结构往往称为”column-store“，并将单个字段的所有值存储在一个单独的数据列中，这样就可以非常高效地进行排序之类的操作。

    Doc values是磁盘数据结构，在索引文档时就创建使得数据访问模式成为可能。他们存储类似_source的值，但是一种更易于排序和聚合的面向列的方式。

参考 - Kubernetes Series: Understanding Why Container Architecture is Important to the Future of Your Business

    Doc values支持除analyzed  string的所有字段类型。Doc values在索引生成，同时创建了倒排索引。这意味着Doc values是在每个段上生成的并且不可变的，就像用于搜索的倒排索引一样。而且与倒排索引一样，doc values被序列号到磁盘。这对性能和伸缩性来说至关重要。

    在磁盘上序列话持久数据，我们可以依靠操作系统的文件系统缓存管理内存，而不是在JVM堆上保留结构。当数据的“工作集”小于可用内存的情况下，操作系统将自然地将doc values保存在内存中。这提供了与堆数据结构相同的性能。

    但是当工作集大于可用内存时，操作系统按需对doc values页换出换入。这显然比纯内存结构更慢，但是它的优点是伸缩性远远超过了服务器的内存容量。如果这些数据结构完全在堆中，那么唯一的选择便是OutOfMemory （或者像操作系统一样实现页）。

    支持doc values的字段默认是开启的。我们我们确认不需要排序或聚合或者通过script访问字段，为了节约磁盘空间可以禁用doc values。

    设置doc_values: false以禁用doc values。例如我创建了一个新索引，其中"user_id"字段禁止doc values。设置doc_values: false使得该字段不能用于聚合、排序或者scripits。

curl -XPUT localhost:9200/my_index -d '{
  "mappings": {
    "my_type": {
      "properties": {
        "user_id": {
          "type": "string",
          "index": "not_analyzed",
          "doc_values": false 
        }
      }
    }
  }
}'

也可以通过配置反向配置：通过doc values为字段提供聚合，但是禁用倒排索引使其无法搜索。例如以下是启用聚合但是索引是禁用的，使得字段无法被查询或者搜索。

curl -XPUT localhost:9200/my_index -d'{
  "mappings": {
    "my_type": {
      "properties": {
        "user_id": {
          "type": "string",
          "index": "not_analyzed",
          "doc_values": true, 
          "index": "no" 
        }
      }
    }
  }
}'

ES在以下情形下应使用doc values:

• 字段排序；

• 字段聚合；

• 特定过滤器 (例如 geolocation filters)；

• fields使用了Scripts。

禁止、小心DELETE_all

    删除索引API允许删除存在的索引。

curl -XDELETE 'localhost:9200/index_one/'

    上例删除了索引名为index_one的索引。指定索引、别名或者通配符是必须的。删除API适用于通过逗号分隔列表的多个索引，或者使用_all or *删除所有索引（慎用）。

参考: Why Is the Supergiant Packing Algorithm Unique? How Does It Save Me Money?

    为了禁止使用通配符或者_all删除索引，可以设置action.destructive_requires_name为true。这个设置也可通过集群更新设置API改变。更新的设置可以是永久的（适用于重启）也可以是临时的（重启时无效）。以下是实例：

    永久更新：

curl -XPUT localhost:9200/_cluster/settings -d '{
    "persistent" : {
        "action.destructive_requires_name" : true
    }
}'

    临时更新：

curl -XPUT localhost:9200/_cluster/settings -d '{
    "transient" : {
        "action.destructive_requires_name" : true
    }
}'

    集群会返回更新后的配置，上一个请求的返回结果是：

{
    "persistent" : {},
    "transient" : {
        "action.destructive_requires_name" : "true"
    }
}'

    集群设置返回：

curl -XGET localhost:9200/_cluster/settings

Transient cluster settings take precedence over persistent cluster settings, which take precedence over settings configured in the elasticsearch.yml config file. For this reason it is preferable to use the elasticsearch.yml file only for local configurations, and set all cluster-wider settings with the settings API.

    临时集群设置优于永久集群设置，这些设置优于在elasticsearch.yml中的设置配置。由于该原因 elasticsearch.yml 适合本地配置，而使用settings API设置集群的设置。

    

禁用或最小化刷新映射请求到主节点

    如果在字段映射中频繁更改或将新字段添加到索引中，那么ES集群可能会被大量的refresh_mappings 请求所淹没。这并不是很重要，但是它可以影响集群的性能。这个问题在2.0版本之前更常见。

    配置参数可以这样使用（/etc/elasticsearch.yml）：

  indices.cluster.send_refresh_mapping: false

    这是什么?它是如果工作的？

    当一个节点在处理索引请求时检测到一个新字段时它将更新自己的映射，并将映射发送到主节点。当主节点发送下一个集群状态时，新的映射可能仍然存在于主的等待任务队列中。在这种情况下，数据节点将接收到映射的“旧”版本。

    尽管这是一个冲突，但并不是很差：集群最终会有一个正确的mapping。 就数据节点而言，主节点拥有较早版本的映射，因此向主节点发送一个刷新映射请求。

    如果一个系统更新映射十分频繁，这会产生惊人的部落效应，因此禁用这个功能是有意义的。indices.cluster.send_refresh_mapping 允许我们禁止这种敏感行为，从而消除数据节点到主节点的刷新映射请求。即使没有配置 send_refresh_mapping ，主节点最终也会看到原始的映射变更并发送一个更新后的集群状态。

    注意，当发生相反情况时，发送刷新映射十分重要。由于某种原因，主节点和存在索引的实际节点相比处于领先或者冲突，在这种情况下，刷新映射将在主节点上记录警告。