parent-field.asciidoc 4.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157
  1. [[mapping-parent-field]]
  2. === `_parent` field
  3. A parent-child relationship can be established between documents in the same
  4. index by making one mapping type the parent of another:
  5. [source,js]
  6. --------------------------------------------------
  7. PUT my_index
  8. {
  9. "mappings": {
  10. "my_parent": {},
  11. "my_child": {
  12. "_parent": {
  13. "type": "my_parent" <1>
  14. }
  15. }
  16. }
  17. }
  18. PUT my_index/my_parent/1 <2>
  19. {
  20. "text": "This is a parent document"
  21. }
  22. PUT my_index/my_child/2?parent=1 <3>
  23. {
  24. "text": "This is a child document"
  25. }
  26. PUT my_index/my_child/3?parent=1&refresh=true <3>
  27. {
  28. "text": "This is another child document"
  29. }
  30. GET my_index/my_parent/_search
  31. {
  32. "query": {
  33. "has_child": { <4>
  34. "type": "my_child",
  35. "query": {
  36. "match": {
  37. "text": "child document"
  38. }
  39. }
  40. }
  41. }
  42. }
  43. --------------------------------------------------
  44. // CONSOLE
  45. <1> The `my_parent` type is parent to the `my_child` type.
  46. <2> Index a parent document.
  47. <3> Index two child documents, specifying the parent document's ID.
  48. <4> Find all parent documents that have children which match the query.
  49. See the <<query-dsl-has-child-query,`has_child`>> and
  50. <<query-dsl-has-parent-query,`has_parent`>> queries,
  51. the <<search-aggregations-bucket-children-aggregation,`children`>> aggregation,
  52. and <<parent-child-inner-hits,inner hits>> for more information.
  53. The value of the `_parent` field is accessible in aggregations
  54. and scripts, and may be queried with the
  55. <<query-dsl-parent-id-query, `parent_id` query>>:
  56. [source,js]
  57. --------------------------
  58. GET my_index/_search
  59. {
  60. "query": {
  61. "parent_id": { <1>
  62. "type": "my_child",
  63. "id": "1"
  64. }
  65. },
  66. "aggs": {
  67. "parents": {
  68. "terms": {
  69. "field": "_parent", <2>
  70. "size": 10
  71. }
  72. }
  73. },
  74. "script_fields": {
  75. "parent": {
  76. "script": {
  77. "inline": "doc['_parent']" <3>
  78. }
  79. }
  80. }
  81. }
  82. --------------------------
  83. // CONSOLE
  84. // TEST[continued]
  85. <1> Querying the id of the `_parent` field (also see the <<query-dsl-has-parent-query,`has_parent` query>> and the <<query-dsl-has-child-query,`has_child` query>>)
  86. <2> Aggregating on the `_parent` field (also see the <<search-aggregations-bucket-children-aggregation,`children`>> aggregation)
  87. <3> Accessing the `_parent` field in scripts
  88. ==== Parent-child restrictions
  89. * The parent and child types must be different -- parent-child relationships
  90. cannot be established between documents of the same type.
  91. * The `_parent.type` setting can only point to a type that doesn't exist yet.
  92. This means that a type cannot become a parent type after it has been
  93. created.
  94. * Parent and child documents must be indexed on the same shard. The `parent`
  95. ID is used as the <<mapping-routing-field,routing>> value for the child,
  96. to ensure that the child is indexed on the same shard as the parent.
  97. This means that the same `parent` value needs to be provided when
  98. <<docs-get,getting>>, <<docs-delete,deleting>>, or <<docs-update,updating>>
  99. a child document.
  100. ==== Global ordinals
  101. Parent-child uses <<global-ordinals,global ordinals>> to speed up joins.
  102. Global ordinals need to be rebuilt after any change to a shard. The more
  103. parent id values are stored in a shard, the longer it takes to rebuild the
  104. global ordinals for the `_parent` field.
  105. Global ordinals, by default, are built lazily: the first parent-child query or
  106. aggregation after a refresh will trigger building of global ordinals. This can
  107. introduce a significant latency spike for your users. You can use
  108. <<global-ordinals,eager_global_ordinals>> to shift the cost of building global
  109. ordinals from query time to refresh time, by mapping the `_parent` field as follows:
  110. [source,js]
  111. --------------------------------------------------
  112. PUT my_index
  113. {
  114. "mappings": {
  115. "my_parent": {},
  116. "my_child": {
  117. "_parent": {
  118. "type": "my_parent",
  119. "eager_global_ordinals": true
  120. }
  121. }
  122. }
  123. }
  124. --------------------------------------------------
  125. // CONSOLE
  126. The amount of heap used by global ordinals can be checked as follows:
  127. [source,sh]
  128. --------------------------------------------------
  129. # Per-index
  130. GET _stats/fielddata?human&fields=_parent
  131. # Per-node per-index
  132. GET _nodes/stats/indices/fielddata?human&fields=_parent
  133. --------------------------------------------------
  134. // CONSOLE