2025年8月20日·2 分
データベースの種類：リレーショナル、カラム型、ドキュメント、グラフ＆その他
主要なデータベースの種類（リレーショナル、カラム型、ドキュメント、グラフ、ベクター、キー・バリューなど）を、ユースケース、トレードオフ、選び方のポイントとともに比較します。
主要なデータベースの種類（リレーショナル、カラム型、ドキュメント、グラフ、ベクター、キー・バリューなど）を、ユースケース、トレードオフ、選び方のポイントとともに比較します。
「データベースの種類」とは単なるラベルではなく、システムがデータをどのように格納するか、どのように問い合わせるか、何に最適化されているかを示す略語です。選択は速度（何が速く、何が遅いか）、コスト（ハードウェアやクラウド費用）、機能（トランザクション、分析、検索、レプリケーションなど）に直接影響します。
データベースの種類ごとに異なるトレードオフがあります：
これらの設計選択は次を左右します：
この記事では主要なデータベースの種類を順に説明し、各種について：
近年の多くの製品は境界を曖昧にしています。リレーショナルDBがJSONサポートを追加してドキュメントDBに近づいたり、検索・分析プラットフォームがベクターインデクシングを提供したり、ストリーミングと保存を組み合わせて時系列機能を持つものもあります。
だから「タイプ」は厳密な箱というより、デフォルトの強みやそのデータベースが得意とするワークロードを理解するための有用な指標です。
まずは主要なワークロードからスタート：
その後、「適切なデータベースの選び方」セクションで、スケール、整合性の必要性、よく実行するクエリに基づいて絞り込んでください。
リレーショナルDBは「データベース」と聞いて多くの人が思い浮かべるものです。データはテーブルに整理され、行（レコード）と列（フィールド）で構成されます。スキーマは各テーブルの構造（どの列があり型は何か、テーブル同士の関係）を定義します。
リレーショナルは通常**SQL（Structured Query Language）**で問い合わせられます。SQLは読みやすく表現力が高い点で普及しています：
WHERE, ORDER BY）。JOIN）。GROUP BY）。多くのレポーティングツールや分析プラットフォーム、業務アプリがSQLをサポートしているため、互換性の観点で安全な出発点です。
リレーショナルDBはACIDトランザクションで知られており、データの正確性を保ちます：
これは課金の二重請求や在庫の消失といったミスのコストが高い場面で重要です。
リレーショナルDBは通常、構造化され明確なデータと次のようなワークフローに向きます：
信頼性を生む構造が摩擦になることもあります：
データモデルが常に変化する、あるいは単純なアクセスパターンで極端な水平スケールが必要な場合は、別のタイプがより適することがあります。
カラム型DBは「行ごと」ではなく「列ごと」にデータを格納します。この違いが分析ワークロードでの速度とコストに大きな影響を与えます。
従来の行ストア（リレーショナル）は、1つのレコードのすべての値が一箇所にまとまっています。顧客や注文を1件単位で頻繁に取得・更新する用途に向いています。
カラムストアでは同一フィールドのすべての値がまとまって格納されます。つまりすべてのprice、すべてのcountry、すべてのtimestampが並ぶ形になり、レポートで必要な少数列だけを効率的に読み取れます。
分析やBIのクエリは多くの場合：
SUM、AVG、COUNT、次元ごとの集約を計算するカラム型は読み取るデータ量が少なく済み、似た値が連続するため圧縮効率が高くなります。多くのカラムエンジンはベクトル化実行や賢いインデックス／パーティショニングで大規模スキャンを高速化します。
ダッシュボードやレポーティングで威力を発揮します：
「週ごとの収益」「地域別上位20商品」「チャネル別コンバージョン率」「過去30日のサービス別エラー数」など、多くの行に触れるが列は少ないクエリです。
ワークロードが「IDで1件取得」や「1行を何度も更新する」中心だと、カラム型は遅く感じたりコストが上がったりします。書き込みはバッチ（追加中心）の最適化がされており、頻繁で小さな更新は不得意な場合が多いです。
カラム型は次に強い：
大量データの集計を高速化したいなら、まず評価すべきタイプです。
ドキュメントDBはデータを「ドキュメント」（JSONに似た自己完結型のレコード）として保存します。多くの情報を複数テーブルに分割せず、関連するフィールドを1つのオブジェクトにまとめて置けるのが特徴です。
ドキュメントはユーザー、商品、記事などを表現できます。各ドキュメントは属性が異なっても構わず、ある商品にsizeとcolorがあり、別の商品にdimensionsとmaterialsがあっても統一スキーマを強制しません。
この柔軟性は要件が頻繁に変わるケースや、アイテムごとに異なるフィールドがある場面で役立ちます。
全ドキュメントをスキャンしないように、ドキュメントDBはインデックスを使います。一般的な検索フィールド（email、sku、status）をインデックス化でき、多くのシステムはネストしたフィールド（address.city）のインデックスもサポートします。インデックスは読み取りを速くしますが、更新時にインデックスを更新するオーバーヘッドが発生します。
ドキュメントDBはスキーマの進化、ネストデータ、APIに適したペイロードに強みがあります。トレードオフは：
コンテンツ管理、商品カタログ、ユーザープロフィール、バックエンドAPIなど、「画面やリクエストごとに1つのオブジェクト」が自然に対応する用途に向いています。
キー・バリューストアは最も単純なデータモデルです：値（文字列やJSONブロブなど）を保存し、ユニークなキーで取り出します。コア操作は「このキーの値をくれ」という1種類の操作であるため、非常に高速に最適化できます。
読み書きが単一のプライマリキーを中心に行われるため、低レイテンシと高スループットに特化できます。多くはホットデータをメモリに載せ、複雑なクエリプランニングを避け、水平スケールに対応します。
この単純さはデータモデリングにも影響します：データベースに「ベルリンにいる今週登録した全ユーザーを探せ」と問うのではなく、取得したいレコードを直接指すキー（例：user:1234:profile）を設計する形になります。
キー・バリューストアはキャッシュとしてよく使われます。アプリが同じデータを繰り返し必要とする場合、キーでキャッシュしておけば再計算や再問い合わせを避けられます。
またセッションストレージにも適しています（例：session:<id> -> session data）。セッションは頻繁に読み書きされ、TTLで自動的に期限切れにできるため相性が良いです。
多くのKVストアはTTL（有効期間）をサポートし、セッションやワンタイムトークン、レートカウンタに便利です。メモリが限られる場合はエビクションポリシー（LRUなど）で古いエントリを削除します。製品によってはメモリ優先型、あるいは耐久性のためにディスク永続化を行うものがあります。選択は速度（メモリ）と保持・回復（ディスク）とのトレードオフです。
キーが既知であればKVは強力です。逆にオープンエンドな検索には向きません。二次インデックスのサポートは製品ごとに幅があり、提供される範囲は様々です。
キー・バリューストアは以下に向きます：
アクセスパターンが「IDで取得・更新」でレイテンシが重要なら、KVは簡潔かつ信頼性ある速度を提供します。
ワイドカラムDB（wide-column store）はデータをカラムファミリに整理します。全行が同じ固定列を持つという考え方ではなく、ファミリごとに関連列をまとめ、行ごとに異なる列セットを持てるのが特徴です。
名前は似ていますが、**カラム型（分析）とワイドカラム（運用）**は別の目的です。
ワイドカラムは次を重視します：
一般的なパターンは：
この構造は時系列や追加中心のワークロードに適しています。
ワイドカラムはクエリ駆動のデータモデリングを要求します。必要なクエリに合わせてテーブル設計を行うため、異なるアクセスパターンをサポートするためにデータを複製することが一般的です。結合は限られ、柔軟なアドホッククエリ性は期待しづらいです。
IoTイベント、メッセージング／アクティビティストリーム、大規模な運用データなど、高速書き込みとキーに基づく予測可能な読み取りが重要な場面に向いています。
グラフDBは多くの実世界システムが振る舞う通りに、ものとものがつながっていることをそのまま表現します。関係をテーブルや結合テーブルに押し込む代わりに、接続そのものをモデルに組み込みます。
グラフは通常：
これによりネットワークや階層、多対多の関係を自然に表現できます。
関係重視のクエリはリレーショナルDBでは多くのJOINを必要とします。JOINが増えるごとにデータ増加時のコストと複雑さが増します。
グラフDBは**トラバース（巡回）**に最適化されており、「あるノードからつながるノードをたどり、さらにその先へ」といった問い合わせがネットワークの規模に対しても読みやすく高速に保たれることが多いです。
グラフが強いのは：
チームにとってデータモデリングの考え方が変わる点や、クエリ言語（Cypher、Gremlin、SPARQL）が新しい学習項目になる点に注意してください。関係の種類や方向の運用ルールを明確にしておかないとモデルが崩れやすくなります。
関係が単純で、フィルタや集計が中心、数回のJOINで済むなら、リレーショナルDBの方が経済的で実装しやすいことが多いです。トランザクションやレポーティングがうまく機能しているなら、無理にグラフに置き換える必要はありません。
ベクターデータベースは「この項目に最も近いものはどれか？」という問いに特化しています。LLMや埋め込み生成モデルが作る数値表現（テキスト、画像、音声、製品などの埋め込み）を扱い、意味的に類似する項目は高次元空間で近くに配置されます。
従来のキーワード検索は語彙が異なると結果を取りこぼします（例：「laptop sleeve」と「notebook case」）。埋め込みを使えば意味に基づく類似性で関連結果を返せます。
主要な操作は最近傍検索（nearest neighbor search）：クエリベクトルに対して最も近いベクトルを取得します。
実アプリでは通常、類似検索にフィルタを組み合わせます：
この「フィルタ＋類似度」パターンにより、ベクトル検索は実用的になります。
ベクトル検索は専用インデックスに依存します。インデックス構築・更新に時間がかかり、メモリ消費も大きくなることがあります。リコール重視（真に良い一致を多く返す）と低レイテンシ（高速応答）のトレードオフが生じます。
ベクトルDBが単体でソースオブトゥルースを置き換えることは稀です。一般的な構成は、元データ（注文・ユーザー・ドキュメント）をリレーショナルやドキュメントDBに保持し、埋め込みと検索インデックスはベクトルDBに置き、検索結果を主DBと結合して完全なレコードや権限情報を取得する形です。
時系列DB（TSDB）は、継続的に到着し常にタイムスタンプに紐づくデータを扱うために設計されています。例：10秒ごとのCPU使用率、各リクエストのAPIレイテンシ、分毎のセンサ読み取り、ミリ秒単位で変動する株価など。
多くの時系列レコードは次を組み合わせます：
この構造により「サービス別のエラー率を表示」「リージョン間のレイテンシ比較」といった問いが簡単になります。
データ量が急増するため、TSDBは通常次の機能を重視します：
これによりストレージとクエリコストを予測可能に保てます。
時系列DBは次の計算に向きます：
監視、オブザーバビリティ、IoT／センサデータ、金融のティックデータなどに典型的に使われます。一方で、多数のエンティティ間で複雑なアドホック結合を行う用途（例：「users → teams → permissions → projects」のような深い結合）には向きません。その場合はリレーショナルやグラフの方が適しています。
データウェアハウスは単一の「データベースの種類」ではなく、むしろワークロードとアーキテクチャです：多くのチームが大規模な履歴データをクエリしてビジネスの問いに答える（収益傾向、チャーン、在庫リスクなど）。マネージド製品として提供されることもありますが、本質は中央集権的で分析志向の使われ方にあります。
多くのウェアハウスは次の2つの方法でデータを受け入れます：
ウェアハウスは分析に最適化するために：
複数部門が同じ数値に依存するようになると、アクセス制御（誰が何を見られるか）、監査ログ（誰がいつクエリ／変更したか）、系譜（lineage）（指標がどこから来てどう変換されたか）が必要になります。これらはクエリ速度と同じくらい重要です。
レイクハウスはウェアハウスの分析性とデータレイクの柔軟性を組み合わせます。キュレーションされたテーブルと生データ（ログ、画像、半構造化イベント）を1箇所に置きつつ、SQLライクに扱いたい場面で有用です。データ量が多く、フォーマットが多様で、SQLでの分析も必要なときに適します。
データベース選びは「どれがベストか」ではなく「何に合っているか」が重要です：どうクエリするのか、どれだけ速く必要か、システムの一部が故障したときどう振る舞うかを基に判断します。
簡単な目安：
リレーショナルはOLTPで強く、カラム型／ウェアハウス／レイクハウスはOLAPでよく使われます。
ネットワーク分断が起きたとき、同時に3つ全部を完璧に満たすことはできません：
多くの分散DBは分断時に可用性を優先して後で整合させる（最終的整合性）戦略を取るか、厳密な正しさを優先して一時的にリクエストを拒否するか、どちらかを選びます。
多くのユーザーが同じデータを更新するなら明確なルールが必要です。トランザクションは複数ステップを「全部成功／全部失敗」にまとめます。ロックやアイソレーションレベルは競合を防ぐがスループットを下げる。緩いアイソレーションは高速だが異常が許容される場合もあります。
バックアップ、レプリケーション、ディザスタリカバリは早めに計画してください。復元テスト、レプリケーション遅延の監視、アップグレード手順の容易さなど、運用の“Day 2”課題はクエリ速度と同等に重要です。
主要なデータベースの種類の選択は流行よりも「データで何をしたいか」に基づきます。実践的な開始方法は、クエリとワークロードから逆算することです。
アプリやチームが最も行う上位5–10の操作を紙に書き出してください：
これで選択肢が絞れます。
簡易的な「形」チェックリスト：
性能目標を（p95レイテンシ、RPS、データ保持期間など）ざっくり決めてください。コストは通常：
| 主な用途 | よく合う選択 | 理由 |
|---|---|---|
| トランザクション、請求、ユーザー管理 | リレーショナル（SQL） | 制約、結合、一貫性に強い |
| フィールドが変わるアプリデータ | ドキュメント | 柔軟なスキーマ、JSONに自然に対応 |
| リアルタイムキャッシュ／セッション | キー・バリュー | キーでの高速参照 |
| クリックストリーム／時間経過を扱う指標 | 時系列 | 大量取り込み＋時間クエリに最適 |
| BIダッシュボード、大規模集計 | カラム型 | 高速スキャン＋圧縮 |
| ソーシャルやナレッジの関係性 | グラフ | 関係の巡回が効率的 |
| セマンティック検索、RAG | ベクター | 埋め込みの類似検索 |
| 大規模運用データ | ワイドカラム | 水平スケール、予測可能なクエリ |
多くのチームは**運用用DB（例：リレーショナル）と分析用DB（例：カラム型／ウェアハウス）**を併用します。最も重要なのは、あなたの最重要クエリを最も簡単かつ高速かつ安価に実行できる選択をすることです。
プロトタイプや新機能を高速に出す場合、DB選択は開発ワークフローと結び付きます。たとえば、Koder.ai のようなプラットフォームは具体例を与えてくれます：Koder.ai のデフォルトバックエンドは Go + PostgreSQL で、トランザクションの正確性と豊富なSQLツールチェーンが必要なときの良い出発点です。
プロダクトが成長したら、ベクトルDBでセマンティック検索を追加したり、分析のためにカラム型ウェアハウスを導入したりといった形で専門的なDBを増やしていくことができます。重要なのは今日サポートすべきワークロードから始め、クエリパターンが要求する場合に2つ目のストアを追加する余地を残しておくことです。
「データベースの種類」は概ね次の3つを指す略語です：
種類を選ぶということは、パフォーマンス、コスト、運用のデフォルトを決めることに他なりません。
まずは上位5〜10件の主要な読み取り／書き込みパターンを書き出してください。そこからマッチする強みを当てはめます：
運用データと分析を両方やるなら、最初から運用DB＋分析DBの併用を検討してください。
次のような場合にリレーショナルが強い選択です：
ただし、スキーマ変更が頻繁だったり、ジョインが多くシャーディングが必要な極端な水平スケールが求められる場合は負担になります。
ACIDはマルチステップの変更を信頼できる形で扱うための保証です：
支払い処理、予約、在庫更新など、間違いのコストが高いワークフローで特に重要です。
カラム型が速い理由は次の通りです：
SUM、COUNT、、 のような集約を効率的に処理できるドキュメントDBが向くのは次のような場合です：
注意点：複雑な結合や、読み取りのために意図的にデータ冗長化する設計（更新時の整合性管理）が必要になることがあります。
キー・バリューストアは主に次の用途で強みを発揮します：
欠点は汎用的な検索や副次インデックスが弱いこと。必要に応じて自前でルックアップキーを設計することが多いです。
名前が似ているため混同しやすいですが用途が異なります：
ワイドカラムはクエリ駆動のモデリングを要し、柔軟なSQL的結合を期待するワークロードには不向きです。
コアとなる問いが“関係”に関するものならグラフDBが適しています：
グラフはトラバース（連結ノードを辿る処理）に最適化されており、同等の処理をリレーショナルで行うと多数のJOINが必要になります。代わりにデータモデルやクエリ言語（Cypher／Gremlin／SPARQL）に慣れる必要があります。
ベクトルDBは埋め込み（embeddings）による類似検索を解くためのものです。典型的な用途：
通常はメインのソースオブトゥルース（注文、ユーザー、ドキュメント）はリレーショナル／ドキュメントDBに置き、埋め込みとインデックスだけをベクトルDBに置いて結果を結合して使います。ベクトルDBがメインDBを置き換えることはほとんどありません。
AVGGROUP BY逆に、頻繁な小さな更新や「IDで1件取得」のようなOLTPパターンは苦手です。