製品に関するFAQ

Milvusの価格はいくらですか？

Milvusは100%無償のオープンソースプロジェクトです。

Milvusを使用する際は、Apache License 2.0を遵守してください。

Milvusの開発元であるZilliz社では、分散インスタンスの構築や保守が不要なお客様向けに、完全マネージド型のクラウドプラットフォームも提供しております。Zilliz Cloudはデータの信頼性を自動的に維持し、ユーザーは使用した分だけ支払うことができる。

Milvusはx86以外のアーキテクチャに対応していますか？

Milvusはx86以外のプラットフォームにはインストール、実行できません。

Milvusを実行するには、CPUが以下の命令セットのいずれかをサポートしている必要があります: SSE4.2、AVX、AVX2、AVX512。これらはすべてx86専用のSIMD命令セットです。

Milvusはどこにデータを格納するのですか？

Milvusでは、挿入データとメタデータの2種類のデータを扱います。

ベクターデータ、スカラーデータ、コレクション固有のスキーマを含む挿入データは、インクリメンタルログとして永続ストレージに保存されます。Milvusは、MinIO、AWS S3、Google Cloud Storage(GCS)、Azure Blob Storage、Alibaba Cloud OSS、Tencent Cloud Object Storage(COS)など、複数のオブジェクトストレージバックエンドをサポートしています。

メタデータはMilvus内で生成されます。Milvusモジュールはそれぞれ独自のメタデータを持ち、etcdに保存されます。

なぜetcdにはベクターデータがないのか？

etcdにはMilvusモジュールのメタデータが格納され、MinIOにはエンティティが格納されます。

Milvusはデータの挿入と検索を同時にサポートしていますか？

挿入操作と検索操作は、互いに独立した2つのモジュールによって処理されます。クライアントから見ると、挿入されたデータがメッセージキューに入った時点で挿入操作は完了します。しかし、挿入されたデータはクエリ・ノードにロードされるまで検索できません。セグメントサイズがインデックス構築のしきい値（デフォルトでは512MB）に達しない場合、Milvusはブルートフォース検索に頼り、クエリのパフォーマンスが低下する可能性があります。

主キーが重複しているベクターをMilvusに挿入できますか?

はい。Milvusはベクターの主キーが重複しているかどうかをチェックしません。

主キーが重複しているベクターが挿入された場合、Milvusはそれを更新操作として扱いますか?

いいえ。Milvusは現在更新操作に対応しておらず、エンティティの主キーが重複しているかどうかのチェックも行っていません。エンティティの主キーが一意であることを確認するのはお客様の責任であり、そうでない場合、Milvusには主キーが重複した複数のエンティティが含まれる可能性があります。

このような場合、クエリ時にどのデータコピーが返されるかは未知のままです。この制限は将来のリリースで修正される予定です。

自分で定義したエンティティの主キーの最大長は?

エンティティ主キーは非負の64ビット整数でなければなりません。

1回の挿入操作で追加できるデータ量の上限は?

挿入操作のサイズは1,024 MBを超えてはなりません。これはgRPCによる制限です。

特定のパーティションで検索する場合、コレクション・サイズはクエリ・パフォーマンスに影響しますか?

いいえ。検索用のパーティションが指定されている場合、Milvusは指定されたパーティションのみを検索します。

検索にパーティションを指定した場合、Milvusはコレクション全体を読み込む必要がありますか?

検索に必要なデータによって異なります。検索結果に表示される可能性のあるパーティションは、検索前にすべて読み込む必要があります。

• たとえば、特定のパーティションだけを検索したい場合は、すべてをロードする必要はありません。load_partition() を呼び出して目的のパーティションをロードし、 search() メソッド呼び出しでパーティションを指定します。
• すべてのパーティションを検索したい場合は、load_collection() を呼び出して、すべてのパーティションを含むコレクション全体をロードします。
• 検索前にコレクションまたは特定のパーティションをロードしなかった場合、Milvusはエラーを返します。

