1.4データモデルの多様性とNoSQL

関係モデルが今日のシステムで広く使われている一方、大規模Webサービスやリアルタイム分析基盤では、関係モデルの制約（厳密なスキーマ・水平分散の難しさ）が課題になる場面があり、NoSQLの各方式が台頭しています。この節では、各データモデルの特徴を並べて暗記するのではなく、「この要件にはどのデータモデルが最も適しているか」という選択判断を軸に理解します。関係モデルが常に最適とは限らず、逆にNoSQLが常に優れているわけでもない、という適材適所の視点が重要です。

1.4.1伝統的なデータモデル

• 階層型モデル＝データを木構造（親子関係）で表現し、1つの子は1つの親しか持てない。網型モデル＝階層型を拡張し、1つの子が複数の親を持てるネットワーク構造。どちらも関係モデル以前に主流だったモデルで、データ構造がアプリケーションのアクセス経路に強く依存するという制約があった。
• 関係モデル＝数学的な集合論に基づき、データ構造とアクセス経路を分離した（データ独立性を実現した）モデル。オブジェクト指向モデル＝プログラミング言語のオブジェクト（クラス・継承・カプセル化）をそのままデータベースの構造として扱うモデルで、複雑な構造を持つデータ（CAD図面・マルチメディア等）の扱いに向くが普及は限定的だった。

1.4.2NoSQLの4方式

• KVS（キーバリューストア）＝キーと値の単純なペアで管理し、キー指定の検索・更新が極めて高速。値の内部構造をDBMS側が理解しないため、セッション情報やキャッシュなど単純な参照パターンに適す。ドキュメント指向＝JSON等の半構造化ドキュメント単位で格納し、ドキュメントごとに柔軟なスキーマを持てる。カタログ情報のように項目数がレコードごとに異なるデータに適す。
• カラム指向（列指向）＝列単位でデータをまとめて格納する方式で、特定の列だけを大量に集計・分析する処理（分析基盤・時系列データ）で読み込みが高速。グラフDB＝ノード（頂点）とエッジ（辺）でデータと関係を直接表現し、多段階の関連をたどる問合せ（SNSの友人関係・レコメンデーション・不正検知の関連調査）を関係モデルの多段結合より高速に処理できる。

あなたはSNSサービスの新機能「友人の友人（2次のつながり）を経由したレコメンデーション」を設計するデータベース設計者です。既存の関係データベースにはユーザー同士のフォロー関係を格納する中間テーブルがありますが、「ユーザーAから2〜3ホップ先までの繋がりを高速に辿って推薦候補を出す」という要件を関係モデルのSQLで実現しようとすると、多段階の自己結合（JOIN）が必要になり、ホップ数が増えるほど結合コストが指数的に増大します。ここで「関係モデルはSQLの表現力が高いのだから、結合を工夫すれば何とかなる」と安易に結合の最適化だけで解決しようとするのは、大規模なユーザー基盤では性能上のボトルネックを先送りするだけの判断です。多段階の関連を頻繁にたどる要件には、ノードとエッジで関係を直接表現するグラフDBの方が構造的に適しており、2〜3ホップの探索も結合ではなくグラフの走査（トラバーサル）として高速に処理できます。一方で、同じSNSサービスでも「ユーザーのプロフィール設定（項目数が将来増減しやすい柔軟な構造）を保存したい」という要件であれば、スキーマを事前に厳密に固定しないドキュメント指向のデータベースが適します。全ての要件を1つのデータモデルで賄おうとせず、アクセスパターンごとに最適なモデルを併用する（ポリグロットパーシステンス）という発想が、大規模システムの設計では重要になります。

1.4.3この節のまとめ

• 階層型（1子1親）と網型（1子複数親）は関係モデル以前の伝統的モデル。関係モデルはデータ構造とアクセス経路を分離しデータ独立性を実現
• NoSQLの4方式（KVS/ドキュメント指向/カラム指向/グラフDB）は、それぞれ得意な処理パターンが異なり、要件のアクセスパターンに応じて選択する
• 多段階の関連をたどる要件にはグラフDB、柔軟なスキーマにはドキュメント指向のように、複数のモデルを併用（ポリグロットパーシステンス）する発想が大規模設計で重要