docs/reference/elasticsearch/mapping-reference/mapping-source-field.md
The _source field contains the original JSON document body that was passed at index time. The _source field itself is not indexed (and thus is not searchable), but it is stored so that it can be returned when executing fetch requests, like get or search.
If disk usage is important to you, then consider the following options:
_source, which reconstructs source content at the time of retrieval instead of storing it on disk. This shrinks disk usage, at the cost of slower access to _source in Get and Search queries._source field completely. This shrinks disk usage but disables features that rely on _source._source [synthetic-source]:::{note} This feature requires a subscription. :::
Though very handy to have around, the source field takes up a significant amount of space on disk. Instead of storing source documents on disk exactly as you send them, Elasticsearch can reconstruct source content on the fly upon retrieval. To enable this feature, use the value synthetic for the index setting index.mapping.source.mode:
$$$enable-synthetic-source-example$$$
PUT idx
{
"settings": {
"index": {
"mapping": {
"source": {
"mode": "synthetic"
}
}
}
}
}
% TESTSETUP
While this on-the-fly reconstruction is generally slower than saving the source documents verbatim and loading them at query time, it saves a lot of storage space. Additional latency can be avoided by not loading _source field in queries when it is not needed.
Synthetic _source is supported by all field types. Depending on implementation details, field types have different properties when used with synthetic _source.
Most field types construct synthetic _source using existing data, most commonly doc_values and stored fields. For these field types, no additional space is needed to store the contents of _source field. Due to the storage layout of doc_values, the generated _source field undergoes modifications compared to the original document.
For all other field types, the original value of the field is stored as is, in the same way as the _source field in non-synthetic mode. In this case there are no modifications and field data in _source is the same as in the original document. Similarly, malformed values of fields that use ignore_malformed or ignore_above need to be stored as is. This approach is less storage efficient since data needed for _source reconstruction is stored in addition to other data required to index the field (like doc_values).
_source restrictions [synthetic-source-restrictions]Some field types have additional restrictions. These restrictions are documented in the synthetic _source section of the field type’s documentation.
Synthetic source is not supported in source-only snapshot repositories. To store indices that use synthetic _source, choose a different repository type.
_source modifications [synthetic-source-modifications]When synthetic _source is enabled, retrieved documents undergo some modifications compared to the original JSON.
Synthetic _source arrays are moved to leaves. For example:
$$$synthetic-source-leaf-arrays-example$$$
PUT idx/_doc/1
{
"foo": [
{
"bar": 1
},
{
"bar": 2
}
]
}
% TEST[s/$/\nGET idx/_doc/1?filter_path=_source\n/]
Will become:
{
"foo": {
"bar": [1, 2]
}
}
% TEST[s/^/{"_source":/ s/\n$/}/]
This can cause some arrays to vanish:
$$$synthetic-source-leaf-arrays-example-sneaky$$$
PUT idx/_doc/1
{
"foo": [
{
"bar": 1
},
{
"baz": 2
}
]
}
% TEST[s/$/\nGET idx/_doc/1?filter_path=_source\n/]
Will become:
{
"foo": {
"bar": 1,
"baz": 2
}
}
% TEST[s/^/{"_source":/ s/\n$/}/]
Synthetic source names fields as they are named in the mapping. When used with dynamic mapping, fields with dots (.) in their names are, by default, interpreted as multiple objects, while dots in field names are preserved within objects that have subobjects disabled. For example:
$$$synthetic-source-objecty-example$$$
PUT idx/_doc/1
{
"foo.bar.baz": 1
}
% TEST[s/$/\nGET idx/_doc/1?filter_path=_source\n/]
Will become:
{
"foo": {
"bar": {
"baz": 1
}
}
}
% TEST[s/^/{"_source":/ s/\n$/}/]
This impacts how source contents can be referenced in scripts. For instance, referencing a script in its original source form will return null:
"script": { "source": """ emit(params._source['foo.bar.baz']) """ }
% NOTCONSOLE
Instead, source references need to be in line with the mapping structure:
"script": { "source": """ emit(params._source['foo']['bar']['baz']) """ }
% NOTCONSOLE
or simply
"script": { "source": """ emit(params._source.foo.bar.baz) """ }
% NOTCONSOLE
The following field APIs are preferable as, in addition to being agnostic to the mapping structure, they make use of docvalues if available and fall back to synthetic source only when needed. This reduces source synthesizing, a slow and costly operation.
"script": { "source": """ emit(field('foo.bar.baz').get(null)) """ }
"script": { "source": """ emit($('foo.bar.baz', null)) """ }
% NOTCONSOLE
Synthetic _source fields are sorted alphabetically. The JSON RFC defines objects as "an unordered collection of zero or more name/value pairs" so applications shouldn’t care but without synthetic _source the original ordering is preserved and some applications may, counter to the spec, do something with that ordering.
Range field values (e.g. long_range) are always represented as inclusive on both sides with bounds adjusted accordingly. See examples.
geo_point values [synthetic-source-precision-loss-for-point-types]Values of geo_point fields are represented in synthetic _source with reduced precision. See examples.
It is possible to avoid synthetic source modifications for a particular object or field, at extra storage cost. This is controlled through param synthetic_source_keep with the following option:
none: synthetic source diverges from the original source as described above (default).arrays: arrays of the corresponding field or object preserve the original element ordering and duplicate elements. The synthetic source fragment for such arrays is not guaranteed to match the original source exactly, e.g. array [1, 2, [5], [[4, [3]]], 5] may appear as-is or in an equivalent format like [1, 2, 5, 4, 3, 5]. The exact format may change in the future, in an effort to reduce the storage overhead of this option. Additionally, if index.mapping.ignore_above or index.mapping.ignore_malformed index settings are enabled then malformed or ignored elements are always appended last in unspecified order.all: the source for both singleton instances and arrays of the corresponding field or object gets recorded. When applied to objects, the source of all sub-objects and sub-fields gets captured. Furthermore, the original source of arrays gets captured and appears in synthetic source with no modifications.For instance:
$$$create-index-with-synthetic-source-keep$$$
PUT idx_keep
{
"settings": {
"index": {
"mapping": {
"source": {
"mode": "synthetic"
}
}
}
},
"mappings": {
"properties": {
"path": {
"type": "object",
"synthetic_source_keep": "all"
},
"ids": {
"type": "integer",
"synthetic_source_keep": "arrays"
}
}
}
}
% TEST
$$$synthetic-source-keep-example$$$
PUT idx_keep/_doc/1
{
"path": {
"to": [
{ "foo": [3, 2, 1] },
{ "foo": [30, 20, 10] }
],
"bar": "baz"
},
"ids": [ 200, 100, 300, 100 ]
}
% TEST[s/$/\nGET idx_keep/_doc/1?filter_path=_source\n/]
returns the original source, with no array deduplication and sorting:
{
"path": {
"to": [
{ "foo": [3, 2, 1] },
{ "foo": [30, 20, 10] }
],
"bar": "baz"
},
"ids": [ 200, 100, 300, 100 ]
}
% TEST[s/^/{"_source":/ s/\n$/}/]
The option for capturing the source of arrays can be applied at index level, by setting index.mapping.synthetic_source_keep to arrays. This applies to all objects and fields in the index, except for the ones with explicit overrides of synthetic_source_keep set to none. In this case, the storage overhead grows with the number and sizes of arrays present in source of each document, naturally.
The following field types support synthetic source using data from doc_values or stored fields, and require no additional storage space to construct the _source field.
::::{note}
If you enable the ignore_malformed or ignore_above settings, then additional storage is required to store ignored field values for these types.
::::
aggregate_metric_doubleannotated-textbinarybooleanbytedatedate_nanosdense_vectordoubleflattenedfloatgeo_pointhalf_floathistogramintegeripkeywordlongrange typesscaled_floatshorttextversionwildcard_source field [disable-source-field]Though very handy to have around, the source field does incur storage overhead within the index. For this reason, it can be disabled as follows:
PUT my-index-000001
{
"mappings": {
"_source": {
"enabled": false
}
}
}
::::{warning}
Do not disable the _source field, unless absolutely necessary. If you disable it, the following critical features will not be supported:
update, update_by_query, and reindex APIs.::::
::::{note}
You can't disable the _source field for indices with index_mode set to logsdb or time_series.
::::
::::{tip}
If disk space is a concern, rather increase the compression level instead of disabling the _source.
::::
_source [include-exclude]An expert-only feature is the ability to prune the contents of the _source field after the document has been indexed, but before the _source field is stored.
::::{warning}
Removing fields from the _source has similar downsides to disabling _source, especially the fact that you cannot reindex documents from one Elasticsearch index to another. Consider using source filtering instead.
::::
::::{note} Source pruning is not available in {{serverless-short}} ::::
The includes/excludes parameters (which also accept wildcards) can be used as follows:
PUT logs
{
"mappings": {
"_source": {
"includes": [
"*.count",
"meta.*"
],
"excludes": [
"meta.description",
"meta.other.*"
]
}
}
}
PUT logs/_doc/1
{
"requests": {
"count": 10,
"foo": "bar" <1>
},
"meta": {
"name": "Some metric",
"description": "Some metric description", <1>
"other": {
"foo": "one", <1>
"baz": "two" <1>
}
}
}
GET logs/_search
{
"query": {
"match": {
"meta.other.foo": "one" <2>
}
}
}
_source field._source.