ベクター挿入後にインデックスを作成することはできますか?

Milvusは、以前create_index() 、コレクションに対してインデックスを作成したことがある場合、その後に挿入されたベクターに対しても自動的にインデックスを作成します。ただし、Milvusは、新しく挿入されたベクターがセグメント全体を満たし、新しく作成されたインデックスファイルが以前のものから分離されるまで、インデックスを作成しません。

FLATインデックスとIVF_FLATインデックスの違いは何ですか？

IVF_FLATインデックスはベクター空間をリスト・クラスターに分割します。デフォルトのリスト値16,384の場合、Milvusはターゲットベクトルと16,384クラスタすべてのセントロイド間の距離を比較し、最も近いクラスタを返します。その後、Milvusはターゲットベクトルと選択されたクラスタ内のベクトルとの距離を比較し、最近接ベクトルを取得します。IVF_FLATとは異なり、FLATはターゲットベクトルと他のすべてのベクトルとの距離を直接比較します。

ベクトルの総数がnlistにほぼ等しい場合、IVF_FLATとFLATの間には計算要件と探索性能の点でほとんど差がありません。しかし、ベクトル数が nlist の 2 倍以上になると、IVF_FLAT の方が性能面で有利になります。

詳細はベクターインデックスを参照してください。

Milvusはどのようにデータをフラッシュするのですか？

挿入されたデータがメッセージキューに取り込まれると、Milvusは成功を返します。しかし、データはまだディスクにフラッシュされていません。その後、Milvusのデータノードがメッセージキュー内のデータをインクリメンタルログとして永続ストレージに書き込みます。flush() が呼び出された場合、データノードはメッセージキュー内の全データを直ちに永続ストレージに書き込むよう強制される。

正規化とは何ですか？なぜ正規化が必要なのですか？

正規化とは、ノルムが1になるようにベクトルを変換する処理のことです。ベクトルの類似度を計算するために内積を使用する場合、ベクトルは正規化されなければなりません。正規化後、内積は余弦類似度に等しくなります。

詳しくはウィキペディアを参照。

なぜユークリッド距離 (L2) と内積 (IP) は異なる結果を返すのですか？

正規化されたベクトルでは、ユークリッド距離 (L2) は内積 (IP) と数学的に等価です。これらの類似度メトリクスが異なる結果を返す場合、ベクトルが正規化されているかどうかを確認してください。

Milvusのコレクションとパーティションの総数に制限はありますか？

Milvusインスタンスでは65,535コレクションまで作成することができます。既存のコレクション数を計算する際、Milvusはシャードとパーティションを含むすべてのコレクションをカウントします。

例えば、既に100のコレクションを作成し、そのうち60に2シャードと4パーティション、残りの40に1シャードと12パーティションを作成したとします。現在のコレクション数は次のように計算できます：

60 * 2 * 4 + 40 * 1 * 12 = 960

topk ベクトルを検索すると、なぜk個以下のベクトルしか得られないのですか？

Milvusがサポートしているインデックスのうち、IVF_FLATとIVF_SQ8はk-meansクラスタリング法を実装しています。データ空間はnlist クラスタに分割され、挿入されたベクトルはこれらのクラスタに分配されます。そしてmilvusはnprobe 最も近いクラスタを選択し、ターゲットベクトルと選択されたクラスタ内のすべてのベクトルとの距離を比較して最終結果を返す。

nlist とtopk が大きく、nprobe が小さい場合、nprobe クラスタ内のベクトル数がk より少なくなることがあります。そのため、topk に最も近いベクトルを検索すると、返されるベクトル数がk より少なくなります。

これを避けるには、nprobe を大きく、nlist とk を小さく設定してみてください。

詳しくはベクトル・インデックスをご覧ください。

Milvusでサポートされている最大ベクトル次元は?

