multi-fields.asciidoc 3.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128
  1. [[multi-fields]]
  2. === `fields`
  3. It is often useful to index the same field in different ways for different
  4. purposes. This is the purpose of _multi-fields_. For instance, a `string`
  5. field could be mapped as a `text` field for full-text
  6. search, and as a `keyword` field for sorting or aggregations:
  7. [source,console]
  8. --------------------------------------------------
  9. PUT my_index
  10. {
  11. "mappings": {
  12. "properties": {
  13. "city": {
  14. "type": "text",
  15. "fields": {
  16. "raw": { <1>
  17. "type": "keyword"
  18. }
  19. }
  20. }
  21. }
  22. }
  23. }
  24. PUT my_index/_doc/1
  25. {
  26. "city": "New York"
  27. }
  28. PUT my_index/_doc/2
  29. {
  30. "city": "York"
  31. }
  32. GET my_index/_search
  33. {
  34. "query": {
  35. "match": {
  36. "city": "york" <2>
  37. }
  38. },
  39. "sort": {
  40. "city.raw": "asc" <3>
  41. },
  42. "aggs": {
  43. "Cities": {
  44. "terms": {
  45. "field": "city.raw" <3>
  46. }
  47. }
  48. }
  49. }
  50. --------------------------------------------------
  51. <1> The `city.raw` field is a `keyword` version of the `city` field.
  52. <2> The `city` field can be used for full text search.
  53. <3> The `city.raw` field can be used for sorting and aggregations
  54. NOTE: Multi-fields do not change the original `_source` field.
  55. TIP: New multi-fields can be added to existing
  56. fields using the <<indices-put-mapping,PUT mapping API>>.
  57. ==== Multi-fields with multiple analyzers
  58. Another use case of multi-fields is to analyze the same field in different
  59. ways for better relevance. For instance we could index a field with the
  60. <<analysis-standard-analyzer,`standard` analyzer>> which breaks text up into
  61. words, and again with the <<english-analyzer,`english` analyzer>>
  62. which stems words into their root form:
  63. [source,console]
  64. --------------------------------------------------
  65. PUT my_index
  66. {
  67. "mappings": {
  68. "properties": {
  69. "text": { <1>
  70. "type": "text",
  71. "fields": {
  72. "english": { <2>
  73. "type": "text",
  74. "analyzer": "english"
  75. }
  76. }
  77. }
  78. }
  79. }
  80. }
  81. PUT my_index/_doc/1
  82. { "text": "quick brown fox" } <3>
  83. PUT my_index/_doc/2
  84. { "text": "quick brown foxes" } <3>
  85. GET my_index/_search
  86. {
  87. "query": {
  88. "multi_match": {
  89. "query": "quick brown foxes",
  90. "fields": [ <4>
  91. "text",
  92. "text.english"
  93. ],
  94. "type": "most_fields" <4>
  95. }
  96. }
  97. }
  98. --------------------------------------------------
  99. <1> The `text` field uses the `standard` analyzer.
  100. <2> The `text.english` field uses the `english` analyzer.
  101. <3> Index two documents, one with `fox` and the other with `foxes`.
  102. <4> Query both the `text` and `text.english` fields and combine the scores.
  103. The `text` field contains the term `fox` in the first document and `foxes` in
  104. the second document. The `text.english` field contains `fox` for both
  105. documents, because `foxes` is stemmed to `fox`.
  106. The query string is also analyzed by the `standard` analyzer for the `text`
  107. field, and by the `english` analyzer for the `text.english` field. The
  108. stemmed field allows a query for `foxes` to also match the document containing
  109. just `fox`. This allows us to match as many documents as possible. By also
  110. querying the unstemmed `text` field, we improve the relevance score of the
  111. document which matches `foxes` exactly.