データベースの基礎——RDB vs NoSQLの選択基準と使い分け

データベースの選択はシステム設計における最も重要な意思決定の一つだ。誤った選択は後からの修正コストが高く、パフォーマンス問題や開発の非効率につながる。リレーショナルデータベース（RDB）とNoSQLは「どちらが優れているか」という問いに答えがあるのではなく、それぞれが異なる問題を解決するために設計されている。

リレーショナルデータベース（RDB）の特性

RDBはEdgar Coddが1970年に提唱したリレーショナルモデルに基づく。データをテーブル（関係）として表現し、テーブル間の関係をJOINで結合することで柔軟なクエリを実現する。PostgreSQL、MySQL、Oracle、SQL Serverが代表的なRDBだ。

ACID特性

RDBの最大の強みはACID特性だ。

Atomicity（原子性）: トランザクション内のすべての操作が成功するか、すべて失敗するかのどちらかだ。銀行の送金処理で「口座Aから引き落とし」と「口座Bへの入金」は不可分な単位として扱われる。

Consistency（一貫性）: トランザクションの前後でデータベースは常に整合した状態を保つ。外部キー制約や一意性制約などのルールが自動的に強制される。

Isolation（分離性）: 複数のトランザクションが並行実行されても、互いに影響を与えない。適切な分離レベル（READ COMMITTED、REPEATABLE READなど）を選択することで、ダーティリードやファントムリードを防ぐ。

Durability（永続性）: コミットされたトランザクションはシステム障害が発生してもデータが失われない。WAL（Write-Ahead Logging）などの仕組みで実現される。

この4特性により、金融取引、在庫管理、予約システムなど、データの整合性が絶対的に重要な用途でRDBは強みを発揮する。

正規化とスキーマ設計

RDBはデータの冗長性を排除する「正規化」の原則に従う。同じ情報を複数の場所に持たないことで更新異常を防ぐ。一方でスキーマ（テーブル定義）を事前に設計する必要があり、後からの変更にはALTER TABLE操作が必要になる。大規模テーブルへのカラム追加はダウンタイムのリスクを伴う場合もある。

NoSQLデータベースの種類と特性

NoSQL（Not Only SQL）は「RDB以外のデータベース」の総称で、内部構造や用途によって大きく4種類に分類できる。

ドキュメントDB（MongoDB、Firestore）

JSONに似た形式（BSON）でドキュメントを保存する。スキーマが柔軟で、フィールドが異なるドキュメントを同じコレクションに格納できる。ECサイトの商品データ（属性が商品カテゴリによって大きく異なる）、CMS、ユーザープロファイルなど、データ構造が不規則なケースに向いている。

欠点: JOIN操作が苦手。参照整合性がRDB比で弱い。

キーバリューDB（Redis、DynamoDB）

キーと値のシンプルな構造でデータを保存する。メモリ上でデータを管理するRedisは読み書きが極めて高速で、セッション管理、キャッシング、ランキング（Sorted Set）などに使われる。

Redisは文字列だけでなく、リスト、セット、ソート済みセット、ハッシュなどのデータ構造をネイティブにサポートする。TTL（有効期限）を設定できるため、一時的なデータ管理に最適だ。

カラム指向DB（Cassandra、HBase）

データを行ではなく列（カラム）単位で保存する。大量の書き込みと読み取りを低レイテンシで処理できる。IoTのセンサーデータ、ログ分析、時系列データなど、時刻+測定値というシンプルなパターンで大量に発生するデータに向いている。

Cassandraはリングトポロジーで複数ノードにデータを分散し、単一障害点がないため高い可用性を実現する。一方でJOINやトランザクションは限定的だ。

グラフDB（Neo4j、Amazon Neptune）

ノードとエッジでデータを表現する。「友人の友人」「商品の推薦」「不正検出」など、エンティティ間の関係性を深く辿るクエリが必要な場合にRDBよりも大幅に高速だ。ソーシャルネットワーク分析、知識グラフ、レコメンデーションエンジンに使われる。

CAP定理

分散データベースの性質を理解するためにCAP定理は重要だ。

Consistency（一貫性）: すべてのノードが同じデータを返す Availability（可用性）: すべてのリクエストが応答を受け取れる Partition tolerance（分断耐性）: ネットワーク分断が起きても動作し続ける

CAP定理はこの3要素のうち、同時に保証できるのは2つまでであると主張する。ネットワーク分断（P）は実際には避けられないため、実質的にCPかAPかの選択になる。

RDBは伝統的にCP（一貫性と分断耐性）を優先する。Cassandraはデフォルトでは可用性を優先するが、一貫性レベルを設定で変更できる。

AIアプリでのVector DB選択

生成AIアプリケーションでは**ベクターデータベース（Vector DB）**が重要な役割を果たす。LLMは文章をベクトル（高次元の数値配列）に変換する。RAG（Retrieval-Augmented Generation）では、ユーザーの質問をベクトル化し、意味的に近いドキュメントを検索してLLMへのコンテキストとして提供する。

Pinecone、Weaviate、Qdrant、pgvector（PostgreSQL拡張）が代表的だ。ANN（Approximate Nearest Neighbor）アルゴリズムを使って、高次元空間での最近傍検索を高速に行う。既存のRDBにpgvectorを導入するか、専用のVector DBを選ぶかは、既存インフラとデータ規模によって判断する。

選択基準の整理

実際のプロジェクトでは複数のDBを組み合わせるポリグロット永続化が一般的だ。注文データはPostgreSQL、セッションはRedis、商品説明の全文検索はElasticsearch、RAG用ベクトルはpgvectorというような構成が現実的な選択肢となる。

まとめ

RDBはACID特性と正規化による整合性保証が強みで、トランザクション処理が必要なシステムに不可欠だ。NoSQLはドキュメント・キーバリュー・カラム指向・グラフという4種類があり、それぞれ異なる課題を解決する。CAP定理は分散システムの設計トレードオフを示す重要な原則だ。AIアプリケーションではVector DBが新たな重要コンポーネントとして加わった。「最適なDB」は存在せず、要件に応じた適切な選択と、複数DBの組み合わせが現代のシステム設計の基本だ。