背景

通常數(shù)據(jù)庫進行分庫分表后，目前比較常規(guī)的作法，是通過將數(shù)據(jù)異構(gòu)到Elasticsearch來提供分頁列表查詢服務(wù)；在創(chuàng)建Elasticsearch索引時，基本都是會參考目前的業(yè)務(wù)需求、關(guān)系數(shù)據(jù)庫中的類型以及對數(shù)據(jù)的相關(guān)規(guī)劃來定義相關(guān)字段mapping的類型.在Elasticsearch的mapping中的列(或則叫屬性)，有幾個比較重要的參數(shù)(更多參數(shù)參考官方文檔)

列類型：type

【資料圖】

指定了該列的數(shù)據(jù)類型，常用的有text,keyword,date,long,double,boolean以及object和nested,不同的類型也有對應(yīng)的不同查詢方式，創(chuàng)建之后是不能修改的；

是否可索引：index

該index選項控制字段值是否被索引。它接受trueorfalse,并且默認為true. 未索引的字段不可查詢,當然也不能做為排序字段。

但是在實際的開發(fā)過程中，又會有需求對現(xiàn)有的mapping的type進行修改（類似對MySQL數(shù)據(jù)表的字段進行DDL操作）的訴求。比如商品上的價格price字段，按原來的業(yè)務(wù)分析，只需要提供數(shù)據(jù)返回即可，在創(chuàng)建索引時類型定義了keyword了，并且index設(shè)置成了false，這時我們需要根據(jù)價格的范圍查詢或則進行排序操作，就希望對mapping進行調(diào)整，將類型修改成數(shù)字類型，索引也需要加上；今天針對Elasticsearch的Mapping類型進行修改，討論幾個可行的方案

方案1：運用reindex

遇到問題第一時間，我們應(yīng)該是查詢官方文檔是否有相關(guān)的操作說明，在官方文檔中，確實還能找到對已有mapping更新的相關(guān)apiput-mapping,通過這個文檔，很快可以找到文檔中對修改已有mapping的列的方式（參考官方文檔），同時也提到的通過reindex的方式來修改已有類型的方式；

除了支持的mapping parameters外，您不能更改現(xiàn)有字段的映射或字段類型。更改現(xiàn)有字段可能會使已編制索引的數(shù)據(jù)無效。如果您需要更改字段的映射，請使用正確的映射創(chuàng)建一個新索引并將您的數(shù)據(jù)重新索引reindex到該索引中。

如原來索引的mapping如下

PUT /users{  "mappings" : {    "properties": {      "user_id": {        "type": "long"      }    }  }}//加一了兩條數(shù)據(jù)POST /users/_doc?refresh=wait_for{    "user_id" : 12345}POST /users/_doc?refresh=wait_for{    "user_id" : 12346}

這時想修改user_id的類型為keyword,我們直接是修改不了的。

//嘗試直接修改type，行不通，會報錯PUT /users/_mapping{    "properties": {        "user_id": {            "type": "keyword"        }    }}//報錯信息{  "error": {    "root_cause": [      {        "type": "illegal_argument_exception",        "reason": "mapper [user_id] of different type, current_type [long], merged_type [keyword]"      }    ],    "type": "illegal_argument_exception",    "reason": "mapper [user_id] of different type, current_type [long], merged_type [keyword]"  },  "status": 400}

按官方文檔說的reindex重新索引可按以下步驟操作

操作步驟第一步：創(chuàng)建新的索引new_users將user_id的類型定義成keyword

PUT /new_users{  "mappings" : {    "properties": {      "user_id": {        "type": "keyword"      }    }  }}

第二步：將原user索引標記為只讀

控制我們的應(yīng)用系統(tǒng)，數(shù)據(jù)停寫不再向老索引中寫數(shù)據(jù)，并且最好對老索引進行只讀操作設(shè)置，保證在reindex的過程中，不要生產(chǎn)新數(shù)據(jù)，導致新老索數(shù)據(jù)不一致；

//設(shè)置索引為讀寫的PUT /users/_settings{  "settings": {    "index.blocks.write": true  }}

第三步：將原user索引中的數(shù)據(jù)遷移到new_users中

POST /_reindex{  "source": {    "index": "users"  },  "dest": {    "index": "new_users"  }}

reindex還有很多的參數(shù)可以配置，包括從遠程的一個集群遷移數(shù)據(jù)都是可以的，詳細可參考：Reindex API

如果新的索引的mapping的定義與原索引的定義有差異的，會按新索引定義的dynamic規(guī)則進行數(shù)據(jù)的遷移，具體的，可以參考:dynamic

該dynamic設(shè)置控制是否可以動態(tài)添加新字段。它接受三種設(shè)置：

值	說明
true	新檢測到的字段被添加到映射中。（默認）; 新增的數(shù)據(jù)類型的規(guī)則，可以參考：dynamic-mapping
false	忽略新檢測到的字段。這些字段不會被編入索引，因此將無法搜索，但仍會出現(xiàn)在_source返回的命中字段中。這些字段不會添加到映射中，必須明確添加新字段。
strict	如果檢測到新字段，則會拋出異常并拒絕文檔。必須將新字段顯式添加到映射中。

同時將原user索引標記為可讀寫

//設(shè)置索引為可讀寫PUT /users/_settings{  "settings": {    "index.blocks.write": false  }}

第四步：切換到使用新的mapping可以將應(yīng)用系統(tǒng)中的配置改成新索引也可以通過索引的別名的方式為新索引增加原來老索引的別名來操作，為索引增加別名參考文檔：Add index alias API，在增加別名前，需要刪除原來的老索引；

