リリースノート（2025年7月15日）
このリリースでは、Zilliz Cloudが運用効率、柔軟性、およびユーザーエクスペリエンスの向上を目的とした複数の強力な機能強化を導入します。これらには、クラスターレベルのスケジュールされたオートスケーリングのサポート、新しいMerge データ APIによるスキーマ進化、データ取り込みを効率化するクラウドネイティブなデータレイヤーであるステージの導入、クロスデータベース選択を伴うクラスターレベルのバックアップからの部分リストア、およびJSONパスインデックスのUIサポートが含まれます。これらの機能により、ユーザーは複雑なワークロードをより効果的に管理し、メンテナンスのオーバーヘッドを削減し、GenAI時代の開発サイクルを短縮できます。
Milvus互換性
このリリース以降に作成されたすべてのZilliz Cloudクラスターは Milvus v2.5.x と互換性があり、Milvus v2.5.xのすべての機能は 一般提供 となります。
機能の利用可能性の詳細については、現在の機能利用可能性 を参照してください。
Merge データ APIによるスキーマ進化Private Preview
GenAI時代において、ビジネスロジックの迅速なイテレーションにより、これまで以上に頻繁なスキーマ変更が求められる一方、それらは依然としてコストがかかり、運用上複雑です。スキーマの更新は、多くの場合、コレクションの再構築を意味します：データのエクスポート、新しいフィールドのマージ、そしてすべてを最初から再インポートします。この手動プロセスは時間がかかり、エラーが発生しやすく、しばしば長期間の書き込みダウンタイムを必要とします。
この課題に対処するため、Zillizは自動化されたスキーマ進化のための新しい バッチETL機能 を導入します。このリリースの一環として、ETLサービスに新しい Merge データ RESTful API が追加され、単一のAPI呼び出しで大規模なスキーマ更新を実行できるようになりました。このAPIにより、既存のコレクション（Base）と外部ファイル（プライマリキーと新しいフィールドを含む）をマージして、更新されたスキーマを持つ新しいコレクション（Target）を生成できます。検証後、ユーザーはエイリアスを更新するだけで、最小限の中断で切り替えることができます。
裏側では、Merge データ APIは分散バッチ処理エンジンとステージ、Backup、Join、Importを単一の操作にオーケストレーションします。ユーザーは各ステップを手動で調整する必要がなくなりました。データ検証からインポートまでのプロセス全体が自動的に処理されます。これにより運用負担が大幅に軽減され、スキーマ更新が 日単位ではなく時間単位 で完了できるようになります。
マージプロセス中は、データ整合性を確保するため、ベースコレクションへの書き込みを停止する必要があります。
この機能は現在 プライベートプレビュー です。アカウントで有効化するには、サポートにお問い合わせ ください。関連するRESTful APIリファレンスページについては、Merge データ を参照してください。
ステージの紹介：Zilliz CloudのデータレイヤーPrivate Preview
ステージ、まったく新しい機能であり、Zilliz Cloudの基盤となる データレイヤー を紹介できることを嬉しく思います。
ステージは、非構造化データのための管理されたクラウドネイティブなステージング領域を提供します。これは、ベクトルクラスターへの移行とインポートのためのデータのアップロード、キャッシュ、準備を含むスケーラブルなデータ移動をサポートするために目的特化されており、Zillizサービス全体のETLワークフローの統一レイヤーとして機能します。
この初期リリース（プライベートプレビュー）では、ユーザーは以下のことができます：
-
データオンボーディングを効率化するため、Migration および Import サービスの両方で ステージを共有ステージングレイヤーとして使用 する：
-
Migration: ローカルのMilvus環境からZilliz Cloudへのデータ移行を、単一のステップでシームレスに実行します。以前は、ユーザーは手動でバックアップを作成し、ファイルをS3にアップロードし、インポートジョブを個別にトリガーする必要がありました。ステージを使用すると、プロセスが統一され、高速化され、エラーが大幅に減少します。詳細については、ステージを介したMilvusからZilliz Cloudへの移行 を参照してください。
-
Import: インポートジョブがステージをステージングバックエンドとして受け入れるようになり、オブジェクトストレージへの依存を減らし、トークンの期限切れを回避し、直接のクラウドストレージアクセスを持たないユーザーが簡単にZilliz Cloudにデータを移動できるようになります。詳細については、インポートジョブの作成 を参照し、リクエストボディ で Use ステージ を選択してください。
-
ステージはまもなくBackup、Import、ETLサービスなどの追加サービスと統合され、Zilliz Cloud内での非構造化データ処理、データ共有、およびパイプライン駆動のワークロードへのサポートを拡張します。
この機能は現在 プライベートプレビュー です。アカウントで有効化するには、サポートにお問い合わせ ください。
スケジュールされたクラスタースケーリングが利用可能に
Zilliz Cloudは、クラスターレベル での スケジュールされたスケーリング をサポートするようになり、予測可能なワークロードパターンに基づいてリソース配分を能動的に制御できます。
-
CUおよびレプリカのスケジュールベースのオートスケーリング: 特定のスケジュールを定義して、CUおよびレプリカを自動的にスケールできるようになりました。ビジネス時間帯のピークトラフィックに対応するためにリソースをスケールアップし、夜間や週末などの静かな時間帯にスケールダウンして、手動の介入なしにコストを最適化できます。
-
可視性と制御の向上: このアップデートにより、スケーリングスケジュールの視覚的表現を導入することで、オートスケーリング設定への透明性が向上します。
-
能動的な監査: リソース提供とコストに安心感を与える、透明なメール通知システムと監査証跡を提供します。
詳細については、クラスターのオートスケーリング を参照してください。
クロスデータベース選択を伴うクラスターレベルのバックアップからの部分リストア
クラスターレベルのバックアップ から、複数のデータベースにまたがるコレクションを含む、特定の データベース および コレクション を選択的にリストアできるようになりました。この機能強化により、復旧時間が短縮され、クラスター全体を復旧する必要なく、どのデータをリストアするかを細かく制御できます。
詳細については、クラスターの部分リストア を参照してください。
Zilliz CloudコンソールでのJSONパスインデックスの作成
Zilliz Cloudは、Webコンソールから直接JSONパスインデックスを作成することをサポートするようになり、半構造化データへのクエリを加速しやすくなりました。この機能は、JSONフィールドとダイナミックフィールドの両方をサポートし、柔軟で高性能なフィルタリングを実現します。
JSONパスインデックスの詳細については、JSONフィールド内の値のインデックス作成 および ダイナミックフィールド内のキーのインデックス作成 を参照してください。
BYOCプロジェクトのインスタンスクォータ設定が利用可能に
Zilliz Cloudは、BYOCプロジェクトのカスタムインスタンスクォータ設定をサポートするようになりました。 このアップデートにより、サービスの明確なリソース境界を定義することでコストを最適化できる、より大きな柔軟性が提供されます。
-
プロジェクトリソースのオートスケーリング制御: 弾力モードと固定リソースモードを簡単に切り替えられるようになりました。最小および最大インスタンス数を設定して弾力性を有効にするか、サービスグループのリソースを固定サイズにロックできます。
-
動的な設定: コンソールのプロジェクトステータスページから、ノードグループのリソースとクォータを直接表示および調整できるようになり、実行中のプロジェクトのリソース配分を簡単に変更できます。
-
独立したインデックスサービスクォータ: Zilliz Cloudでは、インデックスノードグループのリソースクォータを独立して設定できるようになり、異なるワークロードパターンに対してパフォーマンスとリソース配分を微調整できます。
詳細については、AWSへのBYOCのデプロイ、AWSへのBYOC-Iのデプロイ、および GCPへのBYOCのデプロイ を参照してください。
その他の機能強化
-
クラスターレベルのバックアップリストアを実行する際に、RBAC設定をリストアするかどうかを選択できます。
📘Notesこの設定は、新しく作成されたバックアップにのみ適用されます。
-
プライベートプレビュー および パブリックプレビュー の機能を使用する前に、それらについて確認できます。これらの機能を使用するには、Zilliz Cloud サポート にお問い合わせください。
-
インポートリクエストあたりの合計ファイルサイズが100 GBから1 TBに増加しました。
-
手動でバックアップを作成する場合の保持期間は、組織が凍結状態になった後、永続的なままではなく30日に変更され、ストレージコストの節約に役立ちます。