Elasticsearch Mapping型別修改

boo發表於2023-02-17
ElasticsearchAPP型別

背景

通常資料庫進行分庫分表後，目前比較常規的作法，是透過將資料異構到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設定控制是否可以動態新增新欄位。它接受三種設定：

值 說明
true 新檢測到的欄位被新增到對映中。（預設）; 新增的資料型別的規則，可以參考：dynamic-mapping
false 忽略新檢測到的欄位。這些欄位不會被編入索引，因此將無法搜尋，但仍會出現在_source返回的命中欄位中。這些欄位不會新增到對映中，必須明確新增新欄位。
strict 如果檢測到新欄位，則會丟擲異常並拒絕文件。必須將新欄位顯式新增到對映中。

同時將原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 基本是一樣的，只是建立列的方式不同，優缺點都一樣；

參考資料

相關文章