Terms aggregation

ユニークな値ごとにバケットが動的に構築されるマルチバケット値ソースベースの集約です。

例:

Python

  1. resp = client.search(
  2. aggs={
  3. "genres": {
  4. "terms": {
  5. "field": "genre"
  6. }
  7. }
  8. },
  9. )
  10. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. genres: {
  5. terms: {
  6. field: 'genre'
  7. }
  8. }
  9. }
  10. }
  11. )
  12. puts response

Js

  1. const response = await client.search({
  2. aggs: {
  3. genres: {
  4. terms: {
  5. field: "genre",
  6. },
  7. },
  8. },
  9. });
  10. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "genres": {
  5. "terms": { "field": "genre" }
  6. }
  7. }
  8. }

レスポンス:

Console-Result

  1. {
  2. ...
  3. "aggregations": {
  4. "genres": {
  5. "doc_count_error_upper_bound": 0,
  6. "sum_other_doc_count": 0,
  7. "buckets": [
  8. {
  9. "key": "electronic",
  10. "doc_count": 6
  11. },
  12. {
  13. "key": "rock",
  14. "doc_count": 3
  15. },
  16. {
  17. "key": "jazz",
  18. "doc_count": 2
  19. }
  20. ]
  21. }
  22. }
  23. }
各用語のドキュメント数に対する誤差の上限、以下を参照してください。
ユニークな用語が多数ある場合、Elasticsearchは上位の用語のみを返します。この数は、レスポンスに含まれないすべてのバケットのドキュメント数の合計です。
上位バケットのリスト、topの意味は順序によって定義されます。

fieldKeywordNumericipboolean、またはbinaryです。

デフォルトでは、terms集約をtextフィールドで実行することはできません。代わりに、keyword サブフィールドを使用してください。あるいは、textフィールドでfielddataを有効にして、フィールドの分析された用語のバケットを作成できます。fielddataを有効にすると、メモリ使用量が大幅に増加する可能性があります。

Size

デフォルトでは、terms集約は最も多くのドキュメントを持つ上位10用語を返します。sizeパラメータを使用して、search.max_buckets制限まで、より多くの用語を返すことができます。

データに100または1000のユニークな用語が含まれている場合、sizeterms集約を増やしてすべてを返すことができます。ユニークな用語がさらに多く、すべてが必要な場合は、コンポジット集約を使用してください。

  1. ## Shard size
  2. より正確な結果を得るために、`````terms````` aggは各シャードから上位`````size`````用語以上のものを取得します。上位`````shard_size`````用語を取得し、デフォルトは`````size * 1.5 + 10`````です。
  3. これは、1つの用語が1つのシャードに多くのドキュメントを持っているが、他のすべてのシャードで`````size`````しきい値の直下にある場合に対処するためです。各シャードが`````size`````用語のみを返す場合、集約はその用語の部分的なドキュメント数を返します。したがって、`````terms`````は欠落している用語をキャッチしようとするために、より多くの用語を返します。これは役立ちますが、用語の部分的なドキュメント数を返す可能性がまだあります。これは、シャードごとのドキュメント数が異なる用語を必要とします。
  4. `````shard_size`````を増やすことで、これらの異なるドキュメント数をよりよく考慮し、上位用語の選択の精度を向上させることができます。`````shard_size`````を増やす方が、`````size`````を増やすよりもはるかに安価です。ただし、ワイヤー上でより多くのバイトを必要とし、コーディネートノードのメモリで待機します。
  5. このガイダンスは、`````terms`````集約のデフォルトのソート`````order`````を使用している場合にのみ適用されます。ドキュメント数の降順以外でソートしている場合は、[順序](aa21c04ecd5a1ccc.md#search-aggregations-bucket-terms-aggregation-order)を参照してください。
  6. `````shard_size``````````size`````より小さくすることはできません(あまり意味がありません)。そうなった場合、Elasticsearchはそれを上書きし、`````size`````と等しくリセットします。
  7. ## Document count error
  8. より大きな`````shard_size`````値でも、`````doc_count`````値は`````terms`````集約に対して近似的である可能性があります。その結果、`````terms`````集約に対するサブ集約も近似的である可能性があります。
  9. `````sum_other_doc_count`````は、上位`````size`````用語に入らなかったドキュメントの数です。これが`````0`````より大きい場合、`````terms````` aggは、コーディネートノードの`````size`````に収まらなかったか、データノードの`````shard_size`````に収まらなかったため、いくつかのバケットを捨てなければならなかったことが確実です。
  10. ## Per bucket document count error
  11. `````show_term_doc_count_error`````パラメータを`````true`````に設定すると、`````terms`````集約には`````doc_count_error_upper_bound`````が含まれ、これは各シャードによって返される`````doc_count`````の誤差の上限です。これは、`````shard_size`````に収まらなかった各シャードの最大バケットのサイズの合計です。
  12. 具体的には、1つのシャードで非常に大きなバケットがあり、他のすべてのシャードで`````shard_size`````の直下にある場合を想像してください。その場合、`````terms````` aggはそのバケットを返しますが、`````shard_size`````しきい値を下回ったシャードの多くのドキュメントからのデータが欠落しています。`````doc_count_error_upper_bound`````は、その欠落したドキュメントの最大数です。
  13. #### Python
  14. ``````python
  15. resp = client.search(
  16. aggs={
  17. "products": {
  18. "terms": {
  19. "field": "product",
  20. "size": 5,
  21. "show_term_doc_count_error": True
  22. }
  23. }
  24. },
  25. )
  26. print(resp)
  27. `

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. products: {
  5. terms: {
  6. field: 'product',
  7. size: 5,
  8. show_term_doc_count_error: true
  9. }
  10. }
  11. }
  12. }
  13. )
  14. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "products": {
  5. "terms": {
  6. "field": "product",
  7. "size": 5,
  8. "show_term_doc_count_error": true
  9. }
  10. }
  11. }
  12. }`)),
  13. es.Search.WithPretty(),
  14. )
  15. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. products: {
  4. terms: {
  5. field: "product",
  6. size: 5,
  7. show_term_doc_count_error: true,
  8. },
  9. },
  10. },
  11. });
  12. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "products": {
  5. "terms": {
  6. "field": "product",
  7. "size": 5,
  8. "show_term_doc_count_error": true
  9. }
  10. }
  11. }
  12. }

