fields.asciidoc 6.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227
  1. [[modules-scripting-fields]]
  2. === Accessing document fields and special variables
  3. Depending on where a script is used, it will have access to certain special
  4. variables and document fields.
  5. [float]
  6. == Update scripts
  7. A script used in the <<docs-update,update>>,
  8. <<docs-update-by-query,update-by-query>>, or <<docs-reindex,reindex>>
  9. API will have access to the `ctx` variable which exposes:
  10. [horizontal]
  11. `ctx._source`:: Access to the document <<mapping-source-field,`_source` field>>.
  12. `ctx.op`:: The operation that should be applied to the document: `index` or `delete`.
  13. `ctx._index` etc:: Access to <<mapping-fields,document meta-fields>>, some of which may be read-only.
  14. [float]
  15. == Search and Aggregation scripts
  16. With the exception of <<search-request-script-fields,script fields>> which are
  17. executed once per search hit, scripts used in search and aggregations will be
  18. executed once for every document which might match a query or an aggregation.
  19. Depending on how many documents you have, this could mean millions or billions
  20. of executions: these scripts need to be fast!
  21. Field values can be accessed from a script using
  22. <<modules-scripting-doc-vals,doc-values>>, or
  23. <<modules-scripting-stored,stored fields or `_source` field>>, which are explained below.
  24. [[scripting-score]]
  25. [float]
  26. === Accessing the score of a document within a script
  27. Scripts used in the <<query-dsl-function-score-query,`function_score` query>>,
  28. in <<search-request-sort,script-based sorting>>, or in
  29. <<search-aggregations,aggregations>> have access to the `_score` variable which
  30. represents the current relevance score of a document.
  31. Here's an example of using a script in a
  32. <<query-dsl-function-score-query,`function_score` query>> to alter the
  33. relevance `_score` of each document:
  34. [source,js]
  35. -------------------------------------
  36. PUT my_index/my_type/1?refresh
  37. {
  38. "text": "quick brown fox",
  39. "popularity": 1
  40. }
  41. PUT my_index/my_type/2?refresh
  42. {
  43. "text": "quick fox",
  44. "popularity": 5
  45. }
  46. GET my_index/_search
  47. {
  48. "query": {
  49. "function_score": {
  50. "query": {
  51. "match": {
  52. "text": "quick brown fox"
  53. }
  54. },
  55. "script_score": {
  56. "script": {
  57. "lang": "expression",
  58. "source": "_score * doc['popularity']"
  59. }
  60. }
  61. }
  62. }
  63. }
  64. -------------------------------------
  65. // CONSOLE
  66. [float]
  67. [[modules-scripting-doc-vals]]
  68. === Doc Values
  69. By far the fastest most efficient way to access a field value from a
  70. script is to use the `doc['field_name']` syntax, which retrieves the field
  71. value from <<doc-values,doc values>>. Doc values are a columnar field value
  72. store, enabled by default on all fields except for <<text,analyzed `text` fields>>.
  73. [source,js]
  74. -------------------------------
  75. PUT my_index/my_type/1?refresh
  76. {
  77. "cost_price": 100
  78. }
  79. GET my_index/_search
  80. {
  81. "script_fields": {
  82. "sales_price": {
  83. "script": {
  84. "lang": "expression",
  85. "source": "doc['cost_price'] * markup",
  86. "params": {
  87. "markup": 0.2
  88. }
  89. }
  90. }
  91. }
  92. }
  93. -------------------------------
  94. // CONSOLE
  95. Doc-values can only return "simple" field values like numbers, dates, geo-
  96. points, terms, etc, or arrays of these values if the field is multi-valued.
  97. It cannot return JSON objects.
  98. [NOTE]
  99. .Doc values and `text` fields
  100. ===================================================
  101. The `doc['field']` syntax can also be used for <<text,analyzed `text` fields>>
  102. if <<fielddata,`fielddata`>> is enabled, but *BEWARE*: enabling fielddata on a
  103. `text` field requires loading all of the terms into the JVM heap, which can be
  104. very expensive both in terms of memory and CPU. It seldom makes sense to
  105. access `text` fields from scripts.
  106. ===================================================
  107. [float]
  108. [[modules-scripting-stored]]
  109. === Stored Fields and `_source`
  110. _Stored fields_ -- fields explicitly marked as
  111. <<mapping-store,`"store": true`>> -- can be accessed using the
  112. `_fields['field_name'].value` or `_fields['field_name'].values` syntax.
  113. The document <<mapping-source-field,`_source`>>, which is really just a
  114. special stored field, can be accessed using the `_source.field_name` syntax.
  115. The `_source` is loaded as a map-of-maps, so properties within object fields
  116. can be accessed as, for example, `_source.name.first`.
  117. [IMPORTANT]
  118. .Prefer doc-values to stored fields
  119. =========================================================
  120. Stored fields (which includes the stored `_source` field) are much slower than
  121. doc-values. They are optimised for returning several fields per result,
  122. while doc values are optimised for accessing the value of a specific field in
  123. many documents.
  124. It makes sense to use `_source` or stored fields when generating a
  125. <<search-request-script-fields,script field>> for the top ten hits from a search
  126. result but, for other search and aggregation use cases, always prefer using
  127. doc values.
  128. =========================================================
  129. For instance:
  130. [source,js]
  131. -------------------------------
  132. PUT my_index
  133. {
  134. "mappings": {
  135. "my_type": {
  136. "properties": {
  137. "title": { <1>
  138. "type": "text"
  139. },
  140. "first_name": {
  141. "type": "text",
  142. "store": true
  143. },
  144. "last_name": {
  145. "type": "text",
  146. "store": true
  147. }
  148. }
  149. }
  150. }
  151. }
  152. PUT my_index/my_type/1?refresh
  153. {
  154. "title": "Mr",
  155. "first_name": "Barry",
  156. "last_name": "White"
  157. }
  158. GET my_index/_search
  159. {
  160. "script_fields": {
  161. "source": {
  162. "script": {
  163. "lang": "painless",
  164. "source": "params._source.title + ' ' + params._source.first_name + ' ' + params._source.last_name" <2>
  165. }
  166. },
  167. "stored_fields": {
  168. "script": {
  169. "lang": "painless",
  170. "source": "params._fields['first_name'].value + ' ' + params._fields['last_name'].value"
  171. }
  172. }
  173. }
  174. }
  175. -------------------------------
  176. // CONSOLE
  177. <1> The `title` field is not stored and so cannot be used with the `_fields[]` syntax.
  178. <2> The `title` field can still be accessed from the `_source`.
  179. [TIP]
  180. .Stored vs `_source`
  181. =======================================================
  182. The `_source` field is just a special stored field, so the performance is
  183. similar to that of other stored fields. The `_source` provides access to the
  184. original document body that was indexed (including the ability to distinguish
  185. `null` values from empty fields, single-value arrays from plain scalars, etc).
  186. The only time it really makes sense to use stored fields instead of the
  187. `_source` field is when the `_source` is very large and it is less costly to
  188. access a few small stored fields instead of the entire `_source`.
  189. =======================================================