跳到主要内容
版本：v3.0.x

Snapshots

Snapshot（快照）是 Milvus Collection 的时间点镜像，是快速回滚、版本控制和测试的理想选择。它捕捉 Collection 在特定 Timestamp 的状态，只存储元数据与 manifest 文件，例如 Schema、Index 和向量数据文件（Binlog），以便高效存储和恢复。

Snapshot 是快速的时间点数据镜像，适用于快速回滚或测试（几天到几周）。同时，备份是单独存储的独立、完整副本，可用于长期灾难恢复（数周至数年），并能更好地防止整体存储故障。

要创建备份，请参阅 Milvus 备份。

Snapshot 架构​

Milvus 采用基于 manifest 的 Snapshot 架构，可在不复制实际向量数据的情况下实现高效的时间点数据捕获、存储和恢复。该架构将元数据管理与物理数据存储分离开来，实现了引用对象存储中现有 Segment 文件的轻量级 Snapshot。

为 Collection 创建 Snapshot 时，Milvus 会收集以下内容：

  • Snapshot 元数据

提供创建 Snapshot 的基本信息，包括快照名称和描述、目标 Collection ID 以及创建 Snapshot 的时间点。

  • Collection 描述

它包含目标 Collection 的描述，包括其 Schema 定义、Partition 信息和属性。

  • 索引信息

存储索引元数据和索引文件路径。

  • Segment 数据

它捕获了向量数据文件（binlogs）、删除日志（deltalogs）和索引文件。

在上述信息中，Milvus 会为每个 Segment 生成 Apache Avro manifest 文件，并在 JSON 文件中存储快照元数据、Collection 说明、索引信息和清单文件的路径。下图展示 Snapshot 的对象存储目录结构。

Text
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
        └── ...

创建 Snapshot 通常只需几毫秒，恢复 Snapshot 则需要几秒到几分钟，具体取决于数据量。

存储影响和注意事项​

只要 Snapshot 仍引用某个 Segment 或索引文件，Milvus 就不会对该文件执行垃圾回收。快照消耗的存储空间与目标 Collection 的大小成正比，保留 Snapshot 会持续占用对象存储空间，并产生相应的对象存储成本。在极端情况下，单个快照甚至会使对象存储成本翻倍。建议您

  • 定期删除旧快照，以节省存储空间。
  • 使用描述性的名称和说明，以备将来参考。
  • 始终验证快照创建和恢复结果。
  • 跟踪快照创建时间戳和存储使用情况，以便进行监控和故障排除。
  • 存储恢复任务 ID，以便进行监控和故障排除。

限制和约束​

  • Snapshot 在创建后不可更改。
  • 你只能将 Snapshot 恢复到与原始 Collection 在同一集群中的新 Collection。
  • 恢复后的 Collection 保留原有 Schema、Shard 数和 Partition 数。
  • 恢复的历史数据可能与 TTL 策略冲突。建议在创建 Snapshot 前禁用 TTL 或调整 TTL 设置。
  • 要将 Snapshot 作为 milvus-table 外部源使用，源 Snapshot 必须来自普通的 StorageV3 Milvus Collection。不支持将外部 Collection 的 Snapshot 作为 milvus-table 源。

更多信息​