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

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

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

核心的な問題：新しいデータバージョン（Rowsets）によって引き起こされるキャッシュ無効化

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

しかし、読み取り専用コンピュートグループの場合、メタデータを同期してこれらの新しいRowsetsを認識した時、そのローカルキャッシュにはこの新しいデータが含まれていません。クエリがこれらの新しいRowsetsにアクセスする必要がある場合、キャッシュミスが発生し、パフォーマンスの低下につながります。

この問題を解決するための核心的なアイデアは：データがクエリされる前に事前に、または賢明に読み取り専用コンピュートグループのキャッシュにデータをロードすることです。

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

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

1. プロアクティブインクリメンタルウォームアップ（推奨）

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

適用シナリオ：

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

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

2. 読み取り専用コンピュートグループ自動ウォームアップ

これは軽量で自動的なウォームアップ戦略です。読み取り専用コンピュートグループのBEノードで設定を有効にすることで、新しいRowsetを感知した時に自動的に非同期ウォームアップタスクをトリガーします。

適用シナリオ：

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

核心設定： 読み取り専用コンピュートグループの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 タスクが完了し、新しいRowsetが生成されます。
   2. この時点で、Rowsetは即座にコミットされません（つまり、読み取り専用compute groupには見えません）。
   3. システムは、この新しいRowsetのキャッシュをウォームアップするよう、関連する読み取り専用compute groupをトリガーします。
   4. 関連するすべての読み取り専用compute groupがウォームアップを完了した後にのみ、新しいRowsetが最終的にコミットされ、すべてのcompute groupから見えるようになります。

利点:

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

ソリューション 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. 読み取り専用compute groupがCompactionからの新しいRowsetを認識すると、非同期でwarm-upタスクをトリガーします。
   2. enable_prefer_cached_rowsetが有効な場合、クエリプランナーは読み取るRowsetを選択する際に、既にwarmed up済みのRowsetを優先します。
   3. データの一貫性に影響しない限り（つまり、マージ前の古いRowsetがまだアクセス可能である限り）、まだwarming up中の新しいRowsetを自動的に無視します。

利点:

• 比較的設定が簡単で、compute group間のwarm-up関係を設定する必要がない。
• ほとんどの場合でパフォーマンスへの影響を効果的に軽減する。

注意:

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

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

高頻度のデータ取り込み（INSERT INTO、Stream Loadなど）は継続的に新しい小さなファイル（Rowset）を生成し、これも読み取り専用compute groupでcache miss問題を引き起こします。ビジネスが秒単位または秒未満のデータ遅延を許容できる場合、以下の組み合わせ戦略を採用して、わずかな「鮮度」を大幅なパフォーマンス向上と引き換えることができます。

動作原理: この戦略は自動warm-upとクエリ鮮度許容度設定を組み合わせ、クエリプランナーが指定された時間ウィンドウ内でwarmed upされていない最新データを知的にスキップできるようにします。

実装手順:

1. Warm-upメカニズムを有効化:

   1. 読み取り専用compute groupでProactive Incremental Warm-upまたはRead-Only Compute Group Automatic Warm-up（enable_warmup_immediately_on_new_rowset=true）のいずれかを有効にします。これは、データが非同期でキャッシュに読み込まれるための前提条件です。

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

   1. 読み取り専用compute groupのクエリセッションで、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: なし 重いスキーマ変更: なし 新規書き込みデータ: 鮮度許容度に依存
自動プリウォームアップ付き読み取り専用計算グループ + キャッシュデータ優先 + 設定可能なデータ鮮度許容度（オプション）	ユーザーがプリウォームアップ関係を設定する権限を持たない 鮮度許容度が設定されていない場合、MOWプライマリキーテーブルには効果がない	Compaction: なし 重いスキーマ変更: キャッシュミス 新規書き込みデータ: 鮮度許容度に依存

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