misc.asciidoc 5.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173
  1. [[caching-heavy-aggregations]]
  2. == Caching heavy aggregations
  3. Frequently used aggregations (e.g. for display on the home page of a website)
  4. can be cached for faster responses. These cached results are the same results
  5. that would be returned by an uncached aggregation -- you will never get stale
  6. results.
  7. See <<shard-request-cache>> for more details.
  8. [[returning-only-agg-results]]
  9. == Returning only aggregation results
  10. There are many occasions when aggregations are required but search hits are not. For these cases the hits can be ignored by
  11. setting `size=0`. For example:
  12. [source,js]
  13. --------------------------------------------------
  14. GET /twitter/_search
  15. {
  16. "size": 0,
  17. "aggregations": {
  18. "my_agg": {
  19. "terms": {
  20. "field": "text"
  21. }
  22. }
  23. }
  24. }
  25. --------------------------------------------------
  26. // CONSOLE
  27. // TEST[setup:twitter]
  28. Setting `size` to `0` avoids executing the fetch phase of the search making the request more efficient.
  29. [[agg-metadata]]
  30. == Aggregation Metadata
  31. You can associate a piece of metadata with individual aggregations at request time that will be returned in place
  32. at response time.
  33. Consider this example where we want to associate the color blue with our `terms` aggregation.
  34. [source,js]
  35. --------------------------------------------------
  36. GET /twitter/_search
  37. {
  38. "size": 0,
  39. "aggs": {
  40. "titles": {
  41. "terms": {
  42. "field": "title"
  43. },
  44. "meta": {
  45. "color": "blue"
  46. }
  47. }
  48. }
  49. }
  50. --------------------------------------------------
  51. // CONSOLE
  52. // TEST[setup:twitter]
  53. Then that piece of metadata will be returned in place for our `titles` terms aggregation
  54. [source,js]
  55. --------------------------------------------------
  56. {
  57. "aggregations": {
  58. "titles": {
  59. "meta": {
  60. "color" : "blue"
  61. },
  62. "doc_count_error_upper_bound" : 0,
  63. "sum_other_doc_count" : 0,
  64. "buckets": [
  65. ]
  66. }
  67. },
  68. ...
  69. }
  70. --------------------------------------------------
  71. // TESTRESPONSE[s/\.\.\./"took": "$body.took", "timed_out": false, "_shards": "$body._shards", "hits": "$body.hits"/]
  72. [[returning-aggregation-type]]
  73. == Returning the type of the aggregation
  74. Sometimes you need to know the exact type of an aggregation in order to parse its results. The `typed_keys` parameter
  75. can be used to change the aggregation's name in the response so that it will be prefixed by its internal type.
  76. Considering the following <<search-aggregations-bucket-datehistogram-aggregation,`date_histogram` aggregation>> named
  77. `tweets_over_time` which has a sub <<search-aggregations-metrics-top-hits-aggregation, 'top_hits` aggregation>> named
  78. `top_users`:
  79. [source,js]
  80. --------------------------------------------------
  81. GET /twitter/_search?typed_keys
  82. {
  83. "aggregations": {
  84. "tweets_over_time": {
  85. "date_histogram": {
  86. "field": "date",
  87. "calendar_interval": "year"
  88. },
  89. "aggregations": {
  90. "top_users": {
  91. "top_hits": {
  92. "size": 1
  93. }
  94. }
  95. }
  96. }
  97. }
  98. }
  99. --------------------------------------------------
  100. // CONSOLE
  101. // TEST[setup:twitter]
  102. In the response, the aggregations names will be changed to respectively `date_histogram#tweets_over_time` and
  103. `top_hits#top_users`, reflecting the internal types of each aggregation:
  104. [source,js]
  105. --------------------------------------------------
  106. {
  107. "aggregations": {
  108. "date_histogram#tweets_over_time": { <1>
  109. "buckets" : [
  110. {
  111. "key_as_string" : "2009-01-01T00:00:00.000Z",
  112. "key" : 1230768000000,
  113. "doc_count" : 5,
  114. "top_hits#top_users" : { <2>
  115. "hits" : {
  116. "total" : {
  117. "value": 5,
  118. "relation": "eq"
  119. },
  120. "max_score" : 1.0,
  121. "hits" : [
  122. {
  123. "_index": "twitter",
  124. "_type": "_doc",
  125. "_id": "0",
  126. "_score": 1.0,
  127. "_source": {
  128. "date": "2009-11-15T14:12:12",
  129. "message": "trying out Elasticsearch",
  130. "user": "kimchy",
  131. "likes": 0
  132. }
  133. }
  134. ]
  135. }
  136. }
  137. }
  138. ]
  139. }
  140. },
  141. ...
  142. }
  143. --------------------------------------------------
  144. // TESTRESPONSE[s/\.\.\./"took": "$body.took", "timed_out": false, "_shards": "$body._shards", "hits": "$body.hits"/]
  145. <1> The name `tweets_over_time` now contains the `date_histogram` prefix.
  146. <2> The name `top_users` now contains the `top_hits` prefix.
  147. NOTE: For some aggregations, it is possible that the returned type is not the same as the one provided with the
  148. request. This is the case for Terms, Significant Terms and Percentiles aggregations, where the returned type
  149. also contains information about the type of the targeted field: `lterms` (for a terms aggregation on a Long field),
  150. `sigsterms` (for a significant terms aggregation on a String field), `tdigest_percentiles` (for a percentile
  151. aggregation based on the TDigest algorithm).