刪除索引
用以下的請求來 刪除索引:
DELETE /my_index
DELETE /index_one,index_two
DELETE /index_*
DELETE /_all
DELETE /*
對一些人來說膏蚓，能夠用單個(gè)命令來刪除所有數(shù)據(jù)可能會導(dǎo)致可怕的后果瓢谢。如果你想要避免意外的大量刪除, 你可以在你的 elasticsearch.yml 做如下配置：
action.destructive_requires_name: true
這個(gè)設(shè)置使刪除只限于特定名稱指向的數(shù)據(jù), 而不允許通過指定 _all 或通配符來刪除指定索引庫。你同樣可以通過 Cluster State API 動態(tài)的更新這個(gè)設(shè)置驮瞧。
索引設(shè)置
下面是兩個(gè) 最重要的設(shè)置：
-
number_of_shards
每個(gè)索引的主分片數(shù)氓扛，默認(rèn)值是 5 。這個(gè)配置在索引創(chuàng)建后不能修改论笔。
-
number_of_replicas
每個(gè)主分片的副本數(shù)采郎，默認(rèn)值是 1 。對于活動的索引庫狂魔，這個(gè)配置可以隨時(shí)修改蒜埋。
例如，我們可以創(chuàng)建只有 一個(gè)主分片最楷，沒有副本的小索引：
PUT /my_temp_index
{
"settings": {
"number_of_shards" : 1,
"number_of_replicas" : 0
}
}
然后整份，我們可以用 update-index-settings API 動態(tài)修改副本數(shù)：
PUT /my_temp_index/_settings
{
"number_of_replicas": 1
}
配置分析器
第三個(gè)重要的索引設(shè)置是 analysis 部分待错， 用來配置已存在的分析器或針對你的索引創(chuàng)建新的自定義分析器。
在下面的例子中皂林，我們創(chuàng)建了一個(gè)新的分析器朗鸠，叫做 es_std ， 并使用預(yù)定義的 西班牙語停用詞列表：
PUT /spanish_docs
{
"settings": {
"analysis": {
"analyzer": {
"es_std": {
"type": "standard",
"stopwords": "_spanish_"
}
}
}
}
}
es_std 分析器不是全局的--它僅僅存在于我們定義的 spanish_docs 索引中础倍。 為了使用 analyze API來對它進(jìn)行測試烛占，我們必須使用特定的索引名：
GET /spanish_docs/_analyze
{
"analyzer":"my_analyzer",
"text":"El veloz zorro marrón"
}
自定義分析器
雖然Elasticsearch帶有一些現(xiàn)成的分析器，然而在分析器上Elasticsearch真正的強(qiáng)大之處在于沟启，你可以通過在一個(gè)適合你的特定數(shù)據(jù)的設(shè)置之中組合字符過濾器忆家、分詞器、詞匯單元過濾器來創(chuàng)建自定義的分析器德迹。
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 處理文檔的這個(gè)方式為基礎(chǔ)來實(shí)現(xiàn)的芽卿。一個(gè)索引可以有多個(gè)類型，這些類型的文檔可以存儲在相同的索引中胳搞。
Lucene 沒有文檔類型的概念卸例，每個(gè)文檔的類型名被存儲在一個(gè)叫 _type 的元數(shù)據(jù)字段上。 當(dāng)我們要檢索某個(gè)類型的文檔時(shí), Elasticsearch 通過在 _type 字段上使用過濾器限制只返回這個(gè)類型的文檔肌毅。
Lucene 也沒有映射的概念筷转。 映射是 Elasticsearch 將復(fù)雜 JSON 文檔 映射 成 Lucene 需要的扁平化數(shù)據(jù)的方式。
-
避免類型陷阱
這導(dǎo)致了一個(gè)有趣的思想實(shí)驗(yàn)： 如果有兩個(gè)不同的類型悬而，每個(gè)類型都有同名的字段呜舒，但映射不同（例如：一個(gè)是字符串一個(gè)是數(shù)字），將會出現(xiàn)什么情況笨奠？
簡單回答是袭蝗，Elasticsearch 不會允許你定義這個(gè)映射。當(dāng)你配置這個(gè)映射時(shí)般婆，將會出現(xiàn)異常到腥。
詳細(xì)回答是，每個(gè) Lucene 索引中的所有字段都包含一個(gè)單一的蔚袍、扁平的模式左电。一個(gè)特定字段可以映射成 string 類型也可以是 number 類型，但是不能兩者兼具页响。因?yàn)轭愋褪?Elasticsearch 添加的 優(yōu)于 Lucene 的額外機(jī)制（以元數(shù)據(jù) _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"
}
}
}
}
}
}
每個(gè)類型定義兩個(gè)字段 (分別是 "name"/"address" 和 "timestamp"/"message" )闰蚕。它們看起來是相互獨(dú)立的栈拖，但在后臺 Lucene 將創(chuàng)建一個(gè)映射，如:
{
"data": {
"mappings": {
"_type": {
"type": "string",
"index": "not_analyzed"
},
"name": {
"type": "string"
}
"address": {
"type": "string"
}
"timestamp": {
"type": "long"
}
"message": {
"type": "string"
}
}
}
}
注: 這不是真實(shí)有效的映射語法没陡，只是用于演示
對于整個(gè)索引涩哟，映射在本質(zhì)上被 扁平化 成一個(gè)單一的索赏、全局的模式。這就是為什么兩個(gè)類型不能定義沖突的字段：當(dāng)映射被扁平化時(shí)贴彼，Lucene 不知道如何去處理潜腻。
-
類型討論
那么，這個(gè)討論的結(jié)論是什么器仗？技術(shù)上講融涣，多個(gè)類型可以在相同的索引中存在，只要它們的字段不沖突（要么因?yàn)樽侄问腔楠?dú)占模式精钮，要么因?yàn)樗鼈児蚕硐嗤淖侄危?/p>
重要的一點(diǎn)是: 類型可以很好的區(qū)分同一個(gè)集合中的不同細(xì)分威鹿。在不同的細(xì)分中數(shù)據(jù)的整體模式是相同的（或相似的）。
類型不適合 完全不同類型的數(shù)據(jù) 轨香。如果兩個(gè)類型的字段集是互不相同的忽你，這就意味著索引中將有一半的數(shù)據(jù)是空的（字段將是 稀疏的 ），最終將導(dǎo)致性能問題臂容。在這種情況下科雳，最好是使用兩個(gè)單獨(dú)的索引。
根對象
映射的最高一層被稱為 根對象 脓杉，它可能包含下面幾項(xiàng)：
- 一個(gè) properties 節(jié)點(diǎn)糟秘，列出了文檔中可能包含的每個(gè)字段的映射
- 各種元數(shù)據(jù)字段，它們都以一個(gè)下劃線開頭丽已，例如 _type 蚌堵、 _id 和 _source
- 設(shè)置項(xiàng)买决，控制如何動態(tài)處理新的字段沛婴，例如 analyzer 、 dynamic_date_formats 和 dynamic_templates
- 其他設(shè)置督赤，可以同時(shí)應(yīng)用在根對象和其他 object 類型的字段上嘁灯，例如 enabled 、 dynamic 和 include_in_all
動態(tài)映射
當(dāng) Elasticsearch 遇到文檔中以前 未遇到的字段躲舌，它用 dynamic mapping 來確定字段的數(shù)據(jù)類型并自動把新的字段添加到類型映射丑婿。
有時(shí)這是想要的行為有時(shí)又不希望這樣。通常沒有人知道以后會有什么新字段加到文檔没卸，但是又希望這些字段被自動的索引羹奉。也許你只想忽略它們。如果Elasticsearch是作為重要的數(shù)據(jù)存儲约计，可能就會期望遇到新字段就會拋出異常诀拭，這樣能及時(shí)發(fā)現(xiàn)問題。
幸運(yùn)的是可以用 dynamic 配置來控制這種行為 煤蚌，可接受的選項(xiàng)如下：
- true,動態(tài)添加新的字段--缺省
- false,忽略新的字段
- strict,如果遇到新字段拋出異常
配置參數(shù) dynamic 可以用在根 object 或任何 object 類型的字段上耕挨。你可以將 dynamic 的默認(rèn)值設(shè)置為 strict , 而只在指定的內(nèi)部對象中開啟它, 例如：
PUT /my_index
{
"mappings": {
"my_type": {
"dynamic": "strict",
"properties": {
"title": { "type": "string"},
"stash": {
"type": "object",
"dynamic": true
}
}
}
}
}
使用上述動態(tài)映射细卧， 你可以給 stash 對象添加新的可檢索的字段：
PUT /my_index/my_type/1
{
"title": "This doc adds a new field",
"stash": { "new_field": "Success!" }
}
但是對根節(jié)點(diǎn)對象 my_type 進(jìn)行同樣的操作會失敗：
PUT /my_index/my_type/1
{
"title": "This throws a StrictDynamicMappingException",
"new_field": "Fail!"
}
自定義動態(tài)映射
使用 dynamic_templates 筒占，你可以完全控制 新檢測生成字段的映射贪庙。你甚至可以通過字段名稱或數(shù)據(jù)類型來應(yīng)用不同的映射。
每個(gè)模板都有一個(gè)名稱翰苫， 你可以用來描述這個(gè)模板的用途止邮， 一個(gè) mapping 來指定映射應(yīng)該怎樣使用，以及至少一個(gè)參數(shù) (如 match) 來定義這個(gè)模板適用于哪個(gè)字段革骨。
模板按照順序來檢測农尖；第一個(gè)匹配的模板會被啟用。例如良哲，我們給 string 類型字段定義兩個(gè)模板：
- es ：以 _es 結(jié)尾的字段名需要使用 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"
}
}}
]
}}}
缺省映射
通常筑凫，一個(gè)索引中的所有類型（type）共享相同的字段和設(shè)置滑沧。 default 映射更加方便地指定通用設(shè)置，而不是每次創(chuàng)建新類型時(shí)都要重復(fù)設(shè)置巍实。 default 映射是新類型的模板滓技。在設(shè)置 default 映射之后創(chuàng)建的所有類型都將應(yīng)用這些缺省的設(shè)置，除非類型在自己的映射中明確覆蓋這些設(shè)置棚潦。
例如令漂，我們可以使用 default 映射為所有的類型禁用 _all 字段， 而只在 blog 類型啟用：
PUT /my_index
{
"mappings": {
"_default_": {
"_all": { "enabled": false }
},
"blog": {
"_all": { "enabled": true }
}
}
}
重新索引數(shù)據(jù)
盡管可以增加新的類型到索引中丸边，或者增加新的字段到類型中叠必，但是不能添加新的分析器或者對現(xiàn)有的字段做改動。 如果你那么做的話妹窖，結(jié)果就是那些已經(jīng)被索引的數(shù)據(jù)就不正確纬朝， 搜索也不能正常工作。
對現(xiàn)有數(shù)據(jù)的這類改變最簡單的辦法就是重新索引：用新的設(shè)置創(chuàng)建新的索引并把文檔從舊的索引復(fù)制到新的索引骄呼。
字段 _source 的一個(gè)優(yōu)點(diǎn)是在Elasticsearch中已經(jīng)有整個(gè)文檔共苛。你不必從源數(shù)據(jù)中重建索引，而且那樣通常比較慢蜓萄。
為了有效的重新索引所有在舊的索引中的文檔隅茎，用 scroll 從舊的索引檢索批量文檔 ， 然后用 bulk API 把文檔推送到新的索引中嫉沽。
從Elasticsearch v2.3.0開始辟犀， Reindex API 被引入。它能夠?qū)ξ臋n重建索引而不需要任何插件或外部工具耻蛇。
索引別名和零停機(jī)
在前面提到的踪蹬，重建索引的問題是必須更新應(yīng)用中的索引名稱胞此。 索引別名就是用來解決這個(gè)問題的！
索引 別名 就像一個(gè)快捷方式或軟連接跃捣，可以指向一個(gè)或多個(gè)索引漱牵，也可以給任何一個(gè)需要索引名的API來使用。別名 帶給我們極大的靈活性疚漆。
有兩種方式管理別名：
- _alias 用于單個(gè)操作
- _aliases 用于執(zhí)行多個(gè)原子級操作
在本章中酣胀，我們假設(shè)你的應(yīng)用有一個(gè)叫 my_index 的索引。事實(shí)上娶聘， my_index 是一個(gè)指向當(dāng)前真實(shí)索引的別名闻镶。真實(shí)索引包含一個(gè)版本號： my_index_v1 ， my_index_v2 等等丸升。
首先铆农，創(chuàng)建索引 my_index_v1 ，然后將別名 my_index 指向它：
# 創(chuàng)建索引 my_index_v1
PUT /my_index_v1
# 設(shè)置別名 my_index 指向 my_index_v1
PUT /my_index_v1/_alias/my_index
你可以檢測這個(gè)別名指向哪一個(gè)索引：
GET /*/_alias/my_index
或哪些別名指向這個(gè)索引：
GET /my_index_v1/_alias/*
兩者都會返回下面的結(jié)果：
{
"my_index_v1" : {
"aliases" : {
"my_index" : { }
}
}
}
然后狡耻，我們決定修改索引中一個(gè)字段的映射墩剖。當(dāng)然，我們不能修改現(xiàn)存的映射夷狰，所以我們必須重新索引數(shù)據(jù)岭皂。 首先, 我們用新映射創(chuàng)建索引 my_index_v2 ：
PUT /my_index_v2
{
"mappings": {
"my_type": {
"properties": {
"tags": {
"type": "string",
"index": "not_analyzed"
}
}
}
}
}
然后我們將數(shù)據(jù)從 my_index_v1 索引到 my_index_v2 ，下面的過程在 重新索引你的數(shù)據(jù) 中已經(jīng)描述過沼头。一旦我們確定文檔已經(jīng)被正確地重索引了爷绘，我們就將別名指向新的索引。
一個(gè)別名可以指向多個(gè)索引进倍，所以我們在添加別名到新索引的同時(shí)必須從舊的索引中刪除它土至。這個(gè)操作需要原子化，這意味著我們需要使用 _aliases 操作：
POST /_aliases
{
"actions": [
{ "remove": { "index": "my_index_v1", "alias": "my_index" }},
{ "add": { "index": "my_index_v2", "alias": "my_index" }}
]
}
你的應(yīng)用已經(jīng)在零停機(jī)的情況下從舊索引遷移到新索引了背捌。
即使你認(rèn)為現(xiàn)在的索引設(shè)計(jì)已經(jīng)很完美了毙籽，在生產(chǎn)環(huán)境中洞斯，還是有可能需要做一些修改的毡庆。做好準(zhǔn)備：在你的應(yīng)用中使用別名而不是索引名。然后你就可以在任何時(shí)候重建索引烙如。別名的開銷很小么抗，應(yīng)該廣泛使用。