これらのエラーは、用語がドキュメント数の降順で並べられている場合にのみこの方法で計算できます。集約が用語の値自体(昇順または降順)で並べられている場合、他のシャードからの結果に表示される特定の用語を返さないシャードがある場合、そのシャードにはその用語がインデックスに存在しないため、ドキュメント数にエラーはありません。集約がサブ集約でソートされているか、ドキュメント数の昇順でソートされている場合、ドキュメント数のエラーは決定できず、-1の値が与えられます。

Order

デフォルトでは、terms集約は用語をドキュメント_countの降順で並べます。これにより、Elasticsearchが報告できる制限されたドキュメント数の誤差が生成されます。

  1. 特に`````"order": { "_count": "asc" }`````の使用を避けてください。珍しい用語を見つける必要がある場合は、代わりに[`````rare_terms`````](/read/elasticsearch-8-15/4ba2f49082b46b81.md)集約を使用してください。`````terms`````集約が[シャードから用語を取得する方法](aa21c04ecd5a1ccc.md#search-aggregations-bucket-terms-aggregation-shard-size)のため、ドキュメント数の昇順でソートすると、しばしば不正確な結果が得られます。
  2. ### Ordering by the term value
  3. この場合、バケットは実際の用語の値によって順序付けられます。たとえば、キーワードの辞書順や数値の数値順です。このソートは、昇順および降順の両方で安全であり、正確な結果を生成します。
  4. 用語を昇順でアルファベット順に並べるバケットの例:
  5. #### Python
  6. ``````python
  7. resp = client.search(
  8. aggs={
  9. "genres": {
  10. "terms": {
  11. "field": "genre",
  12. "order": {
  13. "_key": "asc"
  14. }
  15. }
  16. }
  17. },
  18. )
  19. print(resp)
  20. `

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. genres: {
  5. terms: {
  6. field: 'genre',
  7. order: {
  8. _key: 'asc'
  9. }
  10. }
  11. }
  12. }
  13. }
  14. )
  15. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "genres": {
  5. "terms": {
  6. "field": "genre",
  7. "order": {
  8. "_key": "asc"
  9. }
  10. }
  11. }
  12. }
  13. }`)),
  14. es.Search.WithPretty(),
  15. )
  16. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. genres: {
  4. terms: {
  5. field: "genre",
  6. order: {
  7. _key: "asc",
  8. },
  9. },
  10. },
  11. },
  12. });
  13. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "genres": {
  5. "terms": {
  6. "field": "genre",
  7. "order": { "_key": "asc" }
  8. }
  9. }
  10. }
  11. }

Ordering by a sub aggregation

サブ集約によるソートは、terms集約がシャードから結果を取得する方法のため、一般的に不正確な順序を生成します。

サブ集約の順序が安全で正しい結果を返す場合は2つのケースがあります:降順での最大値によるソート、または昇順での最小値によるソートです。これらのアプローチは、サブ集約の動作と一致するために機能します。つまり、最大の最大値または最小の最小値を探している場合、グローバルな回答(結合されたシャードから)は、ローカルシャードの回答の1つに含まれている必要があります。逆に、最小の最大値と最大の最小値は正確に計算されません。

これらのケースでは、順序は正しいですが、ドキュメント数と非順序のサブ集約にはまだエラーがある可能性があります(Elasticsearchはそれらのエラーの境界を計算しません)。

単一値メトリックサブ集約によるバケットの順序(集約名で識別):

Python

  1. resp = client.search(
  2. aggs={
  3. "genres": {
  4. "terms": {
  5. "field": "genre",
  6. "order": {
  7. "max_play_count": "desc"
  8. }
  9. },
  10. "aggs": {
  11. "max_play_count": {
  12. "max": {
  13. "field": "play_count"
  14. }
  15. }
  16. }
  17. }
  18. },
  19. )
  20. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. genres: {
  5. terms: {
  6. field: 'genre',
  7. order: {
  8. max_play_count: 'desc'
  9. }
  10. },
  11. aggregations: {
  12. max_play_count: {
  13. max: {
  14. field: 'play_count'
  15. }
  16. }
  17. }
  18. }
  19. }
  20. }
  21. )
  22. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "genres": {
  5. "terms": {
  6. "field": "genre",
  7. "order": {
  8. "max_play_count": "desc"
  9. }
  10. },
  11. "aggs": {
  12. "max_play_count": {
  13. "max": {
  14. "field": "play_count"
  15. }
  16. }
  17. }
  18. }
  19. }
  20. }`)),
  21. es.Search.WithPretty(),
  22. )
  23. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. genres: {
  4. terms: {
  5. field: "genre",
  6. order: {
  7. max_play_count: "desc",
  8. },
  9. },
  10. aggs: {
  11. max_play_count: {
  12. max: {
  13. field: "play_count",
  14. },
  15. },
  16. },
  17. },
  18. },
  19. });
  20. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "genres": {
  5. "terms": {
  6. "field": "genre",
  7. "order": { "max_play_count": "desc" }
  8. },
  9. "aggs": {
  10. "max_play_count": { "max": { "field": "play_count" } }
  11. }
  12. }
  13. }
  14. }

マルチバリューメトリックサブ集約によるバケットの順序(集約名で識別):

Python

  1. resp = client.search(
  2. aggs={
  3. "genres": {
  4. "terms": {
  5. "field": "genre",
  6. "order": {
  7. "playback_stats.max": "desc"
  8. }
  9. },
  10. "aggs": {
  11. "playback_stats": {
  12. "stats": {
  13. "field": "play_count"
  14. }
  15. }
  16. }
  17. }
  18. },
  19. )
  20. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. genres: {
  5. terms: {
  6. field: 'genre',
  7. order: {
  8. 'playback_stats.max' => 'desc'
  9. }
  10. },
  11. aggregations: {
  12. playback_stats: {
  13. stats: {
  14. field: 'play_count'
  15. }
  16. }
  17. }
  18. }
  19. }
  20. }
  21. )
  22. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "genres": {
  5. "terms": {
  6. "field": "genre",
  7. "order": {
  8. "playback_stats.max": "desc"
  9. }
  10. },
  11. "aggs": {
  12. "playback_stats": {
  13. "stats": {
  14. "field": "play_count"
  15. }
  16. }
  17. }
  18. }
  19. }
  20. }`)),
  21. es.Search.WithPretty(),
  22. )
  23. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. genres: {
  4. terms: {
  5. field: "genre",
  6. order: {
  7. "playback_stats.max": "desc",
  8. },
  9. },
  10. aggs: {
  11. playback_stats: {
  12. stats: {
  13. field: "play_count",
  14. },
  15. },
  16. },
  17. },
  18. },
  19. });
  20. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "genres": {
  5. "terms": {
  6. "field": "genre",
  7. "order": { "playback_stats.max": "desc" }
  8. },
  9. "aggs": {
  10. "playback_stats": { "stats": { "field": "play_count" } }
  11. }
  12. }
  13. }
  14. }

