← 概念解説に戻る

Concept Fable

Milvus

先に結論:Milvus は、大規模なベクトル類似度検索のために設計されたオープンソースの分散ベクトルデータベースである。ストレージとコンピューティングを分離したアーキテクチャを採用し、多様なインデックスタイプ(HNSW、IVF_FLAT、IVF_PQ、DiskANN など)、水平スケーリング、データ永続化、ハイブリッドクエリをサポートする。Milvus はアクセス層(proxy)、クエリノード、データノード、インデックスノード、ストレージ層(オブジェクトストレージ + メッセージキュー)に分かれ、各コンポーネントは独立して拡縮できる。企業 RAG では、Milvus はベクトル量が数千万から数十億の規模の場面に適している。高並行のオンラインクエリ、増分データの継続的な書き込み、複数のインデックス戦略の共存、障害復旧とデータ永続性に対する厳格な要件が必要な場合である。Python/Java/Go SDK と RESTful API を提供し、LangChain、LlamaIndex などのフレームワークとの統合も良好である。

Milvus · オープンソースのベクトルデータベース

まず物語を読む。ここでは急いで定義を示さず、まず問題そのものを立ち上がらせる。

寓話

織坊の主は糸を足すのではなく分けることを学んだ

江南最大の織工場では数百台の織機が同時に稼働し、各織機は倉庫から最も合う糸を見つけなければならなかった。老管理人の方法は、すべての糸の見本を長い壁に掛け、工人が走って行って一本ずつ比べるというものだった。

商売が大きくなるにつれ、糸の品種は数十種から数万種になった。あの壁は十数室に広がり、工人は朝から晩まで走り回り、足の方が目より疲れた。経験ある師匠は記憶に頼ったが、新工人は似た糸をいつも混同した。

東家はまず三面のより大きな壁を買った。壁は大きくなったが、照合は速くならず、むしろ歩く距離が長くなったため遅くなった。三人の管事がそれぞれ左・中・右の三面の壁を管理し、互いの同期は声を張り上げるだけだったため、誤りと漏れがさらに増えた。

エンジニアが訪れて一瞥し、こう言った。糸をいくつかの組に分けて別々に置く必要がある。各組の大きさは、人が手を伸ばして届く棚にちょうど収まる程度に。検索時は、探す糸がどの組に属するかをまず判断し、その組の中だけで探す。

主人は部屋が増えると管理が混乱するのではと心配した。技師は彼に全体図を一枚渡した。すべての棚は分散していても、一つの総合调度台によって統一的に管理される。调度台は誰がどこにいるか、どの棚を調べるべきか、そして新しい糸が入ってきたらどこに置くべきかを知っている。

最初の改善は、棚ごとに異なる探し方を与えることでした:あるものは近傍の紐でおおよその類似を素早く見つけ、あるものはバケット分けで大量の粗い検索に適し、またあるものは全量の精密比較を保持し、重要な注文に使います。

2つ目の改善は、棚を横方向に増やせるようにすることだった。繁忙期には、新しい倉庫が総合指令台に接続され、古いクエリを一から作り直す必要がない。作業員は依然として同じ窓口に問い合わせるが、背後では仕事を多くの部屋に振り分けられる。

織坊はついに、無限に延びる壁一面で商売を支える必要がなくなった。東家は理解した。真の能力は、類似検索、グループ化、索引、スケジューリング、拡張を同じ一つの倉庫の秩序に収めることにある。後に織坊は急な注文を再び受け、東家は長い壁を買うのではなく、まずこの束の糸にどの探し方を使い、どの組に置き、精密比較が必要かを問うた。総合調整台が問題を割り振り、結果は老師匠が記憶に頼るより安定した。規模が拡大すれば、秩序は壁面より重要になる。東家は後に理解した。倉庫が大きいほど、一人の老師匠の道案内だけに頼ってはならない。どの工人も総合調整台を通じて近似の糸を見つけられてこそ、商売は支えられる。

明らかにする

この物語が伝えるのは:Milvus

Milvus は、大規模なベクトル類似度検索のために設計されたオープンソースの分散ベクトルデータベースである。ストレージとコンピューティングを分離したアーキテクチャを採用し、多様なインデックスタイプ(HNSW、IVF_FLAT、IVF_PQ、DiskANN など)、水平スケーリング、データ永続化、ハイブリッドクエリをサポートする。Milvus はアクセス層(proxy)、クエリノード、データノード、インデックスノード、ストレージ層(オブジェクトストレージ + メッセージキュー)に分かれ、各コンポーネントは独立して拡縮できる。企業 RAG では、Milvus はベクトル量が数千万から数十億の規模の場面に適している。高並行のオンラインクエリ、増分データの継続的な書き込み、複数のインデックス戦略の共存、障害復旧とデータ永続性に対する厳格な要件が必要な場合である。Python/Java/Go SDK と RESTful API を提供し、LangChain、LlamaIndex などのフレームワークとの統合も良好である。

重要なのは、それが単なる用語ではなく、実際のAI/Agentシステムで繰り返し現れる構造的な問題だという点だ。これを理解して初めて、いつモデルを足すべきか、いつプロセスを変えるべきか、いつガバナンスを補うべきかを判断できる。

メタファーのマッピング

  • 長い壁に糸の見本を掛ける:単機メモリのベクトル検索、データ量が制限され永続化もない
  • 三面の壁を三人の管事がそれぞれ管理:単純なマルチインスタンス配備で、統一的なスケジューリングとデータ整合性に欠ける
  • いくつかの組に分けて別の部屋に置く:シャーディング(sharding)でベクトルデータを水平分割する
  • 総合调度台が統合管理:Milvus proxy 層、クエリと書き込みを対応ノードにルーティング
  • 跳点図、バケット、正確:多様なインデックス型(HNSW、IVF、DiskANN など)
  • データの永続化と増分書き込み:オブジェクトストレージ+メッセージキューベースの永続化メカニズム
  • 架台の数を増やし大型単体に替えない:水平スケーリング、クエリノード/データノードを独立にスケール
  • メモリを分解し、クエリの一貫性を保つ:分散ベクトルデータベースの核心的なエンジニアリング課題

Andy(任旭)判断

この概念の実戦的価値は、「賢く見えるAI機能」を納品可能、検収可能、ガバナンス可能な作業単位に分解する手助けをすることです。

Zillizvector indexANN searchembeddingsRAG
京ICP备2026014272号