SQLキャッシュ
説明
SQL Cacheは、Dorisが提供するクエリ最適化メカニズムで、クエリパフォーマンスを大幅に向上させることができます。クエリ結果をキャッシュすることで冗長な計算を削減し、データの更新頻度が低いシナリオに適しています。
SQL Cacheは、以下の主要な要因に基づいてキャッシュを格納・取得します：
-
SQLテキスト
-
ビュー定義
-
テーブルおよびパーティションのバージョン
-
ユーザー変数および結果値
-
非決定的関数および結果値
-
Row Policy定義
-
Data Masking定義
これらの要因の組み合わせによって、キャッシュされたデータセットが一意に決定されます。SQLの変更、異なるクエリフィールドや条件、データ更新後のバージョン変更など、これらの要因のいずれかが変更された場合、キャッシュはヒットしません。
複数テーブルのjoinを含むクエリの場合、テーブルの1つが更新されると、パーティションIDまたはバージョン番号が異なるため、キャッシュミスが発生します。
SQL Cacheは、T+1更新シナリオに非常に適しています。データは早朝に更新され、最初のクエリがBackend（BE）から結果を取得してキャッシュに格納し、その後の同様のクエリはキャッシュから直接結果を取得します。リアルタイムデータ更新でもSQL Cacheを使用できますが、キャッシュヒット率が低くなる可能性があります。
現在、SQL Cacheは内部のOlapTablesと外部のHiveテーブルの両方をサポートしています。
使用制限
非決定的関数
-
非決定的関数とは、計算結果が入力パラメータと固定の関係を形成しない関数を指します。
-
一般的な関数
select now()を例に取ります。この関数は現在の日時を返します。この関数は異なる時間に実行されると異なる結果を返すため、その戻り値は動的に変化しています。now関数は秒レベルで時刻を返すため、前の秒のSQL Cacheは同じ秒内で再利用できますが、次の秒には新しいSQL Cacheを作成する必要があります。 -
キャッシュ利用を最適化するため、このような細かい粒度の時間を
select * from tbl where dt=date(now())のように粗い粒度の時間に変換することが推奨されます。この場合、同じ日内のクエリはSQL Cacheを活用できます。 -
対照的に、
random()関数は実行のたびに結果が変わるため、キャッシュの利用が困難です。したがって、クエリでこのような非決定的関数の使用は可能な限り避けるべきです。
原理
BE原理
ほとんどの場合、SQL Cache結果はコンシステントハッシュ法を通じてBEを選択し、そのBEのメモリに格納されます。これらの結果はHashMap構造で格納されます。キャッシュの読み書き要求が到着すると、システムはSQL文字列などのメタデータ情報のダイジェストをキーとして使用し、HashMapから結果データを迅速に取得・操作します。
FE原理
Frontend（FE）がクエリ要求を受信すると、まずSQL文字列を使用してメモリ内を検索し、同じクエリが以前に実行されたかを判断し、そのクエリのメタデータ情報の取得を試みます。この情報には、クエリに関わるテーブルとパーティションのバージョンが含まれます。
これらのメタデータが変更されていない場合、対応するテーブル内のデータが変更されていないことを示し、以前のSQL Cacheの再利用が可能です。この場合、FEはSQLパースと最適化プロセスをスキップし、コンシステントハッシュアルゴリズムに基づいて対応するBEを直接特定し、そこからクエリ結果の取得を試みることができます。
-
対象のBEにクエリのキャッシュされた結果が含まれている場合、FEは結果を迅速にクライアントに返すことができます。
-
逆に、BEで対応する結果キャッシュが見つからない場合、FEは完全なSQLパースと最適化プロセスを実行し、その後クエリプランをBEに送信して計算・処理を行う必要があります。
BEが計算結果をFEに返すとき、FEはこれらの結果を対応するBEに格納し、このクエリのメタデータ情報をメモリに記録する責任があります。これは、その後同じクエリを受信したときに、FEがBEから直接結果を取得でき、クエリ効率を向上させるためです。
さらに、SQL最適化段階でクエリ結果が0行または1行のデータのみを含むと判定された場合、FEはこれらの結果をメモリに格納することを選択し、将来の同一クエリにより迅速に応答します。
使用開始
SQL Cacheの有効化と無効化
-- Enable SQL Cache for the current session, default is disabled
set enable_sql_cache=true;
-- Disable SQL Cache for the current session
set enable_sql_cache=false;
-- Globally enable SQL Cache, default is disabled
set global enable_sql_cache=true;
-- Globally disable SQL Cache
set global enable_sql_cache=false;
SQLキャッシュにクエリがヒットしているかの確認
Dorisバージョン2.1.3以降では、ユーザーはexplain plan文を実行して、現在のクエリがSQL Cacheに正常にヒットしているかを確認できます。
例で示されているように、クエリプランツリーにLogicalSqlCacheまたはPhysicalSqlCacheノードが含まれている場合、そのクエリがSQL Cacheにヒットしていることを示しています。
> explain plan select * from t2;
+------------------------------------------------------------------------------------------------------------+
| Explain String (Nereids Planner) |
+------------------------------------------------------------------------------------------------------------+
| ========== PARSED PLAN (time: 28ms) ========== |
| LogicalSqlCache[1] ( queryId=711dea740e4746e6-8bc11afe08f6542c ) |
| +--PhysicalResultSink[39] ( outputExprs=[id#0, name#1] ) |
| +--PhysicalOlapScan[t2]@0 ( stats=12 ) |
| |
| ========== ANALYZED PLAN ========== |
| LogicalSqlCache[1] ( queryId=711dea740e4746e6-8bc11afe08f6542c ) |
| +--PhysicalResultSink[39] ( outputExprs=[id#0, name#1] ) |
| +--PhysicalOlapScan[t2]@0 ( stats=12 ) |
| |
| ========== REWRITTEN PLAN ========== |
| LogicalSqlCache[1] ( queryId=711dea740e4746e6-8bc11afe08f6542c ) |
| +--PhysicalResultSink[39] ( outputExprs=[id#0, name#1] ) |
| +--PhysicalOlapScan[t2]@0 ( stats=12 ) |
| |
| ========== OPTIMIZED PLAN ========== |
| PhysicalSqlCache[3] ( queryId=711dea740e4746e6-8bc11afe08f6542c, backend=192.168.126.3:9051, rowCount=12 ) |
| +--PhysicalResultSink[39] ( outputExprs=[id#0, name#1] ) |
| +--PhysicalOlapScan[t2]@0 ( stats=12 ) |
+------------------------------------------------------------------------------------------------------------+
Doris 2.1.3より前のバージョンでは、ユーザーはクエリがSQL Cacheにヒットしたかどうかを確認するためにProfile情報をチェックする必要があります。Profile情報において、Is Cached:フィールドがYesと表示されている場合、そのクエリがSQL Cacheに正常にヒットしたことを示しています。
Execution Summary:
- Parse SQL Time: 18ms
- Nereids Analysis Time: N/A
- Nereids Rewrite Time: N/A
- Nereids Optimize Time: N/A
- Nereids Translate Time: N/A
- Workload Group: normal
- Analysis Time: N/A
- Wait and Fetch Result Time: N/A
- Fetch Result Time: 0ms
- Write Result Time: 0ms
- Doris Version: 915138e801
- Is Nereids: Yes
- Is Cached: Yes
- Total Instances Num: 0
- Instances Num Per BE:
- Parallel Fragment Exec Instance Num: 1
- Trace ID:
- Transaction Commit Time: N/A
- Nereids Distribute Time: N/A
両方の方法は、ユーザーがクエリがSQL Cacheを利用しているかどうかを確認する効果的な手段を提供し、ユーザーがクエリパフォーマンスをより良く評価し、クエリ戦略を最適化するのに役立ちます。
Metrics and Monitor
1. FEのHTTPインターface http://${FE_IP}:${FE_HTTP_PORT}/metrics は2つの関連するmetricsを返します: この指標はヒット数をカウントし、増加するのみで減少することはありません。FEが再起動されると、カウントは0から開始されます。
# Represents that 1 SQL has been written to the cache
doris_fe_cache_added{type="sql"} 1
# Represents that the SQL Cache has been hit twice
doris_fe_cache_hit{type="sql"} 2
2. BE上のHTTPインターフェース http://${BE_IP}:${BE_HTTP_PORT}/metrics は関連情報を返します: 異なるキャッシュが異なるBEに保存される可能性があるため、完全な情報を取得するにはすべてのBEからメトリクスを収集する必要があります。
# Represents that there are 1205 caches in the memory of the current BE
doris_be_query_cache_sql_total_count 1205
# The current total memory occupied by all caches in the BE is 44k
doris_be_query_cache_memory_total_byte 44101
Memory Control
FE Memory Control
FEでは、Cacheのメタデータ情報は弱参照に設定されています。FEメモリが不足している場合、システムは最も最近使用されていないCacheメタデータを自動的に解放します。さらに、ユーザーは以下のSQL文を実行することでFEメモリ使用量をさらに制限できます。この設定はリアルタイムで有効になり、各FEに対して設定する必要があります。永続的な設定については、fe.confファイルに保存する必要があります。
-- Store up to 100 Cache metadata items, automatically releasing the least recently used ones when exceeded. The default value is 100.
ADMIN SET FRONTEND CONFIG ('sql_cache_manage_num'='100');
-- Automatically release Cache metadata after 300 seconds of inactivity. The default value is 300.
ADMIN SET FRONTEND CONFIG ('expire_sql_cache_in_fe_second'='300');
BE メモリ制御
be.confファイルで以下の設定を変更し、BEを再起動後に変更が有効になります：
-- When the Cache memory exceeds query_cache_max_size_mb + query_cache_elasticity_size_mb,
-- release the least recently used Cache until the memory usage is below query_cache_max_size_mb.
query_cache_max_size_mb = 256
query_cache_elasticity_size_mb = 128
さらに、結果の行数やサイズが特定の閾値を超えた場合にSQL Cacheの作成を回避するよう、FEで設定を行うことができます：
-- By default, do not create SQL Cache for results exceeding 3000 rows.
ADMIN SET FRONTEND CONFIG ('cache_result_max_row_count'='3000');
-- By default, do not create SQL Cache for results exceeding 30MB.
ADMIN SET FRONTEND CONFIG ('cache_result_max_data_size'='31457280');
Cache Missのトラブルシューティング
キャッシュ無効化の理由には、通常以下が含まれます：
-
table/viewの構造変更、例えば
drop table、replace table、alter table、またはalter viewの実行。 -
tableデータの変更、例えば
insert、delete、update、またはtruncateの実行。 -
ユーザー権限の削除、例えば
revokeの実行。 -
評価値が変化する非決定的関数の使用、例えば
select random()の実行。 -
値が変化する変数の使用、例えば
select * from tbl where dt = @dt_varの実行。 -
Row PolicyまたはData Maskingの変更、例えば特定のtableデータをユーザーに対して非表示に設定すること。
-
結果行数がFEで設定された
cache_result_max_row_countを超える場合、デフォルト値は3000行。 -
結果サイズがFEで設定された
cache_result_max_data_sizeを超える場合、デフォルト値は30MB。