Pipeline aggs cannot be used for sorting

パイプライン集約は、すべての他の集約が完了した後のリデュースフェーズ中に実行されます。このため、順序付けに使用することはできません。

バケットの順序を階層内の「より深い」集約に基づいて行うことも可能です。これは、集約パスが単一バケットタイプであり、パス内の最後の集約が単一バケットまたはメトリックのいずれかである限りサポートされます。単一バケットタイプの場合、順序はバケット内のドキュメント数(すなわちdoc_count)によって定義され、メトリックの場合は、上記のルールが適用されます(マルチバリューメトリック集約の場合は、ソートするメトリック名を示す必要があり、単一バリューメトリック集約の場合は、その値に対してソートが適用されます)。

パスは次の形式で定義する必要があります:

Ebnf

  1. AGG_SEPARATOR = '>' ;
  2. METRIC_SEPARATOR = '.' ;
  3. AGG_NAME = <the name of the aggregation> ;
  4. METRIC = <the name of the metric (in case of multi-value metrics aggregation)> ;
  5. PATH = <AGG_NAME> [ <AGG_SEPARATOR>, <AGG_NAME> ]* [ <METRIC_SEPARATOR>, <METRIC> ] ;

Python

  1. resp = client.search(
  2. aggs={
  3. "countries": {
  4. "terms": {
  5. "field": "artist.country",
  6. "order": {
  7. "rock>playback_stats.avg": "desc"
  8. }
  9. },
  10. "aggs": {
  11. "rock": {
  12. "filter": {
  13. "term": {
  14. "genre": "rock"
  15. }
  16. },
  17. "aggs": {
  18. "playback_stats": {
  19. "stats": {
  20. "field": "play_count"
  21. }
  22. }
  23. }
  24. }
  25. }
  26. }
  27. },
  28. )
  29. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. countries: {
  5. terms: {
  6. field: 'artist.country',
  7. order: {
  8. "rock>playback_stats.avg": 'desc'
  9. }
  10. },
  11. aggregations: {
  12. rock: {
  13. filter: {
  14. term: {
  15. genre: 'rock'
  16. }
  17. },
  18. aggregations: {
  19. playback_stats: {
  20. stats: {
  21. field: 'play_count'
  22. }
  23. }
  24. }
  25. }
  26. }
  27. }
  28. }
  29. }
  30. )
  31. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "countries": {
  5. "terms": {
  6. "field": "artist.country",
  7. "order": {
  8. "rock>playback_stats.avg": "desc"
  9. }
  10. },
  11. "aggs": {
  12. "rock": {
  13. "filter": {
  14. "term": {
  15. "genre": "rock"
  16. }
  17. },
  18. "aggs": {
  19. "playback_stats": {
  20. "stats": {
  21. "field": "play_count"
  22. }
  23. }
  24. }
  25. }
  26. }
  27. }
  28. }
  29. }`)),
  30. es.Search.WithPretty(),
  31. )
  32. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. countries: {
  4. terms: {
  5. field: "artist.country",
  6. order: {
  7. "rock>playback_stats.avg": "desc",
  8. },
  9. },
  10. aggs: {
  11. rock: {
  12. filter: {
  13. term: {
  14. genre: "rock",
  15. },
  16. },
  17. aggs: {
  18. playback_stats: {
  19. stats: {
  20. field: "play_count",
  21. },
  22. },
  23. },
  24. },
  25. },
  26. },
  27. },
  28. });
  29. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "countries": {
  5. "terms": {
  6. "field": "artist.country",
  7. "order": { "rock>playback_stats.avg": "desc" }
  8. },
  9. "aggs": {
  10. "rock": {
  11. "filter": { "term": { "genre": "rock" } },
  12. "aggs": {
  13. "playback_stats": { "stats": { "field": "play_count" } }
  14. }
  15. }
  16. }
  17. }
  18. }
  19. }

上記は、アーティストの国のバケットをロックソングの平均再生回数に基づいてソートします。

次のように、バケットを順序付けるために複数の基準を使用できます:

Python

  1. resp = client.search(
  2. aggs={
  3. "countries": {
  4. "terms": {
  5. "field": "artist.country",
  6. "order": [
  7. {
  8. "rock>playback_stats.avg": "desc"
  9. },
  10. {
  11. "_count": "desc"
  12. }
  13. ]
  14. },
  15. "aggs": {
  16. "rock": {
  17. "filter": {
  18. "term": {
  19. "genre": "rock"
  20. }
  21. },
  22. "aggs": {
  23. "playback_stats": {
  24. "stats": {
  25. "field": "play_count"
  26. }
  27. }
  28. }
  29. }
  30. }
  31. }
  32. },
  33. )
  34. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. countries: {
  5. terms: {
  6. field: 'artist.country',
  7. order: [
  8. {
  9. "rock>playback_stats.avg": 'desc'
  10. },
  11. {
  12. _count: 'desc'
  13. }
  14. ]
  15. },
  16. aggregations: {
  17. rock: {
  18. filter: {
  19. term: {
  20. genre: 'rock'
  21. }
  22. },
  23. aggregations: {
  24. playback_stats: {
  25. stats: {
  26. field: 'play_count'
  27. }
  28. }
  29. }
  30. }
  31. }
  32. }
  33. }
  34. }
  35. )
  36. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "countries": {
  5. "terms": {
  6. "field": "artist.country",
  7. "order": [
  8. {
  9. "rock>playback_stats.avg": "desc"
  10. },
  11. {
  12. "_count": "desc"
  13. }
  14. ]
  15. },
  16. "aggs": {
  17. "rock": {
  18. "filter": {
  19. "term": {
  20. "genre": "rock"
  21. }
  22. },
  23. "aggs": {
  24. "playback_stats": {
  25. "stats": {
  26. "field": "play_count"
  27. }
  28. }
  29. }
  30. }
  31. }
  32. }
  33. }
  34. }`)),
  35. es.Search.WithPretty(),
  36. )
  37. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. countries: {
  4. terms: {
  5. field: "artist.country",
  6. order: [
  7. {
  8. "rock>playback_stats.avg": "desc",
  9. },
  10. {
  11. _count: "desc",
  12. },
  13. ],
  14. },
  15. aggs: {
  16. rock: {
  17. filter: {
  18. term: {
  19. genre: "rock",
  20. },
  21. },
  22. aggs: {
  23. playback_stats: {
  24. stats: {
  25. field: "play_count",
  26. },
  27. },
  28. },
  29. },
  30. },
  31. },
  32. },
  33. });
  34. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "countries": {
  5. "terms": {
  6. "field": "artist.country",
  7. "order": [ { "rock>playback_stats.avg": "desc" }, { "_count": "desc" } ]
  8. },
  9. "aggs": {
  10. "rock": {
  11. "filter": { "term": { "genre": "rock" } },
  12. "aggs": {
  13. "playback_stats": { "stats": { "field": "play_count" } }
  14. }
  15. }
  16. }
  17. }
  18. }
  19. }

