リレーショナルデータベース（RDB）は、項目が決まったデータを表で管理し、指定した条件に合う情報を取り出す用途に向いています。
ベクトルデータベース（ベクトルDB）は、文章や画像などの特徴を数値の並びで表し、意味や特徴が近い候補を探す用途に向いています。
両者は優劣で選ぶものではありません。必要なのが厳密な条件検索なのか、類似性を使った検索なのかを整理すると、選択しやすくなります。
RDBとベクトルDBの違い
| 比較項目 | リレーショナルデータベース | ベクトルデータベース |
|---|---|---|
| 保存する形 | 行と列で構成したテーブル | 特徴を表す数値ベクトル |
| 代表的な検索 | IDや日付、数値などを使った条件検索 | ベクトル間の近さを使った類似検索 |
| 扱いやすい情報 | 顧客情報、在庫数、購入履歴など、項目が決まったデータ | テキスト、画像、音声などを数値化したデータ |
| 検索結果の意味 | 指定した条件に一致するレコード | 質問や対象に近い候補 |
| 主な用途 | 顧客管理、会計、在庫管理など | 質問応答、商品推薦、類似画像検索など |
表にある違いは、典型的な使い方を比べたものです。
一つのシステムで両方の検索が必要なら、RDBとベクトルDBを役割ごとに使い分ける構成も選べます。
リレーショナルデータベースの仕組み
リレーショナルデータベースは、データを行と列からなるテーブルに整理し、テーブル同士の関係をキーで表す仕組みです。
一行分のデータを「レコード」、項目ごとの列を「カラム」と呼びます。
各レコードを識別する主キーや、別のテーブルを参照する外部キーを使うと、顧客情報と購入履歴のように分かれたデータを関連付けられます。
| 顧客ID | 名前 | 購入回数 |
|---|---|---|
| C001 | 山田太郎 | 12 |
| C002 | 佐藤花子 | 5 |
たとえば「購入回数が10回以上の顧客」という条件を指定すれば、この例ではC001のレコードを取り出せます。
SQL（Structured Query Language）は、テーブルの検索、追加、更新、集計などをデータベースへ指示するための言語です。
RDBが向いている用途
- 顧客情報をIDで検索する
- 日付や金額などの条件で取引を絞り込む
- 商品の在庫数を更新する
- 複数のテーブルを関連付けて集計する
RDBの具体的な製品を比べたい場合は、MySQLとPostgreSQLの違いと利用時の注意点も参考になります。
ベクトルデータベースの仕組み
ベクトルデータベースは、対象の特徴を数値ベクトルとして扱い、ベクトル同士の近さから似た候補を探すためのデータベースです。
ベクトルとは、ここでは対象の特徴を表す数値の並びを指します。
文章、画像、音声などをこの形へ変換する処理が「ベクトル化」です。
「軽くて丈夫なランニングシューズ」 → [0.21, -0.54, 0.13, …, 0.87]利用者が別の表現で商品を探しても、その検索文を同じようにベクトル化し、商品説明のベクトルと比較すれば、特徴が近い候補を探せます。
近さを測る代表的な方法には、ベクトルの向きの近さを見るコサイン類似度や、点同士の距離を見るユークリッド距離があります。
ベクトルDBが向いている用途
- 質問文に近いFAQを探す
- 説明や特徴が似た商品を候補として示す
- 見た目の特徴が近い画像を探す
- 音声の特徴を使って候補を探す
類似検索が返すのは、条件に完全一致した答えではなく、数値上の近さに基づく候補です。
どの特徴を数値化し、どの類似度を使うかによって結果は変わるため、近い候補が目的に合っているかは用途に沿って確認する必要があります。
検索基盤の構成例を広げて検討する場合は、Amazon OpenSearch Serviceと他の検索サービスの比較も参照できます。
用途から選ぶための判断基準
製品名から選び始める前に、システムが返すべき結果を整理します。
- 条件に一致するデータが必要か
顧客ID、日付、金額、在庫数などを条件として正確に絞り込みたいなら、RDBが基本です。 - 意味や特徴が近い候補を探したいか
言い回しの異なる質問や、特徴が似た商品や画像を探したいなら、ベクトルDBが候補になります。 - 両方の検索が必要か
類似検索で候補を見つけ、その候補にひも付く顧客情報や回答を条件検索で取得するなら、両者の併用を検討します。
システムが複雑だからという理由だけで、両方を導入する必要はありません。
必要な検索が一種類なら、役割に合うデータベースへ絞ったほうが構成を理解しやすくなります。
RDBとベクトルDBを併用する例
問い合わせ対応の仕組みを例にすると、両者の役割分担が明確になります。
- RDBに顧客情報、問い合わせID、回答、担当者などを保存する。
- 問い合わせ文をベクトル化し、ベクトルDBで検索できるようにする。
- 新しい質問をベクトル化し、内容が近い過去の問い合わせIDを探す。
- 見つかったIDを使い、RDBから回答や担当者などの詳細を取得する。
この構成では、ベクトルDBが似た問い合わせを探し、RDBがその問い合わせにひも付く構造化データを返します。
「意味が近い候補を見つける処理」と「条件に合う詳細を取り出す処理」を分けることで、それぞれのデータベースが得意な検索を担当できます。
選択の結論
- 業務データを表で管理し、IDや数値などの条件で検索するならRDBを選ぶ。
- 文章や画像などの意味や特徴が近い候補を探すならベクトルDBを選ぶ。
- 類似検索の結果と顧客情報や回答などを結び付けるなら、両者を併用する。
最初に決めるべきなのはデータベースの種類ではなく、利用者が何を入力し、システムがどのような結果を返す必要があるかです。
必要な検索を条件検索と類似検索に分ければ、RDB、ベクトルDB、または両者の併用を判断できます。