読み書き分離における File Cache 最適化のベストプラクティス
Apache Doris のコンピュートとストレージが分離されたアーキテクチャで、複数のコンピュートグループによって読み書きを分離する場合、クエリ性能は File Cache のヒット率に大きく左右されます。読み取り専用コンピュートグループで Cache Miss が発生すると、リモートのオブジェクトストレージからデータを取得する必要があり、クエリのレイテンシが大幅に増加することがあります。
このドキュメントでは、キャッシュウォームアップと関連設定を使用して、Compaction、データ取り込み、Schema Change に起因する Cache Miss を減らし、読み取り専用クラスタのクエリ性能を安定させる方法を説明します。
主な問題：新しいデータバージョン（Rowset）による Cache Miss
Doris では、Compaction、Schema Change、データ取り込みによって新しいデータファイル群（Rowset）が生成されます。書き込み専用コンピュートグループは、書き込み時にデフォルトでデータをローカルの File Cache にキャッシュするため、そのコンピュートグループのクエリ性能には影響しません。
読み取り専用コンピュートグループでは、メタデータを同期して新しい Rowset を認識しても、そのデータファイルはローカルキャッシュにありません。この時点でクエリが新しい Rowset にアクセスすると、Cache Miss が発生し、性能が低下します。
基本方針は、クエリがアクセスする前に、読み取り専用コンピュートグループのキャッシュへデータを事前に、または状況に応じて読み込むことです。
キャッシュウォームアップの仕組み
キャッシュウォームアップとは、リモートストレージから BE ノードの File Cache へデータを能動的に読み込む処理です。Doris には主に次の二つの方法があります。
| ウォームアップ方式 | 適用する状況 | 特徴 |
|---|---|---|
| アクティブ増分ウォームアップ | ウォームアップ関係を設定する権限がある一般的な状況 | 状況に応じて自動実行される。第一候補として推奨 |
| 読み取り専用コンピュートグループの自動ウォームアップ | ウォームアップ関係を設定する権限がない場合、または MoW 以外のテーブルを使用する場合 | 軽量で設定が簡単 |
アクティブ増分ウォームアップ（推奨）
書き込み用コンピュートグループと読み取り専用コンピュートグループの間にウォームアップ関係を設定します。書き込みや Compaction などで新しい Rowset が生成されると、システムは関連する読み取り専用コンピュートグループに能動的に通知し、非同期のキャッシュウォームアップを開始します。
詳しい設定方法は、FileCache のアクティブ増分ウォームアップを参照してください。
読み取り専用コンピュートグループの自動ウォームアップ
読み取り専用コンピュートグループの BE ノードでこの設定を有効にすると、新しい Rowset を検出するたびに、システムが非同期のウォームアップタスクを自動的に開始します。
読み取り専用コンピュートグループの be.conf に次を設定します。
enable_warmup_immediately_on_new_rowset = true
コンピュートグループ間の Peer Cache Read（フォールバック）
ウォームアップの対象から漏れたコールドデータの読み取りには、Peer Cache Readをフォールバックとして使用できます。ローカルキャッシュでミスが発生すると、読み取り専用コンピュートグループは、まず書き込み用コンピュートグループの BE にある File Cache からブロックを読み取り、それにも失敗した場合にのみオブジェクトストレージへアクセスします。書き込み用コンピュートグループをフィル用コンピュートグループ（peer_cache_fill_compute_group_id）に設定すると、書き込み用グループが読み取り専用グループに代わって不足するブロックをオブジェクトストレージから取得し、自身のキャッシュにもコピーを保持します。
Peer Cache Read はデフォルトで有効です。クエリ実行時に受動的に読み取る仕組みであり、ウォームアップの代わりにはなりません。読み取り専用クエリが、書き込み用コンピュートグループのネットワーク帯域とキャッシュ読み取り能力を利用できるようになります。厳密な分離が必要な場合は無効にしてください。
Compaction と Schema Change がクエリ性能に与える影響を抑える
バックグラウンドの Compaction は古い Rowset を統合し、新しい Rowset を生成します。新しい Rowset がまだウォームアップされていない場合、Cache Miss によって読み取り専用コンピュートグループのクエリ性能が変動することがあります。次の二つの方法で対処できます。
方法 1：アクティブ増分ウォームアップとコミットの遅延（推奨）
この方法では、読み取り専用コンピュートグループが、Compaction や Schema Change によって生成された未キャッシュの新しい Rowset をクエリすることを根本的に防ぎます。
仕組み：
- 書き込み用コンピュートグループと読み取り専用コンピュートグループの間に、アクティブ増分ウォームアップ関係を設定します。
- 書き込み用コンピュートグループの BE ノードで、Compaction と Schema Change に対するコミット遅延機能を有効にします。
書き込み用コンピュートグループの be.conf に次を設定します。
enable_compaction_delay_commit_for_warm_up = true
処理の流れ：
- 書き込み用コンピュートグループで Compaction または Schema Change のタスクが完了し、新しい Rowset が生成されます。
- 新しい Rowset は直ちにはコミットされず、読み取り専用コンピュートグループからは見えません。
- システムが、関連する読み取り専用コンピュートグループで新しい Rowset のキャッシュウォームアップを開始します。
- 関連するすべての読み取り専用コンピュートグループでウォームアップが完了してから、新しい Rowset がコミットされ、すべてのコンピュートグループから見えるようになります。
利点：
- 円滑な切り替え：読み取り専用コンピュートグループから見える Compaction の結果はすべてキャッシュ済みのため、クエリ性能が変動しません。
- 高い安定性：読み書き分離環境でクエリ性能を保証するうえで、最も堅牢な方法です。
方法 2：読み取り専用コンピュートグループの自動ウォームアップとクエリでの考慮
この方法では、クエリ層が状況に応じて Rowset を選択し、ウォームアップが完了していない新しい Rowset を可能な場合にスキップします。
注意：Unique Key MoW テーブルでは、正しい結果を得るために Compaction によって生成された Rowset をスキップできません。
設定手順：
-
読み取り専用コンピュートグループの
be.confで自動ウォームアップを有効にします。enable_warmup_immediately_on_new_rowset = true -
セッション変数またはユーザープロパティを使用して、ウォームアップ状態を考慮した Rowset 選択方式をクエリ時に有効にします。
クエリセッションに設定する場合：
SET enable_prefer_cached_rowset = true;ユーザープロパティとして設定する場合：
SET property for "jack" enable_prefer_cached_rowset = true;
処理の流れ：
- 読み取り専用コンピュートグループが Compaction による新しい Rowset を検出すると、非同期のウォームアップタスクを開始します。
enable_prefer_cached_rowsetを有効にすると、クエリ実行エンジンはウォームアップ済みの Rowset バージョンを優先します。- ウォームアップ中の新しい Rowset は、データの整合性に影響しない範囲でクエリが自動的にスキップし、代わりにキャッシュ済みの古い Rowset にアクセスします。
注意事項：
この方法はベストエフォートです。新しい Rowset に対応する古い Rowset がすでに削除されている場合や、クエリが最新のデータバージョンにアクセスする必要がある場合は、ウォームアップの完了を待つか、コールドデータを直接読み取ります。
データ取り込みがクエリ性能に与える影響を抑える
INSERT INTO や Stream Load などによる高頻度のデータ取り込みでは、小さな新しいファイル（Rowset）が継続的に生成され、読み取り専用コンピュートグループで Cache Miss が発生します。業務上、秒単位またはサブ秒単位のデータ遅延を許容できる場合は、以下を組み合わせることで、データの鮮度をわずかに下げる代わりに性能を大幅に改善できます。
仕組み： 自動ウォームアップとクエリ時の鮮度許容値を組み合わせます。指定した時間内にウォームアップが完了していない最新データを、クエリ実行エンジンが状況に応じてスキップします。
設定手順：
-
ウォームアップを有効にする：読み取り専用コンピュートグループでアクティブ増分ウォームアップを有効にするか、自動ウォームアップを有効にします。
enable_warmup_immediately_on_new_rowset = true -
クエリで許容するデータの遅延を設定する：読み取り専用コンピュートグループのクエリセッションまたはユーザープロパティに
query_freshness_tolerance_msを設定します。クエリセッションに設定する場合：
-- Allow up to 1000 milliseconds (1 second) of data latency
SET query_freshness_tolerance_ms = 1000;ユーザープロパティとして設定する場合：
SET property for "jack" query_freshness_tolerance_ms = 1000;
処理の流れ：
- クエリが実行を開始すると、アクセスが必要な Rowset を確認します。
- Rowset が直近 1000 ms 以内に生成され、かつウォームアップがまだ完了していない場合、クエリ実行エンジンはその Rowset を自動的にスキップし、代わりに古くてもキャッシュ済みのデータにアクセスします。
- ほとんどのクエリがキャッシュにヒットし、新たに書き込まれたコールドデータの読み取りによる性能低下を回避できます。
フォールバック動作： Rowset のウォームアップに query_freshness_tolerance_ms で指定した時間より長くかかる場合（たとえば 1000 ms を超える場合）、クエリはその Rowset をスキップしなくなります。データが最終的に見えるよう、デフォルトの動作に戻ってコールドデータを直接読み取ります。
利点：
- 大幅な性能向上：高スループットの書き込み環境で、クエリ性能の急な変動を効果的に抑えられます。
- 柔軟な調整：業務要件に応じて、データの鮮度とクエリ性能のバランスを調整できます。
方法の比較と選択
| 方法 | 適用する状況 | Compaction の影響 | Schema Change の影響 | 新規書き込みデータの影響 |
|---|---|---|---|---|
| アクティブ増分ウォームアップとコミットの遅延（必要に応じて鮮度許容値を追加） | クエリのレイテンシに対する要件が非常に厳しく、ウォームアップ関係を設定する権限がある場合 | なし | なし | 鮮度許容値の設定に依存 |
| 読み取り専用コンピュートグループの自動ウォームアップとキャッシュ済みデータの優先（必要に応じて鮮度許容値を追加） | ウォームアップ関係を設定する権限がない場合。鮮度許容値を設定しない MoW 主キーテーブルでは効果がない | なし | Cache Miss | 鮮度許容値の設定に依存 |
どちらの方法でも、ウォームアップの対象から漏れたコールドデータについて、オブジェクトストレージからの読み取りを減らすフォールバックとしてコンピュートグループ間の Peer Cache Readを組み合わせられます。上記のキャッシュウォームアップ方式と関連設定を適用することで、Apache Doris の読み書き分離アーキテクチャでキャッシュの動作を管理し、Cache Miss による性能低下を抑えて、読み取り専用クエリの性能を安定させることができます。
よくある質問
Q：アクティブ増分ウォームアップと読み取り専用コンピュートグループの自動ウォームアップを同時に有効にできますか？
はい。両者は併用できます。両方を有効にすると、ウォームアップの対象範囲が広がります。アクティブ増分ウォームアップを主な方法とし、自動ウォームアップを補助として使うことを推奨します。
Q：コミットの遅延を有効にした後、Compaction の結果はいつ見えるようになりますか？
関連するすべての読み取り専用コンピュートグループでウォームアップが完了してから、Compaction の結果がコミットされ、すべてのコンピュートグループから見えるようになります。ウォームアップがタイムアウトした場合は、Compaction の処理が停止しないように、システムが強制的にコミットします。
Q：query_freshness_tolerance_ms にはどの値を設定すればよいですか？
業務で許容できるデータ遅延に応じて設定してください。通常、500～2000 ms の範囲で性能と鮮度のバランスを取れます。リアルタイム性に対する要件が非常に厳しい場合は、この設定を有効にすることは推奨しません。
Q：MoW 主キーテーブルの Compaction による Rowset をスキップできないのはなぜですか？
MoW（Merge-on-Write）テーブルの削除セマンティクスは、Compaction 後に生成されるデータバージョンに依存します。その Rowset をスキップするとクエリ結果が誤る可能性があるため、システムは常に最新の Rowset を読み取ります。
Q：読み取り専用コンピュートグループのクエリ性能が急に低下しました。原因をすばやく調べるにはどうすればよいですか？
- BE の監視で File Cache のヒット率メトリクスを確認し、Cache Miss が大量に発生していないか調べます。
- 最近、Compaction、Schema Change、または大量のデータ取り込みが行われたか確認します。
- ウォームアップの仕組み（
enable_warmup_immediately_on_new_rowsetまたはアクティブ増分ウォームアップ）が正しく設定されているか確認します。 - ウォームアップタスクの実行状況を調べ、正常に完了しているか確認します。