Elasticsearch supports the following simple field types:

When you index a document that contains a new field—​one previously not seen—​Elasticsearch will use dynamic mapping to try to guess the field type from the basic datatypes available in JSON, using the following rules:

We can view the mapping that Elasticsearch has for one or more types in one or more indices by using the /_mapping endpoint. At the start of this chapter, we already retrieved the mapping for type tweet in index gb:

GET /gb/_mapping/tweet

This shows us the mapping for the fields (called properties) that Elasticsearch generated dynamically from the documents that we indexed:

{
   "gb": {
      "mappings": {
         "tweet": {
            "properties": {
               "date": {
                  "type": "date",
                  "format": "strict_date_optional_time||epoch_millis"
               },
               "name": {
                  "type": "string"
               },
               "tweet": {
                  "type": "string"
               },
               "user_id": {
                  "type": "long"
               }
            }
         }
      }
   }
}

While the basic field datatypes are sufficient for many cases, you will often need to customize the mapping for individual fields, especially string fields. Custom mappings allow you to do the following:

The most important attribute of a field is the type. For fields other than string fields, you will seldom need to map anything other than type:

{
    "number_of_clicks": {
        "type": "integer"
    }
}

Fields of type string are, by default, considered to contain full text. That is, their value will be passed through an analyzer before being indexed, and a full-text query on the field will pass the query string through an analyzer before searching.

The two most important mapping attributes for string fields are index and analyzer.

{
    "tag": {
        "type":     "string",
        "index":    "not_analyzed"
    }
}

{
    "tweet": {
        "type":     "string",
        "analyzer": "english"
    }
}

You can specify the mapping for a type when you first create an index. Alternatively, you can add the mapping for a new type (or update the mapping for an existing type) later, using the /_mapping endpoint.

We can update a mapping to add a new field, but we can’t change an existing field from analyzed to not_analyzed.

To demonstrate both ways of specifying mappings, let’s first delete the gb index:

DELETE /gb

Then create a new index, specifying that the tweet field should use the english analyzer:

PUT /gb 
{
  "mappings": {
    "tweet" : {
      "properties" : {
        "tweet" : {
          "type" :    "string",
          "analyzer": "english"
        },
        "date" : {
          "type" :   "date"
        },
        "name" : {
          "type" :   "string"
        },
        "user_id" : {
          "type" :   "long"
        }
      }
    }
  }
}

Later on, we decide to add a new not_analyzed text field called tag to the tweet mapping, using the _mapping endpoint:

PUT /gb/_mapping/tweet
{
  "properties" : {
    "tag" : {
      "type" :    "string",
      "index":    "not_analyzed"
    }
  }
}

Note that we didn’t need to list all of the existing fields again, as we can’t change them anyway. Our new field has been merged into the existing mapping.

You can use the analyze API to test the mapping for string fields by name. Compare the output of these two requests:

GET /gb/_analyze
{
  "field": "tweet",
  "text": "Black-cats" 
}

GET /gb/_analyze
{
  "field": "tag",
  "text": "Black-cats" 
}

The tweet field produces the two terms black and cat, while the tag field produces the single term Black-cats. In other words, our mapping is working correctly.