上記は、アーティストの国のバケットをロックソングの平均再生回数に基づいてソートし、その後doc_countを降順でソートします。

2つのバケットがすべての順序基準で同じ値を共有する場合、バケットの用語値が昇順のアルファベット順でタイブレーカーとして使用され、バケットの非決定的な順序を防ぎます。

Ordering by count ascending

ドキュメント_countの昇順で用語を並べると、Elasticsearchが正確に報告できない無制限の誤差が生成されます。したがって、以下の例に示すように、"order": { "_count": "asc" }の使用は強く推奨しません。

Python

  1. resp = client.search(
  2. aggs={
  3. "genres": {
  4. "terms": {
  5. "field": "genre",
  6. "order": {
  7. "_count": "asc"
  8. }
  9. }
  10. }
  11. },
  12. )
  13. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. genres: {
  5. terms: {
  6. field: 'genre',
  7. order: {
  8. _count: 'asc'
  9. }
  10. }
  11. }
  12. }
  13. }
  14. )
  15. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "genres": {
  5. "terms": {
  6. "field": "genre",
  7. "order": {
  8. "_count": "asc"
  9. }
  10. }
  11. }
  12. }
  13. }`)),
  14. es.Search.WithPretty(),
  15. )
  16. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. genres: {
  4. terms: {
  5. field: "genre",
  6. order: {
  7. _count: "asc",
  8. },
  9. },
  10. },
  11. },
  12. });
  13. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "genres": {
  5. "terms": {
  6. "field": "genre",
  7. "order": { "_count": "asc" }
  8. }
  9. }
  10. }
  11. }

Minimum document count

設定されたヒット数を超える用語のみを返すことが可能です。これは、min_doc_countオプションを使用して行います。

Python

  1. resp = client.search(
  2. aggs={
  3. "tags": {
  4. "terms": {
  5. "field": "tags",
  6. "min_doc_count": 10
  7. }
  8. }
  9. },
  10. )
  11. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. tags: {
  5. terms: {
  6. field: 'tags',
  7. min_doc_count: 10
  8. }
  9. }
  10. }
  11. }
  12. )
  13. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "tags": {
  5. "terms": {
  6. "field": "tags",
  7. "min_doc_count": 10
  8. }
  9. }
  10. }
  11. }`)),
  12. es.Search.WithPretty(),
  13. )
  14. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. tags: {
  4. terms: {
  5. field: "tags",
  6. min_doc_count: 10,
  7. },
  8. },
  9. },
  10. });
  11. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "tags": {
  5. "terms": {
  6. "field": "tags",
  7. "min_doc_count": 10
  8. }
  9. }
  10. }
  11. }

上記の集約は、10ヒット以上で見つかったタグのみを返します。デフォルト値は1です。

用語はシャードレベルで収集され、他のシャードから収集された用語と2番目のステップでマージされます。ただし、シャードはグローバルなドキュメント数に関する情報を持っていません。用語が候補リストに追加されるかどうかの決定は、ローカルシャード頻度を使用してシャード上で計算された順序のみに依存します。min_doc_count基準は、すべてのシャードのローカル用語統計をマージした後にのみ適用されます。ある意味で、候補として用語を追加する決定は、その用語が実際に必要なmin_doc_countに達するかどうかについてあまり「確実」ではない状態で行われます。これにより、候補リストに低頻度の用語が含まれている場合、最終結果に多くの(グローバルに)高頻度の用語が欠落する可能性があります。これを避けるために、shard_sizeパラメータを増やして、シャード上でより多くの候補用語を許可できます。ただし、これによりメモリ消費量とネットワークトラフィックが増加します。

shard_min_doc_count

