ストレージ V3Compatible with Milvus 3.0.x
概要
AIデータセットは、コレクションが作成された後も変化し続けることがよくあります。モデルやワークフローの変更に伴い、チームはテキストを追加したり、既存のエンティティに対して新しいベクトルフィールドを生成したり、Milvusの外部に保存されたデータを利用したりする必要が生じる場合があります。こうしたワークフローに対応するには、データセットの変化に合わせて進化できるストレージモデルが必要です。
Storage V3は、Milvus 3.0においてこのモデルを提供します。バージョン管理されたストレージレイアウトを採用し、時間の経過とともに追加または書き換えられたデータを組み込みつつ、アプリケーションは引き続き同じMilvus APIを通じてコレクションにアクセスできます。
Storage V3はデフォルトで無効になっています。common.storage.useLoonFFI が有効になると、新規の書き込みおよびコンパクション出力にはStorage V3が使用されます。既存のデータは、対象となるデータがバックグラウンドでのコンパクションによって書き換えられるまで、現在のレイアウトのまま保持されます。この移行期間中、Milvusは両方のレイアウトからデータを読み取ることができます。Storage V3は、一般的なパフォーマンス最適化のためではなく、Storage V3に依存する機能を利用するために有効にしてください。
Storage V3 のデータ形式
Storage V3では、基盤となるデータ形式とは独立してコレクションデータを記述するためにマニフェストを使用します。これにより、Milvusによって管理されるデータと、外部システムに残っているデータの両方を、同じストレージ層で処理できるようになります。
管理対象コレクションのファイル形式
管理対象コレクションの場合、dataNode.storage.format が新しいStorage V3データのファイル形式を選択します。この設定では、以下の値がサポートされています：
| 形式 | 説明 |
|---|---|
parquet | デフォルトの、広く採用されているカラム型ファイル形式であり、幅広いエコシステムとの互換性と成熟したツールセットを備えています。Parquetはデータを行グループに整理し、列ごとのエンコーディングと圧縮をサポートしているため、Milvusは必要な列のみを読み取り、大規模なシーケンシャルスキャンを効率的に処理できます。 |
vortex | 拡張可能で組み合わせ可能なエンコーディングと豊富な統計情報を基盤とした、オプションの次世代カラム型ファイル形式です。Milvusにおいて、Vortexはカラム投影、範囲読み取り、およびランダムアクセス読み取りをサポートします。これらの機能により、適切なワークロードにおいて不要なデータ読み取りを削減できます。 |
dataNode.storage.format を変更すると、Storage V3への新規書き込みに影響します。既存のファイルは、コンパクションによって対応するセグメントが書き換えられるまで、現在の形式を維持します。代表的なベンチマークにより、vortex がデータやアクセスパターンにより適していることが示されない限り、ほとんどの導入環境ではデフォルトのparquet 形式を維持すべきです。
外部コレクションとサポートされるソース形式
外部コレクションを使用することで、Milvusは外部ファイルやテーブルに保存されたデータを利用できます。Storage V3は、以下の外部ソース形式をサポートしています：
| 形式 | カテゴリ | 想定されるソース | Storage V3での対応状況 |
|---|---|---|---|
parquet | ファイル形式 | Parquet ファイルを含むディレクトリまたはオブジェクトストレージのプレフィックス。 | ファイルを検出し、そのメタデータと行グループを読み取り、Storage V3 マニフェストに記録します。 |
vortex | ファイル形式 | Vortex ファイルを含むディレクトリまたはオブジェクトストレージのプレフィックス。 | ファイルを検出し、Vortex のレイアウトと統計情報を使用して、プロジェクション、範囲読み取り、およびランダムアクセス読み取りを行います。 |
lance-table | テーブル形式 | Lance データセットディレクトリ。 | データセットのメタデータを読み取り、そのフラグメントを Storage V3 マニフェストにマッピングします。 |
iceberg-table | テーブル形式Iceberg メタデータ JSON ファイルおよびスナップショット ID。 | Iceberg メタデータ JSON ファイルおよびスナップショット ID。 | 指定されたスナップショットを解決し、そのデータファイルを計画し、位置削除メタデータを保持します。等価削除はサポートされておらず、外部コレクションを更新する前に位置削除に変換する必要があります。 |
外部ソースは読み取り専用です。Storage V3 は、ソースデータを変更またはコピーすることなく、独自のマニフェストを作成および更新します。その後、Milvus はインデックスを構築し、外部コレクションを通じてデータに対する検索やクエリを実行できます。
クラウドストレージとアカウント間認証
以下の表は、外部コレクションが別のクラウドアカウントに保存されたソースデータにアクセスする方法についてのみ説明しています。Milvusが管理するデータに使用されるオブジェクトストレージについては説明していません。
| クラウドストレージ | サポートされる外部フォーマット | 外部コレクションのアカウント間認証 |
|---|---|---|
| Amazon S3 | 上記の4つの形式すべて。 | お客様が所有する IAM ロールの ARN を指定してください。Storage V3 は、AWS STS（AssumeRole ）を使用して一時的な認証情報を取得し、必要に応じて更新します。また、ロールの信頼ポリシーで要求される場合は、外部 ID を指定することもできます。 |
| Google Cloud Storage (GCS) | 上記の 4 つの形式すべて。 | 対象のサービスアカウントを指定してください。Storage V3 はそのサービスアカウントになりすまし、その短命な OAuth アクセストークンを使用してソースバケットにアクセスし、トークンが期限切れになる前に更新します。 |
| Azure Blob Storage | parquet、vortex 、およびlance-table 。iceberg-table はサポートされていません。 | Milvusは、milvus-tools のプライベートgRPCサービスを通じて、短期間有効なSAS認証情報を要求します。Storage V3は、このSAS認証情報を使用してソースコンテナにアクセスし、有効期限が切れる前に認証情報を更新します。 |
| Azure Data Lake Storage Gen2 (ADLS Gen2) | 上記の4つの形式すべて。 | Milvus は、milvus-tools プライベート gRPC サービスを介して、有効期間が短い SAS 認証情報を要求します。Storage V3 は、この SAS 認証情報を使用してソース コンテナにアクセスし、認証情報は有効期限が切れる前に更新されます。 |
| Alibaba Cloud Object Storage Service (OSS) | 上記の 4 つの形式すべて。 | お客様が所有する RAM ロールの ARN を指定してください。Storage V3 は、ランタイムのワークロード ID または ECS RAM ロールを使用してそのロールを引き継ぎ、一時的な認証情報を使用してソース バケットにアクセスします。 |
外部コレクションの設定および使用方法については、「外部コレクションの作成」を参照してください。
Storage V3 が必要な機能
| 機能 | 説明 | 必要な構成 |
|---|---|---|
| Vortex ファイル形式 | Vortex ファイル形式で新しい管理対象コレクションのデータを書き込みます。 |
|
TEXT field | パッセージ、ドキュメント、チケット、ログなどの長いソーステキストを、コレクションスキーマに固定の最大長を設定することなく保存します。 | common.storage.useLoonFFI=true |
| 関数生成ベクトルフィールド | 既存のコレクションに BM25 または MinHash 関数を追加することで、Milvus が既存のVARCHAR フィールドから新しいベクトルフィールドを生成します。Milvus は、バックグラウンドでのコンパクションを通じて、既存エンティティに対して生成された値を非同期でバックフィルします。 | |
| 外部コレクション | Milvusの外部に保存されているデータを、管理対象コレクションにコピーすることなくクエリできます。ソースデータが変更された場合は、外部コレクションを更新してください。追加のソースフィールドを公開するには、「外部コレクションスキーマの変更」を参照してください。 | common.storage.useLoonFFI=true |
Storage V3 を有効にする前に
MilvusがStorage V3にデータを書き込んだ後、Storage V3を読み取れないMilvusのバージョンへのダウングレードはサポートされていません。後でStorage V3を無効にしても、既存のすべてのStorage V3データが即座に変換されたり、旧バージョンとの互換性が復元されたりすることはありません。
Storage V3 を有効にする前に、以下のデータの挙動についてご確認ください。
dataCoord.compaction.storageVersion.enabledはデフォルトで有効になっているため、対象となる既存のデータはバックグラウンドでのコンパクションを通じて段階的にStorage V3へ移行されます。- Storage V3を無効にすると、今後の書き込みおよび対象となるコンパクション出力に対するターゲットストレージバージョンが変更されます。これにより、既存のすべてのStorage V3データが同期的に変換されるわけではなく、バージョンのダウングレードが安全に行えるようになるわけでもありません。
Storage V3を有効にする
Milvusの設定で、common.storage.useLoonFFI をtrue に設定します：
common:
storage:
useLoonFFI: true
Milvus はこの設定をリフレッシュ可能として扱います。デプロイメントでサポートされている configuration-update ワークフローを通じて変更を適用してください。静的な設定ファイルを編集するだけでは、実行中のデプロイメントが新しい値を受け取ったことが保証されません。
既存のコレクションにFunctionとその生成されたベクトルフィールドを追加する予定の場合は、既存データのバックフィルに必要な2つのコンパクション設定も有効にしてください:
dataCoord:
compaction:
bumpSchemaVersion:
enabled: true
storageVersion:
enabled: true
既存エンティティに対する関数の出力は、バックグラウンドでのコンパクションを通じて非同期に生成されます。スキーマの更新が成功したからといって、すべての既存エンティティに対するバックフィルが完了したとは限りません。