Milvusはデフォルトで32,768次元までのベクターを管理できます。Proxy.maxDimension の値を大きくすることで、より大きな次元のベクトルを扱うことができます。

MilvusはApple M1 CPUをサポートしていますか？

現在のMilvusはApple M1 CPUを直接サポートしておりません。Milvus 2.3以降では、ARM64アーキテクチャ用のDockerイメージが提供されます。

Milvusはプライマリキーフィールドでどのようなデータタイプをサポートしていますか？

現在のリリースでは、MilvusはINT64と文字列の両方をサポートしています。

Milvusはスケーラブルですか？

Kubernetes上のHelm Chartを利用することで、複数ノードのMilvusクラスタをデプロイすることができます。詳しくはスケールガイドをご参照ください。

growing segmentとsealed segmentとは何ですか？

Milvusは検索要求が来ると、インクリメンタルデータとヒストリカルデータの両方を検索します。増分データは最近更新されたデータで、オブジェクトストレージに永続化される閾値に達する前にメモリにバッファリングされ、より効率的なインデックスが構築される成長セグメントに保存されます。一方、履歴データは少し前に更新されたもので、オブジェクト・ストレージに永続化される前にメモリ上にバッファリングされ、より効率的なインデックスが作成される。インクリメンタルデータとヒストリカルデータは一緒に検索用のデータセット全体を構成する。この設計により、Milvusに取り込まれたデータは即座に検索可能となる。Milvus Distributedの場合、インジェストされたばかりのレコードがいつ検索結果に表示されるかは、より複雑な要因によって決定される。その詳細については一貫性レベルをご覧ください。

Milvusは同時検索に対応していますか？

はい。Milvusは、同じコレクションに対するクエリの場合、インクリメンタルデータと履歴データを同時に検索します。ただし、異なるコレクションに対するクエリは直列に行われます。履歴データは非常に巨大なデータセットになる可能性がありますが、履歴データに対する検索は比較的時間がかかり、基本的に直列に実行されます。

対応するコレクションが削除された後も、MinIOのデータが残るのはなぜですか？

MinIOのデータは、データのロールバックの便宜のため、一定期間残るように設計されています。

MilvusはPulsar以外のメッセージ・エンジンをサポートしていますか？

はい。Milvus 2.1.0ではKafkaがサポートされています。

検索とクエリの違いは何ですか？

Milvusでは、ベクトル類似度検索は類似度計算とベクトル・インデックス加速に基づいてベクトルを検索します。ベクトル類似性検索とは異なり、ベクトル検索はブーリアン式に基づくスカラーフィルタリングによってベクトルを検索します。ブーリアン式はスカラーフィールドまたは主キーフィールドをフィルタリングし、フィルタに一致するすべての結果を取得します。クエリでは、類似度メトリクスもベクトル・インデックスも関与しません。

なぜmilvusではfloatベクトル値の精度が小数点以下7桁なのですか？

MilvusはベクトルをFloat32配列として格納することをサポートしています。Float32の値の精度は小数点以下7桁です。1.3476964684980388のようなFloat64の値であっても、Milvusは1.347696として格納します。したがって、このようなベクトルをMilvusから取り出すと、Float64の値の精度は失われてしまいます。

Milvusではベクトルのデータ型と精度をどのように扱っているのですか？

MilvusはBinary、Float32、Float16、BFloat16のベクトル型をサポートしています。

• バイナリベクタ：0と1のシーケンスとしてバイナリデータを格納し、画像処理や情報検索に使用されます。
• Float32ベクトル：10進数約7桁の精度で格納される。Float64の値もFloat32の精度で格納されるため、検索時に精度が低下する可能性がある。
• Float16 および BFloat16 ベクタ：精度とメモリ使用量が低減されている。Float16は帯域幅とストレージが限られたアプリケーションに適しており、BFloat16は範囲と効率のバランスが取れており、精度に大きな影響を与えることなく計算量を減らすためにディープラーニングでよく使用されます。

