Why were ES Mapping Types removed in ES v6.0?

What are Mapping Types?

In Elasticsearch, each document belongs to an Index and a Type. An Index can be considered as a Database whereas a Type can be seen as a Table when compared to a Relational Database. A mapping Type was a logical partition of an object with other objects which belonged to other Mapping Types in the same Index.

Each Mapping Type has its own fields. For example, a type of user can have following fields:

{
"id" : 123,
"name" : "Shubham",
"website" : 1
}

Another Mapping Type in the same index website can have following fields which are completely different from the user type:

{
"id" : 1,
"title" : "LinuxHint",
"link" : "https://linuxhint.com/"
}

While searching for a document in an index, the search could have been limited to a single document by specifying a single field as:

GET idx_name/user,website/_search
{
"query": {
"match": {
"id": 1
}
}
}

The _type field of the documents was combined with its _id to generate a _uid field so documents with same _id could exist in a single index.

Read Elasticsearch Tutorial for Beginners for a deeper understanding of Elasticsearch Architecture and get started with it with Install ElasticSearch on Ubuntu.

Why are Mapping Types being removed?

Just like what we said above while explaining how Index and Types were similar to a Database and a Table in a Relational Database, Elasticsearch team thought the same but this wasn’t the case as Lucene Engine doesn’t follow the same analogy. This is because of the following reasons:

In a Relational Database, tables are independent of each other and name of the columns, even if they are same have no relationship between them. This is not the case with fields in mapping types as in ES, fields with the same name are treated as same Lucene Engine field internally.
In the example above, the field _id in user type and website type is stored in the same field and should have exactly the same type which can lead to frustration and confusion.
Storing entities with no fields in common stops Lucene to compress documents effectively.

Alternatives to Mapping Types

Although the decision has been made, we still need to separate different types of data. Now, the first alternative is to separate documents in their own index which has two advantages:

Now that data is common in every index, Lucene can very easily apply its own data compression techniques.
Now that all documents in an index have same fields, full-text search abilities increase phenomenally as scoring of each document has increased.

Another alternative to separating the data is maintaining a custom _type field in each document we insert, like:

PUT db_name/doc/123
{
"type": "user",
"id": 123,
"name": "Shubham",
"website": 1
}

PUT db_name/doc/website
{
"type": "website",
"id": 1,
"title": "LinuxHint",
"link": "https://linuxhint.com/"
}

This is an excellent usage if you’re looking for a complete custom solution.

Schedual for removal of Mapping Types

As removing Mapping Types is a big change, ES team is doing the process slowly. Here is a schedule for the roll out extracted from elastic.co:

Elasticsearch 7.x

The type parameter in URLs are optional. For instance, indexing a document no longer requires a document type.
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.

Conclusion

In this lesson, we looked at why were Elasticsearch Mapping types removed and will be completely unsupported in coming versions.