索引管理

1、創(chuàng)建一個索引

到目前為止, 我們已經(jīng)通過索引一篇文檔創(chuàng)建了一個新的索引 。這個索引采用的是默認的配置，新的字段通過動態(tài)映射的方式被添加到類型映射。現(xiàn)在我們需要對這個建立索引的過程做更多的控制：我們想要確保這個索引有數(shù)量適中的主分片，并且在我們索引任何數(shù)據(jù) 之前 ，分析器和映射已經(jīng)被建立好。

為了達到這個目的，我們需要手動創(chuàng)建索引，在請求體里面?zhèn)魅朐O(shè)置或類型映射，如下所示：

PUT /my_index {"settings": { ... any settings ... },"mappings": {"type_one": { ... any mappings ... },"type_two": { ... any mappings ... },...} }

如果你想禁止自動創(chuàng)建索引，你 可以通過在 config/elasticsearch.yml 的每個節(jié)點下添加下面的配置：

action.auto_create_index: false

2、刪除一個索引

用以下的請求來 刪除索引:

DELETE /my_index

你也可以這樣刪除多個索引：

DELETE /index_one,index_two DELETE /index_*

你甚至可以這樣刪除 全部 索引：

DELETE /_all DELETE /*

3、索引設(shè)置

下面是兩個 最重要的設(shè)置：

number_of_shards

每個索引的主分片數(shù)，默認值是 5 。這個配置在索引創(chuàng)建后不能修改。

number_of_replicas

每個主分片的副本數(shù)，默認值是 1 。對于活動的索引庫，這個配置可以隨時修改。?
例如，我們可以創(chuàng)建只有 一個主分片，沒有副本的小索引：

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 }

4、配置分析器

第三個重要的索引設(shè)置是 analysis 部分， 用來配置已存在的分析器或針對你的索引創(chuàng)建新的自定義分析器。

在 分析與分析器 ，我們介紹了一些內(nèi)置的 分析器，用于將全文字符串轉(zhuǎn)換為適合搜索的倒排索引。

standard 分析器是用于全文字段的默認分析器， 對于大部分西方語系來說是一個不錯的選擇。 它包括了以下幾點：

• standard 分詞器，通過單詞邊界分割輸入的文本。
• standard 語匯單元過濾器，目的是整理分詞器觸發(fā)的語匯單元（但是目前什么都沒做）。
• lowercase 語匯單元過濾器，轉(zhuǎn)換所有的語匯單元為小寫。
• stop 語匯單元過濾器，刪除停用詞–對搜索相關(guān)性影響不大的常用詞，如 a ， the ， and ， is 。

默認情況下，停用詞過濾器是被禁用的。如需啟用它，你可以通過創(chuàng)建一個基于 standard 分析器的自定義分析器并設(shè)置 stopwords 參數(shù)。 可以給分析器提供一個停用詞列表，或者告知使用一個基于特定語言的預(yù)定義停用詞列表。

在下面的例子中，我們創(chuàng)建了一個新的分析器，叫做 es_std ， 并使用預(yù)定義的 西班牙語停用詞列表：

PUT /spanish_docs {"settings": {"analysis": {"analyzer": {"es_std": {"type": "standard","stopwords": "_spanish_"}}}} }

es_std 分析器不是全局的–它僅僅存在于我們定義的 spanish_docs 索引中。 為了使用 analyze API來對它進行測試，我們必須使用特定的索引名：

GET /spanish_docs/_analyze?analyzer=es_std El veloz zorro marrón

簡化的結(jié)果顯示西班牙語停用詞 El 已被正確的移除：

{"tokens" : [{ "token" : "veloz", "position" : 2 },{ "token" : "zorro", "position" : 3 },{ "token" : "marrón", "position" : 4 }] }

5、自定義分析器

雖然Elasticsearch帶有一些現(xiàn)成的分析器，然而在分析器上Elasticsearch真正的強大之處在于，你可以通過在一個適合你的特定數(shù)據(jù)的設(shè)置之中組合字符過濾器、分詞器、詞匯單元過濾器來創(chuàng)建自定義的分析器。

在 分析與分析器 我們說過，一個 分析器 就是在一個包里面組合了三種函數(shù)的一個包裝器， 三種函數(shù)按照順序被執(zhí)行:

字符過濾器?
字符過濾器 用來 整理 一個尚未被分詞的字符串。例如，如果我們的文本是HTML格式的，它會包含像

或者

這樣的HTML標簽，這些標簽是我們不想索引的。我們可以使用 html清除 字符過濾器 來移除掉所有的HTML標簽，并且像把 á 轉(zhuǎn)換為相對應(yīng)的Unicode字符 á 這樣，轉(zhuǎn)換HTML實體。

?

一個分析器可能有0個或者多個字符過濾器。

分詞器?
一個分析器 必須 有一個唯一的分詞器。 分詞器把字符串分解成單個詞條或者詞匯單元。 標準 分析器里使用的 標準 分詞器 把一個字符串根據(jù)單詞邊界分解成單個詞條，并且移除掉大部分的標點符號，然而還有其他不同行為的分詞器存在。

例如， 關(guān)鍵詞 分詞器 完整地輸出 接收到的同樣的字符串，并不做任何分詞。 空格 分詞器 只根據(jù)空格分割文本 。 正則 分詞器 根據(jù)匹配正則表達式來分割文本 。

詞單元過濾器?
經(jīng)過分詞，作為結(jié)果的 詞單元流 會按照指定的順序通過指定的詞單元過濾器 。

詞單元過濾器可以修改、添加或者移除詞單元。我們已經(jīng)提到過 lowercase 和 stop 詞過濾器 ，但是在 Elasticsearch 里面還有很多可供選擇的詞單元過濾器。 詞干過濾器 把單詞 遏制 為 詞干。 ascii_folding 過濾器移除變音符，把一個像 “très” 這樣的詞轉(zhuǎn)換為 “tres” 。 ngram 和 edge_ngram 詞單元過濾器 可以產(chǎn)生 適合用于部分匹配或者自動補全的詞單元。

在 深入搜索 ，我們討論了在哪里使用，以及怎樣使用分詞器和過濾器。但是首先，我們需要解釋一下怎樣創(chuàng)建自定義的分析器。

創(chuàng)建一個自定義分析器?
和我們之前配置 es_std 分析器一樣，我們可以在 analysis 下的相應(yīng)位置設(shè)置字符過濾器、分詞器和詞單元過濾器:

PUT /my_index {"settings": {"analysis": {"char_filter": { ... custom character filters ... },"tokenizer": { ... custom tokenizers ... },"filter": { ... custom token filters ... },"analyzer": { ... custom analyzers ... }}} }

作為示范，讓我們一起來創(chuàng)建一個自定義分析器吧，這個分析器可以做到下面的這些事:

• 1、使用 html清除 字符過濾器移除HTML部分。
• 2、使用一個自定義的 映射 字符過濾器把 & 替換為 ” 和 ” ：

"char_filter": {"&_to_and": {"type": "mapping","mappings": [ "&=> and "]} }

• 3、使用 標準 分詞器分詞。
• 4、小寫詞條，使用 小寫 詞過濾器處理。
• 5、使用自定義 停止 詞過濾器移除自定義的停止詞列表中包含的詞：

"filter": {"my_stopwords": {"type": "stop","stopwords": [ "the", "a" ]} }

我們的分析器定義用我們之前已經(jīng)設(shè)置好的自定義過濾器組合了已經(jīng)定義好的分詞器和過濾器：

"analyzer": {"my_analyzer": {"type": "custom","char_filter": [ "html_strip", "&_to_and" ],"tokenizer": "standard","filter": [ "lowercase", "my_stopwords" ]} }

匯總起來，完整的 創(chuàng)建索引 請求 看起來應(yī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" ]}} }}}

索引被創(chuàng)建以后，使用 analyze API 來 測試這個新的分析器：

GET /my_index/_analyze?analyzer=my_analyzer The quick & brown fox

下面的縮略結(jié)果展示出我們的分析器正在正確地運行：

{"tokens" : [{ "token" : "quick", "position" : 2 },{ "token" : "and", "position" : 3 },{ "token" : "brown", "position" : 4 },{ "token" : "fox", "position" : 5 }] }

這個分析器現(xiàn)在是沒有多大用處的，除非我們告訴 Elasticsearch在哪里用上它。我們可以像下面這樣把這個分析器應(yīng)用在一個 string 字段上：

PUT /my_index/_mapping/my_type {"properties": {"title": {"type": "string","analyzer": "my_analyzer"}} }

6、類型和映射

類型 在 Elasticsearch 中表示一類相似的文檔。 類型由 名稱 —比如 user 或 blogpost —和 映射 組成。

映射, 就像數(shù)據(jù)庫中的 schema ，描述了文檔可能具有的字段或 屬性 、 每個字段的數(shù)據(jù)類型—比如 string, integer 或 date —以及Lucene是如何索引和存儲這些字段的。

類型可以很好的抽象劃分相似但不相同的數(shù)據(jù)。但由于 Lucene 的處理方式，類型的使用有些限制。

6.1、Lucene 如何處理文檔

在 Lucene 中，一個文檔由一組簡單的鍵值對組成。 每個字段都可以有多個值，但至少要有一個值。 類似的，一個字符串可以通過分析過程轉(zhuǎn)化為多個值。Lucene 不關(guān)心這些值是字符串、數(shù)字或日期–所有的值都被當做 不透明字節(jié) 。

當我們在 Lucene 中索引一個文檔時，每個字段的值都被添加到相關(guān)字段的倒排索引中。你也可以將未處理的原始數(shù)據(jù) 存儲 起來，以便這些原始數(shù)據(jù)在之后也可以被檢索到。

6.2、類型是如何實現(xiàn)的

Elasticsearch 類型是 以 Lucene 處理文檔的這個方式為基礎(chǔ)來實現(xiàn)的。一個索引可以有多個類型，這些類型的文檔可以存儲在相同的索引中。

Lucene 沒有文檔類型的概念，每個文檔的類型名被存儲在一個叫 _type 的元數(shù)據(jù)字段上。 當我們要檢索某個類型的文檔時, Elasticsearch 通過在 _type 字段上使用過濾器限制只返回這個類型的文檔。

Lucene 也沒有映射的概念。 映射是 Elasticsearch 將復(fù)雜 JSON 文檔 映射 成 Lucene 需要的扁平化數(shù)據(jù)的方式。

例如，在 user 類型中， name 字段的映射可以聲明這個字段是 string 類型，并且它的值被索引到名叫 name 的倒排索引之前，需要通過 whitespace 分詞器分析：

"name": {"type": "string","analyzer": "whitespace" }

6.3、避免類型陷阱

這導(dǎo)致了一個有趣的思想實驗： 如果有兩個不同的類型，每個類型都有同名的字段，但映射不同（例如：一個是字符串一個是數(shù)字），將會出現(xiàn)什么情況？

簡單回答是，Elasticsearch 不會允許你定義這個映射。當你配置這個映射時，將會出現(xiàn)異常。

詳細回答是，每個 Lucene 索引中的所有字段都包含一個單一的、扁平的模式。一個特定字段可以映射成 string 類型也可以是 number 類型，但是不能兩者兼具。因為類型是 Elasticsearch 添加的 優(yōu)于 Lucene 的額外機制（以元數(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"}}}}} }

每個類型定義兩個字段 (分別是?"name"/"address"?和?"timestamp"/"message"?)。它們看起來是相互獨立的，但在后臺 Lucene 將創(chuàng)建一個映射，如:

{"data": {"mappings": {"_type": {"type": "string","index": "not_analyzed"},"name": {"type": "string"}"address": {"type": "string"}"timestamp": {"type": "long"}"message": {"type": "string"}}} }

注: 這不是真實有效的映射語法，只是用于演示

對于整個索引，映射在本質(zhì)上被 扁平化 成一個單一的、全局的模式。這就是為什么兩個類型不能定義沖突的字段：當映射被扁平化時，Lucene 不知道如何去處理。

6.4、類型結(jié)論

那么，這個討論的結(jié)論是什么？技術(shù)上講，多個類型可以在相同的索引中存在，只要它們的字段不沖突（要么因為字段是互為獨占模式，要么因為它們共享相同的字段）。

重要的一點是: 類型可以很好的區(qū)分同一個集合中的不同細分。在不同的細分中數(shù)據(jù)的整體模式是相同的（或相似的）。

類型不適合 完全不同類型的數(shù)據(jù) 。如果兩個類型的字段集是互不相同的，這就意味著索引中將有一半的數(shù)據(jù)是空的（字段將是 稀疏的 ），最終將導(dǎo)致性能問題。在這種情況下，最好是使用兩個單獨的索引。

總結(jié)：

• 正確: 將 kitchen 和 lawn-care 類型放在 products 索引中, 因為這兩種類型基本上是相同的模式
• 錯誤: 將 products 和 logs 類型放在 data 索引中, 因為這兩種類型互不相同。應(yīng)該將它們放在不同的索引中。

7、根對象

映射的最高一層被稱為 根對象 ，它可能包含下面幾項：

• 一個 properties 節(jié)點，列出了文檔中可能包含的每個字段的映射?
  各種元數(shù)據(jù)字段，它們都以一個下劃線開頭，例如 _type 、 _id 和 _source
• 設(shè)置項，控制如何動態(tài)處理新的字段，例如 analyzer 、 dynamic_date_formats 和 dynamic_templates
• 其他設(shè)置，可以同時應(yīng)用在根對象和其他 object 類型的字段上，例如 enabled 、 dynamic 和 include_in_all

7.1、屬性

我們已經(jīng)在 核心簡單域類型 和 復(fù)雜核心域類型 章節(jié)中介紹過文檔字段和屬性的三個 最重要的設(shè)置：

• type?
  字段的數(shù)據(jù)類型，例如 string 或 date
• index?
  字段是否應(yīng)當被當成全文來搜索（ analyzed ），或被當成一個準確的值（ not_analyzed ），還是完全不可被搜索（ no ）
• analyzer?
  確定在索引和搜索時全文字段使用的 analyzer

我們將在本書的后續(xù)部分討論其他字段類型，例如 ip 、 geo_point 和 geo_shape 。

7.2、元數(shù)據(jù): _source 字段

默認地，Elasticsearch 在 _source 字段存儲代表文檔體的JSON字符串。和所有被存儲的字段一樣， _source 字段在被寫入磁盤之前先會被壓縮。

這個字段的存儲幾乎總是我們想要的，因為它意味著下面的這些：

• 搜索結(jié)果包括了整個可用的文檔——不需要額外的從另一個的數(shù)據(jù)倉庫來取文檔。
• 如果沒有 _source 字段，部分 update 請求不會生效。
• 當你的映射改變時，你需要重新索引你的數(shù)據(jù)，有了_source字段你可以直接從Elasticsearch這樣做，而不必從另一個（通常是速度更慢的）數(shù)據(jù)倉庫取回你的所有文檔。
• 當你不需要看到整個文檔時，單個字段可以從 _source 字段提取和通過 get 或者 search 請求返回。
• 調(diào)試查詢語句更加簡單，因為你可以直接看到每個文檔包括什么，而不是從一列id猜測它們的內(nèi)容。

然而，存儲 _source 字段的確要使用磁盤空間。如果上面的原因?qū)δ銇碚f沒有一個是重要的，你可以用下面的映射禁用 _source 字段：

PUT /my_index {"mappings": {"my_type": {"_source": {"enabled": false}}} }

在一個搜索請求里，你可以通過在請求體中指定 _source 參數(shù)，來達到只獲取特定的字段的效果：

GET /_search {"query": { "match_all": {}},"_source": [ "title", "created" ] }

這些字段的值會從 _source 字段被提取和返回，而不是返回整個 _source 。

7.3、元數(shù)據(jù): _all 字段

在 輕量 搜索 中，我們介紹了 _all 字段：一個把其它字段值 當作一個大字符串來索引的特殊字段。 query_string 查詢子句(搜索 ?q=john )在沒有指定字段時默認使用 _all 字段。

_all 字段在新應(yīng)用的探索階段，當你還不清楚文檔的最終結(jié)構(gòu)時是比較有用的。你可以使用這個字段來做任何查詢，并且有很大可能找到需要的文檔：

GET /_search {"match": {"_all": "john smith marketing"} }

隨著應(yīng)用的發(fā)展，搜索需求變得更加明確，你會發(fā)現(xiàn)自己越來越少使用 _all 字段。 _all 字段是搜索的應(yīng)急之策。通過查詢指定字段，你的查詢更加靈活、強大，你也可以對相關(guān)性最高的搜索結(jié)果進行更細粒度的控制。如果你不再需要 _all 字段，你可以通過下面的映射來禁用：

PUT /my_index/_mapping/my_type {"my_type": {"_all": { "enabled": false }} }

通過 include_in_all 設(shè)置來逐個控制字段是否要包含在 _all 字段中，默認值是 true。在一個對象(或根對象)上設(shè)置include_in_all 可以修改這個對象中的所有字段的默認行為。

你可能想要保留 _all 字段作為一個只包含某些特定字段的全文字段，例如只包含 title，overview，summary 和 tags。 相對于完全禁用_all 字段，你可以為所有字段默認禁用 include_in_all 選項，僅在你選擇的字段上啟用：

PUT /my_index/my_type/_mapping {"my_type": {"include_in_all": false,"properties": {"title": {"type": "string","include_in_all": true},...}} }

記住，_all 字段僅僅是一個 經(jīng)過分詞的 string 字段。它使用默認分詞器來分析它的值，不管這個值原本所在字段指定的分詞器。就像所有 string 字段，你可以配置 _all 字段使用的分詞器：

PUT /my_index/my_type/_mapping {"my_type": {"_all": { "analyzer": "whitespace" }} }

7.4、元數(shù)據(jù)：文檔標識

文檔標識與四個元數(shù)據(jù)字段 相關(guān)：

_id?
文檔的 ID 字符串?
_type?
文檔的類型名?
_index?
文檔所在的索引?
_uid?
_type 和 _id 連接在一起構(gòu)造成 type#id?
默認情況下， _uid 字段是被存儲（可取回）和索引（可搜索）的。 _type 字段被索引但是沒有存儲， _id 和 _index 字段則既沒有被索引也沒有被存儲，這意味著它們并不是真實存在的。

盡管如此，你仍然可以像真實字段一樣查詢 _id 字段。Elasticsearch 使用 _uid 字段來派生出 _id 。 雖然你可以修改這些字段的 index 和 store 設(shè)置，但是基本上不需要這么做。

8、動態(tài)映射

當 Elasticsearch 遇到文檔中以前 未遇到的字段，它用 dynamic mapping 來確定字段的數(shù)據(jù)類型并自動把新的字段添加到類型映射。

有時這是想要的行為有時又不希望這樣。通常沒有人知道以后會有什么新字段加到文檔，但是又希望這些字段被自動的索引。也許你只想忽略它們。如果Elasticsearch是作為重要的數(shù)據(jù)存儲，可能就會期望遇到新字段就會拋出異常，這樣能及時發(fā)現(xiàn)問題。

幸運的是可以用 dynamic 配置來控制這種行為 ，可接受的選項如下：

true?
動態(tài)添加新的字段–缺省?
false?
忽略新的字段?
strict?
如果遇到新字段拋出異常?
配置參數(shù) dynamic 可以用在根 object 或任何 object 類型的字段上。你可以將 dynamic 的默認值設(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é)點對象 my_type 進行同樣的操作會失敗：

PUT /my_index/my_type/1 {"title": "This throws a StrictDynamicMappingException","new_field": "Fail!" }

9、缺省映射

通常，一個索引中的所有類型共享相同的字段和設(shè)置。?default?映射更加方便地指定通用設(shè)置，而不是每次創(chuàng)建新類型時都要重復(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 }}} }

default?映射也是一個指定索引 dynamic templates 的好方法。

10、重新索引你的數(shù)據(jù)

盡管可以增加新的類型到索引中，或者增加新的字段到類型中，但是不能添加新的分析器或者對現(xiàn)有的字段做改動。 如果你那么做的話，結(jié)果就是那些已經(jīng)被索引的數(shù)據(jù)就不正確， 搜索也不能正常工作。

對現(xiàn)有數(shù)據(jù)的這類改變最簡單的辦法就是重新索引：用新的設(shè)置創(chuàng)建新的索引并把文檔從舊的索引復(fù)制到新的索引。

字段 _source 的一個優(yōu)點是在Elasticsearch中已經(jīng)有整個文檔。你不必從源數(shù)據(jù)中重建索引，而且那樣通常比較慢。

為了有效的重新索引所有在舊的索引中的文檔，用 scroll 從舊的索引檢索批量文檔 ， 然后用 bulk API 把文檔推送到新的索引中。

從Elasticsearch v2.3.0開始， Reindex API 被引入。它能夠?qū)ξ臋n重建索引而不需要任何插件或外部工具。

批量重新索引

同時并行運行多個重建索引任務(wù)，但是你顯然不希望結(jié)果有重疊。正確的做法是按日期或者時間 這樣的字段作為過濾條件把大的重建索引分成小的任務(wù)：

GET /old_index/_search?scroll=1m {"query": {"range": {"date": {"gte": "2014-01-01","lt": "2014-02-01"}}},"sort": ["_doc"],"size": 1000 }

如果舊的索引持續(xù)會有變化，你希望新的索引中也包括那些新加的文檔。那就可以對新加的文檔做重新索引， 但還是要用日期類字段過濾來匹配那些新加的文檔。

11、索引別名和零停機

在前面提到的，重建索引的問題是必須更新應(yīng)用中的索引名稱。 索引別名就是用來解決這個問題的！

索引 別名 就像一個快捷方式或軟連接，可以指向一個或多個索引，也可以給任何一個需要索引名的API來使用。別名 帶給我們極大的靈活性，允許我們做下面這些：

• 在運行的集群中可以無縫的從一個索引切換到另一個索引
• 給多個索引分組 (例如， last_three_months)
• 給索引的一個子集創(chuàng)建 視圖

在后面我們會討論更多關(guān)于別名的使用。現(xiàn)在，我們將解釋怎樣使用別名在零停機下從舊索引切換到新索引。

有兩種方式管理別名： _alias 用于單個操作， _aliases 用于執(zhí)行多個原子級操作。

在本章中，我們假設(shè)你的應(yīng)用有一個叫 my_index 的索引。事實上， my_index 是一個指向當前真實索引的別名。真實索引包含一個版本號： my_index_v1 ， my_index_v2 等等。

首先，創(chuàng)建索引 my_index_v1 ，然后將別名 my_index 指向它：

PUT /my_index_v1 PUT /my_index_v1/_alias/my_index

你可以檢測這個別名指向哪一個索引：

GET /*/_alias/my_index

或哪些別名指向這個索引：

GET /my_index_v1/_alias/*

兩者都會返回下面的結(jié)果：

{"my_index_v1" : {"aliases" : {"my_index" : { }}} }

然后，我們決定修改索引中一個字段的映射。當然，我們不能修改現(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)被正確地重索引了，我們就將別名指向新的索引。

一個別名可以指向多個索引，所以我們在添加別名到新索引的同時必須從舊的索引中刪除它。這個操作需要原子化，這意味著我們需要使用 _aliases 操作：

POST /_aliases {"actions": [{ "remove": { "index": "my_index_v1", "alias": "my_index" }},{ "add": { "index": "my_index_v2", "alias": "my_index" }}] }

你的應(yīng)用已經(jīng)在零停機的情況下從舊索引遷移到新索引了。

總結(jié)

以上是生活随笔為你收集整理的深入理解ElasticSearch（八）：索引管理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。