階層型ストレージの概要Compatible with Milvus 2.6.4+
Milvusでは、従来のフルロードモードでは、各QueryNodeが初期化時にセグメントの全てのデータフィールドとインデックスをロードする必要があります。これにより、即座にデータを利用できるようになりますが、特に大規模なデータセットを扱う場合、高いメモリ使用量、重いディスクアクティビティ、大きなI/Oオーバーヘッドなど、リソースの浪費につながることがよくあります。
ティアード・ストレージは、データ・キャッシングをセグメントのロードから切り離すことで、この課題に対処します。Milvusは全てのデータを一度にロードする代わりに、ホットデータ（ローカルにキャッシュされたデータ）とコールドデータ（リモートで保存されたデータ）を区別するキャッシュレイヤーを導入します。QueryNodeは軽量なメタデータのみを最初にロードし、必要に応じてフィールドデータを動的にプルまたはエヴィッシュします。これにより、ロード時間が大幅に短縮され、ローカルリソースの利用が最適化され、QueryNodeは物理メモリやディスク容量をはるかに超えるデータセットを処理できるようになります。
以下のようなシナリオでは、Tiered Storageを有効にすることを検討してください：
単一のQueryNodeで利用可能なメモリまたはNVMe容量を超えるコレクション
ファーストクエリのレイテンシよりも、より高速なロードが重要な分析ワークロードまたはバッチワークロード
アクセス頻度の低いデータのキャッシュミスを許容できる混合ワークロード
メタデータには、スキーマ、インデックス定義、チャンクマップ、行数、リモートオブジェクトへの参照が含まれる。この種のデータは小さく、常にキャッシュされ、削除されることはない。
セグメントとチャンクの詳細については、セグメント を参照。
仕組み
Tiered StorageはQueryNodeがセグメントデータを管理する方法を変更します。ロード時にすべてのフィールドとインデックスをキャッシュする代わりに、QueryNodeはメタデータのみをロードし、キャッシュレイヤーを使用して動的にデータをフェッチおよびエヴィクトします。
フルロードモードとティアードストレージモードの比較
フルロードモードと階層化ストレージモードはどちらも同じデータを扱いますが、QueryNodeがこれらのコンポーネントをキャッシュするタイミングと 方法が異なります。
フルロードモード：ロード時に、QueryNodeはメタデータ、フィールドデータ、インデックスを含む完全なコレクションデータをオブジェクトストレージからキャッシュします。
階層ストレージモード：ロード時に、QueryNodeはメタデータのみをキャッシュします。フィールドデータはチャンク単位でオンデマンドでプルされます。インデックス・ファイルは、最初のクエリが必要とするまでリモートのままです。その後、セグメントごとのインデックス全体がフェッチされ、キャッシュされます。
下図はこれらの違いを示している。
フルロードモードと階層化ストレージモード
QueryNodeロードワークフロー
Tiered Storageモードでは、ワークフローは以下のフェーズに分かれます：
クエリノード・ロード・ワークフロー
フェーズ1: 遅延ロード
初期化時、Milvusは遅延ロードを実行し、スキーマ定義、インデックス情報、チャンクマッピングなどのセグメントレベルのメタデータのみをキャッシュします。
この段階では実際のフィールドデータやインデックスファイルはキャッシュされません。これにより、メモリとディスクの消費を最小限に抑えながら、起動後すぐにコレクションをクエリ可能にすることができます。
フィールドデータとインデックスファイルは最初にアクセスされるまでリモートストレージに残るため、最初のクエリは必要なデータをオンデマンドでフェッチする必要があり、さらに待ち時間が発生する可能性があります。クリティカルなフィールドやインデックスに対してこの影響を軽減するには、ウォームアップ戦略を使用して、セグメントがクエリ可能になる前にそれらを事前にロードすることができます。
構成
Tiered Storageが有効な場合、自動的に適用されます。手動設定は不要です。
フェーズ2：ウォームアップ
遅延ロードによってもたらされるファーストヒットレイテンシを削減するために、MilvusはWarm Upメカニズムを提供します。
セグメントがクエリ可能になる前に、Milvusはオブジェクトストレージから特定のフィールドまたはインデックスをプロアクティブにフェッチしてキャッシュし、最初のクエリがオンデマンドロードをトリガするのではなく、キャッシュされたデータに直接ヒットするようにします。
ウォームアップ中、フィールドはチャンクレベルで、インデックスはセグメントレベルでプリロードされます。
設定
ウォームアップ設定は、milvus.yaml の「Tiered Storage」セクションで定義されます。 フィールドやインデックス・タイプごとにプリロードを有効または無効にし、優先するストラテジーを指定できます。詳細な構成については「ウォームアップ」を参照。
フェーズ3：部分ロード
クエリまたは検索が開始すると、QueryNode はパーシャル・ロードを実行し、必要なデータ塊またはインデックス・ファイルのみをオブジェクト・ストレージからフェッチします。
フィールド：チャンクレベルでオンデマンドにロードされます。現在のクエリ条件に一致するデータチャンクのみがフェッチされ、I/Oとメモリの使用を最小限に抑えます。
インデックス：セグメント・レベルでオンデマンドでロードされます。インデックス・ファイルは完全な単位としてフェッチされる必要があり、チャンク間で分割することはできません。
構成
部分ロードは、Tiered Storageが有効な場合に自動的に適用される。手動設定は不要。クリティカルなデータのファーストヒットレイテンシを最小化するには、ウォームアップと組み合わせます。
フェーズ4: エビクション
健全なリソース利用を維持するため、Milvusは特定の閾値に達すると、未使用のキャッシュデータを自動的に解放します。
退避はLRU(Least Recently Used)ポリシーに従い、アクセス頻度の低いデータが最初に削除され、アクティブなデータはキャッシュに残ります。
立ち退きは、以下の設定可能な項目によって管理されます：
ウォーターマーク：メモリまたはディスクのしきい値を定義して、立ち退きのトリガーと停止を設定します。
キャッシュTTL: 定義された非アクティブ時間が経過すると、古くなったキャッシュ・データを削除します。
構成
milvus.yamlで立ち退きパラメータを有効にして調整します。詳細な設定については、「立ち退き」を参照してください。
開始
前提条件
milvus 2.6.4以上
専用のメモリとディスクリソースを持つQueryNode
オブジェクトストレージバックエンド（S3、MinIOなど）
QueryNodeリソースは他のワークロードと共有しないでください。リソースを共有すると、Tiered Storageが利用可能な容量を誤って判断し、クラッシュにつながる可能性があります。
基本構成テンプレート
Milvus設定ファイル(milvus.yaml)を編集して、Tiered Storage設定を行います：
# milvus.yaml
queryNode:
segcore:
tieredStorage:
# Warm Up Configuration
warmup:
scalarField: sync # Preload scalar field data
scalarIndex: sync # Preload scalar indexes
vectorField: disable # Don't preload vector field data (large)
vectorIndex: sync # Preload vector indexes
# Eviction Configuration
evictionEnabled: true
backgroundEvictionEnabled: true
# Memory Watermarks
memoryLowWatermarkRatio: 0.75 # Stop evicting at 75%
memoryHighWatermarkRatio: 0.80 # Start evicting at 80%
# Disk Watermarks
diskLowWatermarkRatio: 0.75
diskHighWatermarkRatio: 0.80
# Cache TTL (7 days)
cacheTtl: 604800
次のステップ
ウォームアップの設定- アクセスパターンに合わせてプリロードを最適化します。ウォームアップを参照してください。
Tune Eviction- リソースの制約に合わせて適切な透かしとTTLを設定します。立ち退き」を参照してください。
パフォーマンスを監視する- キャッシュ・ヒット率、退避頻度、およびクエリ・レイテンシのパターンを追跡します。
設定の反復- 観察されたワークロード特性に基づいて設定を調整します。
よくある質問
実行時にTiered Storageパラメータを変更できますか?
全てのパラメータはmilvusを起動する前にmilvus.yaml 。変更を有効にするには再起動が必要です。
Tiered Storageはデータの耐久性に影響しますか?
いいえ。データの永続性はリモートオブジェクトストレージによって処理されます。Tiered StorageはQueryNode上のキャッシュのみを管理します。
Tiered Storageを使用するとクエリは常に速くなりますか？
必ずしもそうではありません。Tiered Storageはロード時間とリソース使用量を削減しますが、キャッシュされていない（コールド）データに触れるクエリは待ち時間が長くなる可能性があります。レイテンシーに敏感なワークロードには、フルロードモードを推奨します。
Tiered Storageを有効にしてもQueryNodeのリソースが不足するのはなぜですか？
よくある原因は2つあります：
QueryNodeのリソースが少なすぎる。ウォーターマークは利用可能なリソースに対する相対的なものなので、プロビジョニング不足は判断を誤らせます。
QueryNodeリソースは他のワークロードと共有されるため、Tiered Storageは実際に利用可能な容量を正しく評価できません。
これを解決するには、QueryNodeに専用のリソースを割り当てることをお勧めします。
高い同時実行数で失敗するクエリがあるのはなぜですか？
多くのクエリが同時にホットデータをヒットした場合、QueryNodeのリソース制限を超える可能性があります。リソース予約のタイムアウトが原因で失敗するスレッドもあります。負荷が下がってから再試行するか、より多くのリソースを割り当てることで解決できます。
Tiered Storageを有効にすると、検索/クエリの待ち時間が長くなるのはなぜですか？
考えられる原因は以下のとおりです：
コールドデータへのクエリが頻繁に発生し、ストレージからフェッチする必要がある。
ウォーターマークが近すぎる位置に設定されているため、同期消去が頻繁に発生する。