スナップショットCompatible with Milvus 3.0.x

スナップショットはMilvusコレクションのポイントインタイムイメージで、迅速なロールバック、バージョン管理、テストに最適です。特定のタイムスタンプでコレクションの状態をキャプチャし、スキーマ、インデックス、ベクトルデータファイル（binlog）などのメタデータとマニフェストファイルのみを保存し、効率的な保存と復元を実現します。

スナップショット構造

Milvusはマニフェストベースのスナップショットアーキテクチャを実装しており、実際のベクターデータを複製することなく、データの効率的なポイントインタイムのキャプチャ、保存、リストアを実現します。このアーキテクチャはメタデータ管理を物理データストレージから分離し、オブジェクトストレージ内の既存のセグメントファイルを参照する軽量のスナップショットを可能にします。

コレクションのスナップショットを作成すると、Milvusは以下を収集します：

• スナップショットのメタデータ

  スナップショット名と説明、ターゲットコレクションID、スナップショットが作成される時点など、スナップショットを作成するための基本情報を提供します。

• コレクションの説明

  スキーマ定義、パーティション情報、プロパティなど、ターゲット・コレクションの説明が含まれます。

• インデックス情報

  インデックスのメタデータとインデックスファイルへのパスが格納されます。

• セグメントデータ

  ベクターデータファイル(binlogs)、削除ログ(deltalogs)、インデックスファイルが格納される。

上記の情報のうち、Milvusは各セグメントのApache Avroマニフェストファイルを生成し、スナップショットのメタデータ、コレクションの説明、インデックス情報、マニフェストファイルへのパスをJSONファイルに格納します。次の図は、スナップショットのフォルダ構造を示しています。

snapshots/{collection_id}/
├── metadata/
│   └── {snapshot_id}.json         # Snapshot metadata (JSON format)
│
└── manifests/
    └── {snapshot_id}/             # Directory for each snapshot
        ├── {segment_id_1}.avro    # Individual segment manifest (Avro format)
        ├── {segment_id_2}.avro
        └── ...

スナップショットの作成には通常ミリ秒かかり、リストアにはデータ量に応じて数秒から数分かかります。

ストレージへの影響と考慮点

Milvusはスナップショット内のセグメントファイルまたはインデックスファイルを参照すると、スナップショットを削除しない限り、それらのファイルをガベージコレクションすることはありません。スナップショットはターゲットコレクションのサイズに比例してストレージを消費し、オブジェクトストレージのコストはスナップショットの保持に適用されます。極端な場合、スナップショット1つでオブジェクト・ストレージ・コストが2倍になることさえあります。以下のことをお勧めします。

• ストレージを節約するために、古いスナップショットを定期的に削除する。
• 将来の参照のために、わかりやすい名前と説明を使用する。
• スナップショットの作成と復元結果を常に検証する。
• モニタリングとトラブルシューティングのために、スナップショット作成のタイムスタンプ、ストレージ使用量、リストアジョブIDを追跡する。

制限と制約

• スナップショットは作成後、不変になります。
• スナップショットは、オリジナルと同じクラスタ内の新しいコレクションにのみリストアできます。
• リストアされたコレクションは、同じスキーマ、シャード数、パーティション数を保持します。
• リストアされた履歴データはTTLポリシーと競合する可能性があります。スナップショットを作成する前に、TTLを無効にするか、TTL設定を調整することをお勧めします。

その他の情報

• スナップショットの管理- スナップショットの作成、リストア、リストア、および削除。
• スナップショットの使用例- 一般的なパターンとワークフロー。
• Milvus Backup- クラスタ間での長期バックアップとリストア。