PGVectorを超えて：ベクターデータベースにF1アップグレードが必要な場合
Postgresはリレーショナルデータベースの世界の中心的存在であり、28年以上にわたって開発者に忠実なサービスを提供してきました。pgvector](https://zilliz.com/blog/getting-started-pgvector-guide-developers-exploring-vector-databases)**拡張の導入により、Postgresはベクトル埋め込みをサポートし、基本的なベクトル類似検索のための便利なエントリーポイントを提供します。
しかし、pgvectorは実用的な出発点を提供する一方で、特に大規模なアプリケーションや複雑な検索要件を扱う場合には、Milvusのような専用に構築されたベクトルデータベースと比較するとまだ不十分です。要求の厳しいベクトル検索ワークロードを pgvector と Postgres だけに依存することは、パワーアップしたファミリーセダンでフォーミュラ1レースに参加しようとするようなものです。
AIアプリケーションが爆発的に普及するにつれ、開発者は成長痛に遭遇している。pgvectorを使った便利なソリューションとして始まったものが、データが増え、検索要件が高度になるにつれ、すぐにイライラするボトルネックになる。検索品質は低下し、インデックスの更新は長引き、アプリケーションの要求を満たすのに苦労してフラストレーションが高まります。
このブログでは、ベクトル検索アドオンであるpgvectorを持つPostgresが、小規模なプロジェクトや単純なユースケースではうまく機能するが、大規模なベクトル検索では限界に達する理由について説明します。また、Milvus のような専用に構築されたベクトルデータベースが、急速に進歩するこの分野特有の課題に取り組むために不可欠である理由についても説明します。
Postgres と Pgvector のボトルネック
Postgresをセダンと見なすことができます。それは何年も前からここにあり、機能していますが、非常に速くなることはできません。pgvector`はベクトルストレージと基本的な類似検索機能をPostgresに追加しますが、基本的な制限を引き継ぎます: ；
- HNSWとIVF_FLATです。HNSWは一般的なアルゴリズムですが、長いインデックス作成時間や高いメモリ要件など、大きなトレードオフを伴います。一方、IVF_FLATは、インデックスの構築は高速であるが、データセットの規模が大きくなるにつれて、クエリーパフォーマンスを維持するのに苦労する。DiskANNやGPUベースのインデックスタイプのようなオンディスクインデックスのサポートがないため、大規模データセットを扱う際の性能と柔軟性がさらに制限される。
- 高次元ベクトル埋め込み：** Pgvectorはアーキテクチャ上の制約により、高次元ベクトル埋め込みを扱うことができません。Pgvectorは、データ格納に8KBの固定ページに依存しており、ベクトルが対応できる次元数を根本的に制限しています。各次元はfloatを格納するために4バイトを必要とし、メタデータもスペースを占有するため、高次元ベクトルのインデックス付けは事実上不可能となる。対照的に、Milvusのような専用データベースは、高次元の埋め込みを簡単に扱えるように設計されています。pgvectorには量子化のような回避策が存在しますが、多くの場合、精度を妥協する必要があります。
- 高度な機能の欠如:** pgvectorは、専用のベクトルデータベースが提供する包括的な機能セットを欠いています。例えば、Milvusは高度なメタデータフィルタリング検索、L2や内積を超えるより広範な距離メトリクス、ハイブリッドスパース検索と高密度検索、さらには全文検索（Milvus 2.5で利用可能）をサポートしています；
- スケーラビリティの課題:** pgvectorをスケーリングして大規模なデータセットと高いクエリ負荷を扱うことは自明ではありません。シャーディングを実装し、複数のノードにまたがってインデックスを管理するためには、複雑さと運用上のオーバーヘッドを追加するような多大な労力を必要とすることがよくあります。専用に構築されたベクトルデータベースはスケーラビリティを念頭に設計されており、データセットやクエリ要求が増大してもシームレスなパフォーマンスを提供します。
Milvus: フォーミュラ1
Milvusは、大規模なベクトル類似検索に特有の要求に対応するためにゼロから設計されたオープンソースのベクトルデータベースです。ベクトルデータの世界でスピードとパフォーマンスを発揮するために綿密に設計されたフォーミュラ1カーとお考えください。
ここでは、MilvusがどのようにpgvectorでPostgresを凌駕するかを紹介する：
- FLAT、HNSW](https://zilliz.com/learn/vector-index)、DiskANN、CAGRA、およびGPUアクセラレーションを含む11の最先端のインデックス作成アルゴリズムをサポートし、数百億のベクトルでも比類のない検索パフォーマンスを提供します。
- MilvusはKubernetesネイティブの分散アーキテクチャを採用しています。シームレスな水平スケーリングが可能で、手作業による複雑なシャーディングを行うことなく、膨大なデータセットと高いクエリスループットを処理することができます。
- 包括的な機能セット: Milvusは、メタデータフィルタリング、様々な距離メトリックのサポート、全文検索、ハイブリッド検索、柔軟なインデックスオプションを含む包括的な機能スイートを提供し、検索戦略を特定のニーズに合わせて調整することができます；
- データの未来に最適化:** Milvusは、ベクトルとして表現される非構造化データの増大し続ける規模と複雑さを処理するように設計されており、次世代のAIアプリケーションにとって理想的なソリューションとなっています。
- 継続的な革新:** フォーミュラ1チームが常にパフォーマンスの限界を押し広げるように、Milvusは最先端のインデックス作成アルゴリズム、ハードウェアアクセラレーションサポート、機械学習主導の最適化によって継続的に進化しています。
正しい選択をする：いつ何を使うか
pgvectorを使用したPostgresはF1カーではないかもしれませんが、ガレージにはまだその場所があります。それぞれのソリューションをどのような時に使うべきかを考えてみましょう：
**pgvectorを選択するのは以下のような場合です。
- 小規模から中規模のデータセットで概念実証やMVPを構築している場合。
- ベクトル検索のニーズがシンプルで、複雑なフィルタリングを必要としない。
- 埋め込みモデル](https://zilliz.com/ai-models)は、Postgresのページサイズ制限以下の次元のベクトルを生成します。
- ACID準拠](https://zilliz.com/glossary/a.c.i.d.-transactions)と強力なトランザクション保証が必要です。
**以下の場合にMilvusを選択してください。
- 大規模なデータセット（数百万から数十億のベクトル）を扱う場合。
- pgvectorの限界を超える高次元埋め込みが必要な場合。
- クエリのパフォーマンスが重要である。
- 多様なインデックスオプションやGPUアクセラレーションなどの高度な機能を必要としている。
- 急成長が予想され、水平方向にスケールするソリューションが必要な場合。
ベクターのMilvusへの移行サービス
PGVectorをご利用中で問題が発生した場合、オープンソースの移行ツールであるVTS（Vector Transport Serviceの略）をご利用いただくことで、ベクターや非構造化データをMilvusやZilliz Cloud上のマネージドサービスに移行することができます。
Apache Seatunnelの上に構築されたVTSは以下を提供します：
- 豊富で拡張可能なコネクタ
- リアルタイム同期とオフラインバッチインポートのための統一されたストリームとバッチ処理
- データ一貫性のための分散スナップショットサポート
- ハイパフォーマンス、低レイテンシー、スケーラビリティ
- リアルタイムモニタリングとビジュアル管理
pgvectorに加えて、VTSは、Elasticsearch、Pinecone、Qdrant、Tencent Cloud VDBなどの様々なソースから、Milvusのような専用に構築されたベクトルデータベースへのベクトルデータの移行をサポートしています。また、オープンソースのMilvusとZilliz Cloud間のシームレスなベクター移行も可能です。
移行プロセスを簡素化するため、VTSはスキーマ変換を自動的に処理し、複雑なセットアップや開発作業を不要にします。2025年には、VTSはその機能を拡張し、MongoDBやWeaviateのような追加ソースからのデータ移行をサポートする予定です。将来のバージョンでは、ベクトル埋め込みをオンザフライで生成する機能も導入し、非構造化データを簡単に変換してベクトルデータベースに移植し、近似最近傍(ANN)検索を加速できるようにする予定です。これらのエキサイティングなアップデートにご期待ください！
VTSの仕組み](https://assets.zilliz.com/roadmap_22f42cd1b0.png)
前途
ベクトルデータベースは、AI技術の急速な進歩とともに進化し続けている。pgvector`は便利なエントリーポイントを提供するが、生産規模のAIアプリケーションの要求には、しばしば専用のソリューションが必要になる。
pgvectorとMilvusのどちらを選択するかは、単なる技術的な決断ではありません。アプリケーションの将来のスケーラビリティに対する戦略的投資なのです。フォーミュラ1チームが性能要件に基づいて機材を選択するように、組織は成長軌道に照らし合わせてベクトル検索のニーズを評価する必要があります。
移行プロセスを合理化する VTS のようなツールがあれば、企業は、要件が pgvector の機能を超えたときに、自信を持ってベクトル検索機能を移行することができます。新しいアプリケーションをアーキテクトする場合でも、既存のアプリケーションを拡張する場合でも、ベクター検索の要件を早期に検討することで、技術的負債を防ぎ、持続可能な成長を実現することができます。
ぜひご意見をお聞かせください！
このブログ記事が気に入ったら、ぜひご検討ください：
- GitHub](https://github.com/milvus-io/milvus)で星をつけてください。
- 💬 Milvus Discord コミュニティ に参加して、あなたの経験を共有しましょう。
- 🔍 Bootcamp リポジトリ で、Milvus を使用したアプリケーションの例をご覧ください。
Stephen BatifolStephen Batifol is a Developer Advocate at Zilliz. He previously worked as a Machine Learning Engineer at Wolt, where he was working on the ML Platform and as a Data Scientist at Brevo. Stephen studied Computer Science and Artificial Intelligence. He enjoys dancing and surfing.
読み続けて
1 Table = 1000 Words? Foundation Models for Tabular Data
TableGPT2 automates tabular data insights, overcoming schema variability, while Milvus accelerates vector search for efficient, scalable decision-making.
Elasticsearch Was Great, But Vector Databases Are the Future
Purpose-built vector databases outperform dual-system setups by unifying Sparse-BM25 and semantic search in a single, efficient implementation.
Enabling Fine-Grained Access Control with Milvus Row-Level RBAC
Milvus offers row-level RBAC (Role-Based Access Control) which is a robust solution for managing data access with precision and efficiency.