使用 Elasticsearch 映射重命名現有字段

1. 概述

在使用 Elasticsearch 時，我們可能會遇到需要修改資料和元資料的情況。例如，重新命名索引對應中的現有欄位。我們可能需要考慮命名規範、結構不一致或提高清晰度等問題。然而，Elasticsearch 本身並沒有直接重命名欄位的機制。實際上，重新命名欄位需要建立一個新索引，並在應用轉換腳本的同時重新索引現有資料。

本教學將深入探討 Elasticsearch 中的欄位重命名。首先，我們將了解 Elasticsearch 為何不支援直接重命名欄位以及有哪些替代方案。之後，我們將診斷欄位結構問題，以確保重新命名過程順利進行。接下來，我們將探討如何安全地執行基於重新索引的重新命名操作。最後，我們還將討論在需要重新命名欄位時，如何最大限度地減少停機時間並維護資料完整性的最佳實踐。

2. 字段重命名支持

理論上，重命名欄位看似簡單，但Elasticsearch 的設計使得直接重命名成為不可能。這其中有幾個原因。讓我們逐一探討。

2.1. 不可更改的 Lucene 片段

Elasticsearch 將索引文件儲存在不可變的 Lucene 段中。由於文檔直接儲存在段中，因此除非重寫文檔，否則欄位名稱會保持不變。換句話說，僅更新映射無法更改儲存的字段標識符。

理解這個概念至關重要，因為它將概念從重命名轉變為刪除和重建。

2.2.描述性非轉換映射

映射定義描述了字段的幾個屬性：

• 索引
• 分析
• 貯存

然而，映射並不會改變現有文件。即使我們更新映射，將欄位名稱從new_field替換為old_field ，所有先前已索引的文件仍然會包含old_field直到重新索引為止。因此，我們需要額外步驟才能真正實現重新命名。

2.3. 地圖更新時不進行資料重寫

即使舊文檔中不包含新字段，Elasticsearch 也接受新字段的映射更新。這意味著聲明新欄位的更新不會以任何方式驗證或更改現有資料。因此，嘗試透過新增新的對應屬性來變更欄位名稱只會導致新舊文件中出現兩個相同的欄位。此外，後者可能導致長期數據不一致。

3. 診斷場結構問題

在執行重新命名操作之前，必須先了解索引的目前狀態。這樣，我們可以防止意外資料遺失、錯誤的映射變更或產生不一致結果的重新索引過程。

3.1 檢查索引映射

首先，我們可以使用_mapping API 檢查像x_index這樣的索引的映射，以查看所有欄位及其類型：

GET x_index/_mapping

這樣，我們就能發現差異並規劃欄位重命名操作。此外，我們還能突出顯示是否存在因先前資料導入問題或損壞而導致的多個相似欄位。

3.2 檢查已儲存的文檔

關鍵在於，映射可能無法反映文件中存在的字段，尤其是在啟用動態映射時。

在這種情況下，檢查實際文件或許可以確認目前使用的是哪個欄位名稱：

GET x_index/_search

 {

 "_source": true,

 "query": { "match_all": {} },

 "size": 5

 }

如果文件包含old_field但映射包含new_field ，則表示攝取邏輯尚未更新或重新索引。

3.3.審查資料攝取管道和客戶端邏輯

資料攝取管道、日誌處理器、序列化器和應用程式程式碼都會影響索引文件的結構。具體來說，管道可能會動態引入字段，或者即使在映射更新後仍然繼續寫入過時的字段名稱。驗證資料攝取路徑可以確保重新索引的變更在套用後保持一致。

4. 透過重新索引進行欄位重新命名

總而言之，由於 Elasticsearch 無法直接重命名字段，正確的解決方案是建立一個包含更新後映射的新索引，然後使用轉換腳本將現有資料重新索引到該索引中。這種方法可以確保資料一致性，維護資料完整性，並符合 Elasticsearch 的設計理念。

4.1. 使用更新後的映射建立新索引

首先，我們建立一個具有所需欄位名稱的新索引。值得注意的是，這還包括任何設定或分析器：

PUT x_index_v2

 {

 "mappings": {

 "properties": {

 "new_field": { "type": "text" }

 }

 }

 }

確保映射正確至關重要。否則，新索引的行為可能與原始索引不同，導致根本性的資料不一致。

4.2. 使用重新命名腳本重新索引數據

_reindex API 在複製作業期間會將文件從舊索引轉換為新索引。具體來說，腳本可以將old_field的值轉移到new_field ，從而刪除過時的欄位：

POST _reindex

 {

 "source": { "index": "x_index" },

 "dest": { "index": "x_index_v2" },

 "script": {

 "source": """

 if (ctx._source.containsKey('old_field')) {

 ctx._source.new_field = ctx._source.remove('old_field');

 }

 """

 }

 }

如前所述，重新命名操作實際上是刪除並重新建立欄位。這確保了新索引中的所有文件都使用一致的新欄位名稱。

4.3. 使用別名實現零停機切換

索引別名有助於確保無縫遷移。重新索引完成後，將別名從舊索引切換到新索引，即可立即使用更新的結構：

POST _aliases

 {

 "actions": [

 { "remove": { "index": "x_index", "alias": "current" }},

 { "add": { "index": "x_index_v2", "alias": "current" }}

 ]

 }

因此，我們無需重新配置客戶端，只需在需要時切換回別名即可實現回溯。這種機制避免了停機時間，確保流程順暢無阻。

5. 最佳實踐

重命名欄位時需要採取一些步驟和預防措施：

• 確保分析儀、過濾器和現場設定符合預期，可防止意外問題。
• 重新索引操作耗時較長，因此建議在測試環境中執行該過程，以防止意外的資料損壞。
• 重新索引可能會對叢集資源造成沉重的負擔，因此設定維護視窗或限制存取量可能是一個不錯的選擇。
• 應更新資料攝取管道和客戶端，以便在重新索引開始之前寫入new_field
• 別名可以實現高效率的索引，並在索引產生之間轉換時避免停機，此外還能簡化回滾作業。

如果不遵循這些建議，可能會導致系統難以維護、不穩定，甚至出現不一致和腐敗現象。

6. 總結

在本文中，我們了解到在 Elasticsearch 中重新命名欄位通常意味著重新建立和重新索引。

從本質上講，正確的方法不是依賴映射更新，而是建立一個新索引，定義更新後的映射，並透過轉換腳本重新索引資料。

總之，透過驗證映射、審查攝取行為、使用別名以及仔細控制重新索引操作，在任何 Elasticsearch 環境中，欄位重新命名都成為安全且可預測的過程。