階層型ストレージの概要Compatible with Milvus 2.6.4+

Milvusでは、従来のフルロードモードでは、各QueryNodeが初期化時にセグメントの全てのデータフィールドとインデックスをロードする必要があります。これにより、即座にデータを利用できるようになりますが、特に大規模なデータセットを扱う場合、高いメモリ使用量、重いディスクアクティビティ、大きなI/Oオーバーヘッドなど、リソースの浪費につながることがよくあります。

ティアード・ストレージは、データ・キャッシングをセグメントのロードから切り離すことで、この課題に対処します。すべてのデータを一度にロードする代わりに、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はオブジェクトストレージから特定のフィールドまたはインデックスをプロアクティブにフェッチしてキャッシュし、最初のクエリがオンデマンドロードをトリガするのではなく、キャッシュされたデータに直接ヒットするようにします。

ウォームアップ中、フィールドはチャンクレベルで、インデックスはセグメントレベルでプリロードされます。

構成

ウォームアップは3つのレベルで設定できます：

• クラスタ・レベル：milvus.yaml 、すべてのコレクションに適用されるデフォルトを定義します。

• コレクション・レベル：SDK メソッド (create_collection,alter_collection_properties) を使用して、特定のコレクションのクラスタ・デフォルトをオーバーライドします。

• フィールド/インデックス・レベル：SDK メソッド (add_field,alter_collection_field,add_index,alter_index_properties) を使用して、個々のフィールドまたはインデックスを微調整します。

上位の設定は下位の設定より優先されます (Field/Index > Collection > Cluster)。詳細な設定については、ウォームアップを参照してください。

フェーズ3: 部分ロード

クエリまたは検索が始まると、QueryNode は部分ロードを実行し、必要なデータチャンクまたはインデックスファイルのみをオブジェクトストレージからフェッチします。

• フィールド：チャンクレベルでオンデマンドにロードされます。現在のクエリ条件に一致するデータチャンクのみがフェッチされ、I/Oとメモリの使用を最小限に抑えます。

• インデックス：セグメント・レベルでオンデマンドでロードされます。インデックス・ファイルは完全な単位としてフェッチされる必要があり、チャンク間で分割することはできません。

構成

部分ロードは、Tiered Storageが有効な場合に自動的に適用される。手動設定は不要。クリティカルなデータのファーストヒットレイテンシを最小化するには、ウォームアップと組み合わせます。

フェーズ4: エビクション

健全なリソース利用を維持するため、Milvusは特定の閾値に達すると、未使用のキャッシュデータを自動的に解放します。

退避はLRU(Least Recently Used)ポリシーに従い、アクセス頻度の低いデータが最初に削除され、アクティブなデータはキャッシュに残ります。

立ち退きは、以下の設定可能な項目によって管理されます：

• ウォーターマーク：メモリまたはディスクのしきい値を定義して、立ち退きのトリガーと停止を設定します。

• キャッシュTTL: 定義された非アクティブ時間が経過すると、古くなったキャッシュ・データを削除します。

構成

milvus.yamlで立ち退きパラメータを有効にして調整します。詳細な設定については、「立ち退き」を参照してください。

開始

前提条件

• milvus 2.6.4以上

• 専用のメモリとディスクリソースを持つQueryNode

• オブジェクトストレージバックエンド（S3、MinIOなど）

基本構成テンプレート

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

次のステップ

1. ウォームアップの構成- アクセス・パターンに合わせてプリロードを最適化します。ウォームアップを参照してください。

2. Eviction の調整- リソースの制約に合わせて適切な透かしと TTL を設定します。立ち退き」を参照してください。

3. パフォーマンスを監視する- キャッシュ・ヒット率、退避頻度、およびクエリ・レイテンシのパターンを追跡します。

4. 設定の反復- 観察されたワークロード特性に基づいて設定を調整します。

よくある質問

実行時にTiered Storageパラメータを変更できますか?

パラメータの種類によって異なります：

• ウォームアップ設定：ウォームアップ設定：コレクション・レベルおよびフィールド/インデックス・レベルのウォームアップは、コレクションをロードする前にSDKを介して構成できます。コレクションがロードされると、最初にそれをリリースし、設定を変更し、再ロードする必要があります。

• 立ち退きと透かしの設定：これらはmilvusを起動する前にmilvus.yaml 。変更を有効にするには再起動が必要です。

Tiered Storageはデータの耐久性に影響しますか?

いいえ。データの永続性はリモートオブジェクトストレージによって処理されます。Tiered StorageはQueryNode上のキャッシュのみを管理します。

Tiered Storageを使用するとクエリは常に速くなりますか？

必ずしもそうではありません。Tiered Storageはロード時間とリソース使用量を削減しますが、キャッシュされていない（コールド）データに触れるクエリは待ち時間が長くなる可能性があります。レイテンシーに敏感なワークロードには、フルロードモードを推奨します。

Tiered Storageを有効にしてもQueryNodeのリソースが不足するのはなぜですか？

よくある原因は2つあります：

• QueryNodeのリソースが少なすぎる。ウォーターマークは利用可能なリソースに対する相対的なものなので、プロビジョニング不足は判断を誤らせます。

• QueryNodeリソースは他のワークロードと共有されるため、Tiered Storageは実際に利用可能な容量を正しく評価できません。

これを解決するには、QueryNodeに専用のリソースを割り当てることをお勧めします。

高い同時実行数で失敗するクエリがあるのはなぜですか？

多くのクエリが同時にホットデータをヒットした場合、QueryNodeのリソース制限を超える可能性があります。リソース予約のタイムアウトが原因で失敗するスレッドもあります。負荷が下がってから再試行するか、より多くのリソースを割り当てることで解決できます。

Tiered Storageを有効にすると、検索/クエリの待ち時間が長くなるのはなぜですか？

考えられる原因は以下のとおりです：

• コールドデータへのクエリが頻繁に発生し、ストレージからフェッチする必要がある。

• ウォーターマークが近すぎる位置に設定されているため、同期消去が頻繁に発生する。