_id field

Each document has an _id that uniquely identifies it, which is indexed so that documents can be looked up either with the GET API or the ids query. The _id can either be assigned at indexing time, or a unique _id can be generated by Elasticsearch. The _id field has limited configurability in the mappings; see Parameters for _id fields.

The value of the _id field is accessible in queries such as term, terms, match, and query_string.

				
					# Example documents
				PUT my-index-000001/_doc/1
					{
  "text": "Document with ID 1"
}
				PUT my-index-000001/_doc/2?refresh=true
					{
  "text": "Document with ID 2"
}
				GET my-index-000001/_search
					{
  "query": {
    "terms": {
      "_id": [ "1", "2" ]
    }
  }
}
		

1. Querying on the _id field (also see the ids query)

The _id field is restricted from use in aggregations, sorting, and scripting. In case sorting or aggregating on the _id field is required, it is advised to duplicate the content of the _id field into another field that has doc_values enabled.

The _id field accepts the following mapping parameter:

mode

Controls how the _id value is stored and retrieved. Accepted values are:

• document — The _id is stored as a stored field and indexed. This is the standard behaviour. This is default for document based index modes.
• columnar — The _id is stored as binary doc values and indexed, but not as a stored field. This reduces per-document overhead when the index uses a columnar storage layout (for example, the logsdb_columnar index mode) where doc values are already being read for most fields. This is the default for columnar based index modes.

				PUT my-columnar-index
					{
  "mappings": {
    "_id": {
      "mode": "columnar"
    }
  }
}