• static

僅可在創(chuàng)建時或關(guān)閉時更改

• dynamic

可熱更新，通過api

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

Static Index Settings

• index.number_of_shards:

索引的shard分片數(shù)量。默認值1.可在索引關(guān)閉時更新。最大值1024.可通過集群節(jié)點中的以下屬性開啟。

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

• refresh_interval

內(nèi)存索引緩沖區(qū)的文件被刷到segment中的時間伐坏。這段數(shù)據(jù)會被寫入到es的Translog中，可以被檢索到贝润，但是尚未刷到磁盤中奠伪。Es默認值是1s,這迫使es集群每秒創(chuàng)建一個segment段，增加這個值护戳，可以允許segment更大翎冲，并減小以后的segment合并壓力。

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

要對后續(xù)所有的索引有效媳荒，則創(chuàng)建一個默認模板

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

• index.load_fixed_bitset_filters_eagerly

嵌套查詢結(jié)果的緩存預加載抗悍。默認為true。

摘自《深入理解Elasticsearch》2.4.3
通常钳枕，過濾器都會非辰稍ǎ快，因為filter不需要處理文檔得分鱼炒。而執(zhí)行嵌套查詢時所使用bitsets默認提前就加載好了衔沼。這樣做的目的是嵌套查詢執(zhí)行的更快。使用過濾器時昔瞧，過濾結(jié)果不依賴于查詢指蚁，因此過濾結(jié)果可以被輕易的緩存起來供后續(xù)查詢使用，并且每個lucene索引段都有一個過濾結(jié)果緩存自晰。這以為著不需要在每次commit時重建緩存凝化，重建操作只發(fā)生在段生成和合并。依賴于時間的過濾器緩存將沒有任何意義酬荞〈杲伲基于地理位置的場景同樣命中率極低。
轉(zhuǎn)載https://yq.aliyun.com/articles/109629/

• index.shard.check_on_startup

啟動時檢查所有shard. 檢查分片是否有損壞混巧，如果檢查到損壞枪向，將阻止分片打開。

false
checksum
true

• index.codec

索引的壓縮格式牲剃。默認使用LZ4.可以設置為best_compression.以使用DEFLATE開啟更高壓縮比例遣疯。占用更少的內(nèi)存空間。

Dynamic Index Settings

• index.number_of_replicas

數(shù)據(jù)備份數(shù)。默認1.插入索引調(diào)優(yōu)重點項缠犀。使用bulk size更新索引数苫，可將該值設置為0，即不備份辨液，加快插入速度虐急。

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

• index.max_inner_result_window

限制inner-hits的嵌套文檔數(shù)量。

• index.max_result_window

分頁窗口滔迈。默認值10000.超過該值請使用Scroll 或Search After API. 默認使用from + size的情況下的索引

• index.max_docvalue_fields_search

單詞查詢中允許的最大數(shù)量的docvalue_fields.默認100

• index.analyze.max_token_count

分詞器可以產(chǎn)生的最大詞干數(shù)量止吁。默認值10000。

• index.max_slices_per_scroll

滾動可以使用的最大切片數(shù)量燎悍，默認值為1024

Indices APIs

• 創(chuàng)建索引
  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

• 索引的開啟和關(guān)閉

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 是把一個源索引敬惦，收縮到另一個主分片更少的目標索引中。但是目標索引的分片數(shù)谈山，必須是源索引分片數(shù)的因子俄删。比如，源索引的分片數(shù)是：8奏路，那么目標索引的分片數(shù)可以是：4, 2, 1畴椰；如果源索引的分片數(shù)是一個素數(shù)，那么目標索引的分片數(shù)只能是：1鸽粉。在收縮之前斜脂，源索引中每個分片都要有一個副本在這個節(jié)點上。 收縮索引的步驟如下：

• 以源索引的定義（設置）創(chuàng)建一個目標索引触机。但是目標索引的分片數(shù)量要小于源索引的分片數(shù)量帚戳。
• 把源索引的段，硬鏈接到目標索引威兜，如果文件系統(tǒng)不支持硬鏈接销斟，那么只能復制到目標索引，這將是一個耗時操作椒舵。
• 最后目標索引恢復使用蚂踊，就像剛剛重新打開的一樣。

為了收縮索引笔宿，必須將索引標記為只讀犁钟，并且索引中每個分片的（主要副本或副本）副本必須重定位到同一節(jié)點并且健康值為綠色。用下面的請求可以實現(xiàn)上面的要求：
PUT /my_source_index/_settings

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