パラメータshard_min_doc_countは、用語が候補リストに追加されるべきかどうかに関するシャードの「確実性」を調整します。用語は、セット内のローカルシャード頻度がmin_doc_countより高い場合にのみ考慮されます。辞書に多くの低頻度の用語が含まれており、それに興味がない場合(たとえば、誤字など)、shard_min_doc_countパラメータを設定して、ローカルカウントをマージした後に必要なmin_doc_countに達しない可能性が高い候補用語をシャードレベルでフィルタリングできます。shard_min_doc_countはデフォルトで0に設定されており、明示的に設定しない限り効果はありません。

  1. `````doc_count`````降順でソートしていない場合、高い`````min_doc_count`````値は、シャードから収集されたデータが不十分なため、`````size`````より少ないバケットを返す可能性があります。欠落したバケットは、`````shard_size`````を増やすことで戻すことができます。`````shard_min_doc_count`````を高く設定しすぎると、シャードレベルで用語がフィルタリングされます。この値は、`````min_doc_count/#shards`````よりもはるかに低く設定する必要があります。
  2. ## Script
  3. ドキュメント内のデータが集約したい内容と正確に一致しない場合は、[ランタイムフィールド](/read/elasticsearch-8-15/41c27b1e9f3afe47.md)を使用してください。たとえば、「アンソロジー」を特別なカテゴリにする必要がある場合、次のように実行できます:
  4. #### Python
  5. ``````python
  6. resp = client.search(
  7. size=0,
  8. runtime_mappings={
  9. "normalized_genre": {
  10. "type": "keyword",
  11. "script": "\n String genre = doc['genre'].value;\n if (doc['product'].value.startsWith('Anthology')) {\n emit(genre + ' anthology');\n } else {\n emit(genre);\n }\n "
  12. }
  13. },
  14. aggs={
  15. "genres": {
  16. "terms": {
  17. "field": "normalized_genre"
  18. }
  19. }
  20. },
  21. )
  22. print(resp)
  23. `

Ruby

  1. response = client.search(
  2. body: {
  3. size: 0,
  4. runtime_mappings: {
  5. normalized_genre: {
  6. type: 'keyword',
  7. script: "\n String genre = doc['genre'].value;\n if (doc['product'].value.startsWith('Anthology')) {\n emit(genre + ' anthology');\n } else {\n emit(genre);\n }\n "
  8. }
  9. },
  10. aggregations: {
  11. genres: {
  12. terms: {
  13. field: 'normalized_genre'
  14. }
  15. }
  16. }
  17. }
  18. )
  19. puts response

Js

  1. const response = await client.search({
  2. size: 0,
  3. runtime_mappings: {
  4. normalized_genre: {
  5. type: "keyword",
  6. script:
  7. "\n String genre = doc['genre'].value;\n if (doc['product'].value.startsWith('Anthology')) {\n emit(genre + ' anthology');\n } else {\n emit(genre);\n }\n ",
  8. },
  9. },
  10. aggs: {
  11. genres: {
  12. terms: {
  13. field: "normalized_genre",
  14. },
  15. },
  16. },
  17. });
  18. console.log(response);

Console

  1. GET /_search
  2. {
  3. "size": 0,
  4. "runtime_mappings": {
  5. "normalized_genre": {
  6. "type": "keyword",
  7. "script": """
  8. String genre = doc['genre'].value;
  9. if (doc['product'].value.startsWith('Anthology')) {
  10. emit(genre + ' anthology');
  11. } else {
  12. emit(genre);
  13. }
  14. """
  15. }
  16. },
  17. "aggs": {
  18. "genres": {
  19. "terms": {
  20. "field": "normalized_genre"
  21. }
  22. }
  23. }
  24. }

次のようになります:

Console-Result

  1. {
  2. "aggregations": {
  3. "genres": {
  4. "doc_count_error_upper_bound": 0,
  5. "sum_other_doc_count": 0,
  6. "buckets": [
  7. {
  8. "key": "electronic",
  9. "doc_count": 4
  10. },
  11. {
  12. "key": "rock",
  13. "doc_count": 3
  14. },
  15. {
  16. "key": "electronic anthology",
  17. "doc_count": 2
  18. },
  19. {
  20. "key": "jazz",
  21. "doc_count": 2
  22. }
  23. ]
  24. }
  25. },
  26. ...
  27. }

これは少し遅くなります。なぜなら、ランタイムフィールドは1つのフィールドではなく2つのフィールドにアクセスしなければならず、非ランタイムkeywordフィールドで機能するいくつかの最適化を放棄しなければならないからです。速度が必要な場合は、normalized_genreフィールドをインデックス化できます。

Filtering Values

バケットが作成される値をフィルタリングすることが可能です。これは、正規表現文字列または正確な値の配列に基づくincludeおよびexcludeパラメータを使用して行うことができます。さらに、include句はpartition式を使用してフィルタリングできます。

Filtering Values with regular expressions

Python

  1. resp = client.search(
  2. aggs={
  3. "tags": {
  4. "terms": {
  5. "field": "tags",
  6. "include": ".*sport.*",
  7. "exclude": "water_.*"
  8. }
  9. }
  10. },
  11. )
  12. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. tags: {
  5. terms: {
  6. field: 'tags',
  7. include: '.*sport.*',
  8. exclude: 'water_.*'
  9. }
  10. }
  11. }
  12. }
  13. )
  14. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "tags": {
  5. "terms": {
  6. "field": "tags",
  7. "include": ".*sport.*",
  8. "exclude": "water_.*"
  9. }
  10. }
  11. }
  12. }`)),
  13. es.Search.WithPretty(),
  14. )
  15. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. tags: {
  4. terms: {
  5. field: "tags",
  6. include: ".*sport.*",
  7. exclude: "water_.*",
  8. },
  9. },
  10. },
  11. });
  12. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "tags": {
  5. "terms": {
  6. "field": "tags",
  7. "include": ".*sport.*",
  8. "exclude": "water_.*"
  9. }
  10. }
  11. }
  12. }

上記の例では、sportという単語を含むすべてのタグのバケットが作成されますが、water_で始まるものは除外されます(したがって、タグwater_sportsは集約されません)。include正規表現は、集約される「許可された」値を決定し、excludeは集約されるべきでない値を決定します。両方が定義されている場合、excludeが優先され、つまり、includeが最初に評価され、その後excludeが評価されます。

構文は正規表現クエリと同じです。

Filtering Values with exact values

正確な値に基づいて一致させるために、includeおよびexcludeパラメータは、インデックスに見つかった用語を表す文字列の配列を単純に受け取ることができます:

Python

  1. resp = client.search(
  2. aggs={
  3. "JapaneseCars": {
  4. "terms": {
  5. "field": "make",
  6. "include": [
  7. "mazda",
  8. "honda"
  9. ]
  10. }
  11. },
  12. "ActiveCarManufacturers": {
  13. "terms": {
  14. "field": "make",
  15. "exclude": [
  16. "rover",
  17. "jensen"
  18. ]
  19. }
  20. }
  21. },
  22. )
  23. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. "JapaneseCars": {
  5. terms: {
  6. field: 'make',
  7. include: [
  8. 'mazda',
  9. 'honda'
  10. ]
  11. }
  12. },
  13. "ActiveCarManufacturers": {
  14. terms: {
  15. field: 'make',
  16. exclude: [
  17. 'rover',
  18. 'jensen'
  19. ]
  20. }
  21. }
  22. }
  23. }
  24. )
  25. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "JapaneseCars": {
  5. "terms": {
  6. "field": "make",
  7. "include": [
  8. "mazda",
  9. "honda"
  10. ]
  11. }
  12. },
  13. "ActiveCarManufacturers": {
  14. "terms": {
  15. "field": "make",
  16. "exclude": [
  17. "rover",
  18. "jensen"
  19. ]
  20. }
  21. }
  22. }
  23. }`)),
  24. es.Search.WithPretty(),
  25. )
  26. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. JapaneseCars: {
  4. terms: {
  5. field: "make",
  6. include: ["mazda", "honda"],
  7. },
  8. },
  9. ActiveCarManufacturers: {
  10. terms: {
  11. field: "make",
  12. exclude: ["rover", "jensen"],
  13. },
  14. },
  15. },
  16. });
  17. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "JapaneseCars": {
  5. "terms": {
  6. "field": "make",
  7. "include": [ "mazda", "honda" ]
  8. }
  9. },
  10. "ActiveCarManufacturers": {
  11. "terms": {
  12. "field": "make",
  13. "exclude": [ "rover", "jensen" ]
  14. }
  15. }
  16. }
  17. }

Filtering Values with partitions

時には、単一のリクエスト/レスポンスペアで処理するにはユニークな用語が多すぎるため、分析を複数のリクエストに分割することが有用です。これは、クエリ時にフィールドの値を複数のパーティションにグループ化し、各リクエストで1つのパーティションのみを処理することで実現できます。このリクエストは、最近アクセスしていないアカウントを探しています:

Php

  1. $params = [
  2. 'body' => [
  3. 'size' => 0,
  4. 'aggs' => [
  5. 'expired_sessions' => [
  6. 'terms' => [
  7. 'field' => 'account_id',
  8. 'include' => [
  9. 'partition' => 0,
  10. 'num_partitions' => 20,
  11. ],
  12. 'size' => 10000,
  13. 'order' => [
  14. 'last_access' => 'asc',
  15. ],
  16. ],
  17. 'aggs' => [
  18. 'last_access' => [
  19. 'max' => [
  20. 'field' => 'access_date',
  21. ],
  22. ],
  23. ],
  24. ],
  25. ],
  26. ],
  27. ];
  28. $response = $client->search($params);

Python

  1. resp = client.search(
  2. size=0,
  3. aggs={
  4. "expired_sessions": {
  5. "terms": {
  6. "field": "account_id",
  7. "include": {
  8. "partition": 0,
  9. "num_partitions": 20
  10. },
  11. "size": 10000,
  12. "order": {
  13. "last_access": "asc"
  14. }
  15. },
  16. "aggs": {
  17. "last_access": {
  18. "max": {
  19. "field": "access_date"
  20. }
  21. }
  22. }
  23. }
  24. },
  25. )
  26. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. size: 0,
  4. aggregations: {
  5. expired_sessions: {
  6. terms: {
  7. field: 'account_id',
  8. include: {
  9. partition: 0,
  10. num_partitions: 20
  11. },
  12. size: 10_000,
  13. order: {
  14. last_access: 'asc'
  15. }
  16. },
  17. aggregations: {
  18. last_access: {
  19. max: {
  20. field: 'access_date'
  21. }
  22. }
  23. }
  24. }
  25. }
  26. }
  27. )
  28. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "size": 0,
  4. "aggs": {
  5. "expired_sessions": {
  6. "terms": {
  7. "field": "account_id",
  8. "include": {
  9. "partition": 0,
  10. "num_partitions": 20
  11. },
  12. "size": 10000,
  13. "order": {
  14. "last_access": "asc"
  15. }
  16. },
  17. "aggs": {
  18. "last_access": {
  19. "max": {
  20. "field": "access_date"
  21. }
  22. }
  23. }
  24. }
  25. }
  26. }`)),
  27. es.Search.WithPretty(),
  28. )
  29. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. size: 0,
  3. aggs: {
  4. expired_sessions: {
  5. terms: {
  6. field: "account_id",
  7. include: {
  8. partition: 0,
  9. num_partitions: 20,
  10. },
  11. size: 10000,
  12. order: {
  13. last_access: "asc",
  14. },
  15. },
  16. aggs: {
  17. last_access: {
  18. max: {
  19. field: "access_date",
  20. },
  21. },
  22. },
  23. },
  24. },
  25. });
  26. console.log(response);

Console

  1. GET /_search
  2. {
  3. "size": 0,
  4. "aggs": {
  5. "expired_sessions": {
  6. "terms": {
  7. "field": "account_id",
  8. "include": {
  9. "partition": 0,
  10. "num_partitions": 20
  11. },
  12. "size": 10000,
  13. "order": {
  14. "last_access": "asc"
  15. }
  16. },
  17. "aggs": {
  18. "last_access": {
  19. "max": {
  20. "field": "access_date"
  21. }
  22. }
  23. }
  24. }
  25. }
  26. }

このリクエストは、顧客アカウントのサブセットの最終ログイン日を見つけています。なぜなら、長い間見られていない顧客アカウントを期限切れにしたいからです。num_partitions設定は、ユニークなaccount_idsが20のパーティション(0から19)に均等に整理されることを要求しています。このリクエストのpartition設定は、パーティション0に該当するaccount_idsのみを考慮するようにフィルタリングします。次のリクエストでは、パーティション1、次に2などを要求して、期限切れアカウントの分析を完了する必要があります。

返される結果の数に関するsize設定は、num_partitionsと調整する必要があります。この特定のアカウント期限切れの例では、sizenum_partitionsの値をバランスさせるプロセスは次のようになります:

  • 1. cardinality集約を使用して、ユニークなaccount_id値の合計数を推定します。
  • 2. 1)の数をより管理しやすいチャンクに分割するためにnum_partitionsの値を選択します。
  • 3. 各パーティションから取得したいレスポンスの数のためにsize値を選択します。
  • 4. テストリクエストを実行します。

