在ES6.0.0及更高的版本中，建立的索引只能包含一個對映型別。在6.0.0以下的版本中建立的一個索引對映多個型別的索引在6.0.0版本中繼續發揮作用，但是將在7.0.0中完全刪除。

自第一次釋出彈出式搜尋以來，每個文件都儲存在一個索引中，並分配一個對映型別。對映型別用於表示被索引的文件或實體的型別，例如Twitter索引可能具有user型別和tweet型別。

每個對映型別都可以有自己的欄位，因此使用者型別可能有一個FuleNyNoX欄位、一個使用者名稱稱欄位和一個電子郵件欄位，而Twitter型別可以有一個內容欄位、一個TwiteEdEdAT欄位和一個使用者型別，一個使用者名稱稱欄位。

每個文件都有一個包含型別名稱的“型別”元欄位，並且可以通過指定URL中的型別名稱來限制搜尋到一個或多個型別：

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

_type欄位和文件的_id欄位結合生成一個UUID欄位，因此在同一個索引中可以存在不同型別的具有相同SyID的文件。

為什麼刪除多個型別對映？

我們談到了一個類似於SQL資料庫中的“資料庫”的“索引”，一個“型別”相當於一個“表”。

這是一個糟糕的類比，導致了錯誤的假設。在SQL資料庫中，表是相互獨立的。一個表中的列與另一個表中具有相同名稱的列沒有關聯。這不是對映型別中的欄位的情況。

在彈性搜尋索引中，在不同的對映型別中具有相同名稱的欄位由相同的Lucene欄位在內部支援。換句話說，使用上面的示例，使用者型別中的UsRyNoNd欄位與Twitter型別中的UsSeriNoX欄位完全相同的欄位，並且兩個使用者名稱稱欄位必須在兩種型別中都具有相同的對映（定義）。

例如，當您希望刪除一個型別中的日期欄位和在同一索引中的另一個型別中的布林欄位時，這可能會導致挫折。

除此之外，在同一索引中儲存很少或沒有相同欄位的不同實體會導致稀疏資料並干擾Lucene高效壓縮文件的能力。

如何解決多個型別對映問題？

第一種選擇是每個文件型別都有索引。您可以在推特索引和使用者索引中儲存Twitter，而不是在單個Twitter索引中儲存Twitter和使用者。索引是完全獨立的，因此在索引之間不會有欄位型別衝突。
這種方法有兩個好處：

• 資料更可能是密集的，因此受益於Lucene中使用的壓縮技術。
• 在全文搜尋中用於評分的術語更可能是準確的，因為同一索引中的所有文件都代表單個實體。
  每個索引可以適當地為它包含的文件的數量大小：你可以為user使用較少數量的分片和用於Twitter的更大數量的分片。

當然，在叢集中存在多少個主碎片是有限度的，所以您可能不想浪費一個只有幾千個文件集合的碎片。在這種情況下，您可以實現自己的自定義型別欄位，該欄位將以類似於舊型別的方式工作。

舊的實現方式：

PUT twitter
{
  "mappings": {
    "user": {
      "properties": {
        "name": { "type": "text" },
        "user_name": { "type": "keyword" },
        "email": { "type": "keyword" }
      }
    },
    "tweet": {
      "properties": {
        "content": { "type": "text" },
        "user_name": { "type": "keyword" },
        "tweeted_at": { "type": "date" }
      }
    }
  }
}

PUT twitter/user/kimchy
{
  "name": "Shay Banon",
  "user_name": "kimchy",
  "email": "shay@kimchy.com"
}

PUT twitter/tweet/1
{
  "user_name": "kimchy",
  "tweeted_at": "2017-10-24T09:00:00Z",
  "content": "Types are going away"
}

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

我們可以通過新增自定義型別欄位來實現相同的事情：
新的實現方式：

