刪除索引
用以下的請求來 刪除索引:
DELETE /my_index
DELETE /index_one,index_two
DELETE /index_*
DELETE /_all
DELETE /*
對一些人來說，能夠用單個命令來刪除所有數據可能會導致可怕的后果。如果你想要避免意外的大量刪除, 你可以在你的 elasticsearch.yml 做如下配置：
action.destructive_requires_name: true
這個設置使刪除只限于特定名稱指向的數據, 而不允許通過指定 _all 或通配符來刪除指定索引庫。你同樣可以通過 Cluster State API 動態的更新這個設置。
索引設置
下面是兩個 最重要的設置：
-
number_of_shards
每個索引的主分片數，默認值是 5 。這個配置在索引創建后不能修改。
-
number_of_replicas
每個主分片的副本數，默認值是 1 。對于活動的索引庫，這個配置可以隨時修改。
例如，我們可以創建只有 一個主分片，沒有副本的小索引：
PUT /my_temp_index
{
"settings": {
"number_of_shards" : 1,
"number_of_replicas" : 0
}
}
然后，我們可以用 update-index-settings API 動態修改副本數：
PUT /my_temp_index/_settings
{
"number_of_replicas": 1
}
配置分析器
第三個重要的索引設置是 analysis 部分， 用來配置已存在的分析器或針對你的索引創建新的自定義分析器。
在下面的例子中，我們創建了一個新的分析器，叫做 es_std ， 并使用預定義的 西班牙語停用詞列表：
PUT /spanish_docs
{
"settings": {
"analysis": {
"analyzer": {
"es_std": {
"type": "standard",
"stopwords": "_spanish_"
}
}
}
}
}
es_std 分析器不是全局的--它僅僅存在于我們定義的 spanish_docs 索引中。 為了使用 analyze API來對它進行測試，我們必須使用特定的索引名：
GET /spanish_docs/_analyze
{
"analyzer":"my_analyzer",
"text":"El veloz zorro marrón"
}
自定義分析器
雖然Elasticsearch帶有一些現成的分析器，然而在分析器上Elasticsearch真正的強大之處在于，你可以通過在一個適合你的特定數據的設置之中組合字符過濾器、分詞器、詞匯單元過濾器來創建自定義的分析器。
PUT /my_index
{
"settings": {
"analysis": {
"char_filter": {
"&_to_and": {
"type": "mapping",
"mappings": [ "&=> and "]
}},
"filter": {
"my_stopwords": {
"type": "stop",
"stopwords": [ "the", "a" ]
}},
"analyzer": {
"my_analyzer": {
"type": "custom",
"char_filter": [ "html_strip", "&_to_and" ],
"tokenizer": "standard",
"filter": [ "lowercase", "my_stopwords" ]
}}
}}}
測試自定義分析器
GET /my_index/_analyze
{
"analyzer":"my_analyzer",
"text":"The quick & brown fox"
}
類型（type）和映射
Elasticsearch 類型是 以 Lucene 處理文檔的這個方式為基礎來實現的。一個索引可以有多個類型，這些類型的文檔可以存儲在相同的索引中。
Lucene 沒有文檔類型的概念，每個文檔的類型名被存儲在一個叫 _type 的元數據字段上。 當我們要檢索某個類型的文檔時, Elasticsearch 通過在 _type 字段上使用過濾器限制只返回這個類型的文檔。
Lucene 也沒有映射的概念。 映射是 Elasticsearch 將復雜 JSON 文檔 映射 成 Lucene 需要的扁平化數據的方式。
-
避免類型陷阱
這導致了一個有趣的思想實驗： 如果有兩個不同的類型，每個類型都有同名的字段，但映射不同（例如：一個是字符串一個是數字），將會出現什么情況？
簡單回答是，Elasticsearch 不會允許你定義這個映射。當你配置這個映射時，將會出現異常。
詳細回答是，每個 Lucene 索引中的所有字段都包含一個單一的、扁平的模式。一個特定字段可以映射成 string 類型也可以是 number 類型，但是不能兩者兼具。因為類型是 Elasticsearch 添加的 優于 Lucene 的額外機制（以元數據 _type 字段的形式），在 Elasticsearch 中的所有類型最終都共享相同的映射。
以 data 索引中兩種類型的映射為例：
{
"data": {
"mappings": {
"people": {
"properties": {
"name": {
"type": "string",
},
"address": {
"type": "string"
}
}
},
"transactions": {
"properties": {
"timestamp": {
"type": "date",
"format": "strict_date_optional_time"
},
"message": {
"type": "string"
}
}
}
}
}
}
每個類型定義兩個字段 (分別是 "name"/"address" 和 "timestamp"/"message" )。它們看起來是相互獨立的，但在后臺 Lucene 將創建一個映射，如:
{
"data": {
"mappings": {
"_type": {
"type": "string",
"index": "not_analyzed"
},
"name": {
"type": "string"
}
"address": {
"type": "string"
}
"timestamp": {
"type": "long"
}
"message": {
"type": "string"
}
}
}
}
注: 這不是真實有效的映射語法，只是用于演示
對于整個索引，映射在本質上被 扁平化 成一個單一的、全局的模式。這就是為什么兩個類型不能定義沖突的字段：當映射被扁平化時，Lucene 不知道如何去處理。
-
類型討論
那么，這個討論的結論是什么？技術上講，多個類型可以在相同的索引中存在，只要它們的字段不沖突（要么因為字段是互為獨占模式，要么因為它們共享相同的字段）。
重要的一點是: 類型可以很好的區分同一個集合中的不同細分。在不同的細分中數據的整體模式是相同的（或相似的）。
類型不適合 完全不同類型的數據 。如果兩個類型的字段集是互不相同的，這就意味著索引中將有一半的數據是空的（字段將是 稀疏的 ），最終將導致性能問題。在這種情況下，最好是使用兩個單獨的索引。
根對象
映射的最高一層被稱為 根對象 ，它可能包含下面幾項：
- 一個 properties 節點，列出了文檔中可能包含的每個字段的映射
- 各種元數據字段，它們都以一個下劃線開頭，例如 _type 、 _id 和 _source
- 設置項，控制如何動態處理新的字段，例如 analyzer 、 dynamic_date_formats 和 dynamic_templates
- 其他設置，可以同時應用在根對象和其他 object 類型的字段上，例如 enabled 、 dynamic 和 include_in_all
動態映射
當 Elasticsearch 遇到文檔中以前 未遇到的字段，它用 dynamic mapping 來確定字段的數據類型并自動把新的字段添加到類型映射。
有時這是想要的行為有時又不希望這樣。通常沒有人知道以后會有什么新字段加到文檔，但是又希望這些字段被自動的索引。也許你只想忽略它們。如果Elasticsearch是作為重要的數據存儲，可能就會期望遇到新字段就會拋出異常，這樣能及時發現問題。
幸運的是可以用 dynamic 配置來控制這種行為 ，可接受的選項如下：
- true,動態添加新的字段--缺省
- false,忽略新的字段
- strict,如果遇到新字段拋出異常
配置參數 dynamic 可以用在根 object 或任何 object 類型的字段上。你可以將 dynamic 的默認值設置為 strict , 而只在指定的內部對象中開啟它, 例如：
PUT /my_index
{
"mappings": {
"my_type": {
"dynamic": "strict",
"properties": {
"title": { "type": "string"},
"stash": {
"type": "object",
"dynamic": true
}
}
}
}
}
使用上述動態映射， 你可以給 stash 對象添加新的可檢索的字段：
PUT /my_index/my_type/1
{
"title": "This doc adds a new field",
"stash": { "new_field": "Success!" }
}
但是對根節點對象 my_type 進行同樣的操作會失敗：
PUT /my_index/my_type/1
{
"title": "This throws a StrictDynamicMappingException",
"new_field": "Fail!"
}
自定義動態映射
使用 dynamic_templates ，你可以完全控制 新檢測生成字段的映射。你甚至可以通過字段名稱或數據類型來應用不同的映射。
每個模板都有一個名稱， 你可以用來描述這個模板的用途， 一個 mapping 來指定映射應該怎樣使用，以及至少一個參數 (如 match) 來定義這個模板適用于哪個字段。
模板按照順序來檢測；第一個匹配的模板會被啟用。例如，我們給 string 類型字段定義兩個模板：
- es ：以 _es 結尾的字段名需要使用 spanish 分詞器。
- en ：所有其他字段使用 english 分詞器。
PUT /my_index
{
"mappings": {
"my_type": {
"dynamic_templates": [
{ "es": {
"match": "*_es",
"match_mapping_type": "string",
"mapping": {
"type": "string",
"analyzer": "spanish"
}
}},
{ "en": {
"match": "*",
"match_mapping_type": "string",
"mapping": {
"type": "string",
"analyzer": "english"
}
}}
]
}}}
缺省映射
通常，一個索引中的所有類型（type）共享相同的字段和設置。 default 映射更加方便地指定通用設置，而不是每次創建新類型時都要重復設置。 default 映射是新類型的模板。在設置 default 映射之后創建的所有類型都將應用這些缺省的設置，除非類型在自己的映射中明確覆蓋這些設置。
例如，我們可以使用 default 映射為所有的類型禁用 _all 字段， 而只在 blog 類型啟用：
PUT /my_index
{
"mappings": {
"_default_": {
"_all": { "enabled": false }
},
"blog": {
"_all": { "enabled": true }
}
}
}
重新索引數據
盡管可以增加新的類型到索引中，或者增加新的字段到類型中，但是不能添加新的分析器或者對現有的字段做改動。 如果你那么做的話，結果就是那些已經被索引的數據就不正確， 搜索也不能正常工作。
對現有數據的這類改變最簡單的辦法就是重新索引：用新的設置創建新的索引并把文檔從舊的索引復制到新的索引。
字段 _source 的一個優點是在Elasticsearch中已經有整個文檔。你不必從源數據中重建索引，而且那樣通常比較慢。
為了有效的重新索引所有在舊的索引中的文檔，用 scroll 從舊的索引檢索批量文檔 ， 然后用 bulk API 把文檔推送到新的索引中。
從Elasticsearch v2.3.0開始， Reindex API 被引入。它能夠對文檔重建索引而不需要任何插件或外部工具。
索引別名和零停機
在前面提到的，重建索引的問題是必須更新應用中的索引名稱。 索引別名就是用來解決這個問題的！
索引 別名 就像一個快捷方式或軟連接，可以指向一個或多個索引，也可以給任何一個需要索引名的API來使用。別名 帶給我們極大的靈活性。
有兩種方式管理別名：
- _alias 用于單個操作
- _aliases 用于執行多個原子級操作
在本章中，我們假設你的應用有一個叫 my_index 的索引。事實上， my_index 是一個指向當前真實索引的別名。真實索引包含一個版本號： my_index_v1 ， my_index_v2 等等。
首先，創建索引 my_index_v1 ，然后將別名 my_index 指向它：
# 創建索引 my_index_v1
PUT /my_index_v1
# 設置別名 my_index 指向 my_index_v1
PUT /my_index_v1/_alias/my_index
你可以檢測這個別名指向哪一個索引：
GET /*/_alias/my_index
或哪些別名指向這個索引：
GET /my_index_v1/_alias/*
兩者都會返回下面的結果：
{
"my_index_v1" : {
"aliases" : {
"my_index" : { }
}
}
}
然后，我們決定修改索引中一個字段的映射。當然，我們不能修改現存的映射，所以我們必須重新索引數據。 首先, 我們用新映射創建索引 my_index_v2 ：
PUT /my_index_v2
{
"mappings": {
"my_type": {
"properties": {
"tags": {
"type": "string",
"index": "not_analyzed"
}
}
}
}
}
然后我們將數據從 my_index_v1 索引到 my_index_v2 ，下面的過程在 重新索引你的數據 中已經描述過。一旦我們確定文檔已經被正確地重索引了，我們就將別名指向新的索引。
一個別名可以指向多個索引，所以我們在添加別名到新索引的同時必須從舊的索引中刪除它。這個操作需要原子化，這意味著我們需要使用 _aliases 操作：
POST /_aliases
{
"actions": [
{ "remove": { "index": "my_index_v1", "alias": "my_index" }},
{ "add": { "index": "my_index_v2", "alias": "my_index" }}
]
}
你的應用已經在零停機的情況下從舊索引遷移到新索引了。
即使你認為現在的索引設計已經很完美了，在生產環境中，還是有可能需要做一些修改的。做好準備：在你的應用中使用別名而不是索引名。然后你就可以在任何時候重建索引。別名的開銷很小，應該廣泛使用。