サーキットブレーカーエラーが発生した場合、1つのリクエストでやりすぎているため、num_partitionsを増やす必要があります。リクエストが成功したが、日付でソートされたテストレスポンスの最後のアカウントIDがまだ期限切れにしたいアカウントである場合、興味のあるアカウントが欠落している可能性があり、数値を低く設定しすぎている可能性があります。私たちは、

  • 各パーティションでより多くの結果を返すためにsizeパラメータを増やす(メモリに重い可能性があります)か、
  • 各リクエストで考慮するアカウントを減らすためにnum_partitionsを増やす(より多くのリクエストを行う必要があるため、全体の処理時間が増加する可能性があります)

最終的には、単一のリクエストを処理するために必要なElasticsearchリソースと、クライアントアプリケーションがタスクを完了するために発行しなければならないリクエストのボリュームとのバランスを取ることになります。

パーティションは、excludeパラメータと一緒に使用することはできません。

Multi-field terms aggregation

terms集約は、同じドキュメント内の複数のフィールドから用語を収集することをサポートしていません。その理由は、terms aggが文字列の用語値自体を収集するのではなく、グローバルオーディナルを使用してフィールド内のすべてのユニークな値のリストを生成するためです。グローバルオーディナルは、複数のフィールドにわたっては不可能な重要なパフォーマンスブーストをもたらします。

複数のフィールドにわたってterms aggを実行するために使用できる3つのアプローチがあります:

  • スクリプト
  • 複数のフィールドから用語を取得するためにスクリプトを使用します。これにより、グローバルオーディナルの最適化が無効になり、単一フィールドから用語を収集するよりも遅くなりますが、検索時にこのオプションを実装する柔軟性が得られます。
  • copy_toフィールド
  • 2つ以上のフィールドから用語を収集したいことが事前にわかっている場合は、copy_toを使用してインデックス時に両方のフィールドの値を含む新しい専用フィールドを作成します。この単一フィールドで集約でき、グローバルオーディナルの最適化の恩恵を受けます。
  • multi_terms集約
  • 複数のフィールドから用語を組み合わせて複合キーを作成するためにマルチターム集約を使用します。これにより、グローバルオーディナルが無効になり、単一フィールドから用語を収集するよりも遅くなりますが、スクリプトを使用するよりも速く、柔軟性は低くなります。

Collect mode

子集約の計算を遅延させる

ユニークな用語が多く、必要な結果が少ないフィールドでは、親レベルの集約がプルーニングされるまで子集約の計算を遅らせる方が効率的です。通常、集約ツリーのすべてのブランチは、1つの深さ優先パスで展開され、その後にプルーニングが行われます。いくつかのシナリオでは、これは非常に無駄であり、メモリ制約に達する可能性があります。問題のシナリオの例は、映画データベースに対して最も人気のある10人の俳優とその5人の最も一般的な共演者をクエリすることです:

Python

  1. resp = client.search(
  2. aggs={
  3. "actors": {
  4. "terms": {
  5. "field": "actors",
  6. "size": 10
  7. },
  8. "aggs": {
  9. "costars": {
  10. "terms": {
  11. "field": "actors",
  12. "size": 5
  13. }
  14. }
  15. }
  16. }
  17. },
  18. )
  19. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. actors: {
  5. terms: {
  6. field: 'actors',
  7. size: 10
  8. },
  9. aggregations: {
  10. costars: {
  11. terms: {
  12. field: 'actors',
  13. size: 5
  14. }
  15. }
  16. }
  17. }
  18. }
  19. }
  20. )
  21. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "actors": {
  5. "terms": {
  6. "field": "actors",
  7. "size": 10
  8. },
  9. "aggs": {
  10. "costars": {
  11. "terms": {
  12. "field": "actors",
  13. "size": 5
  14. }
  15. }
  16. }
  17. }
  18. }
  19. }`)),
  20. es.Search.WithPretty(),
  21. )
  22. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. actors: {
  4. terms: {
  5. field: "actors",
  6. size: 10,
  7. },
  8. aggs: {
  9. costars: {
  10. terms: {
  11. field: "actors",
  12. size: 5,
  13. },
  14. },
  15. },
  16. },
  17. },
  18. });
  19. console.log(response);

用語の集約

ユニークな値ごとにバケットが動的に構築されるマルチバケット値ソースベースの集約です。

例:

用語の集約

ユニークな値ごとにバケットが動的に構築されるマルチバケット値ソースベースの集約です。

例:

ルビー

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. actors: {
  5. terms: {
  6. field: 'actors',
  7. size: 10,
  8. collect_mode: 'breadth_first'
  9. },
  10. aggregations: {
  11. costars: {
  12. terms: {
  13. field: 'actors',
  14. size: 5
  15. }
  16. }
  17. }
  18. }
  19. }
  20. }
  21. )
  22. puts response

ゴー

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "actors": {
  5. "terms": {
  6. "field": "actors",
  7. "size": 10,
  8. "collect_mode": "breadth_first"
  9. },
  10. "aggs": {
  11. "costars": {
  12. "terms": {
  13. "field": "actors",
  14. "size": 5
  15. }
  16. }
  17. }
  18. }
  19. }
  20. }`)),
  21. es.Search.WithPretty(),
  22. )
  23. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. actors: {
  4. terms: {
  5. field: "actors",
  6. size: 10,
  7. collect_mode: "breadth_first",
  8. },
  9. aggs: {
  10. costars: {
  11. terms: {
  12. field: "actors",
  13. size: 5,
  14. },
  15. },
  16. },
  17. },
  18. },
  19. });
  20. console.log(response);

コンソール

  1. GET /_search
  2. {
  3. "aggs": {
  4. "actors": {
  5. "terms": {
  6. "field": "actors",
  7. "size": 10,
  8. "collect_mode": "breadth_first"
  9. },
  10. "aggs": {
  11. "costars": {
  12. "terms": {
  13. "field": "actors",
  14. "size": 5
  15. }
  16. }
  17. }
  18. }
  19. }
  20. }
可能な値は breadth_firstdepth_first です

