multi-fields.asciidoc 3.2 KB

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