一 前言

官方解釋?zhuān)?a rel="external nofollow" target="_blank">https://www.elastic.co/guide/en/elasticsearch/reference/6.0/removal-of-types.html

在elasticsearch6.0.0或更高的版本中創(chuàng)建索引僅能包含單個(gè)映射類(lèi)型。在具有多種映射類(lèi)型的5.x版本中創(chuàng)建的索引將繼續(xù)像以前一樣在elasticsearch6.x中運(yùn)行。類(lèi)型將在elasticsearch7.0.0中的API中棄用，并在8.0.0中完全刪除。

二 什么是映射類(lèi)型？

從elasticsearch發(fā)布以來(lái)，每個(gè)文檔都存儲(chǔ)在單個(gè)索引中并分配了單個(gè)映射類(lèi)型。映射類(lèi)型用于表示要編制索引的文檔或?qū)嶓w的類(lèi)型。例如微博（twitter）索引可能具有用戶(hù)（user）類(lèi)型和推文（tweet）兩個(gè)類(lèi)型。

每種映射類(lèi)型都可以有自己的字段，因此用戶(hù)（user）類(lèi)型可能有 full_name、user_name、email字段；而推文（tweet）類(lèi)型可能有content、tweet_at字段和用戶(hù)（user）類(lèi)型的user_name字段。每個(gè)文檔都有一個(gè)_type包含類(lèi)型名稱(chēng)的元字段，通過(guò)在URL中指定類(lèi)型名稱(chēng)，搜索可以限制為一種或多種類(lèi)型：

GET twitter/user,tweet/_search
{
  "query":{
    "match":{
      "user_name":"kimchy"
    }
  }
}

該_type字段與文檔組合_id以生成_uid字段，因此具有相同類(lèi)型的文檔_id可以存儲(chǔ)在單個(gè)索引中。
映射類(lèi)型也用于在文檔中建立父子關(guān)系，因此類(lèi)型的文檔question可以是類(lèi)型文檔的父類(lèi)answer。
扯了半天淡，一切不都是挺好的嘛？那還為啥要?jiǎng)h除映射類(lèi)型呢？

三 為什么要?jiǎng)h除映射類(lèi)型？

最初（其實(shí)到現(xiàn)在），為了便于理解elasticsearch的數(shù)據(jù)組織，通常拿elasticsearch和關(guān)系型數(shù)據(jù)庫(kù)做對(duì)比，比如我們談到一個(gè)es索引（index）時(shí)，通常將它比喻為類(lèi)似于SQL數(shù)據(jù)庫(kù)中的database，而類(lèi)型（type）等同于SQL數(shù)據(jù)庫(kù)中的表。

這真是一個(gè)糟糕的比喻！讓我們有了錯(cuò)誤理解。因?yàn)樵赟QL數(shù)據(jù)庫(kù)中，表彼此獨(dú)立，一個(gè)表中的字段與另一個(gè)表中具有相同名稱(chēng)的字段無(wú)關(guān)，而映射類(lèi)型中的字段不是這種情況。

在elasticsearch的索引中，不同映射類(lèi)型具有相同名稱(chēng)的字段在內(nèi)部由相同的Lucene字段支持。換句話說(shuō)，使用上面的示例，用戶(hù)（user）類(lèi)型中的user_name字段存儲(chǔ)在和推文（tweet）類(lèi)型中的user_name字段完全相同的字段中，而且兩種類(lèi)型中的user_name字段必須具有相同的映射（定義）。

當(dāng)我們希望刪除一個(gè)類(lèi)型的日期字段和同一個(gè)索引中另一個(gè)類(lèi)型的布爾字段時(shí)，這可能會(huì)導(dǎo)致挫敗感（可以理解為刪除失敗）。

最重要的是，在同一索引中存儲(chǔ)具有很少或沒(méi)有共同字段的不同實(shí)體會(huì)導(dǎo)致稀疏數(shù)據(jù)并干擾Lucene有效壓縮文檔的能力。

出于這些原因，我們決定從elasticsearch中刪除映射類(lèi)型的概念。

四 映射類(lèi)型的替代方法

4.1 將映射類(lèi)型分開(kāi)存儲(chǔ)在索引中

第一種方法是每個(gè)文檔類(lèi)型都有一個(gè)索引，例如微博（twitter）索引中，我們可以將推文（tweet）類(lèi)型和用戶(hù)（user）類(lèi)型分開(kāi)，分別存儲(chǔ)在獨(dú)立的索引中。這樣兩個(gè)相互的索引就不會(huì)引起字段沖突了。

這中方法有兩個(gè)好處：

• 數(shù)據(jù)更可能是密集的，因此受益于Lucene中使用的壓縮技術(shù)。
• 用于全文搜索評(píng)分的詞條統(tǒng)計(jì)將會(huì)更精確，應(yīng)為同一索引中的所有文檔都代表單個(gè)實(shí)體。