PUT twitter
{
  "mappings": {
    "doc": {
      "properties": {
        "type": { "type": "keyword" }, 
        "name": { "type": "text" },
        "user_name": { "type": "keyword" },
        "email": { "type": "keyword" },
        "content": { "type": "text" },
        "tweeted_at": { "type": "date" }
      }
    }
  }
}

PUT twitter/doc/user-kimchy
{
  "type": "user", 
  "name": "Shay Banon",
  "user_name": "kimchy",
  "email": "shay@kimchy.com"
}

PUT twitter/doc/tweet-1
{
  "type": "tweet", 
  "user_name": "kimchy",
  "tweeted_at": "2017-10-24T09:00:00Z",
  "content": "Types are going away"
}

GET twitter/_search
{
  "query": {
    "bool": {
      "must": {
        "match": {
          "user_name": "kimchy"
        }
      },
      "filter": {
        "match": {
          "type": "tweet" 
        }
      }
    }
  }
}

以前，父子關係是由一個對映型別為父函式和一個或多個其他對映型別的子代來表示的。沒有型別，我們就不能再使用這個語法了。父子特徵將一如既往地起作用，除了表示文件之間關係的方式已被更改為使用新的聯接欄位。

各個版本對型別操作的變化如下：

Elasticsearch 5.6.0

• Setting index.mapping.single_type: true on an index will enable the
  single-type-per-index behaviour which will be enforced in 6.0.
• The join field replacement for parent-child is available on indices
  created in 5.6.

Elasticsearch 6.x

• Indices created in 5.x will continue to function in 6.x as they did
  in 5.x.
• Indices created in 6.x only allow a single-type per index. Any name
  can be used for the type, but there can be only one.
• The _type name can no longer be combined with the _id to form the
  _uid field. The _uid field has become an alias for the _id field.
• New indices no longer support the old-style of parent/child and
  should use the join field instead. The _default_ mapping type is
  deprecated.

Elasticsearch 7.x

• The type parameter in URLs are optional. For instance, indexing a
  document no longer requires a document type.
• The GET|PUT _mapping APIs support a query string parameter
  (include_type_name) which indicates whether the body should include a
  layer for the type name. It defaults to true. 7.x indices which don’t
  have an explicit type will use the dummy type name _doc.
• The _default_ mapping type is removed.

Elasticsearch 8.x

• The type parameter is no longer supported in URLs.
• The include_type_name parameter defaults to false.

Elasticsearch 9.x

• The include_type_name parameter is removed.

The Reindex API 可以用於將多型別索引轉換為單型別索引：

這個第一個例子把我們的Twitter索引分成一個tweet索引和一個user索引：

PUT users
{
  "settings": {
    "index.mapping.single_type": true
  },
  "mappings": {
    "user": {
      "properties": {
        "name": {
          "type": "text"
        },
        "user_name": {
          "type": "keyword"
        },
        "email": {
          "type": "keyword"
        }
      }
    }
  }
}

PUT tweets
{
  "settings": {
    "index.mapping.single_type": true
  },
  "mappings": {
    "tweet": {
      "properties": {
        "content": {
          "type": "text"
        },
        "user_name": {
          "type": "keyword"
        },
        "tweeted_at": {
          "type": "date"
        }
      }
    }
  }
}

POST _reindex
{
  "source": {
    "index": "twitter",
    "type": "user"
  },
  "dest": {
    "index": "users"
  }
}

POST _reindex
{
  "source": {
    "index": "twitter",
    "type": "tweet"
  },
  "dest": {
    "index": "tweets"
  }
}

自定義型別欄位

下一個示例新增自定義型別欄位，並將其設定為原始型別的值。它還將型別新增到yid中，以防存在不同型別的具有衝突ID的文件：

PUT new_twitter
{
  "mappings": {
    "doc": {
      "properties": {
        "type": {
          "type": "keyword"
        },
        "name": {
          "type": "text"
        },
        "user_name": {
          "type": "keyword"
        },
        "email": {
          "type": "keyword"
        },
        "content": {
          "type": "text"
        },
        "tweeted_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';
    """
  }
}