Query Cache
Query Cache は StarRocks の強力な機能で、集計クエリのパフォーマンスを大幅に向上させることができます。ローカル集計の中間結果をメモリに保存することで、以前と同一または類似の新しいクエリに対して不要なディスクアクセスや計算を避けることができます。Query Cache を使用することで、StarRocks は集計クエリに対して迅速かつ正確な結果を提供し、時間とリソースを節約し、より良いスケーラビリティを実現します。特に、多くのユーザーが大規模で複雑なデータセットに対して類似のクエリを実行する高並行性のシナリオで有用です。
この機能は、v2.5 以降の共有なしクラスタと v3.4.0 以降の共有データクラスタでサポートされています。
v2.5 では、Query Cache は単一のフラットテーブルに対する集計クエリのみをサポートしています。v3.0 以降、Query Cache はスタースキーマで結合された複数のテーブルに対する集計クエリもサポートしています。
適用シナリオ
以下のシナリオで Query Cache の使用をお勧めします:
- 個々のフラットテーブルまたはスタースキーマで接続された複数の結合テーブルに対して頻繁に集計クエリを実行する場合。
- 集計クエリのほとんどが非-GROUP BY 集計クエリおよび低カーディナリティの GROUP BY 集計クエリである場合 。
- データが時間パーティションで追加モードでロードされ、アクセス頻度に基づいてホットデータとコールドデータに分類できる場合。
Query Cache は、以下の条件を満たすクエリをサポートします:
-
クエリエンジンが Pipeline であること。Pipeline エンジンを有効にするには、セッション変数
enable_pipeline_engine
をtrue
に設定します。注意
他のクエリエンジンは Query Cache をサポートしていません。
-
クエリが内部 OLAP テーブル (v2.5 以降) またはクラウドネイティブテーブル (v3.0 以降) に対して行われること。Query Cache は外部テーブルに対するクエリをサポートしていません。また、Query Cache は同期マテリアライズドビューへのアクセスを必要とするクエリもサポートしていますが、非同期マテリアライズドビューへのアクセスを必要とするクエリはサポートしていません。
-
クエリが個々のテーブルまたは複数の結合テーブルに対する集計クエリであること。
注意
- Query Cache は Broadcast Join と Bucket Shuffle Join をサポートしています。
- Query Cache は Join 演算子を含む 2 つの木構造をサポートしています: Aggregation-Join と Join-Aggregation。Aggregation-Join 木構造では Shuffle Join はサポートされておらず、Join-Aggregation 木構造では Hash Join はサポートされていません。
-
クエリに
rand
、random
、uuid
、sleep
などの非決定的な関数が含まれていないこと。
Query Cache は、以下のパーティションポリシーを使用するテーブルに対するクエリをサポートします: 非パーティション、マルチカラムパーティション、シングルカラムパーティション。
機能の境界
- Query Cache は Pipeline エンジンの per-tablet 計算に基づいています。per-tablet 計算とは、パイプラインドライバーがタブレット全体を一つずつ処理できることを意味します。各 BE がクエリのために処理する必要のあるタブレットの数が、このクエリを実行するために呼び出されるパイプラインドライバーの数以上である場合、Query Cache は機能します。呼び出されるパイプラインドライバーの数は、実際の並行度 (DOP) を表します。タブレットの数がパイプラインドライバーの数より少ない場合、各パイプラインドライバーは特定のタブレットの一部のみを処理します。この状況では、per-tablet 計算結果を生成できないため、Query Cache は機能しません。
- StarRocks では、集計クエリは少なくとも 4 つのステージで構成されています。最初のステージで AggregateNode によって生成された per-tablet 計算結果は、OlapScanNode と AggregateNode が同じフラグメントからデータを計算する場合にのみキャッシュできます。他のステージで AggregateNode によって生成された per-tablet 計算結果はキャッシュできません。一部の DISTINCT 集計クエリでは、セッション変数
cbo_cte_reuse
がtrue
に設定されている場合、データを生成する OlapScanNode と生成されたデータを消費するステージ 1 の AggregateNode が異なるフラグメントからデータを計算し、ExchangeNode によって橋渡しされる場合、Query Cache は機能しません。以下の 2 つの例は、CTE 最適化が実行され、Query Cache が機能しないシナリオを示しています:- 出力列が集計関数
avg(distinct)
を使用して計算される場合。 - 出力列が複数の DISTINCT 集計関数によって計算される場合。
- 出力列が集計関数
- データが集計前にシャッフルされる場合、そのデータに対するクエリは Query Cache で加速できません。
- テーブルの group-by 列または重複排除列が高カーディナリティの列である場合、そのテーブルに対する集計クエリは大きな結果を生成します。このような場合、クエリは実行時に Query Cache をバイパスします。
- Query Cache は、計算結果を保存するために BE によって提供される少量のメモリを占有します。Query Cache のデフォルトサイズは 512 MB です。したがって、大きなサイズのデータ項目を保存するには不適切です。さらに、Query Cache を有効にした後、キャッシュヒット率が低い場合、クエリパフォーマンスが低下します。したがって、タブレットの計算結果のサイズが
query_cache_entry_max_bytes
またはquery_cache_entry_max_rows
パラメータで指定されたしきい値を超える場合、Query Cache はクエリに対して機能しなくなり、クエリは Passthrough モードに切り替わります。
動作の仕組み
Query Cache が有効になっている場合、各 BE はクエリのローカル集計を次の 2 つのステージに分割します:
-
Per-tablet 集計
BE は各タブレットを個別に処理します。BE がタブレットの処理を開始するとき、まず Query Cache を調べ、そのタブレットに対する集計の中間結果が Query Cache にあるかどうかを確認します。ある場合 (キャッシュヒット)、BE は Query Cache から直接中間結果を取得します。ない場合 (キャッシュミス)、BE はディスク上のデータにアクセスし、ローカル集計を実行して中間結果を計算します。BE がタブレットの処理を終了すると、そのタブレットに対する集計の中間結果を Query Cache に保存します。
-
Inter-tablet 集計
BE はクエリに関与するすべてのタブレットから中間結果を収集し、それらを最終結果に統合します。
将来的に類似のクエリが発行されると、以前のクエリのキャッシュされた結果を再利用できます。例えば、次の図に示すクエリは 3 つのタブレット (Tablet 0 から 2) を含み、最初のタブレット (Tablet 0) の中間結果はすでに Query Cache にあります。この例では、BE はディスク上のデータにアクセスする代わりに、Query Cache から直接 Tablet 0 の結果を取得できます。Query Cache が完全にウォームアップされると、すべてのタブレットの中間結果を含むことができ、BE はディスク上のデータにアクセスする必要がありません。
余分 なメモリを解放するために、Query Cache は LRU (Least Recently Used) ベースのエビクションポリシーを採用してキャッシュエントリを管理します。このエビクションポリシーに従って、Query Cache が占有するメモリ量が事前定義されたサイズ (query_cache_capacity
) を超えると、最も最近使用されていないキャッシュエントリが Query Cache から削除されます。
注意
将来的に、StarRocks はキャッシュエントリを Query Cache から削除できる TTL (Time to Live) ベースのエビクションポリシーもサポートします。
FE は各クエリが Query Cache を使用して加速する必要があるかどうかを判断し、クエリのセマンティクスに影響を与えない些細なリテラルの詳細を排除するためにクエリを正規化します。
Query Cache の悪いケースによって引き起こされるパフォーマンスのペナルティを防ぐために、BE は実行時に Query Cache をバイパスするための適応ポリシーを採用しています。
Query Cache の有効化
このセクションでは、Query Cache を有効にして設定するために使用されるパラメータとセッション変数について説明します。
FE セッション変数
変数 | デフォルト値 | 動的に設定可能か | 説明 |
---|---|---|---|
enable_query_cache | false | Yes | Query Cache を有効にするかどうかを指定します。有効な値: true と false 。true はこの機能を有効にし、false は無効にします。Query Cache が有効な場合、このトピックの「適用シナリオ」セクションで指定された条件を満たすクエリに対してのみ機能します。 |
query_cache_entry_max_bytes | 4194304 | Yes | Passthrough モードをトリガーするしきい値を指定します。有効な値: 0 から 9223372036854775807 。クエリによってアクセスされる特定のタブレットの計算結果のバイト数または行数が query_cache_entry_max_bytes または query_cache_entry_max_rows パラメータで指定されたしきい値を超える場合、クエリは Passthrough モードに切り替わります。query_cache_entry_max_bytes または query_cache_entry_max_rows パラメータが 0 に設定されている場合、関与するタブレットから計算結果が生成されていない場合でも Passthrough モードが使用されます。 |
query_cache_entry_max_rows | 409600 | Yes | 上記と同じです。 |
BE パラメータ
BE の設定ファイル be.conf で次のパラメータを設定する必要があります。このパラメータを BE に再設定した後、BE を再起動して新しいパラメータ設定を 有効にする必要があります。
パラメータ | 必須 | 説明 |
---|---|---|
query_cache_capacity | No | Query Cache のサイズを指定します。単位: バイト。デフォルトサイズは 512 MB です。 各 BE はメモリ内に独自のローカル Query Cache を持ち、自分の Query Cache のみをポピュレートおよびプローブします。 Query Cache のサイズは 4 MB 未満にすることはできません。BE のメモリ容量が期待される Query Cache サイズをプロビジョニングするのに不十分な場合、BE のメモリ容量を増やすことができます。 |
すべてのシナリオでの最大キャッシュヒット率を実現するための設計
クエリが文字通り同一でない場合でも Query Cache が有効な 3 つのシナリオを考えてみましょう。これらの 3 つのシナリオは次のとおりです:
- セマンティックに等価なクエリ
- スキャンされたパーティションが重複するクエリ
- 追加のみのデータ変更があるデータに対するクエリ (UPDATE または DELETE 操作なし)
セマンティックに等価なクエリ
2 つのクエリが類似している場合、それらが文字通り等価である必要はありませんが、実行プランにセマンティックに等価なスニペットを含む場合、それらはセマンティックに等価と見なされ、互いの計算結果を再利用できます。広義には、2 つのクエリが同じソースからデータをクエリし、同じ計算方法を使用し、同じ実行プランを持っている場合、それらはセマンティックに等価です。StarRocks は、2 つのクエリがセマンティックに等価かどうかを評価するために次のルールを適用します:
-
2 つのクエリが複数の集計を含む場合、それらの最初の集計がセマンティックに等価である限り、それらはセマンティックに等価と評価されます。例えば、次の 2 つのクエリ、Q1 と Q2 はどちらも複数の集計を含んでいますが、それらの最初の集計はセマンティックに等価です。したがって、Q1 と Q2 はセマンティックに等価と評価されます。
-
Q1
SELECT
(
ifnull(sum(murmur_hash3_32(hour)), 0) + ifnull(sum(murmur_hash3_32(k0)), 0) + ifnull(sum(murmur_hash3_32(__c_0)), 0)
) AS fingerprint
FROM
(
SELECT
date_trunc('hour', ts) AS hour,
k0,
sum(v1) AS __c_0
FROM
t0
WHERE
ts between '2022-01-03 00:00:00'
and '2022-01-03 23:59:59'
GROUP BY
date_trunc('hour', ts),
k0
) AS t; -
Q2
SELECT
date_trunc('hour', ts) AS hour,
k0,
sum(v1) AS __c_0
FROM
t0
WHERE
ts between '2022-01-03 00:00:00'
and '2022-01-03 23:59:59'
GROUP BY
date_trunc('hour', ts),
k0
-
-
2 つのクエリが次のいずれかのクエリタイプに属する場合、それらはセマンティックに等価と評価されます。HAVING 句を含 むクエリは、HAVING 句を含まないクエリとセマンティックに等価と評価されることはありません。ただし、ORDER BY または LIMIT 句の有無は、2 つのクエリがセマンティックに等価かどうかの評価に影響を与えません。
-
GROUP BY 集計
SELECT <GroupByItems>, <AggFunctionItems>
FROM <Table>
WHERE <Predicates> [and <PartitionColumnRangePredicate>]
GROUP BY <GroupByItems>
[HAVING <HavingPredicate>]注意
上記の例では、HAVING 句はオプションです。
-
GROUP BY DISTINCT 集計
SELECT DISTINCT <GroupByItems>, <Items>
FROM <Table>
WHERE <Predicates> [and <PartitionColumnRangePredicate>]
GROUP BY <GroupByItems>
HAVING <HavingPredicate>注意
上記の例では、HAVING 句はオプションです。
-
非-GROUP BY 集計
-
SELECT <AggFunctionItems> FROM <Table>
WHERE <Predicates> [and <PartitionColumnRangePredicate>]