ファイルキャッシュの内部構造

基礎概念

(1) キャッシュスライシングとプリフェッチメカニズム

Dorisは、データキャッシュ管理と読み取り効率を最適化するためにキャッシュスライシングとプリフェッチメカニズムを採用しています。具体的には、対象ファイルは1MBアラインメントでスライスされ、完全ダウンロード後に各スライスは個別のBlockファイルとしてローカルファイルシステムに保存されます。このスライシングアプローチは、キャッシュの粒度を効果的に削減し、キャッシュの柔軟性と容量使用率を向上させます。Dorisは必要なデータ部分のみをキャッシュでき、大きなファイル全体をキャッシュすることによる容量の無駄を回避します。小さなキャッシュブロックは管理と削除も容易にし、より精密なホットスポットデータアクセスを可能にします。

(2) ローカルファイルディレクトリの構成

キャッシュされたデータをより適切に管理するため、Dorisは特定のローカルファイルディレクトリ構造を採用しています。キャッシュは複数のディスクの複数のディレクトリに分散される可能性があります。ディレクトリ間での均等な分散を実現するため、Dorisは対象ファイルパスからハッシュ値を計算し、このハッシュをBlockファイル保存用の最下位レベルディレクトリとして使用します。各Blockファイルは、対象ファイル内でのオフセット位置に基づいて命名されます。

たとえば、対象ファイルパスが/remote/data/datafile1でハッシュ値が12345の場合、キャッシュされたBlockファイルは/cache/123/12345/offset1に保存される可能性があります。ここでoffset1は元ファイル内でのブロックのオフセット位置を表します。

(3) マルチキューメカニズム

Dorisのファイルキャッシュは、異なるデータタイプを分離してキャッシュ汚染を防ぎ、ヒット率を向上させるためにマルチキューメカニズムを使用します。キャッシュデータは以下のタイプに分類され、それぞれが重要度に基づいて優先順位付けされた別々のキューに保存されます：

• TTL Queue：TTL（Time-To-Live）属性を持つデータを保存します。このデータは指定されたTTL期間中キャッシュに残り、その期間中は最も高い優先度を持ちます。キャッシュ容量が不足している場合、システムはTTLデータを保持するために他のキューからデータを優先的に削除します。TTLはテーブル属性です。たとえば、3600に設定すると、このテーブルにインポートされたデータはインポート後1時間ファイルキャッシュに残ることを意味します。使用例：長いTTL値を持つ常駐テーブルなど、ローカル永続化が必要な小規模テーブルに適しています。
• Index Queue：主にクエリフィルタリング操作を加速するために使用されるインデックスデータを保存し、通常はアクセス頻度が高いです。注意：転置インデックスファイルは「インデックス」であるにもかかわらず、通常サイズが大きいため、通常のキャッシュデータとして扱われます。
• Normal Queue：TTL属性を持たない通常のデータを保存します。大部分のデータがこのカテゴリに該当します。
• Disposable Queue：compaction読み取りなどの一時的なデータを保存します。このデータは通常使用後に削除され、最も低い優先度を持ちます。

このマルチキューメカニズムにより、Dorisは異なるデータ特性と使用シナリオに基づいてキャッシュ容量を合理的に割り当て、キャッシュリソースの使用率を最大化できます。

(4) 削除メカニズム

キャッシュ削除メカニズムは、ファイルキャッシュ管理において重要であり、容量が制限されている場合にどのデータを削除対象として選択するかを決定します。Dorisの削除メカニズムには以下のトリガーと選択戦略が含まれます：

削除トリガー：

• 容量制約による受動的削除：
  • ローカルディスク容量やinode数が不足している場合、Dorisは容量を解放するために受動的削除をトリガーします。
  • キャッシュ容量制限に達した場合：ディスク容量が残っていても、キャッシュ使用量が事前定義された閾値に達すると削除が開始されます。
• 能動的な事前削除：新しいデータが古いデータの削除を待つ必要がある同期削除（クエリパフォーマンスに影響）とは異なり、Dorisは使用量がハイウォーターマークに達した際に古いキャッシュを非同期でクリーンアップします。
• 能動的なガベージコレクション：LRUは未使用データを削除できますが、Dorisはcompaction/Schema Change元データ、失敗したインポートロールバックデータ、削除されたテーブル/パーティションデータなどのガベージデータを能動的にクリーンアップします。
• TTL期限切れ：TTLデータ特有です。TTLが期限切れになると、データは通常キャッシュに降格され、通常の削除に参加します。

削除対象の選択：

