大規模な分析ワークロードにおいて、クエリはしばしば**繰り返しフィルタリング条件(Conditions)**を含みます。例えば:
SELECT * FROM orders WHERE region = 'ASIA'; SELECT count(*) FROM orders WHERE region = 'ASIA';
このようなクエリは、同一のデータセグメントに対して同じフィルタリングロジックを繰り返し実行するため、冗長なCPUとI/Oオーバーヘッドを引き起こします。
これを解決するため、Apache DorisはCondition Cacheメカニズムを導入しています。 特定の条件による特定のセグメントでのフィルタリング結果をキャッシュし、後続のクエリがそれらの結果を直接再利用できるようにすることで、不要なスキャンとフィルタリング処理を削減し、クエリレイテンシを大幅に低減します。
Condition Cacheの核となる概念は以下の通りです:
キャッシュされた結果は、圧縮された**bitベクトル(std::vector<bool>)**として保存されます:
このメカニズムにより、Dorisは粗い粒度で無関係なデータブロックを迅速に除外し、必要な場合のみ細かい粒度でのフィルタリングを実行できます。
Condition Cacheは以下の場合に最も効果的です:
以下の状況では、Condition Cacheは使用されません:
SET enable_condition_cache = true;
condition_cache_limitを超えた場合、最も最近使用されていないエントリが自動的にクリアされます。be.confでメモリ制限を変更できます:
condition_cache_limit = 1024 # Unit: MB
DorisはCondition Cacheの効果を監視するためのユーザー向け包括的なメトリクスを提供します:
ConditionCacheSegmentHit: キャッシュにヒットしたセグメント数ConditionCacheFilteredRows: キャッシュされた結果によって直接スキップされた行数/metrics経由で表示可能)condition_cache_search_count: 総キャッシュ検索回数condition_cache_hit_count: 成功したキャッシュヒット数これらのメトリクスはキャッシュの効果とヒット率を評価するのに役立ちます。
以下のクエリを考えてみます:
SELECT order_id, amount FROM orders WHERE region = 'ASIA' AND order_date >= '2023-01-01';
複数のクエリが同じフィルタリング条件(例: region = 'ASIA' AND order_date >= '2023-01-01')を共有する場合、それらは互いのCondition Cacheエントリを再利用でき、全体的なワークロードを削減します。
Condition CacheはDorisにおける繰り返し条件クエリ向けに設計された最適化メカニズムです。その利点には以下があります:
Condition Cacheを効果的に活用することで、ユーザーは高頻度OLAPクエリシナリオにおいて大幅に高速な応答時間を実現できます。