• static

仅可在创建时或关闭时更改

• dynamic

可热更新，通过api

PUT /twitter/_settings
{
    "index" : {
        "number_of_replicas" : 2
    }
}

Static Index Settings

• index.number_of_shards:

索引的shard分片数量。默认值1.可在索引关闭时更新。最大值1024.可通过集群节点中的以下属性开启。

export ES_JAVA_OPTS="-Des.index.max_number_of_shards=128" 

• refresh_interval

内存索引缓冲区的文件被刷到segment中的时间。这段数据会被写入到es的Translog中，可以被检索到，但是尚未刷到磁盘中。Es默认值是1s,这迫使es集群每秒创建一个segment段，增加这个值，可以允许segment更大，并减小以后的segment合并压力。

PUT /twitter/_settings
{
    "index" : {
        "refresh_interval" : "-1"
    }
}

要对后续所有的索引有效，则创建一个默认模板

PUT /_template/template_log"
{
    "index_patterns" : ["filebeat*"],
    "order" : 0,
    "settings" : {
        "number_of_replicas" : 0
    }
}

• index.load_fixed_bitset_filters_eagerly

嵌套查询结果的缓存预加载。默认为true。

摘自《深入理解Elasticsearch》2.4.3
通常，过滤器都会非常快，因为filter不需要处理文档得分。而执行嵌套查询时所使用bitsets默认提前就加载好了。这样做的目的是嵌套查询执行的更快。使用过滤器时，过滤结果不依赖于查询，因此过滤结果可以被轻易的缓存起来供后续查询使用，并且每个lucene索引段都有一个过滤结果缓存。这以为着不需要在每次commit时重建缓存，重建操作只发生在段生成和合并。依赖于时间的过滤器缓存将没有任何意义。基于地理位置的场景同样命中率极低。
转载https://yq.aliyun.com/articles/109629/

• index.shard.check_on_startup

启动时检查所有shard. 检查分片是否有损坏，如果检查到损坏，将阻止分片打开。

false
checksum
true

• index.codec

索引的压缩格式。默认使用LZ4.可以设置为best_compression.以使用DEFLATE开启更高压缩比例。占用更少的内存空间。

Dynamic Index Settings

• index.number_of_replicas

数据备份数。默认1.插入索引调优重点项。使用bulk size更新索引，可将该值设置为0，即不备份，加快插入速度。

PUT /twitter/_settings
{
    "index" : {
        "number_of_replicas" : "0"
    }
}

• index.max_inner_result_window

限制inner-hits的嵌套文档数量。

• index.max_result_window

分页窗口。默认值10000.超过该值请使用Scroll 或Search After API. 默认使用from + size的情况下的索引

• index.max_docvalue_fields_search

单词查询中允许的最大数量的docvalue_fields.默认100

• index.analyze.max_token_count

分词器可以产生的最大词干数量。默认值10000。

• index.max_slices_per_scroll

滚动可以使用的最大切片数量，默认值为1024

Indices APIs

• 创建索引
  PUT /test_index

