原英文版地址: https://www.elastic.co/guide/en/elasticsearch/reference/7.7/mapping-store.html, 原文档版权归 www.elastic.co 所有
本地英文版地址: ../en/mapping-store.html
重要: 此版本不会发布额外的bug修复或文档更新。最新信息请参考 当前版本文档。
Elasticsearch Guide [7.7] » Mapping » Mapping parameters » store
« similarity term_vector »

storeedit

By default, field values are indexed to make them searchable, but they are not stored. This means that the field can be queried, but the original field value cannot be retrieved.

Usually this doesn’t matter. The field value is already part of the _source field, which is stored by default. If you only want to retrieve the value of a single field or of a few fields, instead of the whole _source, then this can be achieved with source filtering.

In certain situations it can make sense to store a field. For instance, if you have a document with a title, a date, and a very large content field, you may want to retrieve just the title and the date without having to extract those fields from a large _source field:

PUT my_index
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "store": true 
      },
      "date": {
        "type": "date",
        "store": true 
      },
      "content": {
        "type": "text"
      }
    }
  }
}

PUT my_index/_doc/1
{
  "title":   "Some short title",
  "date":    "2015-01-01",
  "content": "A very long content field..."
}

GET my_index/_search
{
  "stored_fields": [ "title", "date" ] 
}

The title and date fields are stored.

This request will retrieve the values of the title and date fields.

Stored fields returned as arrays

For consistency, stored fields are always returned as an array because there is no way of knowing if the original field value was a single value, multiple values, or an empty array.

If you need the original value, you should retrieve it from the _source field instead.

Another situation where it can make sense to make a field stored is for those that don’t appear in the _source field (such as copy_to fields).

« similarity term_vector »