top-children-query.asciidoc 2.8 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586
  1. [[query-dsl-top-children-query]]
  2. == Top Children Query
  3. deprecated[1.6.0, Use the `has_child` query instead]
  4. The `top_children` query runs the child query with an estimated hits
  5. size, and out of the hit docs, aggregates it into parent docs. If there
  6. aren't enough parent docs matching the requested from/size search
  7. request, then it is run again with a wider (more hits) search.
  8. The `top_children` also provide scoring capabilities, with the ability
  9. to specify `max`, `sum` or `avg` as the score type.
  10. One downside of using the `top_children` is that if there are more child
  11. docs matching the required hits when executing the child query, then the
  12. `total_hits` result of the search response will be incorrect.
  13. How many hits are asked for in the first child query run is controlled
  14. using the `factor` parameter (defaults to `5`). For example, when asking
  15. for 10 parent docs (with `from` set to 0), then the child query will
  16. execute with 50 hits expected. If not enough parents are found (in our
  17. example 10), and there are still more child docs to query, then the
  18. child search hits are expanded by multiplying by the
  19. `incremental_factor` (defaults to `2`).
  20. The required parameters are the `query` and `type` (the child type to
  21. execute the query on). Here is an example with all different parameters,
  22. including the default values:
  23. [source,js]
  24. --------------------------------------------------
  25. {
  26. "top_children" : {
  27. "type": "blog_tag",
  28. "query" : {
  29. "term" : {
  30. "tag" : "something"
  31. }
  32. },
  33. "score" : "max",
  34. "factor" : 5,
  35. "incremental_factor" : 2
  36. }
  37. }
  38. --------------------------------------------------
  39. [float]
  40. === Scope
  41. A `_scope` can be defined on the query allowing to run aggregations on the
  42. same scope name that will work against the child documents. For example:
  43. [source,js]
  44. --------------------------------------------------
  45. {
  46. "top_children" : {
  47. "_scope" : "my_scope",
  48. "type": "blog_tag",
  49. "query" : {
  50. "term" : {
  51. "tag" : "something"
  52. }
  53. }
  54. }
  55. }
  56. --------------------------------------------------
  57. [float]
  58. === Memory Considerations
  59. In order to support parent-child joins, all of the (string) parent IDs
  60. must be resident in memory (in the <<index-modules-fielddata,field data cache>>.
  61. Additionally, every child document is mapped to its parent using a long
  62. value (approximately). It is advisable to keep the string parent ID short
  63. in order to reduce memory usage.
  64. You can check how much memory is being used by the ID cache using the
  65. <<indices-stats,indices stats>> or <<cluster-nodes-stats,nodes stats>>
  66. APIS, eg:
  67. [source,js]
  68. --------------------------------------------------
  69. curl -XGET "http://localhost:9200/_stats/id_cache?pretty&human"
  70. --------------------------------------------------