{
  "settings": {
    "index.number_of_shards": 3,
    "index.max_result_window": 20000000,
    "number_of_replicas": 1,
    "index.refresh_interval": "60s",
    "index.highlight.max_analyzed_offset": "10000",
    "analysis": {
      "analyzer": {
        "my_analyzer": {
          "tokenizer": "ik_max_word",
          "char_filter": [
            "camel_case_filter",
            "special_character_filter"
          ]
        }
      },
      "char_filter": {
        "camel_case_filter": {
          "type": "pattern_replace",
          "pattern": "(?<=\\p{Lower})(?=\\p{Upper})",
          "replacement": " "
        },
        "special_character_filter": {
            "type": "pattern_replace",
            "pattern": "(?:\\p{Punct})",
            "replacement" : " "
        }
      }
    }
  },
  "mappings": {
    "record": {
      "_all" : { "enabled" : false },
      "dynamic": true,
      "date_detection": true,
      "properties": {
        "id": {
          "type": "keyword",
          "index": true
        },
        "verify_result": {
          "type" : "boolean",
          "index" : true
        },
        "verify_client_name": {
          "type": "text",
          "index": true,
          "analyzer": "ik_max_word",
          "search_analyzer" : "ik_smart",
          "fields": {
            "exact": {
              "type": "keyword"
            }
          },
          "fielddata": true
        },
        "verify_type": {
          "type" : "keyword",
          "index": true
        },
        "verify_client_id": {
          "type": "keyword",
          "index": true
        },
        "appid": {
          "type": "keyword",
          "index": true
        },
        "appname": {
          "type": "text",
          "index": true,
          "analyzer": "ik_max_word",
          "search_analyzer" : "ik_smart",
          "fields": {
            "exact": {
              "type": "keyword"
            }
          },
          "fielddata": true
        },
        "groupname": {
          "type": "text",
          "index": "true",
          "analyzer": "ik_max_word",
          "search_analyzer" : "ik_smart",
          "fields": {
            "exact": {
              "type": "keyword"
            }
          },
          "fielddata": true
        },
        "clientname": {
          "type": "text",
          "index": "true",
          "fields": {
            "exact": {
              "type": "keyword"
            }
          },
          "fielddata": true
        },
        "modeltype": {
          "type": "text",
          "index": true,
          "fields": {
            "exact": {
              "type": "keyword"
            }
          },
          "fielddata": true
        },
        "createtime": {
          "type": "date",
          "index": true,
          "format": "strict_date_optional_time||yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
        },
        "devuid": {
          "type": "text",
          "index": true,
          "analyzer": "ik_max_word",
          "search_analyzer" : "ik_smart",
          "fields": {
            "exact": {
              "type": "keyword"
            }
          },
          "fielddata": true
        },
        "threshold": {
          "type" : "double",
          "index": true
        },
        "value" : {
          "type" : "double",
          "index": true
        },
        "asv": {
            "type" : "boolean",
            "index": true
        },
        "asv_threshold": {
            "type" : "double",
            "index" : true
        },
        "asv_score" : {
            "type": "double",
            "index": true
        }
      }
    }
  }
}

• 删除索引

DELETE /test_index

• 查询

GET /test_index

• 查询是否存在

HEAD test_index

• 索引的开启和关闭

POST /my_index/_close?wait_for_active_shards=1
POST /my_index/_open

shrink index

https://my.oschina.net/5icode/blog/2872151

shrink index API 是把一个源索引，收缩到另一个主分片更少的目标索引中。但是目标索引的分片数，必须是源索引分片数的因子。比如，源索引的分片数是：8，那么目标索引的分片数可以是：4, 2, 1；如果源索引的分片数是一个素数，那么目标索引的分片数只能是：1。在收缩之前，源索引中每个分片都要有一个副本在这个节点上。 收缩索引的步骤如下：

• 以源索引的定义（设置）创建一个目标索引。但是目标索引的分片数量要小于源索引的分片数量。
• 把源索引的段，硬链接到目标索引，如果文件系统不支持硬链接，那么只能复制到目标索引，这将是一个耗时操作。
• 最后目标索引恢复使用，就像刚刚重新打开的一样。

为了收缩索引，必须将索引标记为只读，并且索引中每个分片的（主要副本或副本）副本必须重定位到同一节点并且健康值为绿色。用下面的请求可以实现上面的要求：
PUT /my_source_index/_settings

{
  "settings": {
    "index.routing.allocation.require._name": "shrink_node_name",  -1 
    "index.blocks.write": true -2 
  }
}

（1）：强制将每个分片的副本重定位到名为shrink_node_name的节点。详见
（2）：阻止对此索引的写入操作，同时仍允许更改元数据，例如删除索引。

目标索引添加到集群状态后，请求就会返回，不会等待收缩开始。 索引要满足一下要求，才能执行收缩：

• 目标索引不得存在
• 源索引必须具有比目标索引更多的主分片。
• 目标索引中的主分片数必须是源索引中主分片数的一个因子。源索引必须具有比目标索引更多的主分片。
• 源索引的所有分片中的文档总数不得超过2,147,483,519个，这些分片将收缩到目标索引上的单个分片中，这是可以放入单个分片的最大文档数。
• 处理收缩过程的节点必须具有足够的可用磁盘空间，以容纳现有索引的第二个副本。（感觉还是事前把副本去掉，不要副本了，之后再设置副本）_shrinkAPI和 create index API一样，可以有setting和aliases参数，所以可以为目标索引添加一些配置：

