Milvus
Zilliz
フロントページへ

階層型ストレージのベストプラクティスCompatible with Milvus 2.6.4+

Milvusは、クエリのレイテンシ、容量、リソースの使用量のバランスをとりながら、大規模データを効率的に処理するためのTiered Storageを提供します。このガイドでは、典型的なワークロードに対する推奨構成をまとめ、各チューニング戦略の背景となる理由を説明します。

始める前に

  • Milvus v2.6.4以降であること。

  • QueryNodeは専用のローカルリソース(メモリとディスク)を持つ必要があります。共有環境はキャッシュの推定を歪め、退避の判断を誤らせる可能性があります。

適切な戦略を選択する

Tiered Storageは、ワークロードに合わせて組み合わせることができる柔軟なローディングとキャッシュ戦略を提供します。

目標

推奨されるフォーカス

主要メカニズム

ファーストクエリの待ち時間を最小化する

重要なフィールドのプリロード

ウォームアップ

大規模データを効率的に扱う

オンデマンドロード

遅延ロード+部分ロード

長期安定性の維持

キャッシュのオーバーフローを防ぐ

立ち退き

パフォーマンスと容量のバランス

プリロードとダイナミック・キャッシュの組み合わせ

ハイブリッド構成

シナリオ1:リアルタイム、低遅延検索

どのような場合に使用するか

  • クエリーレイテンシーが重要な場合(例:リアルタイム推薦や検索ランキング)

  • コアベクターインデックスとスカラーフィルターが頻繁にアクセスされる

  • 起動速度よりも安定したパフォーマンスが重要

推奨構成

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      warmup:
        # scalar field/index warm-up to eliminate first-time latency
        scalarField: sync
        scalarIndex: sync
        # warm-up of vector fields is disabled (if the original vector is not required)
        vectorField: disable
        # vector indexes warm-up to elminate first-time latenct
        vectorIndex: sync
      # enable cache eviction, and also turn on background asynchronous eviction
      # to reduce the triggering of synchronous eviction.
      evictionEnabled: true
      backgroundEvictionEnabled: true
      memoryLowWatermarkRatio: 0.75
      memoryHighWatermarkRatio: 0.8
      diskLowWatermarkRatio: 0.75
      diskHighWatermarkRatio: 0.8
      # no expiration time, which avoids frequent reloading
      cacheTtl: 0

理由

  • ウォームアップにより、アクセス頻度の高いスカラーおよびベクトル・インデックスのファーストヒット・レイテンシを排除。

  • バックグラウンド・エビクションにより、クエリをブロックすることなく安定したキャッシュ・プレッシャーを維持する。

  • キャッシュTTLを無効にすることで、ホットデータに対する不要なリロードを回避。

シナリオ2:オフライン、バッチ分析

使用する場合

  • クエリのレイテンシ耐性が高い

  • ワークロードが巨大なデータセットまたは多数のセグメントを含む

  • 応答性よりも容量とスループットが優先される

推奨構成

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      enabled: true
      warmup:
        # disable scalar field/index warm-up to speed up loading
        scalarField: disable
        scalarIndex: disable
        # disable vector field/index warm-up to speed up loading
        vectorField: disable
        vectorIndex: disable
      # enable cache eviction, and also turn on background asynchronous eviction
      # to reduce the triggering of synchronous eviction.
      evictionEnabled: true
      backgroundEvictionEnabled: true
      memoryLowWatermarkRatio: 0.7
      memoryHighWatermarkRatio: 0.85
      diskLowWatermarkRatio: 0.7
      diskHighWatermarkRatio: 0.85
      # use 1 day expiration to clean unused cache
      cacheTtl: 86400

理由

  • ウォームアップを無効にすることで、多数のセグメントを初期化する際の起動が高速化される。

  • ウォーターマークを高くすることで、キャッシュをより密に使用できるようになり、総負荷容量が向上する。

  • キャッシュTTLが自動的に未使用データを削除し、ローカルスペースを解放する。

シナリオ3:ハイブリッド展開(オンラインとオフラインの混合)

使用する場合

  • 単一のクラスタがオンラインと分析の両方のワークロードに対応

  • 低レイテンシーを必要とするコレクションもあれば、容量を優先するコレクションもある。

推奨戦略

  • レイテンシに敏感なコレクションにはリアルタイム構成を適用

  • オフライン構成を分析またはアーカイブコレクションに適用する

  • ワークロードの種類ごとに、evictableMemoryCacheRatio、cacheTtl、および透かしの比率を個別に調整する。

理由

構成を組み合わせることで、リソースの割り当てをきめ細かく制御できる。

クリティカル・コレクションは低レイテンシの保証を維持し、セカンダリ・コレクションはより多くのセグメントとデータ量を処理できます。

その他のチューニングのヒント

側面

推奨事項

説明

ウォームアップ範囲

クエリ頻度の高いフィールドまたはインデックスのみをプリロードする。

不必要なプリロードはロード時間とリソース使用を増加させる。

立ち退きチューニング

デフォルトのウォーターマーク(75~80%)で開始し、徐々に調整する。

ギャップが小さいと頻繁に立ち退きが発生し、ギャップが大きいとリソースの解放が遅れます。

キャッシュTTL

安定したホットデータセットの場合は無効、動的データの場合は有効(例:1~3日)。

クリーンアップのオーバーヘッドのバランスをとりながら、古いキャッシュの蓄積を防ぎます。

オーバーコミット率

リソース・ヘッドルームが大きくない限り、0.7を超える値は避けてください。

過剰なオーバーコミットは、キャッシュのスラッシングと不安定なレイテンシを引き起こす可能性があります。

モニタリング

キャッシュヒット率、リソースの使用率、退避頻度を追跡する。

コールドロードが頻繁に発生する場合は、ウォームアップまたはウォーターマークの調整が必要であることを示している可能性があります。