breadth_first モードを使用する場合、最上位のバケットに該当するドキュメントのセットは、後続のリプレイのためにキャッシュされるため、これを行う際にはメモリのオーバーヘッドが発生し、これは一致するドキュメントの数に対して線形です。order パラメータは、breadth_first 設定を使用する際に、子集計からのデータを参照するために引き続き使用できます - 親集計は、この子集計が他の子集計の前に呼び出される必要があることを理解しています。

top_hits のようなネストされた集計は、breadth_first コレクションモードを使用する集計の下でスコア情報にアクセスする必要があるため、2回目のパスでクエリをリプレイする必要がありますが、最上位のバケットに属するドキュメントのみに対してのみ行われます。

実行ヒント

用語集計を実行するための異なるメカニズムがあります:

  • バケットごとにデータを集計するためにフィールド値を直接使用すること (map)
  • フィールドのグローバルオーディナルを使用し、グローバルオーディナルごとに1つのバケットを割り当てること (global_ordinals)

Elasticsearchは、合理的なデフォルトを持つように努めているため、これは一般的に構成する必要がないものです。

global_ordinalskeyword フィールドのデフォルトオプションであり、グローバルオーディナルを使用してバケットを動的に割り当てるため、メモリ使用量は集計スコープに含まれるドキュメントの値の数に対して線形です。

map は、非常に少数のドキュメントがクエリに一致する場合にのみ考慮されるべきです。そうでなければ、オーディナルベースの実行モードは大幅に高速です。デフォルトでは、map はスクリプトで集計を実行する場合にのみ使用されます。スクリプトにはオーディナルがないためです。

Python

  1. resp = client.search(
  2. aggs={
  3. "tags": {
  4. "terms": {
  5. "field": "tags",
  6. "execution_hint": "map"
  7. }
  8. }
  9. },
  10. )
  11. print(resp)

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. tags: {
  5. terms: {
  6. field: 'tags',
  7. execution_hint: 'map'
  8. }
  9. }
  10. }
  11. }
  12. )
  13. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "tags": {
  5. "terms": {
  6. "field": "tags",
  7. "execution_hint": "map"
  8. }
  9. }
  10. }
  11. }`)),
  12. es.Search.WithPretty(),
  13. )
  14. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. tags: {
  4. terms: {
  5. field: "tags",
  6. execution_hint: "map",
  7. },
  8. },
  9. },
  10. });
  11. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "tags": {
  5. "terms": {
  6. "field": "tags",
  7. "execution_hint": "map"
  8. }
  9. }
  10. }
  11. }
可能な値はmapglobal_ordinalsです。

Elasticsearchは、適用できない場合はこの実行ヒントを無視し、これらのヒントに対して後方互換性の保証はありません。

Missing value

  1. #### Python
  2. ``````python
  3. resp = client.search(
  4. aggs={
  5. "tags": {
  6. "terms": {
  7. "field": "tags",
  8. "missing": "N/A"
  9. }
  10. }
  11. },
  12. )
  13. print(resp)
  14. `

Ruby

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. tags: {
  5. terms: {
  6. field: 'tags',
  7. missing: 'N/A'
  8. }
  9. }
  10. }
  11. }
  12. )
  13. puts response

Go

  1. res, err := es.Search(
  2. es.Search.WithBody(strings.NewReader(`{
  3. "aggs": {
  4. "tags": {
  5. "terms": {
  6. "field": "tags",
  7. "missing": "N/A"
  8. }
  9. }
  10. }
  11. }`)),
  12. es.Search.WithPretty(),
  13. )
  14. fmt.Println(res, err)

Js

  1. const response = await client.search({
  2. aggs: {
  3. tags: {
  4. terms: {
  5. field: "tags",
  6. missing: "N/A",
  7. },
  8. },
  9. },
  10. });
  11. console.log(response);

Console

  1. GET /_search
  2. {
  3. "aggs": {
  4. "tags": {
  5. "terms": {
  6. "field": "tags",
  7. "missing": "N/A"
  8. }
  9. }
  10. }
  11. }
tagsフィールドに値がないドキュメントは、N/Aの値を持つドキュメントと同じバケットに入ります。

フィールドタイプの混合

複数のインデックスで集計する場合、集計されるフィールドのタイプはすべてのインデックスで同じでない可能性があります。一部のタイプは互換性があります (integerlong または floatdouble) が、タイプが小数と非小数の数の混合である場合、用語集計は非小数の数を小数の数に昇格させます。これにより、バケット値の精度が失われる可能性があります。

トラブルシューティング

バイトのフォーマットに失敗しました

複数のインデックスで用語集計(または他の集計、実際には通常は用語)を実行していると、
「バイトのフォーマットに失敗しました…」で始まるエラーが発生することがあります。これは通常、集計されるフィールドのマッピングタイプが同じでない2つのインデックスが原因です。

明示的な value_type を使用してください マッピングを修正するのが最善ですが、インデックスの1つでフィールドが未マップの場合、この問題を回避することができます。value_type パラメータを設定することで、未マップのフィールドを正しいタイプに強制することで問題を解決できます。

Python

  1. resp = client.search(
  2. aggs={
  3. "ip_addresses": {
  4. "terms": {
  5. "field": "destination_ip",
  6. "missing": "0.0.0.0",
  7. "value_type": "ip"
  8. }
  9. }
  10. },
  11. )
  12. print(resp)

ルビー

  1. response = client.search(
  2. body: {
  3. aggregations: {
  4. ip_addresses: {
  5. terms: {
  6. field: 'destination_ip',
  7. missing: '0.0.0.0',
  8. value_type: 'ip'
  9. }
  10. }
  11. }
  12. }
  13. )
  14. puts response

Js

  1. const response = await client.search({
  2. aggs: {
  3. ip_addresses: {
  4. terms: {
  5. field: "destination_ip",
  6. missing: "0.0.0.0",
  7. value_type: "ip",
  8. },
  9. },
  10. },
  11. });
  12. console.log(response);

コンソール

  1. GET /_search
  2. {
  3. "aggs": {
  4. "ip_addresses": {
  5. "terms": {
  6. "field": "destination_ip",
  7. "missing": "0.0.0.0",
  8. "value_type": "ip"
  9. }
  10. }
  11. }
  12. }