リリースノート
Milvusの新機能をご確認ください！このページでは、各リリースの新機能、改善点、既知の問題、バグ修正についてまとめています。定期的にこのページをご覧いただき、アップデート情報をご確認ください。
v3.0ベータ版
リリース日: 2026年5月9日
| Milvusバージョン | Python SDKバージョン | Node.js SDKバージョン |
|---|---|---|
| 3.0ベータ | 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にコピーすると、ストレージコストが2倍になり、同期を維持しなければならないETLパイプラインが追加され、データガバナンスが顧客から遠ざかります。
外部コレクションはコピーを削除します。Milvusコレクションは、既に存在するファイルを参照することができ、Milvusはスキーマ、インデックス、クエリ実行のみを管理します。インクリメンタルリフレッシュにより、Collectionは基礎となるファイルと整合性を保ちます。財務やヘルスケアチームなど、データがレイクを離れることができない顧客は、そのデータに対してベクトル検索を実行することができます。1つのレイク常駐データセットを複数のMilvusインスタンスから同時に提供することも可能です。
詳細については、外部コレクションの作成を参照してください。
スナップショット
サービングとバッチディスカバリは同時に同じコレクションを必要とすることがよくあります。A/Bモデル評価、大規模重複排除、バックフィル検証、およびバージョンロールバックはすべて、書き込みが行われている間、コレクションの安定したビューを必要とします。
スナップショットは、データをコピーする代わりに既存のセグメントを参照することで、コレクションのポイントインタイムの読み取り専用ビューを作成します。バッチジョブは、MVCCスタイルの分離の下でスナップショットから読み取ることができますが、ライブのCollectionは書き込みを受け付け続けます。
詳細については、スナップショット、スナップショットの管理、およびスナップショットの使用例を参照してください。
クエリ/検索 Order By
Milvusカーネルにソートがプッシュダウンされ、ASC /DESC 、フィールド毎に設定可能です。これは一般的な生産ギャップを埋めるものです：最も類似したアイテムが最も安く、最も新しく、最も人気があるわけではない場合、距離によるトップKだけではビジネスニーズにマッチしないことがよくあります。
アプリケーションは、複合ランキングを表現するために、結果をオーバーフェッチしたり、クライアント上で再ソートしたりする必要がなくなります。
詳細については、スカラー・フィールドによる検索結果の並べ替えおよび クエリ結果の並べ替えを参照してください。
クエリー集計
Milvusコレクションからテナント分布の統計、フィールドの完全性カウント、またはバージョン展開の進捗を生成するには、一致するエンティティをクライアントにプルバックし、そこで集計する必要がありました。Milvus 3.0はSQLスタイルのスカラー集約をカーネルにプッシュします。クエリコールはgroup_by_fields 、count(*) 、count(<field>) 、sum(<field>) 、avg(<field>) 、min(<field>) 、max(<field>) を含むoutput_fields の集約式を受け付けます。集約は、フィルタリング後にサーバーサイドで評価される。
詳細については、「クエリ結果の集約」を参照してください。
Nullベクトル
エンベッディングは多くの場合非同期に生成されるため、エンティティのベクトルが先に到着することがあります。マルチモーダルなデータには、キャプションのないビデオや画像のない製品など、自然なギャップもあります。以前のバージョンでは、ベクターの準備ができるまで書き込みを遅らせるか、プレースホルダーベクターで埋めるかのどちらかしかありませんでした。
Milvus3.0は6つのベクトルタイプすべてにおいてベクトルフィールドのNULLをサポートしています。検索はNULLベクターを自動的にスキップし、検索品質は影響を受けず、NULLベクターは実質的にストレージを必要としません。AddField 、この変更によりベクターフィールドも拡張されました。nullable=True 、既存のコレクションは再構築することなく、新しいベクターフィールドをオンラインで成長させることができます。
詳しくはNullable Fields を参照してください。
カスタム辞書と同義語辞書
既製のトークナイザーは、必ずしも本番の検索品質要件を満たしているとは限りません。中国語、医学、法律、化学のような垂直ドメイン、多言語コーパスは、カスタム辞書と同義語テーブルから大きな恩恵を受けることができます。これまでは、これらのリソースはアプリケーション側のクエリ書き換えとして使用されることがほとんどでした。
Milvus 3.0では、カスタムトークナイザ辞書、同義語リスト、ストップワードリスト、デコンパウンダルールを登録するためのFileResourceメカニズムが追加されました。一度登録されたリソースは、どのトークナイザーやフィルターからも参照することができ、BM25、アナライザー、Text Matchに反映されます。辞書と類義語は、アプリケーション・コードに散らばっていたものを、一元的にバージョン管理・管理できるようになりました。
詳細については、「ファイル・リソースの管理」を参照してください。
エンティティTTL
コレクションレベルおよびパーティションレベルのTTLは、多くのライフサイクルおよびコンプライアンスシナリオでは粗すぎます。同じCollection内の異なるテナントには異なる保持ルールがあることが多く、個々のエンティティはCollectionの他の部分と一致しないスケジュールで期限切れにする必要がある場合があります。
Milvus 3.0はエンティティごとのTTLをサポートしています。スキーマでTIMESTAMPTZ フィールドを宣言し、コレクションプロパティでTTLフィールドとしてマークすると、Milvusは自動的に期限切れのエンティティを再生します。これにより、アプリケーション側でクリーンアップすることなく、right-to-be-forgottenリクエスト、期限切れセッションデータ、および制限付き会話履歴をカバーします。
詳細については、「エンティティレベルのTTLを設定する」を参照してください。
MinHash DIDO (Doc-in, Doc-out)
Milvus2.6では、MINHASH_LSH インデックスが追加され、セットベースの重複検出が可能になりましたが、アプリケーションはMilvusにデータを書き込む前にMinHashシグネチャを計算する必要がありました。
Milvus 3.0ではサーバサイドのMinHash関数が追加されました。スキーマにVARCHAR 入力フィールドとBINARY_VECTOR 出力フィールドを宣言し、FunctionType.MINHASH 関数をアタッチすると、Milvusは挿入、一括挿入、検索時に署名を計算します。MINHASH_LSH と共に、Milvus内部で大規模データセットの重複排除ワークフロー、フィンガープリンティング、剽窃検知をサポートします。
詳細はMinHash Functionを参照。
EmbList + DISKANN
1つのエンティティ＝1つのベクトル」という仮定は、もはや現代の検索には当てはまりません。長い文書は多くのチャンクに分割され、ColBERTのような後発のインタラクションモデルはトークンごとに1つのベクトルを生成し、マルチモーダルなエンティティは複数のビューを持つことができる。
EmbListは、DISKANN をディスク上のインデックスとして、エンティティごとに可変長のベクトルリストを格納する。ディスクパスは、コーパスがメモリバジェットを超えたときにRAMの使用量を抑制する。EmbList +DISKANN は、このRCではより広範なStructListファミリーの最初のバリエーションである。StructList フィルタリングと Muvera / Lemur マルチベクトルアクセラレーションを含む残りのファミリーは、正式な 3.0 リリースを目標にしています。
詳細については、埋め込みリストによる検索を参照してください。
強制マージ
実運用ワークロードでは、時間の経過とともにセグメントの断片化が蓄積され、クエリーレイテンシーのジッターやストレージの膨張を引き起こします。
Milvus 3.0では、同期モードと非同期モードの両方で、オフピーク時にセグメント圧縮を明示的にトリガーする機能が追加されました。
詳細はForce Merge Compactionを参照。
ストレージ V3
Milvus3.0では、データとメタデータがS3互換のオブジェクトストレージ上に存在する、マニフェストベースのカラム型ストレージエンジンであるStorage V3が導入されました。各データセットのバージョンは、データセットを構成するカラムグループ、デルタログ、および統計情報を記録するAvroエンコードされたファイルである、不変のマニフェストスナップショットとしてキャプチャされます。
マニフェストはコンパクトな Avro ファイルであり、デルタログはデータファイルを書き換えることなくエンティティレベルの削除を記録します。これにより、データセットが大きくなってもメタデータのオーバーヘッドを小さく保つことができます。マニフェストはまた、メタデータの追跡をクエリ・パスから切り離し、コレクションがクエリ・パフォーマンスを低下させることなく、より多くのセグメントを管理できるようにします。
ステートはオブジェクト・ストレージに格納されるため、データセットは自己記述的です。ストレージ・パスにアクセスできるリーダーであれば、中央カタログを使用せずにそれを発見し、解釈することができます。この特性は、External Collection、Snapshot、および将来のレイクの統合を支えるものです。