Keyword type family

keyword fields support synthetic _source in their default configuration. Synthetic _source cannot be used together with a normalizer or copy_to.

By default, synthetic source sorts keyword fields and removes duplicates. For example:

PUT idx
{
  "mappings": {
    "_source": { "mode": "synthetic" },
    "properties": {
      "kwd": { "type": "keyword" }
    }
  }
}
PUT idx/_doc/1
{
  "kwd": ["foo", "foo", "bar", "baz"]
}

Will become:

{
  "kwd": ["bar", "baz", "foo"]
}

If a keyword field sets store to true then order and duplicates are preserved. For example:

PUT idx
{
  "mappings": {
    "_source": { "mode": "synthetic" },
    "properties": {
      "kwd": { "type": "keyword", "store": true }
    }
  }
}
PUT idx/_doc/1
{
  "kwd": ["foo", "foo", "bar", "baz"]
}

Will become:

{
  "kwd": ["foo", "foo", "bar", "baz"]
}

Values longer than ignore_above are preserved but sorted to the end. For example:

PUT idx
{
  "mappings": {
    "_source": { "mode": "synthetic" },
    "properties": {
      "kwd": { "type": "keyword", "ignore_above": 3 }
    }
  }
}
PUT idx/_doc/1
{
  "kwd": ["foo", "foo", "bang", "bar", "baz"]
}

Will become:

{
  "kwd": ["bar", "baz", "foo", "bang"]
}

Constant keyword is a specialization of the keyword field for the case that all documents in the index have the same value.

PUT logs-debug
{
  "mappings": {
    "properties": {
      "@timestamp": {
        "type": "date"
      },
      "message": {
        "type": "text"
      },
      "level": {
        "type": "constant_keyword",
        "value": "debug"
      }
    }
  }
}

constant_keyword supports the same queries and aggregations as keyword fields do, but takes advantage of the fact that all documents have the same value per index to execute queries more efficiently.

It is both allowed to submit documents that don’t have a value for the field or that have a value equal to the value configured in mappings. The two below indexing requests are equivalent:

POST logs-debug/_doc
{
  "date": "2019-12-12",
  "message": "Starting up Elasticsearch",
  "level": "debug"
}

POST logs-debug/_doc
{
  "date": "2019-12-12",
  "message": "Starting up Elasticsearch"
}

However providing a value that is different from the one configured in the mapping is disallowed.

In case no value is provided in the mappings, the field will automatically configure itself based on the value contained in the first indexed document. While this behavior can be convenient, note that it means that a single poisonous document can cause all other documents to be rejected if it had a wrong value.

Before a value has been provided (either through the mappings or from a document), queries on the field will not match any documents. This includes exists queries.

The value of the field cannot be changed after it has been set.

The following mapping parameters are accepted:

The wildcard field type is a specialized keyword field for unstructured machine-generated content you plan to search using grep-like wildcard and regexp queries. The wildcard type is optimized for fields with large values or high cardinality.

Internally the wildcard field indexes the whole field value using ngrams and stores the full string. The index is used as a rough filter to cut down the number of values that are then checked by retrieving and checking the full values. This field is especially well suited to run grep-like queries on log lines. Storage costs are typically lower than those of keyword fields but search speeds for exact matches on full terms are slower. If the field values share many prefixes, such as URLs for the same website, storage costs for a wildcard field may be higher than an equivalent keyword field.

You index and search a wildcard field as follows

PUT my-index-000001
{
  "mappings": {
    "properties": {
      "my_wildcard": {
        "type": "wildcard"
      }
    }
  }
}

PUT my-index-000001/_doc/1
{
  "my_wildcard" : "This string can be quite lengthy"
}

GET my-index-000001/_search
{
  "query": {
    "wildcard": {
      "my_wildcard": {
        "value": "*quite*lengthy"
      }
    }
  }
}

The following parameters are accepted by wildcard fields: