SingleStore vs pgvector AIアプリケーションに適したベクターデータベースの選択
ベクターデータベースとは？
SingleStoreとpgvectorを比較する前に、まずベクターデータベースの概念について説明します；
ベクトルデータベース](https://zilliz.com/learn/what-is-vector-database)は、高次元のベクトルを格納し、クエリするために特別に設計されています。これらのベクトルは、テキストの意味、画像の視覚的特徴、または製品の属性などの複雑な情報をエンコードします。効率的な類似検索を可能にすることで、ベクトルデータベースはAIアプリケーションにおいて極めて重要な役割を果たし、より高度なデータ分析と検索を可能にしている。
ベクトルデータベースの一般的なユースケースには、電子商取引の商品推奨、コンテンツ発見プラットフォーム、サイバーセキュリティにおける異常検知、医療画像分析、自然言語処理(NLP)タスクなどがある。また、AI幻覚のような問題を軽減するために、外部知識を提供することによって大規模言語モデル(LLMs)の性能を向上させる技術であるRAG(Retrieval Augmented Generation) において重要な役割を果たす。
市場には、以下のような多くの種類のベクトル・データベースがある：
- Milvus](https://zilliz.com/what-is-milvus)、Zilliz Cloud(フルマネージドMilvus)など。
- Faiss](https://zilliz.com/learn/faiss)やAnnoyのようなベクトル検索ライブラリ。
- Chroma](https://zilliz.com/blog/milvus-vs-chroma)やMilvus Liteのような軽量ベクトルデータベース。
- 小規模なベクトル検索が可能なベクトル検索アドオンを備えた従来のデータベース**。
SingleStoreは分散リレーショナルSQLデータベース管理システムであり、pgvectorは伝統的なデータベースである。どちらもベクトル検索をアドオンとして備えている。この記事では、両者のベクトル検索機能を比較する。
SingleStore：概要とコアテクノロジー
SingleStoreは、データベース自体にベクター検索機能を持たせることで、技術スタックに個別のベクターデータベースを必要としません。ベクターは通常のデータベーステーブルに格納され、標準的なSQLクエリで検索することができます。例えば、価格帯でフィルタリングしながら類似の商品画像を検索したり、特定の部門に結果を限定しながらドキュメントの埋め込みを検索したりすることができます。システムは、ベクトルインデックスにFLAT、IVF_FLAT、IVF_PQ、IVF_PQFS、HNSW_FLAT、HNSW_PQを、類似性マッチングにドット積とユークリッド距離を使用したセマンティック検索の両方をサポートしている。これは、推薦システム、画像認識、AIチャットボットなど、類似性マッチングが高速なアプリケーションに超便利である。
SingleStoreの中核は、パフォーマンスとスケールのために構築されている。データベースは複数のノードにデータを分散させるので、大規模なベクトルデータ操作に対応できます。データが大きくなっても、ノードを追加すれば問題ありません。クエリプロセッサーはベクトル検索とSQLオペレーションを組み合わせることができるので、複数のクエリを別々に実行する必要がありません。ベクターのみのデータベースとは異なり、SingleStoreはこれらの機能を完全なデータベースの一部として提供するため、複数のシステムを管理したり、複雑なデータ転送に対応したりすることなく、AI機能を構築することができます。
SingleStoreのベクトルインデックスには2つのオプションがあります。1つ目は厳密なk-最近傍(kNN)検索で、クエリベクトルに最も近いk個の近傍集合を正確に見つけます。しかし、非常に大きなデータセットや高い同時実行性の場合、SingleStoreはベクトルインデックスを使用した近似最近傍（ANN）検索もサポートします。ANN検索は、厳密なkNN検索よりもはるかに高速にk近傍を見つけることができます。速度と精度はトレードオフの関係にあり、ANNは高速ですが、正確なk個の最近傍セットを返すとは限りません。インタラクティブな応答時間が必要で、絶対的な精度を必要としない数十億のベクトルを扱うアプリケーションには、ANN検索が適しています。
SingleStoreにおけるベクトルインデックスの技術的実装には特別な要件があります。これらのインデックスはカラムストアテーブルにのみ作成可能で、ベクトルデータを格納する単一のカラムに作成する必要があります。システムは現在Vector Type(dimensions[, F32])フォーマットをサポートしており、F32は唯一サポートされている要素タイプです。この構造化されたアプローチにより、SingleStoreは大規模な言語モデルからのベクトルを使用した意味検索、焦点を絞ったテキスト生成のためのRAG（retrieval-augmented generation）、ベクトル埋め込みに基づく画像マッチングなどのアプリケーションに最適です。これらを従来のデータベース機能と組み合わせることで、SingleStoreは開発者がパフォーマンスとスケールを維持しながら、SQL構文を使用して複雑なAIアプリケーションを構築することを可能にします。
pgvector：概要とコア
pgvectorはPostgreSQLの拡張で、PostgreSQLデータベースで直接ベクトル演算を行うことができます。つまり、ベクタデータベースを別に用意することなく、ベクタの埋め込みを保存したり問い合わせたりすることができます。
pgvectorは完全なベクトル演算機能を備えています。ネイティブなベクトル類似度検索、厳密/近似最近傍検索、PostgreSQLのインデックスとの統合が可能です。ベクトル演算：加算と減算、複数の距離メトリックをサポートしています：ユークリッド、余弦、内積。
検索機構とインデックスタイプ
デフォルトでは、pgvectorは正確な最近傍探索を使用します。これは完全な想起を与えますが、大規模なデータセットでは遅くなる可能性があります。より良いパフォーマンスを得るために、pgvectorはインデックスによる近似最近傍探索を提供します。
HNSW (Hierarchical Navigable Small World)：pgvector 0.5.0で導入されたHNSWは、高速な検索探索のために多層グラフ構造を作成します。素晴らしい性能と良い結果で知られていますが、IVFFlatよりも多くのメモリを必要とします。このインデックスは、高速で正確な検索を必要とするアプリケーションに適しています。
IVFFlat (Inverted File Flat)：IVFFlat法はベクトル空間内のベクトルをクラスタ化し、2段階の検索プロセスを使用します。まず、関連するクラスターを見つけ、次に選択したクラスター内で厳密な検索を行います。HNSWよりもメモリ効率は良いが、場合によっては若干遅くなったり、精度が落ちることもある。
技術的限界
pgvectorの技術的な制限は、その次元の制限です。デフォルトのページサイズを8KiBとすると、拡張モジュールは2000次元までの完全精度(32ビット/4バイト)ベクトルデータを格納することができます。スカラー量子化(halfvec/16-bit/2-bytes)を使用すると、最大次元数は4000まで増加しますが、それでも1ベクトルあたり7.8125KiBを使用します。
現代言語モデルへの影響
これはRAG（Retrieval-Augmented Generation）アプリケーションを制限します。HuggingFaceのMTEBリーダーボードで上位を占める埋め込みモデルのほとんどは、この次元制限を超えています。halfvecスカラー量子化でさえ、互換性があるのはgte-qwen2-7B-instruct、gte-qwen2-7B-instruct-fp16、bge-multilingual-gemma2の3つのモデルだけです。
実装のヒント
pgvectorを使用する際には、HNSWとIVFFlatの両方のインデックスを試して、使用するケースに最適なものを見つけるべきです。データセットのサイズ、クエリ速度の要件、許容できる精度のトレードオフ、 メモリの制約などです。インデックスのパラメータを微調整し、様々な構成をベンチマークして、ユースケースに最適なものを見つけてください。
パフォーマンス
pgvectorを使用する場合、近似インデックスを追加すると、従来のデータベースのインデックスとは異なり、クエリの結果が変化することに留意してください。これは、開発とテストの段階で考慮すべきことであり、正確さと性能のトレードオフがアプリケーションのニーズに合っていることを確認する必要があります。データや使用パターンの変化に応じて、設定を監視し、調整してください。
主な相違点
検索方法
SingleStore：SingleStoreには、厳密検索と近似最近傍（ANN）検索の両方がある。そのベクトル索引付けは、FLAT、IVF_FLAT、IVF_PQ、HNSW_FLAT、および HNSW_PQをサポートしています。これにより、ドット積やユークリッド距離による高性能な類似性検索が可能になる。ANNは、精度のトレードオフをある程度許容できる、低レイテンシの大規模データセットに最適である。
pgvector: pgvectorはPostgreSQLのネイティブなベクトル演算を持ち、正確な検索とANN検索を含みます。ANNにはHNSWとIVFFlatを使用し、HNSWは高速ですがメモリを消費します。pgvectorは非常に柔軟ですが、デフォルトの正確検索は、これらのインデックスで最適化しない限り、大規模なデータセットで苦労します。
データの取り扱い
**シングルストアSingleStoreはベクトルデータをカラムストアテーブルに格納するため、構造化データと非構造化データをシームレスにクエリできます。そのSQL駆動型アプローチは、ベクトル検索と標準的なデータベースクエリを組み合わせるので、価格やカテゴリでフィルタリングされた製品エンベッディングを検索するようなハイブリッドなユースケースに最適です。
pgvector：PostgreSQLの拡張として、pgvectorはリレーショナルデータ処理と緊密に結合しています。pgvectorは、従来のリレーショナルデータと共にベクトル埋め込みデータを格納することができます。しかし、ベクトル次元の上限（精度に依存しますが、2000-4000）があるため、最新のLLMアプリケーションには制限があるかもしれません。
スケーラビリティとパフォーマンス
**シングルストアSingleStoreはデータをノードに分散することで水平方向に拡張し、データが増大してもパフォーマンスは変わりません。分散アーキテクチャとクエリ・プロセッサはベクトル演算とSQL演算を並列処理でき、クエリのオーバヘッドを削減。ANNインデックスにより、大規模データセットのクエリを高速化。
pgvector：pgvectorのスケーラビリティはPostgreSQLの強みに依存しています。pgvectorのスケーラビリティはPostgreSQLの強みに依存します。中程度のデータセットであれば十分に扱うことができますが、大規模なデータセットや並行性の高い作業負荷では苦戦するかもしれません。インデックスチューニングとクラスタリングは助けになりますが、水平スケーリングにはパーティショニングのような追加の回避策が必要になるかもしれません。
柔軟性とカスタマイズ
**シングルストアSingleStoreはシンプルで、標準SQLでベクトル検索を行うことができます。このため実装は簡単ですが、ベクターインデックスのオプションはカラムストアテーブルのような特定の構成に限定されるため、カスタムセットアップの柔軟性が制限される可能性があります。
pgvector: pgvectorはより柔軟で、ベクトル演算と複数の類似度メトリクス（ユークリッド、余弦、内積）をサポートしています。カスタムインデックスの実験、パラメータの微調整、PostgreSQLのエコシステムとの統合を行いたい開発者に適しています。
統合とエコシステム
SingleStore：スタンドアロンデータベースであるSingleStoreはオールインワンであるため、別々のシステムの必要性を低減します。このオール・イン・ワンのアプローチは統合の複雑さを最小化しますが、PostgreSQLベースのツールのエコシステムには欠けるかもしれません。
pgvector: pgvectorは、一般的なフレームワーク、ツール、拡張機能との互換性を含む、PostgreSQLのエコシステムの恩恵を受けています。あなたのスタックが既にPostgreSQLの上に構築されているのであれば、これは強力な選択肢です。
使いやすさ
**シングルストアSQLファーストの設計により、セットアップとクエリが簡単で、迅速なデプロイと最小限の学習曲線を望むチームに最適です。しかし、ベクターインデックスの制約に適応するには、多少の調整が必要かもしれない。
pgvector：PostgreSQLに慣れている開発者であれば、pgvectorは簡単だと感じるでしょう。インデックスの実験と調整は若干の複雑さを加えますが、使用例に特化した最適化の機会もあります。
コスト
**シングルストア高性能なエンタープライズグレードのデータベースである SingleStore は、特にマネージドサービスや大規模な導入の場合、運用コストが高くなる可能性があります。多様なデータニーズを持つ組織では、システムを統合することでコストを相殺できる可能性があります。
pgvector: pgvectorはオープンソースであるため、小規模なプロジェクトでは費用対効果が高いです。しかし、PostgreSQLのインフラストラクチャを大規模に管理すると、追加のハードウェアやメンテナンスのような隠れたコストが発生する可能性があります。
セキュリティ
SingleStore：SingleStoreは、データの暗号化、ロールベースのアクセスコントロール、監査ログなど、エンタープライズグレードのセキュリティ機能を備えています。これらは、高いコンプライアンス要件が求められるユースケース向けです。
pgvector: pgvectorはPostgreSQLのセキュリティ機能を継承しています。
SingleStore を使用する場合
SingleStoreは、高いパフォーマンスとスケールを必要とする大規模な分散データシステム向けです。ベクトル検索とSQLクエリーを組み合わせることで、AIを活用したレコメンデーションシステム、フィルターを使った商品検索、企業ワークロード向けのセマンティック検索などのアプリケーションで、構造化データと非構造化データをまとめることができます。SingleStoreの分散アーキテクチャ、ANNインデックスオプション、オールインワン設計は、インタラクティブなレスポンスタイムで何十億ものベクトルを処理する必要があるシナリオに最適です。
pgvectorを使用する場合
pgvectorは、既にPostgreSQLを使用している環境や、シンプルさとコストが重要な場合に使用します。小規模なベクトル検索アプリケーションや、全文検索、伝統的なリレーショナルクエリ、ベクトル操作を同じデータベース内で組み合わせる必要があるプロジェクト向けです。PostgreSQLの豊富なエコシステムとうまく統合されており、モデルを組み込んだり、既存のPostgreSQLインフラストラクチャにベクトル検索を追加したりすることができます。
結論
SingleStoreもpgvectorもベクトル検索においてそれぞれの強みがあります。SingleStoreはSQLの統合と高いパフォーマンスで大規模な分散データセットに適しており、pgvectorは柔軟性、PostgreSQLでの使いやすさ、コスト効率に優れています。エンタープライズグレードのスケーラビリティが必要なのか、それとも既存のPostgreSQL環境内で軽量なソリューションが必要なのか、といったユースケースによって選択は異なります。データの種類、性能のニーズ、エコシステムの要件を評価することで、プロジェクトに合ったツールを選択することができます。
SingleStoreとpgvectorの概要を知るにはこれを読んでください。しかし、これらを評価するには、ユースケースに基づいて評価する必要があります。その助けとなるツールの一つが、ベクターデータベースの比較のためのオープンソースのベンチマークツールであるVectorDBBenchです。最終的には、独自のデータセットとクエリパターンで徹底的なベンチマークを行うことが、分散データベースシステムにおけるベクトル検索に対する、強力ではあるが異なるこれら2つのアプローチのどちらを選ぶかを決定する鍵となるでしょう。
オープンソースのVectorDBBenchを使ってベクトルデータベースを評価・比較する
VectorDBBenchは、高性能なデータ保存・検索システム、特にベクトルデータベースを必要とするユーザーのためのオープンソースのベンチマークツールです。このツールにより、ユーザはMilvusやZilliz Cloud(マネージドMilvus)のような異なるベクトルデータベースシステムを独自のデータセットを使ってテストし比較し、自分のユースケースに合うものを見つけることができます。VectorDBBenchを使えば、ユーザーはマーケティング上の主張や伝聞ではなく、実際のベクターデータベースのパフォーマンスに基づいて決定を下すことができます。
VectorDBBenchはPythonで書かれており、MITオープンソースライセンスの下でライセンスされています。VectorDBBenchは、その機能と性能の改善に取り組む開発者のコミュニティによって活発にメンテナンスされています。
VectorDBBenchをGitHubリポジトリ**からダウンロードして、我々のベンチマーク結果を再現したり、あなた自身のデータセットでパフォーマンス結果を得てください。
VectorDBBench Leaderboard](https://zilliz.com/vector-database-benchmark-tool?database=ZillizCloud%2CMilvus%2CElasticCloud%2CPgVector%2CPinecone%2CQdrantCloud%2CWeaviateCloud&dataset=medium&filter=none%2Clow%2Chigh&tab=1)で、主流のベクトルデータベースの性能を簡単に見てみましょう。
ベクターデータベースの評価については、以下のブログをお読みください。
- ベンチマーク・ベクター・データベースのパフォーマンス：テクニックと洞察](https://zilliz.com/learn/benchmark-vector-database-performance-techniques-and-insights)
- VectorDBBench: Open-Source Vector Database Benchmark Tool](https://zilliz.com/learn/open-source-vector-database-benchmarking-your-way)
- ベクターデータベースを他のデータベースと比較する](https://zilliz.com/comparison)
VectorDB、GenAI、MLに関するその他のリソース
- ジェネレーティブAIリソースハブ｜Zilliz](https://zilliz.com/learn/generative-ai)
- あなたのGenAIアプリのためのトップパフォーマンスAIモデル｜Zilliz](https://zilliz.com/ai-models)
- RAGとは](https://zilliz.com/learn/Retrieval-Augmented-Generation)
- 大規模言語モデル(LLM)を学ぶ](https://zilliz.com/learn/ChatGPT-Vector-Database-Prompt-as-code)
- ベクトルデータベース101](https://zilliz.com/learn/what-is-vector-database)
- 自然言語処理(NLP)](https://zilliz.com/learn/introduction-to-natural-language-processing-tokens-ngrams-bag-of-words-models)
Chloe WilliamsChloe Williams is a technical writer at Zilliz.
読み続けて
Semantic Search vs. Lexical Search vs. Full-text Search
Lexical search offers exact term matching; full-text search allows for fuzzy matching; semantic search understands context and intent.
AI Video Editing Software: Revolutionizing Video Tech Through Intelligent Search and Automation
Learn how to build AI-powered video editing tools using CLIP, ResNet, and vector databases. Discover implementation steps for intelligent search, automated tagging, and scalable video processing.
Matryoshka Representation Learning Explained: The Method Behind OpenAI’s Efficient Text Embeddings
Matryoshka Representation Learning (MRL) is a method for generating hierarchical, nested embeddings that capture information at multiple levels of abstraction.
The Definitive Guide to Choosing a Vector Database
Overwhelmed by all the options? Learn key features to look for & how to evaluate with your own data. Choose with confidence.