55 lines
2.2 KiB
Plaintext
55 lines
2.2 KiB
Plaintext
[[mapping-parent-field]]
|
|
=== `_parent`
|
|
|
|
TIP: It is highly recommend to reindex all indices with `_parent` field created before version 2.x.
|
|
The reason for this is to gain from all the optimizations added with the 2.0 release.
|
|
|
|
The parent field mapping is defined on a child mapping, and points to
|
|
the parent type this child relates to. For example, in case of a `blog`
|
|
type and a `blog_tag` type child document, the mapping for `blog_tag`
|
|
should be:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
{
|
|
"blog_tag" : {
|
|
"_parent" : {
|
|
"type" : "blog"
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
|
|
The mapping is automatically stored and indexed (meaning it can be
|
|
searched on using the `_parent` field notation).
|
|
|
|
==== Limitations
|
|
|
|
The `_parent.type` setting can only point to a type that doesn't exist yet.
|
|
This means that a type can't become a parent type after is has been created.
|
|
|
|
The `parent.type` setting can't point to itself. This means self referential
|
|
parent/child isn't supported.
|
|
|
|
==== Global ordinals
|
|
|
|
Parent-child uses <<global-ordinals,global ordinals>> to speed up joins and global ordinals need to be rebuilt after any change to a shard.
|
|
The more parent id values are stored in a shard, the longer it takes to rebuild global ordinals for the `_parent` field.
|
|
|
|
Global ordinals, by default, are built lazily: the first parent-child query or aggregation after a refresh will trigger building of global ordinals.
|
|
This can introduce a significant latency spike for your users. You can use <<fielddata-loading,eager_global_ordinals>> to shift the cost of building global ordinals
|
|
from query time to refresh time, by mapping the _parent field as follows:
|
|
|
|
==== Memory usage
|
|
|
|
The only on heap memory used by parent/child is the global ordinals for the `_parent` field.
|
|
|
|
How much memory is used for the global ordianls for the `_parent` field in the fielddata cache
|
|
can be checked via the <<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
|
|
APIS, eg:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
curl -XGET "http://localhost:9200/_stats/fielddata?pretty&human&fielddata_fields=_parent"
|
|
--------------------------------------------------
|