読み書き分離シナリオにおけるCache最適化のベストプラクティス

Apache Dorisのstorage-compute分離アーキテクチャを使用する際、特に複数のCompute Groupをデプロイして読み取り/書き込み分離を実装するシナリオでは、クエリパフォーマンスはFile Cacheのヒット率に大きく依存します。読み取り専用compute groupでキャッシュミスが発生すると、リモートオブジェクトストレージからデータを取得する必要があり、クエリレイテンシが大幅に増加します。

本ドキュメントでは、Compaction、Data Ingestion、Schema Changeなどの一般的なシナリオによって引き起こされるキャッシュミス問題を、キャッシュウォームアップと関連設定を通じて効果的に軽減する方法について詳述し、読み取り専用クラスタのクエリパフォーマンスの安定性を確保することを目的としています。

核心的問題：新しいデータバージョン（Rowsets）によるキャッシュ無効化

Dorisでは、Compaction / Schema Changeなどのバックグラウンドプロセスやフォアグラウンドデータ取り込みの両方が、新しいデータファイルセット（Rowsets）を生成します。書き込みを担当する書き込み専用compute groupのノードでは、このデータはデフォルトでローカルFile Cacheに書き込まれるため、そのクエリパフォーマンスは影響を受けません。

しかし、読み取り専用compute groupの場合、メタデータを同期してこれらの新しいRowsetsを認識しても、ローカルキャッシュにはこの新しいデータが含まれていません。その後クエリがこれらの新しいRowsetsにアクセスする必要がある場合、キャッシュミスがトリガーされ、パフォーマンスの低下を招きます。

この問題を解決するための核心的な考え方は：読み取り専用compute groupのキャッシュに、クエリされる前にデータを事前に、または知的にロードすることです。

I. キャッシュウォームアップメカニズムの概要

キャッシュウォームアップは、リモートストレージからBEノードのFile Cacheへデータを能動的にロードするプロセスです。Dorisでは以下の3つの主要なウォームアップ手法を提供しています：

1. プロアクティブ増分ウォームアップ（推奨）

これはより知的で自動化されたメカニズムです。書き込みcompute groupと読み取り専用compute groupの間にウォームアップ関係を確立します。書き込み/Compactionイベントが新しいRowsetを生成すると、関連する読み取り専用compute groupに能動的に通知し、非同期キャッシュウォームアップをトリガーします。

適用シナリオ:

• ほとんどのシナリオ。
• ウォームアップ関係を設定するためのユーザー権限が必要。

[ドキュメントリンク]: プロアクティブ増分ウォームアップの設定と使用方法の詳細については、公式ドキュメント FileCache Proactive Incremental Warm-up を参照してください。

2. 読み取り専用Compute Group自動ウォームアップ

これは軽量で自動的なウォームアップ戦略です。読み取り専用compute groupのBEノードで設定を有効にすることで、新しいRowsetを認識した際に自動的に非同期ウォームアップタスクをトリガーします。

適用シナリオ:

• ほとんどのシナリオ。
• ウォームアップ関係を設定するためのユーザー権限が必要。

核心的設定: 読み取り専用compute groupのbe.confで以下を設定：

enable_warmup_immediately_on_new_rowset = true

II. Compaction / Schema Change がクエリパフォーマンスに与える影響の最適化

背景 Compaction は古い Rowsets をマージし、新しいものを生成します。新しい Rowsets がウォームアップされていない場合、キャッシュミスにより読み取り専用コンピュートグループのクエリパフォーマンスが変動します。以下は2つの推奨ソリューションです。

ソリューション1：プロアクティブ増分ウォームアップ + 遅延コミット（推奨）

このソリューションは、読み取り専用コンピュートグループが Compaction / Schema Change によって生成されたまだキャッシュされていない新しい Rowsets をクエリすることを根本的に防ぐことができます。

動作原理：

1. まず、書き込みコンピュートグループと読み取り専用コンピュートグループ間のプロアクティブ増分ウォームアップ関係を設定します。
2. 書き込みコンピュートグループの BE ノードで、Compaction / Schema Change の遅延コミット機能を有効にします。

コア設定（書き込みコンピュートグループ be.conf）：

enable_compaction_delay_commit_for_warm_up = true

1. ワークフロー:
   1. 書き込みcompute groupでCompaction / Schema Change taskが完了し、新しいRowsetが生成されます。
   2. この時点では、Rowsetは即座にコミットされません（つまり、読み取り専用compute groupからは見えません）。
   3. システムは、関連する読み取り専用compute groupに対して、この新しいRowsetのキャッシュのウォームアップをトリガーします。
   4. 関連するすべての読み取り専用compute groupがウォームアップを完了した後にのみ、新しいRowsetが最終的にコミットされ、すべてのcompute groupから見えるようになります。

利点:

• シームレスな切り替え: 読み取り専用compute groupにとって、Compaction後に見えるすべてのデータは既にキャッシュに入っているため、クエリパフォーマンスが変動しません。
• 高い安定性: これは、読み書き分離シナリオにおけるクエリパフォーマンスを保証するための最も堅牢なソリューションです。

Solution 2: 読み取り専用Compute Group自動ウォームアップ + クエリ認識

このソリューションは、クエリレイヤーでインテリジェントな選択を使用して、まだウォームアップされていない新しいRowsetをスキップしようと試みます（注意：Unique Key MoWテーブルの場合、正確性を保証するためにcompactionからのRowsetはスキップできません）。