• 削除比率：キューは個別の比率制限でディスク容量を共有します。容量が豊富な場合（他のキューが比率に達していない）、キューは残りの全容量を使用できます。たとえば、通常キャッシュは総容量の40%に制限されている可能性がありますが、他のデータが存在しない場合は利用可能な全容量を使用できます。他のキューデータが入ってくると、比率は徐々に事前設定値に近づきます。
• 削除順序：書き込みキャッシュ容量が不足している場合、Dorisは次の順序でデータを削除します：Disposable → Normal → Index → TTL。他のキューデータを削除してもまだ十分な容量が解放されない場合、同じキュータイプ内でLRU削除が発生します。

削除回避の推奨事項：

• 十分なディスク容量：容量制約による頻繁な削除を避けるため、キャッシュデータを収容するのに十分な容量を確保してください。キャッシュクリーンアップには遅延があるため、ある程度のバッファを維持してください。経験上、最適なヒット率を得るにはファイルキャッシュ容量はクエリホットデータサイズの約1.5倍にする必要があります。
• 大規模クエリの分離：大規模クエリを別のクラスターにルーティングして、キャッシュ容量を占有し他のクエリのヒット率に影響を与えることを防いでください。

(5) ウォームアップメカニズム

キャッシュウォームアップは、後続のクエリを加速するためにデータを事前にキャッシュに読み込みます。Dorisは複数のウォームアップアプローチを提供します：

• 手動ウォームアップ：ユーザーは特定のテーブル/パーティションの現在のクラスターキャッシュをウォームアップしたり、別のクラスターを参照してそのキャッシュされたテーブル/パーティションをウォームアップしたりできます。ウォームアップは常にリモートストレージから（他のクラスター/BEからではなく）ダウンロードします。実行後、対象（テーブル/パーティションまたは参照クラスター）はBEダウンロード用のタブレットセットに変換されます。BEダウンロードロジックは本質的に、すべてのタブレットデータファイルの順次読み取りを実行してローカルにキャッシュします。ウォームアップデータ量は大きい可能性があるため、Dorisは中断後の復旧用チェックポイントを持つ最大20GBのバッチにタスクを分割します。BEで深刻な問題（クラッシュなど）が発生したりユーザーがウォームアップをキャンセルしたりした場合、すべてのBEがダウンロードを停止します。ユーザーはSHOW WARM UP JOBを通じて実行中ジョブの進行状況を含むジョブステータス（FINISHED、CANCELLED、RUNNING）を確認できます。同じテーブル/パーティションの繰り返しウォームアップは既存データを再ダウンロードせず、増分更新のみを実行します。
• 負荷分散トリガードウォームアップ：タブレット分散がアンバランスになった場合（特にノード障害やスケーリング時）、タブレットは新しいBEに移行します。対象BEは次に、ソースBE（利用可能な場合）からのメタデータを使用してキャッシュデータをダウンロードし、新しいノードでのクエリキャッシュヒットを確実にします。ソースBEキャッシュデータはクリーンアップ中に能動的に削除されます。注意：移行と完全ダウンロード間にはキャッシュミスが発生する可能性のある時間窓があります。
• クロスクラスター自動ウォームアップ（v3.1+）：compute-storage分離シナリオでは、ユーザーはコンピュートクラスター間での自動キャッシュ同期を望む場合があります（例：インポートがクラスターAで発生するがクエリがクラスターBで行われる場合）。Dorisは2つの自動同期方法を提供します：
  • 定期的ウォームアップ：リアルタイム要件がない場合、WARM UP SQLに同期間隔を追加します。一回限りの実行ではなく、タスクは定期的に指定されたテーブル/パーティションを一つのクラスターから別のクラスターに増分的に同期します。
  • インポート/compactionトリガードウォームアップ：リアルタイム要件の場合、インポート完了イベントを使用してウォームアップをトリガーします。タブレットはクラスター間で異なって分散される可能性があるため、FEはソースクラスターに対象クラスターのタブレット分散について通知します。ソースクラスターのインポートコミット段階で、新しくインポートされたリモートストレージデータをダウンロードするよう対象クラスターBEに通知します。Compactionはウォームアップ用の類似した通知パスに従います。

シナリオ分析

(1) クエリ処理におけるファイルキャッシュ

クエリ時、ファイルキャッシュはリモートストレージアクセスを削減し、データ取得を加速します：