每個(gè)索引的大小可以根據(jù)其包含的文檔數(shù)量進(jìn)行適當(dāng)?shù)恼{(diào)整，比如我們?yōu)橛脩?hù)（user）類(lèi)型分配較少的主分片，而為推文（tweet）類(lèi)型分配較多的主分片。

4.2 自定義類(lèi)型字段回到頂部

當(dāng)然了，集群中可以存儲(chǔ)多少個(gè)主分片是有限制的，我們不希望僅為幾千個(gè)文檔的集合而浪費(fèi)整個(gè)分片。在這種情況下，我們可以實(shí)現(xiàn)自己的自定義type字段，該字段的工作方式與舊的_type相似。
還是上面微博（twitter）例子，最初，它的映射類(lèi)型看起來(lái)是這樣的：

PUT twitter
{
  "mappings": {
    "user":{
      "properties":{
        "name":{
          "type":"text"
        },
        "user_name":{
          "type":"keyword"
        },
        "email":{
          "type":"keyword"
        }
      }
    },
    "tweet":{
      "properties":{
        "content":{
          "type":"text"
        },
        "user_name":{
          "type":"keyword"
        },
        "tweet_at":{
          "type":"date"
        }
      }
    }
  }
}
PUT twitter/user/kimchy
{
  "name":"狗子",
  "user_name":"二狗子",
  "email":"dog@twodog.com"
}
PUT twitter/tweet/1
{
  "name":"kimchy",
  "tweet_ad":"2019-04-30T10:26:20Z",
  "content":"單身狗求包養(yǎng)"
}
GET twitter/tweet/_search
{
  "query": {
    "match": {
      "user_name": "kimchy"
    }
  }
}

如上示例，請(qǐng)?jiān)?.x及以下版本測(cè)試
我們也可以通過(guò)添加自定義type字段來(lái)實(shí)現(xiàn)相同目的：

PUT twitter
{
  "mappings": {
    "doc":{
      "properties":{
        "type":{
          "type":"keyword"
        },
        "name":{
          "type":"text"
        },
        "user_name":{
          "type":"keyword"
        },
        "email":{
          "type":"text"
        },
        "content":{
          "type":"text"
        },
        "tweet_at":{
          "type":"date"
        }
      }  
    }
  }
}
PUT twitter/doc/user-kimchy
{
  "type":"user",
  "name":"狗子",
  "user_name":"二狗子",
  "email":"dog@twodog.com"
}
PUT twitter/doc/tweet-1
{
  "type":"tweet",
  "user_name":"kimchy",
  "tweet_at":"2019-04-30T10:26:20Z",
  "content":"單身狗求包養(yǎng)"
}
GET twitter/_search
{
  "query": {
    "bool": {
      "must":[
        {
          "match": {
            "user_name": "kimchy"
          }
        }
      ],
      "filter": {
        "match":{
          "type":"tweet"
        }
      }
    }
  }
}

上述示例6.5.4版本運(yùn)行無(wú)誤。

五 沒(méi)有映射類(lèi)型的父/子

以前，通過(guò)將一個(gè)映射類(lèi)型設(shè)置為父級(jí)，將一個(gè)或多個(gè)其他映射類(lèi)型設(shè)置為子級(jí)來(lái)表示父子關(guān)系?，F(xiàn)在，沒(méi)有了多類(lèi)型，我們就不能再使用這種語(yǔ)法了。除了表示文檔之間的關(guān)系方式已改為使用新的join字段之外，父子特征將繼續(xù)像以前一樣運(yùn)行。

六 刪除映射類(lèi)型的計(jì)劃

這個(gè)刪除映射類(lèi)型的計(jì)劃，對(duì)于用戶(hù)來(lái)說(shuō)是一個(gè)很大的變化，所以我們?cè)噲D讓它盡可能輕松，更改將如下所示：

在elasticsearch5.6.0中：

• index.mapping.single_type:true在索引上設(shè)置將啟用在6.0中強(qiáng)制執(zhí)行的單索引類(lèi)型。
• 父子的join字段替換可用于在5.6中創(chuàng)建索引。

在elasticsearch6.x中：

• 在5.x中創(chuàng)建的索引將繼續(xù)在6.x中運(yùn)行，就像在5.x中一樣。
• 在6.x中創(chuàng)建的索引僅允許每個(gè)索引使用單一類(lèi)型，任何字段都可以用于該類(lèi)型，但必須是唯一的。
• 該_type名稱(chēng)可以不再與_id組合形成_uid字段，_uid字段已成為_(kāi)id字段的別名。
• 新索引不再支持舊的父/子關(guān)系，而是應(yīng)該使用連接字段。
• 不推薦使用_default_mapping類(lèi)型。
• 在6.7中，索引創(chuàng)建、索引模板和映射API支持查詢(xún)字符串參數(shù)（include_type_name），該參數(shù)僅表示請(qǐng)求和響應(yīng)是否應(yīng)該包含類(lèi)型名稱(chēng)，默認(rèn)為true，應(yīng)該設(shè)置為一個(gè)顯式值，以便準(zhǔn)備升級(jí)到7.0。未設(shè)置include_type_name將導(dǎo)致一個(gè)棄用警告，沒(méi)有顯式類(lèi)型的索引將使用默認(rèn)的類(lèi)型名稱(chēng)_doc。