//為索引增加別名 基本格式PUT //_alias/POST //_alias///為new_users索引增加別名usersPUT /new_users/_alias/users//沒有刪除老索引前，是增加不了別名的,需要先刪除老別名{  "error": {    "root_cause": [      {        "type": "invalid_alias_name_exception",        "reason": "Invalid alias name [users], an index exists with the same name as the alias",        "index_uuid": "8Rbq_32BTHC4CoO_CqWdXA",        "index": "users"      }    ],    "type": "invalid_alias_name_exception",    "reason": "Invalid alias name [users], an index exists with the same name as the alias",    "index_uuid": "8Rbq_32BTHC4CoO_CqWdXA",    "index": "users"  },  "status": 400}

方案優(yōu)劣分析【優(yōu)點】操作簡單，官方方案

該方案，不需要對原索引做操作，在線即可進行，并且操作步驟也簡單；也是官方文檔提供的方案。

【缺點】數(shù)據(jù)量大遷移耗時長

當數(shù)據(jù)最大時，這個數(shù)據(jù)遷移會比較耗時

結(jié)論

當數(shù)據(jù)量小時，并且希望mapping比較規(guī)整好看，該方案是比較推薦的。當數(shù)據(jù)量大時，可能該方案在數(shù)據(jù)遷移過程中會比較耗時，需要評估是否可行；

方案2：運用multi-fields

為不同的目的以不同的方式索引同一個字段通常很有用。這就是multi-fields的目的。例如，一個string字段可以映射為text用于全文搜索的字段，也可以映射keyword為用于排序或聚合的字段;在這個方案中，應(yīng)用的是mapping參數(shù)fields來對同一個列，定義多種數(shù)據(jù)類型；詳細[【官方文檔】multi-fields] (https://www.elastic.co/guide/en/elasticsearch/reference/7.5/multi-fields.html)

操作步驟第一步：為列增加fields屬性

還是以上面的users這個索引為例，我們還是想將user_id的類型定義成keyword；

PUT /users/_mapping{    "properties":{        "user_id":{            "type":"long",            "fields":{                "raw":{                    "type":"keyword"                }            }        }    }}

操作完成后，在users的user_id列下，就會多出一個raw的子屬性；在我們正常寫數(shù)據(jù)user_id時，會自動生成這兩個索引，一個是long類型的user_id，以及keyword類型的user_id.raw（注意這里有個點，跟子對象訪問方式一樣）;在put mapping時，type參數(shù)必需給，并且需要跟原來的類型一致，fields中新定義的子屬性可以多個；

【可選】第二步：歷史數(shù)據(jù)更新

針對歷史數(shù)據(jù)需要處理，可以借助_update_by_query來更新數(shù)據(jù)，只需要將原來的索引再寫一次，即可將新加的字段寫入數(shù)據(jù)。

POST /users/_update_by_query {   "query":{       "exists":{           "field":"user_id"       }   },   "script":{       "source":"ctx._source.user_id=ctx._source.user_id ",       "lang":"painless"   }}// query 部分為需要更新數(shù)據(jù)過濾條件，可根據(jù)業(yè)務(wù)規(guī)則寫// script 更數(shù)據(jù)的邏輯，這個基本可以不改

方案優(yōu)劣分析【優(yōu)點】不影響原索引，同一列可以定義多種類型

通過這方式不會影響原來的索引數(shù)據(jù)，可以不用修改現(xiàn)在的應(yīng)用程序的讀寫方式，對應(yīng)用程序一切按原來邏輯執(zhí)行，對應(yīng)用方無感知，非常優(yōu)化。只需要有使用新類型的場景使用即可，可以說影響是最小的；同時只是做了一個定義，執(zhí)行速度是非?？斓?，對Elasticsearch服務(wù)基本不會有太大影響；并且對于同一個列可以定義多個類型，比如商品名稱，在多國多語言環(huán)境下可以根據(jù)不同語言定義多個列，對應(yīng)使用不同的分詞器；

【缺點】老數(shù)據(jù)不會自動創(chuàng)建子索引，多出額外的存儲

老數(shù)據(jù)不會自動創(chuàng)建索引，因為需要多出新的索引來，會增加額外的存儲；

結(jié)論

1、需要對多一列創(chuàng)建多個索引類型時，是一個非常推薦的方案；2、對于新索引，只有新業(yè)務(wù)使用，對老數(shù)據(jù)沒有訴求的，也非常推薦該方案；

方案3：運用copy_to

copy_to是將多個字段的值，合并到一個字段中，便于搜索。但是也可以實現(xiàn)一個字段存在多個類型的需求。詳細參考【官方文檔】copy_to

操作步驟

還是用上面的users這個索引為例，為user_id創(chuàng)建一個copy列：user_id_raw類型定義成keyword

PUT /users/_mapping{    "properties":{        "user_id_raw":{          "type":"keyword",          "copy_to":"user_id"        }    }}

這個方案與方案2：multi-fields基本是一樣的，只是創(chuàng)建列的方式不同，優(yōu)缺點都一樣；

參考資料[1]【官方文檔】Mapping parameters[2]【官方文檔】Mapping Field datatypes[3] [【官方文檔】multi-fields] (https://www.elastic.co/guide/en/elasticsearch/reference/7.5/multi-fields.html)[4]Elasticsearch Rename Index[5]elasticSearch7.x—mapping中的fields屬性||copy_to配置（同一個字段兩種類型）[6]《Elasticsearch:權(quán)威指南》Mapping -- Mapping parameters -- fields(multi-fields)

作者：京東零售 周德東

來源：京東云開發(fā)者社區(qū) 轉(zhuǎn)載請注明來源

關(guān)鍵詞：