リレーショナル対ドキュメントモデル

# リレーショナル対ドキュメントモデル ## 定義リレーショナルモデルとドキュメントモデルは、アプリケーションデータを構造化する2つの代表的な方式である。リレーショナルモデル(SQL、Edgar Codd, 1970年)はデータを*リレーション*(テーブル)の集合として組織し、各リレーションは*タプル*(行)の順序を持たない集合として表現する。ドキュメントモデルは、NoSQLムーブメントの持続的な効果として普及した方式で、データを自己完結的なJSONドキュメントとして表現する([[MongoDB]]・Couchbase等が代表実装)。両者の選択は、データの関係構造(一対多か多対多か)・スキーマの厳格さの要否・クエリパターンに応じたトレードオフの問題であり、優劣が固定的に決まるものではない。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "Relational Versus Document Models") ## オブジェクト-リレーショナルミスマッチオブジェクト指向のアプリケーションコードとリレーショナルモデルの間に生じる変換層の不整合を*impedance mismatch*と呼ぶ(電子工学における入出力インピーダンスの不整合という語の借用)。ORM(ActiveRecord、Hibernate等)はこの変換のボイラープレートを削減するが、以下のような固有の問題を抱える。 - N+1クエリ問題: N件のコメントそれぞれの投稿者情報を個別にクエリしてしまい、本来1回の結合で済む処理がN+1回のクエリになる。 - ORMは主にOLTP用途のリレーショナルDBのみを対象とし、検索エンジン・グラフDB・NoSQLシステムなど多様なデータ基盤を持つ組織ではサポートが不足しがちである。 - 自動生成されるスキーマがリレーショナルデータへ直接アクセスするユーザーにとって非効率・扱いにくい場合がある。一方でORMは、キャッシング・スキーママイグレーション管理といった付随的な利便性も提供する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "The Object-Relational Mismatch") ## 一対多関係とドキュメントの木構造 résumé(LinkedInプロフィール)のような、ポジション・学歴・連絡先が1人のユーザーに紐づく一対多関係(*one-to-few*とも呼ばれる)は、JSONドキュメントとして自然な木構造で表現できる。ドキュメント表現はリレーショナルの多テーブル分割より*局所性(locality)*に優れ、プロフィール全体を1回のクエリで取得できる一方、真に大量の関連アイテム(著名人の投稿への数千件のコメント等)を1ドキュメントへ埋め込むのは不適切で、そうしたケースはリレーショナル的な分割の方が向く。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "The Document Data Model for One-to-Many Relationships") ## 正規化・非正規化のトレードオフ IDによる参照(正規化)は人間可読な情報の重複を避け、更新を容易にし、一貫したスタイル・曖昧性回避・箇所特定(localization)対応・検索性向上といった利点を持つ。一方、参照を人間可読な形に戻すには結合(join)が必要になる。一般則として、正規化データは書き込みが速く(コピーが1つ)問い合わせが遅く(結合が必要)、非正規化データは読み取りが速く(結合が少ない)書き込みが高価になる(更新すべきコピーが多い)。非正規化は[[導出データ]]の一形態とみなせる——冗長コピーを更新し続けるプロセスが必要になる点で共通する。ドキュメントDBは弱い結合サポートのため非正規化と結び付けられやすいが、MongoDBの`$lookup`のように正規化データを結合できる機構を持つものもある。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "Normalization, Denormalization, and Joins") X(旧Twitter)のタイムライン実装はこのトレードオフを具体化する好例である。マテリアライズドタイムラインには投稿本文でなく投稿ID・送信者IDのみが格納され(いいね数やユーザー名など高頻度に変化する情報を非正規化しない)、読み取り時にIDを人間可読情報へ解決する処理——*ハイドレーション(hydrating)*と呼ばれる——がアプリケーションコード上の結合として行われる。この設計は、読み取り時の結合が必ずしもスケーラビリティの障害にならないこと(ハイドレーションはフォロー数・フォロワー数に依存せず並列化しやすい)、そして「何を非正規化し何を正規化するか」の判断が更新頻度と読み書きコストに応じて個別に決まることを示す。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "Denormalization in the Social Networking Case Study") ## スキーマオンリード対スキーマオンライトドキュメントDBの多く(およびリレーショナルDBのJSONサポート)はスキーマを強制しない。これは*schemaless*と呼ばれることがあるが、実際には読み取り側のコードが暗黙のスキーマを前提とするため、*schema-on-read*(構造はデータ読み取り時に解釈される)と呼ぶ方が正確であり、リレーショナルDBの伝統的な*schema-on-write*(書き込み時にスキーマが強制される)と対比される。この対比は動的型付けと静的型付けの論争に類似し、優劣に明確な決着はない。異種データ(オブジェクトごとに構造が異なる、または外部システムに構造を制御されている)にはschema-on-readが有利に働く。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "Schema Flexibility in the Document Model") スキーマ変更の実務上のコストにも差がある。schema-on-writeのリレーショナルDBで列を追加しデフォルト値を与える操作自体は高速だが、既存行を書き換える`UPDATE`は大テーブルで低速になりうる。オンラインスキーマ変更ツール(gh-ost、pg-osc、pgroll等)や、デフォルトNULLで列を追加し読み取り時に補完する(schema-on-read的な回避策)といった対応が取られる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "Schema Flexibility in the Document Model") ## データ局所性ドキュメントは通常JSON・XML・バイナリ変種(MongoDBのBSON等)としてひとつながりの文字列で保存される。ドキュメント全体を頻繁に必要とするアプリケーションでは、この*storage locality*が性能上の利点になる。ただし局所性の利点はドキュメントモデルに限定されない——[[Spanner|Google Spanner]]はリレーショナルモデルのまま子テーブルの行を親テーブルへインターリーブ(ネスト)する機能で同種の局所性を実現し、OracleのMulti-Table Index Cluster Tablesも同様の目的を持つ。局所性は「大部分のドキュメントを同時に必要とする場合」にのみ有効で、更新のたびにドキュメント全体を書き換える必要があるため、頻繁な小規模更新には不向きである。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] "Data Locality for Reads and Writes") ## 横断的知見 - 複数ソースの突き合わせで見えた観察は現時点でまだ蓄積されていない(本ページは今回のingestが初出)。今後、他のデータモデル系concept([[グラフデータモデル]]・[[イベントソーシングとCQRS]])や他書籍のスキーマ設計論との突き合わせで加筆する。 ## 未解決の問い - ドキュメントモデルの「収束」(リレーショナルDBへのJSONサポート追加、ドキュメントDBへの結合・セカンダリインデックス追加)が進む中で、実務者はどのような基準で「純粋なドキュメントDB」と「JSON拡張したリレーショナルDB」を使い分けているか。 - schema-on-read/schema-on-writeの選択は、Chapter 5で扱われるスキーマ発展(schema evolution)・後方互換性/前方互換性の議論とどう接続するか。 - X(旧Twitter)のハイドレーション事例のように「読み取り時結合はスケーラブル」という主張は、どの程度の規模・アクセスパターンまで一般化できるか。逆に読み取り時結合がボトルネックになる条件は何か。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]] - 実体: [[MongoDB]] / [[PostgreSQL]] / [[Spanner]] - 概念: [[導出データ]] / [[グラフデータモデル]] / [[イベントソーシングとCQRS]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 3 Data Models and Query Languages]]("Relational Versus Document Models", "The Object-Relational Mismatch", "Normalization, Denormalization, and Joins", "When to Use Which Model")