• Scannerがデータファイルを読み取り：クエリが到着すると、Scannerは必要なデータファイルの読み取りを試行します。
• ローカルキャッシュチェック：リモートストレージにアクセスする前に、Scannerは最初にローカルファイルキャッシュをチェックします。
• キャッシュヒット：キャッシュメタデータが要求されたファイルパスとオフセットを含んでいる場合、ScannerがBlockFileハンドルを直接読み取れるよう返し、リモートダウンロードを回避して遅延を削減します。
• キャッシュミス：部分的または完全にキャッシュされていない範囲については、Scannerはリモートストレージから不足データをダウンロードします。ダウンロードされたデータは削除ポリシーに従いながら、将来のクエリのためにファイルキャッシュに入ります。

(2) データロードにおけるファイルキャッシュ

インポート時、ファイルキャッシュは後続のクエリのためにデータを準備します：

• リモートストレージへのデータアップロード：インポートされたデータは最初にリモートストレージに送られます。
• 非同期ローカルキャッシュ書き込み：Dorisは非同期でこのデータをローカルディスクキャッシュに書き込み、インポート後クエリの即座のキャッシュヒットを可能にします。
• キャッシュタイプ：データタイプと属性（TTLなど）に基づいて、インポートされたデータは対応するキュー（TTL、Index、またはNormal）に入ります。

(3) Compactionにおけるファイルキャッシュ

Compactionは小さなファイルを統合することでストレージとクエリパフォーマンスを最適化します。Dorisには2つのタイプがあります：

• Cumulative Compaction：増分データバージョンを統合
• Base Compaction：ベースラインデータ（バージョン0）と増分バージョンを統合

compaction中のキャッシュ処理：

• Cumulative Compaction：新しく統合されたデータは、リモートストレージアップロード後にインポートと同様にファイルキャッシュに入り、後続のクエリを加速します。
• Base Compaction：Base Compactionは通常大きなコールドデータを含むため、新しいデータは容量が許可する場合のみキャッシュに入ります。ユーザーはBE設定enable_file_cache_keep_base_compaction_output = trueを通じてキャッシュ挿入を強制できますが、これは他のホットデータを削除する可能性があります。将来のバージョンでは、履歴クエリ統計を使用してキャッシュ挿入を決定する適応戦略を計画しています。

(4) 再起動後のキャッシュロード

再起動後のキャッシュロードは、キャッシュ状態の復旧と迅速なクエリレスポンスにとって重要です。v3.1以前では、保持されないLRU情報が一貫性のないキュー順序を引き起こし、ヒット率に影響していました。

v3.1でLRU永続化を導入：

• 定期的ダンプ：DorisはLRUキュー順序情報を定期的にディスクにダンプします。
• 再起動後ロード：ノードはダンプされたLRU情報を再ロードしてキュー状態を復元します。
• フルディスクスキャン：定期ダンプによる潜在的なメタデータファイル不整合に対処するため、Dorisは完全性のためにLRUロード後にフルディスクスキャンを実行します。
• クエリトリガード非同期ロード：スキャンには時間がかかるため、BEはプロセス中にクエリを処理できます。クエリがスキャンされていないデータにアクセスする場合、遅延を最小化するために早期ロードが発生します。

(5) スケーリング中のキャッシュ処理

スケーリング操作はクラスター管理において一般的です。Dorisはスケーリング中に以下のようにファイルキャッシュを処理します：

• 水平スケールアウト：タブレットの新しいBEへの移行中、対象BEはソースBEからのメタデータを使用してキャッシュデータをダウンロードし、新しいノードでのキャッシュヒットを確実にします。
• 水平スケールイン：スケールアウトと類似ですが、縮小されたクラスターキャッシュ容量が実際のキャッシュサイズを下回る場合、標準メカニズムに従って削除が発生します。
• 垂直スケールアウト：
  • ディスク追加：Dorisはディスク間でのリハッシュやバランシングを行わないため推奨されません。キャッシュディレクトリの変更は検索失敗を引き起こす可能性があります。必要な場合は、キャッシュをクリアし必要に応じてウォームアップしてください。
  • ディスク容量の増加：同じディスク数での容量拡張の場合、curl http://BE_IP:WEB_PORT/api/file_cache?op=reset&capacity=123456を使用してBEに通知します。
• 垂直スケールイン：
  • ディスク容量の削減：reset操作も必要です。新しい容量がキャッシュサイズを下回る場合、標準メカニズムに従って削除が発生します。
• スケーリング後ウォームアップの注意事項：水平スケーリングにはタブレットリバランシングが含まれるため、効果的にするためウォームアップ前に安定化を待ってください。doris_fe_tablet_numメトリクスを監視してください。カーブが安定すると、ウォームアップが完了します。