4. 主要データストアの比較と選定
データストアの重要性と分類
RAG システムにおいて、文書やそのベクトルデータをどこに保存し、どう検索するかを決定するデータストアの選定は極めて重要です。 検索速度、精度、インフラ運用の難易度、コストに直結するためです。
RAG で用いられるデータストアは、大きく次の4つに分類されます。
- ローカル・組込型: アプリケーション内やローカル環境で手軽に動く軽量ストア
- 特化型ベクトルデータベース: ベクトル検索に最適化された高性能エンジン
- 全文検索エンジン拡張: 強力な BM25 機能にベクトル検索機能を追加したエンジン
- リレーショナルデータベース拡張: 既存の RDBMS にベクトル検索拡張を追加したシステム
主要データストアの詳細比較
▸ Chroma
Chroma は、AI アプリケーション開発者向けに設計されたオープンソースの埋め込みベクトルストアです。
Python から pip install chromadb で即座に導入でき、SQLite をバックエンドにしてローカルで動作します。
-
メリット:
セットアップが非常に簡単で、外部サーバーを立てずにメモリまたはローカルディスク上で動かせます。 LangChain との統合が非常に手厚く、プロトタイプ作成や小中規模の開発を素早く開始できます。
-
デメリット:
大規模な分散処理や数千万件を超えるような大規模データには不向きです。 標準では高度な BM25 全文検索エンジンを備えておらず、純粋なベクトルストアとして動作します。
-
おすすめのユースケース:
個人開発、社内 PoC(概念実証)、ローカルで完結させたい小規模 RAG アプリケーション。
▸ FAISS (Facebook AI Similarity Search)
Meta(旧 Facebook)が開発した、超高速なベクトル類似度計算のためのライブラリです。 データベースというよりは計算アルゴリズムのライブラリであり、インメモリで高次元ベクトルを極限まで高速に探索します。
-
メリット:
世界最高峰の検索アルゴリズム(IVF、HNSW、PQ など)を搭載しており、CPU および GPU で極めて高速に動作します。 数十万〜数百万のベクトルを数ミリ秒で検索できる計算性能を誇ります。
-
デメリット:
CRUD(作成・読み取り・更新・削除)のデータ管理機能が貧弱で、永続化やメタデータ検索を自前で実装する必要があります。 BM25 のようなテキストキーワード検索機能は一切持っていません。
-
おすすめのユースケース:
静的なベクトルデータの一括検索、ミリ秒単位の超低レイテンシが求められる推薦システムや検索バックエンド。
▸ Qdrant
Qdrant は、Rust 言語で書かれたオープンソースの高性能ベクトル検索エンジンです。 ベクトルだけでなく、メタデータ(ペイロード)に基づく高度な絞り込み検索に強みがあります。
-
メリット:
Rust 製のためメモリ効率が良く、非常に高速です。 密ベクトルだけでなく「疎ベクトル(Sparse Vector)」にもネイティブ対応しており、Qdrant 単体でベクトル検索と BM25 相当のハイブリッド検索を完結できます。 Docker で簡単にセルフホストでき、クラウド版も提供されています。
-
デメリット:
Elasticsearch などの成熟した全文検索エンジンに比べると、日本語の高度な形態素解析辞書の細かなカスタマイズ機能は限定的です。
-
おすすめのユースケース:
単一のデータベースでハイブリッド検索を実現したい本格的な本番サービス、メタデータによる厳密な権限制御が必要なシステム。
▸ Pinecone
Pinecone は、ベクトル検索に特化した完全マネージド型のクラウドサービス(DBaaS: Database as a Service)です。
-
メリット:
サーバーの構築、クラスタ管理、バックアップなどのインフラ運用が一切不要です。 API を呼び出すだけで自動スケーリングし、数十億件規模のベクトル検索にも耐えられます。 疎ベクトルと密ベクトルを組み合わせたハイブリッド検索機能も標準で備えています。
-
デメリット:
完全にクラウドサービスであるため、データを社外のクラウドに出せない機密性の高い要件では利用できません。 データ量やクエリ数に応じた従量課金が発生するため、トラフィックが多い場合はコストが高くなる可能性があります。
-
おすすめのユースケース:
インフラ運用保守に人員を割きたくないチーム、素早く本番環境をスケールさせたいスタートアップや Web サービス。
▸ Milvus
Milvus は、Linux Foundation 傘下で開発されているオープンソースの大規模分散ベクトルデータベースです。
-
メリット:
数十億件から数百億件の巨大なベクトルデータを水平分散して処理できる圧倒的なスケーラビリティを備えています。 エンタープライズ向けのクラスタ運用機能が充実しています。
-
デメリット:
Kubernetes、etcd、MinIO、Pulsar など多くのミドルウェアを必要とするため、自前でのクラスタ構築と運用保守の難易度が非常に高いです。 小規模なシステムで導入すると過剰な構成になります。
-
おすすめのユースケース:
大規模なエンタープライズ基盤、数千万件以上の文書を扱う巨大な企業内データレイクの RAG 基盤。
▸ Elasticsearch / OpenSearch
Elasticsearch およびそのフォークである OpenSearch は、長年世界中で使われてきた分散型全文検索エンジンのデファクトスタンダードです。
-
メリット:
BM25 アルゴリズムの本家であり、日本語形態素解析(kuromoji、Sudachi 等)の辞書管理やカスタマイズ機能が極めて成熟しています。 近年のバージョンでは HNSW アルゴリズムによるベクトル検索(k-NN)にも対応しており、伝統的な全文検索とベクトル検索を最高品質で両立できます。
-
デメリット:
Java 仮想マシン(JVM)上で動作するため、大量のメモリを消費します。 検索設定やクラスタ運用のパラメータが多く、学習コストと運用負荷が高めです。
-
おすすめのユースケース:
高度な日本語全文検索とベクトル検索を高いレベルで両立したい本番システム、既存のログ・検索基盤を活用したい環境。
▸ PostgreSQL (pgvector)
世界で最も普及しているオープンソース RDBMS の一つである PostgreSQL に、ベクトル検索機能を追加する拡張機能が pgvector です。
-
メリット:
通常の業務テーブル(ユーザー情報、注文情報、権限テーブルなど)と同じデータベース内でベクトルを管理できます。 SQL の
JOINやWHERE句を使った完全なトランザクション整合性とメタデータ検索が可能です。 新しいデータベースを導入・運用する必要がありません。 -
デメリット:
特化型ベクトル DB や FAISS と比べると、数百万件を超える大規模データでの検索速度やスループットは劣ります。 PostgreSQL 標準の全文検索機能(pg_trgm や to_tsvector)は日本語の BM25 と比較すると精度面で見劣りします。
▸ SQLite FTS5 (組み込みBM25エンジン)
Python 3 に標準搭載されている SQLite の全文検索モジュール(Full-Text Search 5)です。
外部サーバーの立ち上げや重い外部ライブラリのインストールが不要で、単一の .db ファイル上で C 言語レベルの高速な BM25 スコアリングを実行できます。
-
メリット:
Python 標準ライブラリのみで動作し、外部依存がゼロです。 数百万件規模のテキストであっても、ディスクベースと OS ページキャッシュにより常駐メモリ数十 MB・検索レイテンシ数ミリ秒で動作します。
-
デメリット:
ベクトル検索(密ベクトル)機能は標準で持たないため、ベクトル検索と併用する場合は Chroma などのベクトルストアと組み合わせる必要があります。 また、標準トークナイザー(unicode61)では日本語を単語分割できないため、文字バイグラム(2-gram)等の前処理を自前で実装する必要があります。
-
おすすめのユースケース:
外部サービスや外部ミドルウェアに依存したくないローカル/デスクトップアプリ、数百万件規模の大規模テキストに対する低リソース・高速なキーワード辞書引き(詳細は第9章の実践事例を参照)。
主要データストアの比較一覧表
各データストアの特性を一覧表にまとめます。
| データストア | 分類 | ホスティング形態 | BM25・疎検索 | 検索速度 | 運用負荷 | 主なメリット | 主なデメリット |
|---|---|---|---|---|---|---|---|
| Chroma | 組込型 | ローカル / 自前 | △ (外部連携) | 中 | 最小 | インストール即起動、軽量 | 大規模分散に不向き |
| FAISS | ライブラリ | インメモリ / 自前 | × (非対応) | 超高速 | 低〜中 | 圧倒的な計算速度、GPU対応 | CRUD・永続化が自前 |
| SQLite FTS5 | 組込型 | ローカル / 単一DB | ◯ (組み込みBM25) | 高速 | ゼロ | ゼロ外部依存、省メモリ | 単体ではベクトル非対応 |
| Qdrant | 特化型 | 自前 / クラウド | ◯ (疎ベクトル) | 高速 | 中 | Rust製で高速、疎密両対応 | 形態素辞書の調整が限定的 |
| Pinecone | 特化型 | 完全クラウド | ◯ (疎ベクトル) | 高速 | ゼロ | 運用不要、自動スケール | クラウド限定、従量課金 |
| Milvus | 特化型 | 分散クラスタ | △ (外部連携) | 高速 | 非常に高 | 数十億件へのスケーラビリティ | 構成要素が多く運用が複雑 |
| Elasticsearch | 全文検索 | 自前 / クラウド | ◎ (最高峰BM25) | 高速 | 高 | 成熟したBM25と日本語辞書 | メモリ消費大、設定が複雑 |
| PostgreSQL | RDBMS拡張 | 自前 / クラウド | △ (LIKE/trgm) | 中 | 低 (既存活用) | 既存SQL・テーブルと結合可能 | 大規模での性能限界 |
データストア選定のガイドライン
システムの要件に応じて、次の基準で選定することをおすすめします。
-
プロトタイプ作成や手元の検証: 手軽さを最優先し、
ChromaまたはFAISSを採用します。 -
インフラ運用を避けたいクラウド本番環境: 完全マネージドな
Pineconeまたは Qdrant Cloud を採用します。 -
既存の業務システムへの RAG 組み込み: 既存のデータベースが PostgreSQL であれば、まずは
pgvectorを導入するのが最も低コストです。 -
単一ストアで高品質なハイブリッド検索(BM25 + ベクトル)を実現したい場合: 日本語辞書の細かな制御を重視するなら
Elasticsearch、最新の特化型ベクトル検索エンジンならQdrantを選択します。 -
外部依存なしで大規模テキストの高速 BM25 検索をローカル完結させたい場合: Python 標準の
SQLite FTS5を採用し、バイグラム展開と組み合わせることで、省メモリかつミリ秒応答の検索環境を実現できます(第9章・第10章を参照)。
次章からは、Python と LangChain を使って、これらを組み合わせた検索パイプラインを実際に実装していきます。