mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-08 05:58:44 +00:00
53874bf5a6
The work around for resolving `now` doesn't need to be used for aliases, becuase alias filters are parsed at search time. However it can't be removed, because the percolator relies on it. Parent/child can be specified again in alias filters, this now works again because alias filters are parsed at search time. Parent/child will also use the late query parse work around, to make sure to do the final preparations when the search context is around. This allows the aliases api to validate the parent/child queries without failing because there is no search context. Closes #10485
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"
|
|
--------------------------------------------------
|