背景

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

• 列類型：type
• 指定了該列的數據類型，常用的有text, keyword, date, long, double,boolean以及 object和nested,不同的類型也有對應的不同查詢方式，創建之后是不能修改的；
• 是否可索引：index
• 該index選項控制字段值是否被索引。它接受true or false,并且默認為true. 未索引的字段不可查詢,當然也不能做為排序字段。

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

方案1：運用reindex

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

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

如原來索引的mapping如下

PUT /users
{
  "mappings" : {
    "properties": {
      "user_id": {
        "type": "long"
      }
    }
  }
}

//加一了兩條數據
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重新索引可按以下步驟操作

操作步驟

第一步：創建新的索引new_users將user_id的類型定義成keyword

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

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

控制我們的應用系統，數據停寫不再向老索引中寫數據，并且最好對老索引進行只讀操作設置，保證在reindex的過程中，不要生產新數據，導致新老索數據不一致；

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

第三步：將原user索引中的數據遷移到new_users中

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

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

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

該dynamic設置控制是否可以動態添加新字段。它接受三種設置：

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

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

第四步：切換到使用新的mapping

1. 可以將應用系統中的配置改成新索引
2. 也可以通過索引的別名的方式為新索引增加原來老索引的別名來操作，為索引增加別名參考文檔：Add index alias API，在增加別名前，需要刪除原來的老索引；

//為索引增加別名 基本格式
PUT /<index>/_alias/<alias>
POST /<index>/_alias/<alias>

//為new_users索引增加別名users
PUT /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
}

方案優劣分析

【優點】操作簡單，官方方案

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

【缺點】數據量大遷移耗時長

當數據最大時，這個數據遷移會比較耗時

結論

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

方案2：運用multi-fields

為不同的目的以不同的方式索引同一個字段通常很有用。這就是multi-fields的目的。例如，一個string 字段可以映射為text用于全文搜索的字段，也可以映射keyword為用于排序或聚合的字段;在這個方案中，應用的是mapping參數fields來對同一個列，定義多種數據類型；詳細[【官方文檔】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的子屬性；在我們正常寫數據user_id時，會自動生成這兩個索引，一個是long類型的user_id，以及keyword類型的user_id.raw（注意這里有個點，跟子對象訪問方式一樣）;在put mapping時，type參數必需給，并且需要跟原來的類型一致，fields中新定義的子屬性可以多個；

【可選】第二步：歷史數據更新

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

POST /users/_update_by_query 

{
   "query":{
       "exists":{
           "field":"user_id"
       }
   },
   "script":{
       "source":"ctx._source.user_id=ctx._source.user_id ",
       "lang":"painless"
   }
}

// query 部分為需要更新數據過濾條件，可根據業務規則寫
// script 更數據的邏輯，這個基本可以不改

方案優劣分析

【優點】不影響原索引，同一列可以定義多種類型

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

【缺點】老數據不會自動創建子索引，多出額外的存儲

老數據不會自動創建索引，因為需要多出新的索引來，會增加額外的存儲；

結論

1、需要對多一列創建多個索引類型時，是一個非常推薦的方案；2、對于新索引，只有新業務使用，對老數據沒有訴求的，也非常推薦該方案；

方案3：運用copy_to

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

操作步驟

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

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

這個方案與方案2：multi-fields 基本是一樣的，只是創建列的方式不同，優缺點都一樣；

參考資料

• [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:權威指南》Mapping -- Mapping parameters -- fields(multi-fields)

作者：京東零售 周德東

來源：京東云開發者社區 轉載請注明來源