1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586 |
- [[query-dsl-top-children-query]]
- == Top Children Query
- deprecated[1.6.0, Use the `has_child` query instead]
- The `top_children` query runs the child query with an estimated hits
- size, and out of the hit docs, aggregates it into parent docs. If there
- aren't enough parent docs matching the requested from/size search
- request, then it is run again with a wider (more hits) search.
- The `top_children` also provide scoring capabilities, with the ability
- to specify `max`, `sum` or `avg` as the score type.
- One downside of using the `top_children` is that if there are more child
- docs matching the required hits when executing the child query, then the
- `total_hits` result of the search response will be incorrect.
- How many hits are asked for in the first child query run is controlled
- using the `factor` parameter (defaults to `5`). For example, when asking
- for 10 parent docs (with `from` set to 0), then the child query will
- execute with 50 hits expected. If not enough parents are found (in our
- example 10), and there are still more child docs to query, then the
- child search hits are expanded by multiplying by the
- `incremental_factor` (defaults to `2`).
- The required parameters are the `query` and `type` (the child type to
- execute the query on). Here is an example with all different parameters,
- including the default values:
- [source,js]
- --------------------------------------------------
- {
- "top_children" : {
- "type": "blog_tag",
- "query" : {
- "term" : {
- "tag" : "something"
- }
- },
- "score" : "max",
- "factor" : 5,
- "incremental_factor" : 2
- }
- }
- --------------------------------------------------
- [float]
- === Scope
- A `_scope` can be defined on the query allowing to run aggregations on the
- same scope name that will work against the child documents. For example:
- [source,js]
- --------------------------------------------------
- {
- "top_children" : {
- "_scope" : "my_scope",
- "type": "blog_tag",
- "query" : {
- "term" : {
- "tag" : "something"
- }
- }
- }
- }
- --------------------------------------------------
- [float]
- === Memory Considerations
- In order to support parent-child joins, all of the (string) parent IDs
- must be resident in memory (in the <<index-modules-fielddata,field data cache>>.
- Additionally, every child document is mapped to its parent using a long
- value (approximately). It is advisable to keep the string parent ID short
- in order to reduce memory usage.
- You can check how much memory is being used by the ID cache using the
- <<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
- APIS, eg:
- [source,js]
- --------------------------------------------------
- curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
- --------------------------------------------------
|