ベクトルデータベース比較ガイド¶
概要¶
RAG（Retrieval-Augmented Generation）システムを構築する際、ベクトルデータベースの選択は非常に重要です。このガイドでは、主要なベクトルデータベースを比較し、用途に応じた最適な選択をサポートします。
ベクトルデータベースとは¶
ベクトルデータベースは、高次元ベクトルの保存と高速な類似検索に特化したデータベースです。
必要性¶
- 意味検索: キーワードではなく意味的な類似性で検索
- 高速検索: 数百万〜数億のベクトルから近似最近傍探索
- スケーラビリティ: 大規模データセットへの対応
主要ベクトルデータベース比較¶
総合比較表¶
| データベース | 種別 | 特徴 | 適用規模 | 導入難易度 | コスト |
|---|---|---|---|---|---|
| pgvector | PostgreSQL拡張 | 既存RDBに統合可能 | 小〜中規模 | 低 | 無料 |
| Qdrant | 専用ベクトルDB | Rust製、高速 | 中〜大規模 | 中 | 無料（OSS） |
| FAISS | ライブラリ | Meta製、超高速 | 大規模 | 高 | 無料 |
| ChromaDB | 軽量ベクトルDB | Python統合が容易 | 小〜中規模 | 低 | 無料 |
| Milvus | 分散ベクトルDB | エンタープライズ向け | 大規模 | 高 | 無料（OSS） |
| Pinecone | マネージドサービス | クラウドネイティブ | 全規模 | 低 | 有料 |
| Weaviate | GraphQL対応 | セマンティック検索 | 中〜大規模 | 中 | 無料（OSS） |
詳細比較¶
1. pgvector¶
概要¶
PostgreSQLの拡張モジュールとして動作するベクトル検索機能。既存のPostgreSQLインフラに統合できる点が最大の強みです。
特徴¶
メリット - 既存のPostgreSQL環境にプラグイン追加だけで導入可能 - SQLで直接ベクトル検索が可能 - トランザクション管理、ACID特性を持つ - メタデータとベクトルを同じDBで管理 - バックアップ・運用が既存の仕組みで対応可能
デメリット - 大規模（数百万件以上）では専用DBより遅い - インデックス最適化に工夫が必要 - 分散構成が難しい
技術詳細¶
-- 拡張のインストール
CREATE EXTENSION vector;
-- テーブル作成
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
content TEXT,
embedding vector(1536), -- OpenAI embedding
metadata JSONB,
created_at TIMESTAMP DEFAULT NOW()
);
-- インデックス作成（IVFFlat）
CREATE INDEX ON documents
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);
-- インデックス作成（HNSW）- より高速
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops);
-- 類似検索
SELECT
id,
content,
embedding <-> '[0.1, 0.2, ...]' AS distance
FROM documents
ORDER BY distance ASC
LIMIT 10;
距離関数¶
| 演算子 | 距離メトリック | 用途 |
|---|---|---|
<-> |
ユークリッド距離（L2） | 一般的なベクトル検索 |
<#> |
内積（負の値） | 高速な近似検索 |
<=> |
コサイン距離 | テキストEmbedding検索 |
適用シナリオ¶
- 既にPostgreSQLを使用している
- データ規模が10万〜100万件程度
- SQLでの統合管理を優先したい
- 運用コストを抑えたい
パフォーマンスチューニング¶
-- パーティショニング
CREATE TABLE documents_2024_01 PARTITION OF documents
FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');
-- 並列クエリの有効化
SET max_parallel_workers_per_gather = 4;
-- メモリ設定
SET work_mem = '256MB';
2. Qdrant¶
概要¶
Rust製の高性能ベクトルデータベース。REST APIとgRPCでアクセス可能で、スケーラビリティに優れています。
特徴¶
メリット - 高速: Rust実装による高いパフォーマンス - スケーラブル: 分散クラスタ構成が可能 - フィルタリング: メタデータによる条件付き検索 - マルチテナント: コレクション分割が容易 - 豊富なSDK: Python, Go, Rust, JavaScript対応
デメリット - 独立したサービスとして運用が必要 - RDBのような複雑なJOINは不可 - バックアップは専用API経由
技術詳細¶
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
# クライアント接続
client = QdrantClient(host="localhost", port=6333)
# コレクション作成
client.create_collection(
collection_name="documents",
vectors_config=VectorParams(
size=1536, # Embedding次元数
distance=Distance.COSINE
)
)
# ベクトル挿入
client.upsert(
collection_name="documents",
points=[
PointStruct(
id=1,
vector=[0.1, 0.2, ...], # 1536次元
payload={"content": "PostgreSQLは強力なRDBMS", "category": "database"}
)
]
)
# 類似検索
results = client.search(
collection_name="documents",
query_vector=[0.12, 0.23, ...],
limit=10,
query_filter={
"must": [
{"key": "category", "match": {"value": "database"}}
]
}
)
Docker構成¶
# docker-compose.yaml
services:
qdrant:
image: qdrant/qdrant:latest
container_name: qdrant
ports:
- "6333:6333" # REST API
- "6334:6334" # gRPC
volumes:
- ./qdrant_storage:/qdrant/storage
restart: unless-stopped
適用シナリオ¶
- 数百万件以上のベクトルデータ
- 高速検索が必須
- メタデータフィルタリングが必要
- LangChain/LlamaIndexと統合したい
パフォーマンス比較¶
| データ量 | pgvector検索時間 | Qdrant検索時間 |
|---|---|---|
| 10万件 | 50ms | 10ms |
| 100万件 | 500ms | 50ms |
| 1000万件 | 5000ms | 200ms |
3. FAISS¶
概要¶
Meta（Facebook）が開発した高速ベクトル検索ライブラリ。ライブラリとして組み込むため、最も柔軟性が高いです。
特徴¶
メリット - 超高速: GPUも活用可能 - 豊富なインデックス: 用途に応じて最適なアルゴリズムを選択 - オフライン処理: ローカルで完結 - 柔軟性: Pythonコードに直接組み込み可能
デメリット - データ永続化は自分で実装 - スケールアウトには工夫が必要 - リアルタイム更新には不向き - サーバーとしての運用には別途実装が必要
技術詳細¶
import faiss
import numpy as np
# サンプルデータ
dimension = 1536 # Embedding次元数
n_vectors = 100000
vectors = np.random.random((n_vectors, dimension)).astype('float32')
# インデックス構築（Flat - 正確だが遅い）
index_flat = faiss.IndexFlatL2(dimension)
index_flat.add(vectors)
# インデックス構築（IVF - 高速だが近似）
quantizer = faiss.IndexFlatL2(dimension)
index_ivf = faiss.IndexIVFFlat(quantizer, dimension, 100) # 100クラスタ
index_ivf.train(vectors)
index_ivf.add(vectors)
# インデックス構築（HNSW - 高速・高精度）
index_hnsw = faiss.IndexHNSWFlat(dimension, 32)
index_hnsw.add(vectors)
# 検索
query = np.random.random((1, dimension)).astype('float32')
k = 10 # 上位10件
distances, indices = index_hnsw.search(query, k)
# インデックス保存
faiss.write_index(index_hnsw, "index.faiss")
# インデックス読み込み
index = faiss.read_index("index.faiss")
インデックスタイプ比較¶
| インデックス | 速度 | 精度 | メモリ | 用途 |
|---|---|---|---|---|
| IndexFlatL2 | 遅い | 100% | 大 | 小規模・高精度要求 |
| IndexIVFFlat | 速い | 95-99% | 中 | 中規模・バランス型 |
| IndexHNSWFlat | 非常に速い | 98-99% | 大 | 大規模・高速要求 |
| IndexIVFPQ | 非常に速い | 90-95% | 小 | 超大規模・省メモリ |
適用シナリオ¶
- バッチ処理での類似検索
- オフライン分析
- 最高速度が必要
- 独自のカスタマイズが必要
4. ChromaDB¶
概要¶
Pythonで書かれた軽量ベクトルデータベース。LangChainとの統合が非常に簡単です。
特徴¶
メリット - 簡単: pip installだけで開始 - LangChain統合: ネイティブサポート - ローカル実行: 開発環境で手軽に試せる - Pythonネイティブ: API設計が直感的
デメリット - 大規模データには不向き - 本番運用には追加構成が必要 - パフォーマンスは専用DBに劣る
技術詳細¶
import chromadb
from chromadb.config import Settings
# クライアント作成
client = chromadb.Client(Settings(
chroma_db_impl="duckdb+parquet",
persist_directory="./chroma_db"
))
# コレクション作成
collection = client.create_collection(name="documents")
# ドキュメント追加
collection.add(
documents=["PostgreSQLは強力なRDBMS", "Pythonは人気のプログラミング言語"],
metadatas=[{"category": "database"}, {"category": "programming"}],
ids=["doc1", "doc2"]
)
# 類似検索
results = collection.query(
query_texts=["データベース管理システム"],
n_results=10,
where={"category": "database"}
)
print(results)
LangChain統合¶
from langchain.vectorstores import Chroma
from langchain.embeddings import OpenAIEmbeddings
# Embedding関数
embeddings = OpenAIEmbeddings()
# ベクトルストア作成
vectorstore = Chroma(
collection_name="documents",
embedding_function=embeddings,
persist_directory="./chroma_db"
)
# ドキュメント追加
vectorstore.add_texts(
texts=["PostgreSQLは強力なRDBMS"],
metadatas=[{"category": "database"}]
)
# 類似検索
docs = vectorstore.similarity_search("データベース管理", k=5)
適用シナリオ¶
- プロトタイプ開発
- 小規模アプリケーション（〜10万件）
- LangChainベースの開発
- ローカル開発環境
5. Milvus¶
概要¶
Zillizが開発したエンタープライズ向け分散ベクトルデータベース。大規模運用に最適化されています。
特徴¶
メリット - 超大規模対応: 数十億ベクトルをサポート - 分散アーキテクチャ: 水平スケーリング - 高可用性: レプリケーション・フェイルオーバー - 多様なインデックス: 用途に応じた最適化 - クラウドサービス: Zilliz Cloudで簡単運用
デメリット - セットアップが複雑 - リソース要件が高い - 小規模では過剰スペック
技術詳細¶
from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType
# 接続
connections.connect(host="localhost", port="19530")
# スキーマ定義
fields = [
FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1536),
FieldSchema(name="content", dtype=DataType.VARCHAR, max_length=65535)
]
schema = CollectionSchema(fields, description="Documents collection")
# コレクション作成
collection = Collection(name="documents", schema=schema)
# インデックス作成
index_params = {
"metric_type": "L2",
"index_type": "IVF_FLAT",
"params": {"nlist": 1024}
}
collection.create_index(field_name="embedding", index_params=index_params)
# データ挿入
entities = [
[0.1, 0.2, ...], # embedding
["PostgreSQLは強力なRDBMS"] # content
]
collection.insert(entities)
# 検索
collection.load()
search_params = {"metric_type": "L2", "params": {"nprobe": 10}}
results = collection.search(
data=[[0.12, 0.23, ...]],
anns_field="embedding",
param=search_params,
limit=10
)
適用シナリオ¶
- 数億件以上のベクトルデータ
- エンタープライズ運用
- 高可用性が必須
- 複数データセンター展開
選択ガイド¶
規模別推奨¶
| データ規模 | 推奨データベース | 理由 |
|---|---|---|
| 〜10万件 | pgvector, ChromaDB | シンプル、運用コスト低 |
| 10万〜100万件 | pgvector, Qdrant | バランスの取れた性能 |
| 100万〜1000万件 | Qdrant, FAISS | 高速検索が必要 |
| 1000万件〜 | Milvus, FAISS | 分散・スケーラビリティ |
用途別推奨¶
社内RAGシステム¶
AIアプリケーション（SaaS）¶
研究・分析プロジェクト¶
プロトタイプ開発¶
ハイブリッド構成¶
実際のプロジェクトでは、複数のベクトルDBを組み合わせることもあります。
パターン1: pgvector + Qdrant¶
利点: - 通常のSQLクエリはpgvectorで高速処理 - 大量ベクトル検索はQdrantにオフロード
パターン2: FAISS (バッチ) + Qdrant (リアルタイム)¶
Docker Compose 構成例¶
pgvector + Qdrant¶
version: "3.9"
services:
# PostgreSQL with pgvector
postgres:
image: ankane/pgvector:latest
environment:
POSTGRES_USER: appuser
POSTGRES_PASSWORD: secret
POSTGRES_DB: vectordb
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
# Qdrant
qdrant:
image: qdrant/qdrant:latest
ports:
- "6333:6333"
- "6334:6334"
volumes:
- qdrant_data:/qdrant/storage
# FastAPI Application
api:
build: ./app
environment:
- DATABASE_URL=postgresql://appuser:secret@postgres:5432/vectordb
- QDRANT_URL=http://qdrant:6333
ports:
- "8000:8000"
depends_on:
- postgres
- qdrant
volumes:
postgres_data:
qdrant_data:
まとめ¶
選択フローチャート¶
データ量は？
├─ 〜10万件
│ └─ 既存PostgreSQL有り？
│ ├─ Yes → pgvector
│ └─ No → ChromaDB
│
├─ 10万〜100万件
│ └─ SQL統合重視？
│ ├─ Yes → pgvector
│ └─ No → Qdrant
│
└─ 100万件〜
└─ リアルタイム必要？
├─ Yes → Qdrant/Milvus
└─ No → FAISS
最終推奨¶
| 状況 | 第1選択 | 第2選択 |
|---|---|---|
| 初めてのRAG開発 | ChromaDB | pgvector |
| 既存システム統合 | pgvector | - |
| 本格的RAGアプリ | Qdrant | Milvus |
| 研究・分析 | FAISS | Qdrant |
| エンタープライズ | Milvus | Qdrant |
移行パス¶
ベクトルデータベースの選択は、プロジェクトの成長に合わせて変更できます。初期はシンプルなもので開始し、必要に応じてスケールアップしていくアプローチが推奨されます。