Milvusはスカラーフィールドやベクトルフィールドのデフォルト値の指定に対応していますか？

現在のところ、Milvus 2.4.xではスカラーフィールドやベクトルフィールドのデフォルト値を指定することはできません。この機能は将来のリリースを予定しています。

Milvusでデータを削除した後、すぐに保存領域は解放されますか？

いいえ。Milvusでデータを削除しても、すぐにストレージ領域が解放されるわけではありません。データを削除するとエンティティは「論理的に削除された」ことになりますが、実際の容量はすぐに解放されない場合があります。その理由は以下の通りです：

• コンパクション：Milvusはバックグラウンドで自動的にデータを圧縮します。このプロセスは、より小さなデータセグメントをより大きなデータセグメントに統合し、論理的に削除されたデータ（削除マークが付けられたエンティティ）やTTL（Time-To-Live）を超えたデータを削除します。ただし、コンパクションは新しいセグメントを作成する一方で、古いセグメントには "Dropped "というマークを付ける。
• ガベージコレクション：ガベージコレクション (GC) と呼ばれる別プロセスが、定期的に "Dropped" セグメントを削除する。これにより、ストレージの効率的な使用が保証されますが、削除とスペースの再利用の間に若干の遅延が生じる可能性があります。

挿入、削除、またはアップサートされたデータを、フラッシュを待たずに操作直後に見ることはできますか？

Milvusでは、ストレージとコンピュートの分離アーキテクチャを採用しているため、データの可視性はフラッシュ操作に直接関係しません。一貫性レベルを使用してデータの可読性を管理することができます。

一貫性レベルを選択する際には、一貫性とパフォーマンスのトレードオフを考慮してください。即時の可視性が必要な操作には、"Strong "一貫性レベルを使用する。書き込みを高速に行うには、一貫性を弱くすることを優先する（データはすぐには見えないかもしれない）。詳細については、「一貫性」を参照してください。

パーティション・キー機能を有効にした後、milvusのデフォルト値num_partitions 。

パーティションキー機能を有効にすると、Milvusのnum_partitions のデフォルト値は16 に設定されます。このデフォルト値は安定性とパフォーマンス上の理由から選択されています。create_collection 関数で指定することにより、必要に応じてnum_partitions の値を調整することができます。

スカラーフィルタリング式の長さの上限はありますか？

はい、スカラー・フィルタリング式の最大長は、milvus.yaml 設定ファイルで定義される RPC 転送制限によって制約されます。具体的には、この制限はプロキシ・セクションのserverMaxRecvSize パラメータによって設定されます：

proxy:
  grpc:
    serverMaxRecvSize: 67108864 # The maximum size of each RPC request that the proxy can receive, unit: byte

デフォルトでは、各 RPC リクエストの最大サイズは 64MB です。したがって、フィルタリング式の長さがこの制限値以下でないと正常に処理できません。

一括ベクトル検索を実行する場合、一度に指定できるベクトルの数はいくつですか?制限はありますか?

はい。一括ベクター検索で指定できるベクターの数は、milvus.yaml 設定ファイルで定義されている RPC 転送サイズによって制限されます。この制限は、proxy セクションのserverMaxRecvSize パラメータによって決定されます：

proxy:
  grpc:
    serverMaxRecvSize: 67108864 # The maximum size of each RPC request that the proxy can receive, unit: byte

デフォルトでは、各 RPC 要求の最大サイズは 64MB です。したがって、入力ベクターの次元データとメタデータを含む合計サイズは、正常に実行するためにこの制限を下回る必要があります。

まだ質問がありますか？

できます：

• GitHubでMilvusをチェックしてください。質問を投げかけたり、アイデアを共有したり、他の人を助けたりすることができます。
• Slackのコミュニティに参加し、オープンソースコミュニティに参加してください。