（1）：強制將每個分片的副本重定位到名為shrink_node_name的節(jié)點泼橘。詳見
（2）：阻止對此索引的寫入操作涝动，同時仍允許更改元數(shù)據(jù)，例如刪除索引炬灭。

目標索引添加到集群狀態(tài)后醋粟，請求就會返回，不會等待收縮開始。 索引要滿足一下要求米愿，才能執(zhí)行收縮：

• 目標索引不得存在
• 源索引必須具有比目標索引更多的主分片厦凤。
• 目標索引中的主分片數(shù)必須是源索引中主分片數(shù)的一個因子。源索引必須具有比目標索引更多的主分片育苟。
• 源索引的所有分片中的文檔總數(shù)不得超過2,147,483,519個较鼓，這些分片將收縮到目標索引上的單個分片中，這是可以放入單個分片的最大文檔數(shù)违柏。
• 處理收縮過程的節(jié)點必須具有足夠的可用磁盤空間博烂，以容納現(xiàn)有索引的第二個副本。（感覺還是事前把副本去掉漱竖，不要副本了禽篱，之后再設置副本）_shrinkAPI和 create index API一樣，可以有setting和aliases參數(shù)闲孤，所以可以為目標索引添加一些配置：

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的設置到目的索引中去，所以在執(zhí)行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: 遷移文檔數(shù)量
• remote: 從遠程服務器進行數(shù)據(jù)遷移
• index: source index
• sort: 以指定順序插入
• query: 僅插入指定查詢的文檔

性能提升

• 1）批量大小值可能太小勤众。
  需要結(jié)合堆內(nèi)存、線程池調(diào)整大欣鹪唷们颜；
• 2）reindex的底層是scroll實現(xiàn)，借助scroll并行優(yōu)化方式猎醇，提升效率窥突；
• 3）跨索引、跨集群的核心是寫入數(shù)據(jù)硫嘶，考慮寫入優(yōu)化角度提升效率阻问。

提升批量大小寫入值：

batch_size 大小的設置依據(jù)：
批量大小取決于數(shù)據(jù)，分析和集群配置沦疾，但仍然建議批處理設置大小為5-15MB.
逐步遞增文檔容量大小的方式調(diào)優(yōu)称近。
1）從大約5-15 MB的大容量開始，慢慢增加哮塞，直到你看不到性能的提升刨秆。然后開始增加批量寫入的并發(fā)性(多線程等等)。
2）要么減少并發(fā)性忆畅，或者提供更多有限的資源(例如從機械硬盤切換到ssd固態(tài)硬盤)衡未，要么添加更多節(jié)點。

借助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大小=分片數(shù)橄镜；針對多索引偎快，slices=分片的最小值。
• 2）當slices的數(shù)量等于索引中的分片數(shù)量時洽胶，查詢性能最高效晒夹。slices大小大于分片數(shù)，非但不會提升效率姊氓，反而會增加開銷丐怯。
• 3）如果這個slices數(shù)字很大(例如500)，建議選擇一個較低的數(shù)字翔横，因為過大的slices 會影響性能读跷。

NOTE：如果 slices 的數(shù)量比 shards 的數(shù)量大，第一次調(diào)用時禾唁，slice filter 的速度會非常慢效览。它的復雜度時 O(n) ，內(nèi)存開銷等于每個 slice N 位荡短，其中 N 時 shard 中的文檔總數(shù)丐枉。經(jīng)過幾次調(diào)用后，篩選器會被緩存掘托，后續(xù)的調(diào)用會更快瘦锹。但是仍需要限制并行執(zhí)行的 sliced 查詢的數(shù)量，以免內(nèi)存激增烫映。

為了完全避免此成本沼本，可以使用另一個字段的 doc_values 來進行切片，但用戶必須確保該字段具有以下屬性：

• 該字段是數(shù)字類型
• 該字段啟用了 doc_values
• 每個文檔應當包含單個值锭沟。如果一份文檔有指定字段的多個值抽兆，則使用第一個值
• 每個文檔的值在創(chuàng)建文檔時設置了之后不再更新，這可以確保每個切片獲得確定的結(jié)果
• 字段的基數(shù)應當很高族淮，這可以確保每個切片獲得的文檔數(shù)量大致相同

NOTE：默認情況下辫红，每個 scroll 允許的最大切片數(shù)量時 1024凭涂。你可以更新索引設置中的 index.max_slices_per_scroll 來繞過此限制。