[翻訳] star-tree インデックスの力：OpenSearch の集計を強化する
OpenSearch の集計機能は、リアルタイムのデータ分析と可視化において重要な役割を果たしています。OpenSearch Dashboards ではインタラクティブなチャートやダッシュボードの作成に広く活用され、大量のデータから洞察を得ることができます。しかし、データ量が増加するにつれて、集計のパフォーマンスが低下することがあります。そこで登場するのが star-tree インデックス です。
star-tree インデックスは OpenSearch 2.18 で導入された実験的機能で、インデックス作成時に集計結果を事前計算します。これにより、特に大規模なデータセットや複雑な集計において、クエリのレイテンシーを大幅に削減できます。ログデータに対するダッシュボードの実行や、数百万件のレコードに対するメトリクスの計算など、star-tree インデックスを使用すれば、クエリを変更することなく、より高速かつ予測可能なパフォーマンスを実現できます。
本記事では、star-tree インデックスの概要、仕組み、そして集計を高速化するための活用方法について解説します。
OpenSearch の集計機能
OpenSearch では、以下のような集計タイプが提供されています。
- メトリック集計: 数値フィールドに対する合計、最小値、最大値、平均値などを計算します。
- バケット集計: 定義された基準に基づいてクエリ結果をグループ化します。例えば、日付ヒストグラムを使用して時間間隔ごとにグループ化できます。
ただし、通常のクエリと比較して、集計にはパフォーマンス上の課題があります。
- スケーラビリティ: 一致するドキュメント数が増えるとクエリのレイテンシーが増加します。
- リソース消費: 集計には、より多くの CPU、メモリ、ディスクリソースが必要です。
例として、HTTP ステータスコードでグループ化し、平均値や合計などのメトリック集計を計算してアプリケーションログを分析するケースを考えてみましょう。
次の表は、出現頻度の高いステータスコードと低いステータスコードで集計する場合のクエリレイテンシーを比較しています。
| クエリ | ドキュメント数 | レイテンシー (ミリ秒) |
|---|---|---|
ステータス = 200 のメトリック集計 |
200,000,000 | 4200 |
ステータス = 400 のメトリック集計 |
3,000 | 5 |
この例では、ステータスコード 200 (OK) はログに非常に頻繁に出現しますが、ステータスコード 400 (Bad Request) は比較的まれです。200 のような高頻度の値に対する集計では、はるかに多くのドキュメントをスキャンする必要があり、レイテンシーが大幅に高くなります。一方、400 のような低頻度の値に対する集計では、処理するドキュメント数が少ないため、はるかに速く完了します。
star-tree インデックスは、データ量が増加しても、このレイテンシーを削減するように設計されています。
star-tree インデックスとは
Apache Pinot にインスパイアされた star-tree インデックスは、集計を高速化するために設計された OpenSearch 初のマルチフィールドインデックスです。インデックス作成時に、定義されたディメンションのすべての組み合わせに対して、設定されたメトリクスの集計を事前計算します。
次の図は、star-tree インデックスの概要を示しています。
このツリーは、status や Day などのディメンション値に基づいて階層的に構成されています。ルートノードからリーフへの各パスは、ディメンション値の一意の組み合わせを表します。リーフノードには、そのディメンションの組み合わせに一致するドキュメントの集計済みメトリクス (Avg(size) や Count(reqs) など) が格納されています。スターノード (*) は、特定のディメンションのすべての値にわたる集計値を表し、クエリが不要なブランチをスキップできるようにします。子ノード は、ドキュメント数が設定可能なしきい値 (maxLeafDocs) を超える場合にのみ作成されます。
図の例は、クエリがツリーをどのように走査するかを示しています。status = 200 かつ Day = 11 の平均サイズを求めるクエリは特定のパス (青い矢印で示されています) をたどりますが、Day = 12 (ステータスに関係なく) の平均サイズを求めるクエリはスターノードを使用して status ディメンションを完全にスキップします。
内部的には、star-tree インデックスは次のコンポーネントで構成されています。
- 効率的な走査のために一意のディメンション値をツリーノードに整理する スターツリー
- 設定されたディメンションの事前集計された結果を格納する 列指向のドキュメント値
詳細な技術情報については、star-tree インデックス構造をご覧ください。
star-tree インデックスを使用するメリット
star-tree インデックスは、大規模な高性能分析に適した以下のメリットを提供します。
予測可能なレイテンシー
従来、OpenSearch の集計クエリのレイテンシーは、一致するドキュメント数に応じて増加していました。star-tree インデックスは集計結果を事前計算することで、より高速で予測可能なクエリレイテンシーを実現します。
| クエリ | ドキュメント数 | 通常クエリのレイテンシー | star-tree クエリのレイテンシー |
|---|---|---|---|
| ステータス = 200 の Avg(duration) | 2 億 | 4.2 秒 | 6.3 ミリ秒 |
| ステータス = 400 の Avg(duration) | 3,000 | 5 ミリ秒 | 6.5 ミリ秒 |
複数集計のサポート
従来、異なるフィールドに対する複数の集計を含むクエリを実行する場合、各集計の各フィールドが個別に処理され、レイテンシーが増加していました。一方、star-tree インデックスはネイティブなマルチフィールドサポートを提供し、これらのシナリオでの効率が大幅に向上します。star-tree インデックスは複数の集計にまたがるクエリを前処理し、star-tree の繰り返し走査を不要にすることで、全体的なパフォーマンスを向上させます。
複雑な集計のスループット向上
大規模なデータセットに対するサブ集計を含む日付ヒストグラムのようなリソース集約型の操作では、star-tree インデックスによりレイテンシーを大幅に削減し、スループットを向上させることができます。
| クエリ | ドキュメント数 | 従来のクエリレイテンシー | star-tree クエリレイテンシー (N = 10,000) | 従来のクエリスループット | star-tree クエリスループット |
|---|---|---|---|---|---|
| チップ金額の合計に関する年次日付ヒストグラム (乗客数 = 1) | 1 億 2 千万 | 13 秒 | 94 ミリ秒 | 0.08 | 2.01 |
| 年次日付ヒストグラム (乗客数 = 1–2) | 1 億 4 千万 | 15 秒 | 114 ミリ秒 | 0.07 | 2.01 |
| 年次日付ヒストグラム (乗客数 = 1–5) | 1 億 6 千万 | 17 秒 | 160 ミリ秒 | 0.06 | 2.01 |
柔軟な設定
star-tree インデックスには、ストレージオーバーヘッドとクエリパフォーマンスのバランスを調整するための様々な設定オプションが用意されています。例えば、max_leaf_docs パラメータは、各 star-tree リーフに含まれるドキュメント数を制御します。max_leaf_docs の値を大きくするとストレージ効率は向上しますが、クエリレイテンシーが増加します。
次の表は、従来のクエリと異なる max_leaf_docs 値 (N) を持つ star-tree クエリのパフォーマンスの違いを示しています。
| クエリ | ドキュメント数 | 従来のクエリレイテンシー | star-tree クエリレイテンシー (N = 100) | star-tree レイテンシー (N = 10,000) |
|---|---|---|---|---|
ステータス = 200 のメトリック集計 |
2 億 | 4.2 秒 | 2.5 ミリ秒 | 6.3 ミリ秒 |
ステータス = 400 のメトリック集計 |
3,000 | 5 ミリ秒 | 2.7 ミリ秒 | 8.5 ミリ秒 |
リアルタイム対応
インデックスロールアップやトランスフォームなどの機能は事前集計されたビューを提供しますが、リアルタイムデータでは動作せず、インデックス作成のパフォーマンスを低下させる可能性があります。一方、star-tree インデックスは最小限のインデックス作成オーバーヘッドでリアルタイムに動作します。クエリの変更は不要で、エンジンが自動的に適格なクエリを検出し、star-tree インデックスにルーティングします。
制限事項
star-tree インデックスは大幅なパフォーマンス向上を実現しますが、現時点では以下の制限があります。
- star-tree インデックスは現在、不変のデータセットにのみ適しています。ドキュメントの変更 (更新または削除) は star-tree インデックスに反映されません。
- star-tree インデックスは refresh/flush/merge 操作中に作成されるため、書き込みスループットに影響を与える可能性があります。ベンチマークデータは近日公開予定です。
- インデックスに star-tree が作成されると、そのインデックスから削除することはできません。star-tree 機能を無効にする必要がある場合は、star-tree マッピング設定なしで新しいインデックスにすべてのデータを再インデックスする必要があります。ただし、
indices.composite_index.star_tree.enabledをfalseに設定することで、star-tree 検索ではなく従来の検索を使用してインデックスを検索できます。
詳細については、制限事項をご覧ください。
star-tree インデックスの使用方法
star-tree インデックスを使用するには、インデックス作成時に star-tree マッピングを定義します。マッピングは、最適化したい集計のディメンションとメトリクスを反映する必要があります。
star-tree インデックスを使用する際のポイントは以下のとおりです。
- クエリ構文やパラメータの変更は不要です。
- OpenSearch 2.19 時点では、特定の集計タイプのみがサポートされています。
- OpenSearch は自動的に適格なクエリを識別し、リアルタイムで star-tree インデックスを使用して最適化します。
- インデックス作成時に設定すれば、star-tree インデックスは追加のメンテナンスや変更を必要としません。
まとめ
star-tree インデックスは OpenSearch の集計パフォーマンスを大幅に向上させます。データ量が増加しても一貫した低レイテンシーの結果を提供し、クエリ側の変更は不要です。
今後は、ブールクエリ、日付範囲クエリ、ネストされた集計、および terms 集計を含む追加の集計およびクエリタイプをサポートする予定です。採用が進むにつれて、star-tree インデックスは OpenSearch におけるリアルタイム分析の重要なコンポーネントになることが期待されます。この機能の進捗状況を追跡するには、この Issue をご覧ください。
補足
OpenSearch 3.0.0 において、追加で以下の機能がサポートされました。
Discussion