POST my_source_index/_shrink/my_target_index?copy_settings=true
{
  "settings": {
    "index.number_of_replicas": 1,
    "index.number_of_shards": 1,  （1）
    "index.codec": "best_compression"  （2）
  },
  "aliases": {
    "my_search_indices": {}
  }
}

Reindex API

需要reindex的文档必须保证_source字段存在。
reindex不会尝试新建或者拷贝原index的设置到目的索引中去，所以在执行reindex之前，你需要新建destination，并且进行一系列的设置。

POST _reindex
{
  "size": 1,
  "source": {
  "remote": {
      "host": "http://otherhost:9200",
      "username": "user",
      "password": "pass"
    },
    "index": "twitter",
    "sort": { "date": "desc" },
    "_source": ["user", "_doc"],
    "query": {
      "term": {
        "user": "kimchy"
      }
    }
  },
  "dest": {
    "index": "new_twitter"
  }
}

• size: 迁移文档数量
• remote: 从远程服务器进行数据迁移
• index: source index
• sort: 以指定顺序插入
• query: 仅插入指定查询的文档

性能提升

• 1）批量大小值可能太小。
  需要结合堆内存、线程池调整大小；
• 2）reindex的底层是scroll实现，借助scroll并行优化方式，提升效率；
• 3）跨索引、跨集群的核心是写入数据，考虑写入优化角度提升效率。

提升批量大小写入值：

batch_size 大小的设置依据：
批量大小取决于数据，分析和集群配置，但仍然建议批处理设置大小为5-15MB.
逐步递增文档容量大小的方式调优。
1）从大约5-15 MB的大容量开始，慢慢增加，直到你看不到性能的提升。然后开始增加批量写入的并发性(多线程等等)。
2）要么减少并发性，或者提供更多有限的资源(例如从机械硬盘切换到ssd固态硬盘)，要么添加更多节点。

借助scroll的sliced提升写入效率

每个Scroll请求，可以分成多个Slice请求，可以理解为切片，各Slice独立并行，利用Scroll重建或者遍历要快很多倍。

slice设定方式分为两种：手动设置分片，自动设置分片。自动设置分片如下：

POST _reindex?slices=5&refresh
{
  "source": {
    "index": "twitter"
  },
  "dest": {
    "index": "new_twitter"
  }
}

slice大小注意事项：

• 1）slices大小的设置可以手动指定，或者设置slices设置为auto，auto的含义是：针对单索引，slices大小=分片数；针对多索引，slices=分片的最小值。
• 2）当slices的数量等于索引中的分片数量时，查询性能最高效。slices大小大于分片数，非但不会提升效率，反而会增加开销。
• 3）如果这个slices数字很大(例如500)，建议选择一个较低的数字，因为过大的slices 会影响性能。

NOTE：如果 slices 的数量比 shards 的数量大，第一次调用时，slice filter 的速度会非常慢。它的复杂度时 O(n) ，内存开销等于每个 slice N 位，其中 N 时 shard 中的文档总数。经过几次调用后，筛选器会被缓存，后续的调用会更快。但是仍需要限制并行执行的 sliced 查询的数量，以免内存激增。

为了完全避免此成本，可以使用另一个字段的 doc_values 来进行切片，但用户必须确保该字段具有以下属性：

• 该字段是数字类型
• 该字段启用了 doc_values
• 每个文档应当包含单个值。如果一份文档有指定字段的多个值，则使用第一个值
• 每个文档的值在创建文档时设置了之后不再更新，这可以确保每个切片获得确定的结果
• 字段的基数应当很高，这可以确保每个切片获得的文档数量大致相同

NOTE：默认情况下，每个 scroll 允许的最大切片数量时 1024。你可以更新索引设置中的 index.max_slices_per_scroll 来绕过此限制。