Elasticsearch Mapping類型修改

背景

通常資料庫進行分庫分表後，目前比較常規的作法，是通過將數據異構到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重新索引可按以下步驟操作

操作步驟

第一步：創建新的mapping 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中新定義的屬性，可以多個；

方案優劣分析

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

通過這方式不會影響原來的索引數據，可以不修改現在的應用程式，查詢方式與數據寫入方式，都是可以按原來的執行，對應用方無感知，只需要在使用新類型時使用即可，可以說影響是最小的；
同時只是做了一個定義，執行速度是非常快的，對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)

本文來自博客園，作者：阿布-boo，轉載請註明原文鏈接：https://www.cnblogs.com/salted/p/17130111.html