ロールアップ検索の制限

8.11.0で非推奨

ロールアップは将来のバージョンで削除されます。代わりに、ダウンサンプリングにmigrateしてください。

ロールアップ機能は非常に柔軟であると感じていますが、データを要約する性質上、いくつかの制限があります。一度ライブデータが破棄されると、常にいくつかの柔軟性を失います。

このページでは、主要な制限を強調し、あなたがそれらを認識できるようにしています。

検索ごとに1つのロールアップインデックスのみ

indexエンドポイントを使用する場合、indexパラメータは1つ以上のインデックスを受け入れます。これらは通常の非ロールアップインデックスとロールアップインデックスの混合である可能性があります。ただし、指定できるロールアップインデックスは1つだけです。indexパラメータの正確なルールは次のとおりです：

  • 少なくとも1つのインデックス/インデックスパターンを指定する必要があります。これはロールアップインデックスまたは非ロールアップインデックスのいずれかです。インデックスパラメータを省略することや、_allを使用することは許可されていません
  • 複数の非ロールアップインデックスを指定できます
  • 指定できるロールアップインデックスは1つだけです。複数指定すると例外がスローされます
  • インデックスパターンを使用できますが、複数のロールアップインデックスに一致する場合は例外がスローされます。

この制限は、特定のクエリに対して「最適な」ジョブを決定するロジックによって駆動されています。単一のインデックスに保存された10のジョブがあり、異なる完全性と異なる間隔でソースデータをカバーしている場合、クエリは実際に検索するジョブのセットを決定する必要があります。不正確な決定は不正確な集計結果（例：ドキュメント数の過剰カウントや不正確なメトリック）につながる可能性があります。言うまでもなく、これは技術的に難しいコードの部分です。

問題を簡素化するために、検索を1回のロールアップインデックスのみに制限しました（複数のジョブを含む可能性があります）。将来的には、複数のロールアップジョブを開放できるかもしれません。

保存されたデータのみを集計可能

おそらく明白な制限ですが、ロールアップはロールアップに保存されたデータのみを集計できます。priceフィールドに関するメトリックを保存するようにロールアップジョブを構成しない場合、priceフィールドをクエリや集計で使用することはできません。

たとえば、次のクエリのtemperatureフィールドはロールアップジョブに保存されていますが、avgメトリックではありません。つまり、ここでのavgの使用は許可されていません：

Python

  1. resp = client.rollup.rollup_search(
  2.    index="sensor_rollup",
  3.    size=0,
  4.    aggregations={
  5.    "avg_temperature": {
  6.    "avg": {
  7.    "field": "temperature"
  8.    }
  9.    }
  10.    },
  11. )
  12. print(resp)

Ruby

  1. response = client.rollup.rollup_search(
  2.   index: 'sensor_rollup',
  3.   body: {
  4.    size: 0,
  5.    aggregations: {
  6.    avg_temperature: {
  7.    avg: {
  8.    field: 'temperature'
  9.    }
  10.    }
  11.    }
  12.   }
  13. )
  14. puts response

Js

  1. const response = await client.rollup.rollupSearch({
  2.   index: "sensor_rollup",
  3.   size: 0,
  4.   aggregations: {
  5.    avg_temperature: {
  6.    avg: {
  7.    field: "temperature",
  8.    },
  9.    },
  10.   },
  11. });
  12. console.log(response);

コンソール

  1. GET sensor_rollup/_rollup_search
  2. {
  3.   "size": 0,
  4.   "aggregations": {
  5.    "avg_temperature": {
  6.    "avg": {
  7.    "field": "temperature"
  8.    }
  9.    }
  10.   }
  11. }

レスポンスは、フィールドと集計が不可能であることを伝えます。なぜなら、それらを含むロールアップジョブが見つからなかったからです：

コンソール-結果

  1. {
  2.   "error": {
  3.    "root_cause": [
  4.    {
  5.    "type": "illegal_argument_exception",
  6.    "reason": "There is not a rollup job that has a [avg] agg with name [avg_temperature] which also satisfies all requirements of query.",
  7.    "stack_trace": ...
  8.    }
  9.    ],
  10.    "type": "illegal_argument_exception",
  11.    "reason": "There is not a rollup job that has a [avg] agg with name [avg_temperature] which also satisfies all requirements of query.",
  12.    "stack_trace": ...
  13.   },
  14.   "status": 400
  15. }

間隔の粒度

ロールアップは、設定のdate_histogramグループによって定義された特定の粒度で保存されます。これは、設定されたロールアップ間隔以上の間隔でのみロールアップデータを検索/集計できることを意味します。

たとえば、データが時間単位でロールアップされている場合、date_histogram APIは、時間単位またはそれ以上の任意の時間間隔で集計できます。1時間未満の間隔は例外をスローします。なぜなら、データが単純に存在しないからです。

リクエストは設定の倍数でなければなりません

すぐには明らかではないかもしれませんが、集計リクエストで指定された間隔は、設定された間隔の整数倍でなければなりません。ジョブが3d間隔でロールアップするように構成されている場合、3d、6d、9dなどの倍数でのみクエリおよび集計できます。

非倍数では機能しません。なぜなら、ロールアップされたデータが集計によって生成されたバケットと「重ならない」ため、不正確な結果につながるからです。

そのため、設定された間隔の整数倍が見つからない場合はエラーがスローされます。

ロールアップ検索エンドポイントは間隔を「アップサンプル」できるため、複数の間隔（時間単位、日単位など）でジョブを構成する必要はありません。必要な最小の粒度で単一のジョブを構成し、検索エンドポイントが必要に応じてアップサンプルできるようにすることをお勧めします。

とはいえ、異なる間隔を持つ複数のジョブが単一のロールアップインデックスに存在する場合、検索エンドポイントは検索リクエストを満たすために最大の間隔を持つジョブを特定して使用します。

制限されたクエリコンポーネント

ロールアップ機能は、検索リクエスト内でqueryを許可しますが、限られたサブセットのコンポーネントでのみ許可されます。現在許可されているクエリは次のとおりです：

  • タームクエリ
  • タームズクエリ
  • 範囲クエリ
  • MatchAllクエリ
  • 任意の複合クエリ（ブール、ブースティング、定数スコアなど）

さらに、これらのクエリは、ロールアップジョブにgroupとして保存されたフィールドのみを使用できます。キーワードhostnameフィールドでフィルタリングしたい場合、そのフィールドはtermsグループの下でロールアップジョブに構成されている必要があります。

サポートされていないクエリを使用しようとしたり、クエリがロールアップジョブに構成されていないフィールドを参照したりすると、例外がスローされます。サポートされるクエリのリストは、今後の実装に伴い増加することを期待しています。

タイムゾーン

ロールアップドキュメントは、ジョブのdate_histogramグループ設定のタイムゾーンに保存されます。タイムゾーンが指定されていない場合、デフォルトはUTCのタイムスタンプをロールアップすることです。