動作方法:

1. 読み取り専用compute groupのBEノードで、自動ウォームアップを有効にします。

コア設定（読み取り専用Compute Group be.conf）:

enable_warmup_immediately_on_new_rowset = true

1. クエリ実行時に、セッション変数またはユーザープロパティを通じて「prefer cached」Rowset選択ストラテジーを有効にします。

クエリセッションで設定:

SET enable_prefer_cached_rowset = true;

またはユーザープロパティとして設定：

SET property for "jack" enable_prefer_cached_rowset = true;

1. ワークフロー:
   1. read-onlyコンピュートグループがCompactionからの新しいRowsetを認識すると、非同期でウォームアップタスクをトリガーします。
   2. enable_prefer_cached_rowsetが有効な場合、クエリプランナーは読み込むRowsetを選択する際に、既にウォームアップされているものを優先します。
   3. データの一貫性に影響を与えない限り（つまり、マージ前の古いRowsetにまだアクセス可能）、まだウォームアップ中の新しいRowsetを自動的に無視します。

利点:

• コンピュートグループ間のウォームアップ関係を設定する必要がなく、比較的簡単に設定できます。
• ほとんどの場合でパフォーマンスへの影響を効果的に軽減します。

注意:

このソリューションは「ベストエフォート」戦略です。新しいRowsetに対応する古いRowsetが既にクリーンアップされている場合、またはクエリが最新のデータバージョンにアクセスする必要がある場合、クエリはウォームアップの完了を待つか、コールドデータに直接アクセスする必要があります。

III. データ取り込みがクエリパフォーマンスに与える影響の最適化

高頻度のデータ取り込み（INSERT INTO、Stream Loadなど）は継続的に新しい小さなファイル（Rowset）を生成し、これもread-onlyコンピュートグループでキャッシュミス問題を引き起こします。ビジネスが秒または秒未満のデータ遅延を許容できる場合、わずかな「鮮度」と引き換えに大きなパフォーマンス向上を得るために、以下の組み合わせ戦略を採用できます。

動作原理: この戦略は自動ウォームアップとクエリ鮮度許容設定を組み合わせ、クエリプランナーが指定された時間窓内でウォームアップされていない最新データをインテリジェントにスキップできるようにします。

実装手順:

1. ウォームアップメカニズムを有効化:

   1. read-onlyコンピュートグループでProactive Incremental Warm-upまたはRead-Only Compute Group Automatic Warm-up（enable_warmup_immediately_on_new_rowset=true）のいずれかを有効にします。これはデータが非同期でキャッシュに読み込まれるための前提条件です。

2. クエリ鮮度許容を設定:

   1. read-onlyコンピュートグループのクエリセッションでquery_freshness_tolerance_ms変数を設定します。

   2. クエリセッションで設定:

      -- Set a tolerance for 1000 milliseconds (1 second) of data latency
      SET query_freshness_tolerance_ms = 1000;

またはユーザープロパティとして設定:

  ```sql
  SET property for "jack" query_freshness_tolerance_ms = 1000;
  ```

ワークフロー:

• クエリが開始されると、アクセスする必要があるRowsetをチェックします。
• Rowsetが過去1000ms以内に生成され、まだウォームアップされていない場合、クエリプランナーは自動的にそれをスキップし、代わりに古いがすでにキャッシュされたデータにアクセスします。
• これにより、クエリの大部分がキャッシュにヒットし、最新の書き込みからのコールドデータを読み取ることによるパフォーマンス劣化を回避します。

フォールバックメカニズム:

Rowsetのウォームアッププロセスが非常に遅く、query_freshness_tolerance_msで設定された時間を超える場合（例：1000ms後もまだ完了していない）、最終的なデータ可視性を確保するため、クエリはもはやそれをスキップしません。デフォルトの動作にフォールバックします：コールドデータを直接読み取ります。

利点:

• 大幅なパフォーマンス向上: 高スループット書き込みシナリオにおけるクエリパフォーマンスのスパイクを効果的に排除します。
• 高い柔軟性: ユーザーはビジネスニーズに基づいて、データの新鮮さとクエリパフォーマンスの間で柔軟なトレードオフを行うことができます。

まとめと推奨事項

ソリューション	適用シナリオ	期待される効果（様々な書き込み操作がキャッシュヒット率に与える影響）
アクティブ増分プリウォーミング + 遅延コミット + 設定可能なデータ新鮮度許容値（オプション）	極めて高いクエリレイテンシ要件があるシナリオに適している; ユーザーがプリウォーミング関係を設定する権限を持つ必要がある	Compaction: なし 重い schema 変更: なし 新しく書き込まれたデータ: 新鮮度許容値に依存
自動プリウォーミング付き読み取り専用計算グループ + キャッシュデータの優先 + 設定可能なデータ新鮮度許容値（オプション）	ユーザーがプリウォーミング関係を設定する権限を持たない 新鮮度許容値が設定されていない場合、MOWプライマリキーテーブルには効果なし	Compaction: なし 重い schema 変更: キャッシュミス 新しく書き込まれたデータ: 新鮮度許容値に依存

上記のキャッシュウォームアップ戦略と関連設定を合理的に適用することで、読み書き分離アーキテクチャにおけるApache Dorisのキャッシュ動作を効果的に管理し、キャッシュミスによるパフォーマンス損失を最小化し、読み取り専用クエリサービスの安定性と効率性を確保できます。