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

標籤：其他

上一篇：袋鼠云產品功能更新報告04期丨2023年首次，產品升級“狂飆”

下一篇：主鍵、唯一索引、聚集索引、非聚集索引，你真知道他們的區別么？