Update Indices Settings

Change specific index level settings in real time.

The REST endpoint is /_settings (to update all indices) or {index}/_settings to update one (or more) indices settings. The body of the request includes the updated settings, for example:

{
    "index" : {
        "number_of_replicas" : 4
    }
}

The above will change the number of replicas to 4 from the current number of replicas. Here is a curl example:

curl -XPUT 'localhost:9200/my_index/_settings' -d '
{
    "index" : {
        "number_of_replicas" : 4
    }
}'

Below is the list of settings that can be changed using the update settings API:

For example, the update settings API can be used to dynamically change the index from being more performant for bulk indexing, and then move it to more real time indexing state. Before the bulk indexing is started, use:

curl -XPUT localhost:9200/test/_settings -d '{
    "index" : {
        "refresh_interval" : "-1"
    } }'

(Another optimization option is to start the index without any replicas, and only later adding them, but that really depends on the use case).

Then, once bulk indexing is done, the settings can be updated (back to the defaults for example):

curl -XPUT localhost:9200/test/_settings -d '{
    "index" : {
        "refresh_interval" : "1s"
    } }'

And, an optimize should be called:

curl -XPOST 'http://localhost:9200/test/_optimize?max_num_segments=5'

It is also possible to define new analyzers for the index. But it is required to close the index first and open it after the changes are made.

For example if content analyzer hasn’t been defined on myindex yet you can use the following commands to add it:

curl -XPOST 'localhost:9200/myindex/_close'

curl -XPUT 'localhost:9200/myindex/_settings' -d '{
  "analysis" : {
    "analyzer":{
      "content":{
        "type":"custom",
        "tokenizer":"whitespace"
      }
    }
  }
}'

curl -XPOST 'localhost:9200/myindex/_open'

Up to version 1.3, Elasticsearch used to generate bloom filters for the _uid field at indexing time and to load them at search time in order to speed-up primary-key lookups by savings disk seeks.

As of 1.4, bloom filters are still generated at indexing time, but they are no longer loaded at search time by default: they consume RAM in proportion to the number of unique terms, which can quickly add up for certain use cases, and separate performance improvements have made the performance gains with bloom filters very small.

PUT /old_index/_settings?index.codec.bloom.load=true