parent-field.asciidoc 4.5 KB

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