在elasticsearch7.x中：

• 不推薦在請(qǐng)求中指定類(lèi)型。例如，索引文檔不再需要文檔類(lèi)型。對(duì)于自動(dòng)生成的id，新的索引API在顯式ids和POST {index_name}/_doc的情況下是PUT {index_name}/_doc/{id}。
• 索引創(chuàng)建，索引模板和映射API中的include_type_name參數(shù)將默認(rèn)為false，未設(shè)置參數(shù)將導(dǎo)致啟動(dòng)警告。
• 刪除了_default_mapping類(lèi)型。

在elasticsearch8.x中：

• 不在支持在請(qǐng)求中指定類(lèi)型。
• include_type_name參數(shù)已刪除。

七將多類(lèi)型索引遷移到單一類(lèi)型

Reindex API可用于將多類(lèi)型索引轉(zhuǎn)換為單類(lèi)型索引。下面的例子可以在Elasticsearch 5.6或Elasticsearch 6.x中使用。在6.x中，不需要指定index.mapping。默認(rèn)為單一類(lèi)型。

7.1 每種文檔類(lèi)型的索引

第一個(gè)示例將微博（twitter）索引拆分為推文（tweets）索引和用戶(hù)（users）索引：

PUT users
{
  "mappings": {
    "user":{
      "properties":{
        "name":{
          "type":"text"
        },
        "user_name":{
          "type":"keyword"
        },
        "email":{
          "type":"keyword"
        }
      }
    }
  }
}
PUT tweets
{
  "mappings": {
    "tweet":{
      "properties":{
        "content":{
          "type":"text"
        },
        "user_name":{
          "type":"keyword"
        },
        "tweet_at":{
          "type":"date"
        }
      }
    }
  }
}
POST _reindex
{
  "source": {
    "index":"twitter",
    "type":"user"
  },
  "dest": {
    "index":"users"
  }
}
POST _reindex
{
  "source": {
    "index":"twitter",
    "type":"tweet"
  },
  "dest": {
    "index": "tweets"
  }
}

上述代碼在6.5.4版本中運(yùn)行無(wú)誤。

上述的示例意思是，在之前我們?cè)谖⒉╰witter）索引中，有兩個(gè)類(lèi)型（tweet和user）。

現(xiàn)在要將兩個(gè)類(lèi)型分開(kāi)，成為獨(dú)立的索引。

所以，首先先創(chuàng)建出各自的索引（tweets和users），然后通過(guò)POST _reindex來(lái)完成遷移工作。

7.2 自定義類(lèi)型字段

第二個(gè)示例添加自自定義的type字段，并將其設(shè)置為原始值_type。

它還添加了類(lèi)型到id，以防有任何不同類(lèi)型的文檔具有沖突的id：

PUT new_twitter
{
  "mappings": {
    "doc":{
      "properties":{
        "type":{
          "type":"keyword"
        },
        "name":{
          "type":"text"
        },
        "user_name":{
          "type":"keyword"
        },
        "email":{
          "type":"keyword"
        },
        "content":{
          "type":"text"
        },
        "tweet_at":{
          "type":"date"
        }
      }
    }
  }
}
POST _reindex
{
  "source": {
    "index":"twitter"
  },
  "dest":{
    "index": "new_twitter"
  },
  "script": {
    "source": """
      ctx._source.type = ctx._type;
      ctx._id = ctx._type + "-" + ctx._id;
      ctx._type = "doc";
    """
  }
}

上述代碼在6.5.4版本運(yùn)行無(wú)誤。

八 總結(jié)

總之，通篇看下來(lái)，如果對(duì)elasticsearch，尤其是各版本不太了解的話，這篇文檔看著索然無(wú)味！重要的是看不懂，如果我們是新手，接觸elasticsearch的時(shí)候，就是從6.x版本開(kāi)始的，那只要記得，一個(gè)索引下面只能創(chuàng)建一個(gè)類(lèi)型就行了，其中各字段都具有唯一性，如果在創(chuàng)建映射的時(shí)候，如果沒(méi)有指定文檔類(lèi)型，那么該索引的默認(rèn)索引類(lèi)型是_doc，不指定文檔id則會(huì)內(nèi)部幫我們生成一個(gè)id字符串。

以上就是Elasticsearch的刪除映射類(lèi)型操作示例的詳細(xì)內(nèi)容，更多關(guān)于Elasticsearch刪除映射類(lèi)型的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論