templates.asciidoc 12 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429
  1. [[dynamic-templates]]
  2. === Dynamic templates
  3. Dynamic templates allow you to define custom mappings that can be applied to
  4. dynamically added fields based on:
  5. * the <<dynamic-mapping,datatype>> detected by Elasticsearch, with <<match-mapping-type,`match_mapping_type`>>.
  6. * the name of the field, with <<match-unmatch,`match` and `unmatch`>> or <<match-pattern,`match_pattern`>>.
  7. * the full dotted path to the field, with <<path-match-unmatch,`path_match` and `path_unmatch`>>.
  8. The original field name `{name}` and the detected datatype
  9. `{dynamic_type`} <<template-variables,template variables>> can be used in
  10. the mapping specification as placeholders.
  11. IMPORTANT: Dynamic field mappings are only added when a field contains a
  12. concrete value -- not `null` or an empty array. This means that if the
  13. `null_value` option is used in a `dynamic_template`, it will only be applied
  14. after the first document with a concrete value for the field has been
  15. indexed.
  16. Dynamic templates are specified as an array of named objects:
  17. [source,js]
  18. --------------------------------------------------
  19. "dynamic_templates": [
  20. {
  21. "my_template_name": { <1>
  22. ... match conditions ... <2>
  23. "mapping": { ... } <3>
  24. }
  25. },
  26. ...
  27. ]
  28. --------------------------------------------------
  29. // NOTCONSOLE
  30. <1> The template name can be any string value.
  31. <2> The match conditions can include any of : `match_mapping_type`, `match`, `match_pattern`, `unmatch`, `path_match`, `path_unmatch`.
  32. <3> The mapping that the matched field should use.
  33. Templates are processed in order -- the first matching template wins. New
  34. templates can be appended to the end of the list with the
  35. <<indices-put-mapping,PUT mapping>> API. If a new template has the same
  36. name as an existing template, it will replace the old version.
  37. [[match-mapping-type]]
  38. ==== `match_mapping_type`
  39. The `match_mapping_type` matches on the datatype detected by
  40. <<dynamic-field-mapping,dynamic field mapping>>, in other words, the datatype
  41. that Elasticsearch thinks the field should have. Only the following datatypes
  42. can be automatically detected: `boolean`, `date`, `double`, `long`, `object`,
  43. `string`. It also accepts `*` to match all datatypes.
  44. For example, if we wanted to map all integer fields as `integer` instead of
  45. `long`, and all `string` fields as both `text` and `keyword`, we
  46. could use the following template:
  47. [source,js]
  48. --------------------------------------------------
  49. PUT my_index
  50. {
  51. "mappings": {
  52. "my_type": {
  53. "dynamic_templates": [
  54. {
  55. "integers": {
  56. "match_mapping_type": "long",
  57. "mapping": {
  58. "type": "integer"
  59. }
  60. }
  61. },
  62. {
  63. "strings": {
  64. "match_mapping_type": "string",
  65. "mapping": {
  66. "type": "text",
  67. "fields": {
  68. "raw": {
  69. "type": "keyword",
  70. "ignore_above": 256
  71. }
  72. }
  73. }
  74. }
  75. }
  76. ]
  77. }
  78. }
  79. }
  80. PUT my_index/my_type/1
  81. {
  82. "my_integer": 5, <1>
  83. "my_string": "Some string" <2>
  84. }
  85. --------------------------------------------------
  86. // CONSOLE
  87. <1> The `my_integer` field is mapped as an `integer`.
  88. <2> The `my_string` field is mapped as a `text`, with a `keyword` <<multi-fields,multi field>>.
  89. [[match-unmatch]]
  90. ==== `match` and `unmatch`
  91. The `match` parameter uses a pattern to match on the fieldname, while
  92. `unmatch` uses a pattern to exclude fields matched by `match`.
  93. The following example matches all `string` fields whose name starts with
  94. `long_` (except for those which end with `_text`) and maps them as `long`
  95. fields:
  96. [source,js]
  97. --------------------------------------------------
  98. PUT my_index
  99. {
  100. "mappings": {
  101. "my_type": {
  102. "dynamic_templates": [
  103. {
  104. "longs_as_strings": {
  105. "match_mapping_type": "string",
  106. "match": "long_*",
  107. "unmatch": "*_text",
  108. "mapping": {
  109. "type": "long"
  110. }
  111. }
  112. }
  113. ]
  114. }
  115. }
  116. }
  117. PUT my_index/my_type/1
  118. {
  119. "long_num": "5", <1>
  120. "long_text": "foo" <2>
  121. }
  122. --------------------------------------------------
  123. // CONSOLE
  124. <1> The `long_num` field is mapped as a `long`.
  125. <2> The `long_text` field uses the default `string` mapping.
  126. [[match-pattern]]
  127. ==== `match_pattern`
  128. The `match_pattern` parameter adjusts the behavior of the `match` parameter
  129. such that it supports full Java regular expression matching on the field name
  130. instead of simple wildcards, for instance:
  131. [source,js]
  132. --------------------------------------------------
  133. "match_pattern": "regex",
  134. "match": "^profit_\d+$"
  135. --------------------------------------------------
  136. // NOTCONSOLE
  137. [[path-match-unmatch]]
  138. ==== `path_match` and `path_unmatch`
  139. The `path_match` and `path_unmatch` parameters work in the same way as `match`
  140. and `unmatch`, but operate on the full dotted path to the field, not just the
  141. final name, e.g. `some_object.*.some_field`.
  142. This example copies the values of any fields in the `name` object to the
  143. top-level `full_name` field, except for the `middle` field:
  144. [source,js]
  145. --------------------------------------------------
  146. PUT my_index
  147. {
  148. "mappings": {
  149. "my_type": {
  150. "dynamic_templates": [
  151. {
  152. "full_name": {
  153. "path_match": "name.*",
  154. "path_unmatch": "*.middle",
  155. "mapping": {
  156. "type": "text",
  157. "copy_to": "full_name"
  158. }
  159. }
  160. }
  161. ]
  162. }
  163. }
  164. }
  165. PUT my_index/my_type/1
  166. {
  167. "name": {
  168. "first": "Alice",
  169. "middle": "Mary",
  170. "last": "White"
  171. }
  172. }
  173. --------------------------------------------------
  174. // CONSOLE
  175. [[template-variables]]
  176. ==== `{name}` and `{dynamic_type}`
  177. The `{name}` and `{dynamic_type}` placeholders are replaced in the `mapping`
  178. with the field name and detected dynamic type. The following example sets all
  179. string fields to use an <<analyzer,`analyzer`>> with the same name as the
  180. field, and disables <<doc-values,`doc_values`>> for all non-string fields:
  181. [source,js]
  182. --------------------------------------------------
  183. PUT my_index
  184. {
  185. "mappings": {
  186. "my_type": {
  187. "dynamic_templates": [
  188. {
  189. "named_analyzers": {
  190. "match_mapping_type": "string",
  191. "match": "*",
  192. "mapping": {
  193. "type": "text",
  194. "analyzer": "{name}"
  195. }
  196. }
  197. },
  198. {
  199. "no_doc_values": {
  200. "match_mapping_type":"*",
  201. "mapping": {
  202. "type": "{dynamic_type}",
  203. "doc_values": false
  204. }
  205. }
  206. }
  207. ]
  208. }
  209. }
  210. }
  211. PUT my_index/my_type/1
  212. {
  213. "english": "Some English text", <1>
  214. "count": 5 <2>
  215. }
  216. --------------------------------------------------
  217. // CONSOLE
  218. <1> The `english` field is mapped as a `string` field with the `english` analyzer.
  219. <2> The `count` field is mapped as a `long` field with `doc_values` disabled
  220. [[template-examples]]
  221. ==== Template examples
  222. Here are some examples of potentially useful dynamic templates:
  223. ===== Structured search
  224. By default elasticsearch will map string fields as a `text` field with a sub
  225. `keyword` field. However if you are only indexing structured content and not
  226. interested in full text search, you can make elasticsearch map your fields
  227. only as `keyword`s. Note that this means that in order to search those fields,
  228. you will have to search on the exact same value that was indexed.
  229. [source,js]
  230. --------------------------------------------------
  231. PUT my_index
  232. {
  233. "mappings": {
  234. "my_type": {
  235. "dynamic_templates": [
  236. {
  237. "strings_as_keywords": {
  238. "match_mapping_type": "string",
  239. "mapping": {
  240. "type": "keyword"
  241. }
  242. }
  243. }
  244. ]
  245. }
  246. }
  247. }
  248. --------------------------------------------------
  249. // CONSOLE
  250. ===== `text`-only mappings for strings
  251. On the contrary to the previous example, if the only thing that you care about
  252. on your string fields is full-text search, and if you don't plan on running
  253. aggregations, sorting or exact search on your string fields, you could tell
  254. elasticsearch to map it only as a text field (which was the default behaviour
  255. before 5.0):
  256. [source,js]
  257. --------------------------------------------------
  258. PUT my_index
  259. {
  260. "mappings": {
  261. "my_type": {
  262. "dynamic_templates": [
  263. {
  264. "strings_as_text": {
  265. "match_mapping_type": "string",
  266. "mapping": {
  267. "type": "text"
  268. }
  269. }
  270. }
  271. ]
  272. }
  273. }
  274. }
  275. --------------------------------------------------
  276. // CONSOLE
  277. ===== Disabled norms
  278. Norms are index-time scoring factors. If you do not care about scoring, which
  279. would be the case for instance if you never sort documents by score, you could
  280. disable the storage of these scoring factors in the index and save some space.
  281. [source,js]
  282. --------------------------------------------------
  283. PUT my_index
  284. {
  285. "mappings": {
  286. "my_type": {
  287. "dynamic_templates": [
  288. {
  289. "strings_as_keywords": {
  290. "match_mapping_type": "string",
  291. "mapping": {
  292. "type": "text",
  293. "norms": false,
  294. "fields": {
  295. "keyword": {
  296. "type": "keyword",
  297. "ignore_above": 256
  298. }
  299. }
  300. }
  301. }
  302. }
  303. ]
  304. }
  305. }
  306. }
  307. --------------------------------------------------
  308. // CONSOLE
  309. The sub `keyword` field appears in this template to be consistent with the
  310. default rules of dynamic mappings. Of course if you do not need them because
  311. you don't need to perform exact search or aggregate on this field, you could
  312. remove it as described in the previous section.
  313. ===== Time-series
  314. When doing time series analysis with elasticsearch, it is common to have many
  315. numeric fields that you will often aggregate on but never filter on. In such a
  316. case, you could disable indexing on those fields to save disk space and also
  317. maybe gain some indexing speed:
  318. [source,js]
  319. --------------------------------------------------
  320. PUT my_index
  321. {
  322. "mappings": {
  323. "my_type": {
  324. "dynamic_templates": [
  325. {
  326. "unindexed_longs": {
  327. "match_mapping_type": "long",
  328. "mapping": {
  329. "type": "long",
  330. "index": false
  331. }
  332. }
  333. },
  334. {
  335. "unindexed_doubles": {
  336. "match_mapping_type": "double",
  337. "mapping": {
  338. "type": "float", <1>
  339. "index": false
  340. }
  341. }
  342. }
  343. ]
  344. }
  345. }
  346. }
  347. --------------------------------------------------
  348. // CONSOLE
  349. <1> Like the default dynamic mapping rules, doubles are mapped as floats, which
  350. are usually accurate enough, yet require half the disk space.
  351. [[override-default-template]]
  352. === Override default template
  353. You can override the default mappings for all indices and all types
  354. by specifying a `_default_` type mapping in an index template
  355. which matches all indices.
  356. For example, to disable the `_field_names` field by default for all types in all
  357. new indices, you could create the following index template:
  358. [source,js]
  359. --------------------------------------------------
  360. PUT _template/disable_field_names
  361. {
  362. "order": 0,
  363. "index_patterns": ["*"], <1>
  364. "mappings": {
  365. "_default_": { <2>
  366. "_field_names": { <3>
  367. "enabled": false
  368. }
  369. }
  370. }
  371. }
  372. --------------------------------------------------
  373. // CONSOLE
  374. <1> Applies the mappings to an `index` which matches the pattern `*`, in other
  375. words, all new indices.
  376. <2> Defines the `_default_` type mapping types within the index.
  377. <3> Disables the `_field_names` field by default.