リリースノート
Milvusの新機能をご覧ください！このページでは、各リリースにおける新機能、改善点、既知の問題、およびバグ修正についてまとめています。更新情報を確認するため、定期的にこのページをご覧になることをお勧めします。
v3.0-beta
リリース日：2026年5月9日
| Milvus バージョン | Python SDK バージョン | Node.js SDK バージョン |
|---|---|---|
| 3.0-beta | 3.0.0 | 3.0.0 |
Milvus 3.0-beta は、オープンレイクエコシステムへの新たな統合により Milvus ベクトルデータベースを拡張します。External Collection により、Milvus は外部レイクテーブルをゼロコピーでクエリでき、Spark は Snapshot を通じて Milvus コレクションを直接読み取ることができます。 また、このリリースでは、より豊富な検索機能、より表現力豊かなスキーマ、より詳細なテキスト検索のカスタマイズ、よりきめ細かなデータおよびモデルのライフサイクル制御、さらにオペレーター側の制御機能も強化されています。Milvus 3.0 は Zilliz Lakebase のコアカーネルであり、その統合されたサービング、ディスカバリー、バッチ処理を支えています。
Milvus 3.0の詳細や、コアメンテナーとのAMAについては、以下の動画をご覧ください：
主な機能
外部コレクション
一般的なAIデータパイプラインでは、テラバイト規模の埋め込みデータやメタデータが、Parquet、Lance、またはIcebergテーブルとしてすでにオブジェクトストレージ上に存在しています。そのデータをMilvusにコピーすると、ストレージコストが倍増し、同期を維持しなければならないETLパイプラインが追加され、データガバナンスが顧客から遠ざかってしまいます。
外部コレクション機能により、このコピー作業が不要になります。Milvusコレクションは、データが既に存在する場所にあるファイルを参照でき、Milvusはスキーマ、インデックス、およびクエリの実行のみを管理します。 増分更新により、コレクションは基となるファイルと常に同期されます。金融や医療チームなど、データをレイクから持ち出せないお客様は、データが格納されている場所のままベクトル検索を実行できます。また、レイク上に存在する単一のデータセットを、複数のMilvusインスタンスから同時に提供することも可能です。
詳細については、「外部コレクションの作成」を参照してください。
スナップショット
サービングとバッチディスカバリーでは、多くの場合、同じコレクションを同時に必要とします。A/Bモデル評価、大規模な重複排除、バックフィル検証、およびバージョンロールバックはすべて、書き込みが継続している間もコレクションの安定したビューを必要とします。
スナップショットは、データをコピーするのではなく既存のセグメントを参照することで、コレクションの特定の時点における読み取り専用ビューを作成するため、追加のストレージコストはほぼゼロです。ライブのコレクションが書き込みを受け入れ続けている間も、バッチジョブはMVCCスタイルの分離環境下でスナップショットから読み取ることができます。
詳細については、「スナップショット」、「スナップショットの管理」、「スナップショットのユースケース」を参照してください。
クエリ / 検索の Order By
検索およびクエリでは、マルチフィールドの順序付けが可能になり、ソート処理はMilvusカーネルにオフロードされ、フィールドごとにASC およびDESC を設定できるようになりました。これにより、一般的な運用上の課題が解決されます。距離だけでTop-Kを決定する場合、最も類似したアイテムが最も安価、最新、または人気のあるものではない場合、ビジネスニーズに合致しないことがよくあります。
これにより、アプリケーションは複合ランキングを表現するために、結果を過剰に取得してクライアント側で再ソートする必要がなくなりました。
詳細については、「スカラーフィールドによる検索結果のソート」および「クエリ結果のソート」を参照してください。
クエリの集計
Milvus コレクションからテナント分布統計、フィールドの完全性カウント、またはバージョンロールアウトの進捗状況を生成するには、以前は一致するエンティティをクライアントに引き戻し、そこで集計する必要がありました。 Milvus 3.0 では、SQL スタイルのスカラー集計がカーネルに組み込まれています。クエリ呼び出しでは、group_by_fields およびoutput_fields 形式の集計式を受け付けます。これには、count(*) 、count(<field>) 、sum(<field>) 、avg(<field>) 、min(<field>) 、max(<field>) が含まれます。集計は、フィルタリング後にサーバー側で評価されます。
詳細については、「クエリ結果の集計」を参照してください。
Nullベクトル
エンベディングは非同期で生成されることが多いため、エンティティがベクトルよりも先に到着することがあります。 マルチモーダルデータにも、キャプションのない動画や画像のない製品など、自然なギャップが存在します。以前のバージョンには適切な解決策がなく、アプリケーションはベクトルの準備ができるまで書き込みを遅らせるか、プレースホルダーベクトルを埋めるかのいずれかを選択していましたが、どちらの選択肢も検索品質を低下させていました。
Milvus 3.0 は、6 種類のベクトル型すべてにおいて、ベクトルフィールドでの NULL をサポートしています。検索では NULL ベクトルが自動的にスキップされるため、検索品質に影響はなく、NULL ベクトルは実質的にストレージを消費しません。この変更に伴い、AddField もベクトルフィールドに拡張されました。nullable=True を使用すると、既存のコレクションを再構築することなく、オンラインで新しいベクトルフィールドを追加できます。
詳細については、「Nullable Fields」を参照してください。
カスタム辞書とシノニム辞書
標準のトークナイザーでは、本番環境の検索品質要件を常に満たせるわけではありません。中国語、医学、法律、化学などの専門分野、および多言語コーパスでは、カスタム辞書や同義語テーブルを活用することで大幅な改善が期待できます。これまで、これらのリソースは主にアプリケーション側でのクエリ書き換えとして実装されていました。
Milvus 3.0 では、カスタム トークナイザー辞書、同義語リスト、ストップワードリスト、および複合語分解ルールを登録するための FileResource メカニズムが追加されました。 一度登録されたリソースは、どのトークナイザーやフィルターからも参照可能となり、BM25、アナライザー、およびテキストマッチに適用されます。辞書や同義語は、アプリケーションコード全体に散在させるのではなく、バージョン管理を行い一元的に管理できるようになりました。
詳細については、「ファイルリソースの管理」を参照してください。
エンティティの TTL
コレクションレベルおよびパーティションレベルの TTL は、多くのライフサイクルおよびコンプライアンスのシナリオでは粗すぎます。同じコレクション内のテナントによって保存ルールが異なることが多く、個々のエンティティは、コレクションの他の部分とは異なるスケジュールで有効期限が切れる必要がある場合があります。
Milvus 3.0では、エンティティごとのTTLがサポートされています。スキーマ内でTIMESTAMPTZ フィールドを宣言し、コレクションのプロパティを通じてそれをTTLフィールドとして指定することで、Milvusは期限切れのエンティティを自動的に回収します。これにより、忘れられる権利（Right to be forgotten）に基づくリクエストへの対応、セッションデータの期限切れ処理、およびアプリケーション側でのクリーンアップを必要としない限定的な会話履歴の管理が可能になります。
詳細については、「エンティティレベルのTTLの設定」を参照してください。
MinHash DIDO (Doc-in, Doc-out)
Milvus 2.6では、セットベースのニアダブリ検出のためのMINHASH_LSH インデックスが追加されましたが、アプリケーションは依然として、データをMilvusに書き込む前にMinHash署名を計算する必要がありました。
Milvus 3.0 では、サーバーサイドの MinHash 関数が追加されました。スキーマでVARCHAR 入力フィールドとBINARY_VECTOR 出力フィールドを宣言し、FunctionType.MINHASH 関数をアタッチすると、Milvus は挿入、一括挿入、および検索中にシグネチャを計算します。MINHASH_LSH と組み合わせることで、Milvus 内での大規模データセットの重複排除ワークフロー、フィンガープリント、および盗用検出をサポートします。
詳細については、MinHash関数を参照してください。
EmbList + DISKANN
「1つのエンティティ＝1つのベクトル」という前提は、現代の検索にはもはや適合しません。長い文書は多くのチャンクに分割され、ColBERTのようなレイトインタラクションモデルはトークンごとに1つのベクトルを生成し、マルチモーダルエンティティは複数のビューを持つことがあります。
EmbListはエンティティごとに可変長ベクトルリストを格納し、DISKANN をディスク上のインデックスとして使用します。コーパスがメモリ予算を超過した場合でも、このディスクパスによりRAM使用量を抑えることができます。EmbList +DISKANN は、このRCにおける広範なStructListファミリーの最初のバリエーションです。 StructListのフィルタリングやMuvera / Lemurによるマルチベクトル高速化を含む、このファミリーの残りの機能は、公式の3.0リリースでの提供を予定しています。
詳細については、「Search with Embedding Lists」を参照してください。
強制マージ
本番環境のワークロードでは、時間の経過とともにセグメントの断片化が蓄積され、クエリのレイテンシの変動やストレージの肥大化を引き起こします。
Milvus 3.0 では、ピーク時以外の時間帯に、同期モードおよび非同期モードの両方で、セグメントのコンパクションを明示的にトリガーする機能が追加されました。
詳細については、「Force Merge コンパクション」を参照してください。
Storage V3
Milvus 3.0 では、データとメタデータが S3 互換のオブジェクトストレージ上に格納される、マニフェストベースのカラム型ストレージエンジンである Storage V3 が導入されました。各データセットのバージョンは、不変のマニフェストスナップショットとしてキャプチャされます。これは、どのカラムグループ、デルタログ、および統計情報がデータセットを構成しているかを記録した Avro エンコードのファイルです。
マニフェストはコンパクトなAvroファイルであり、デルタログはデータファイルを書き換えることなくエンティティレベルの削除を記録します。これにより、データセットが拡大してもメタデータのオーバーヘッドを小さく抑えることができます。また、マニフェストはメタデータの追跡をクエリパスから切り離すため、コレクションはクエリのパフォーマンスを低下させることなく、より多くのセグメントを管理できるようになります。
状態はオブジェクトストレージに保存されるため、データセットは自己記述的です。つまり、ストレージパスへのアクセス権を持つ任意のリーダーは、中央カタログを介さずにデータセットを発見し、解釈することができます。この特性は、External Collection、Snapshot、および将来のレイク統合の基盤となっています。