Elasticsearch 7.0 废弃mapping type原因及替代方案

Love The Way You Lie 2021-12-22 08:37 365阅读 0赞

# Removal of mapping types #

> Indices created in Elasticsearch 7.0.0 or later no longer accept a *default* mapping. Indices created in 6.x will continue to function as before in Elasticsearch 6.x. Types are deprecated in APIs in 7.0, with breaking changes to the index creation, put mapping, get mapping, put template, get template and get field mappings APIs.

# What are mapping types? #

Since the first release of Elasticsearch, each document has been stored in a single index and assigned a single mapping type. A mapping type was used to represent the type of document or entity being indexed, for instance a twitter index might have a user type and a tweet type.

Each mapping type could have its own fields, so the user type might have a full\_name field, a user\_name field, and an email field, while the tweet type could have a content field, a tweeted\_at field and, like the user type, a user\_name field.

Each document had a \_type meta-field containing the type name, and searches could be limited to one or more types by specifying the type name(s) in the URL:

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

The \_type field was combined with the document’s \_id to generate a \_uid field, so documents of different types with the same \_id could exist in a single index.

Mapping types were also used to establish a [parent-child relationship][] between documents, so documents of type question could be parents to documents of type answer.

# Why are mapping types being removed? #

Initially, we spoke about an “index” being similar to a “database” in an SQL database, and a “type” being equivalent to a “table”.

This was a bad analogy that led to incorrect assumptions. In an SQL database, tables are independent of each other. The columns in one table have no bearing on columns with the same name in another table. This is not the case for fields in a mapping type.

In an Elasticsearch index, fields that have the same name in different mapping types are backed by the same Lucene field internally. In other words, using the example above, the user\_name field in the user type is stored in exactly the same field as the user\_name field in the tweet type, and both user\_name fields must have the same mapping (definition) in both types.

This can lead to frustration when, for example, you want deleted to be a date field in one type and a boolean field in another type in the same index.

On top of that, storing different entities that have few or no fields in common in the same index leads to sparse data and interferes with Lucene’s ability to compress documents efficiently.

For these reasons, we have decided to remove the concept of mapping types from Elasticsearch.

# Alternatives to mapping types #

## Index per document type ##

The first alternative is to have an index per document type. Instead of storing tweets and users in a single twitter index, you could store tweets in the tweets index and users in the user index. Indices are completely independent of each other and so there will be no conflict of field types between indices.

This approach has two benefits:

*  Data is more likely to be dense and so benefit from compression techniques used in Lucene.
 *  The term statistics used for scoring in full text search are more likely to be accurate because all documents in the same index represent a single entity.

Each index can be sized appropriately for the number of documents it will contain: you can use a smaller number of primary shards for users and a larger number of primary shards for tweets.

## Custom type field ##

Of course, there is a limit to how many primary shards can exist in a cluster so you may not want to waste an entire shard for a collection of only a few thousand documents. In this case, you can implement your own custom type field which will work in a similar way to the old \_type.

Let’s take the user/tweet example above. Originally, the workflow would have looked something like this:

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"
        }
      }
    }

You can achieve the same thing by adding a custom type field as follows:

PUT twitter
    {
      "mappings": {
        "_doc": {
          "properties": {
            "type": { "type": "keyword" }, # 1
            "name": { "type": "text" },
            "user_name": { "type": "keyword" },
            "email": { "type": "keyword" },
            "content": { "type": "text" },
            "tweeted_at": { "type": "date" }
          }
        }
      }
    }
    
    PUT twitter/_doc/user-kimchy
    {
      "type": "user", # 2
      "name": "Shay Banon",
      "user_name": "kimchy",
      "email": "shay@kimchy.com"
    }
    
    PUT twitter/_doc/tweet-1
    {
      "type": "tweet", # 3
      "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" # 4
            }
          }
        }
      }
    }

> The explicit type field takes the place of the implicit \_type field.

# Parent/Child without mapping types #

Previously, a parent-child relationship was represented by making one mapping type the parent, and one or more other mapping types the children. Without types, we can no longer use this syntax. The parent-child feature will continue to function as before, except that the way of expressing the relationship between documents has been changed to use the new [join field][].

原文地址：[https://www.elastic.co/guide/en/elasticsearch/reference/7.2/removal-of-types.html\#removal-of-types][https_www.elastic.co_guide_en_elasticsearch_reference_7.2_removal-of-types.html_removal-of-types]

个人微信公众号：  
![这里写图片描述][SouthEast]

> 作者：jiankunking 出处：[http://blog.csdn.net/jiankunking][http_blog.csdn.net_jiankunking]

[parent-child relationship]: https://www.elastic.co/guide/en/elasticsearch/reference/7.2/mapping-parent-field.html
[join field]: https://www.elastic.co/guide/en/elasticsearch/reference/7.2/parent-join.html
[https_www.elastic.co_guide_en_elasticsearch_reference_7.2_removal-of-types.html_removal-of-types]: https://www.elastic.co/guide/en/elasticsearch/reference/7.2/removal-of-types.html#removal-of-types
[SouthEast]: /images/20211220/6469a0eda8214daea65151200a9080ff.png
[http_blog.csdn.net_jiankunking]: http://blog.csdn.net/jiankunking