5.3データベース方式設計

システムアーキテクトは、データの特性（構造の定まり方・整合性要求）とアクセス特性（読み取り/書き込みの比率・データ量の増え方）から、適切なデータベース方式と拡張手段を選ぶ必要があります。単に「流行っているから」ではなく、整合性要求とスケール要求のどちらを優先するかという軸で判断することが実務では求められます。

5.3.1RDBとNoSQLの選択

• RDB（リレーショナルデータベース）＝あらかじめ定義したスキーマに基づき表形式でデータを管理し、ACID特性（原子性・一貫性・独立性・永続性）に基づくトランザクションで強い整合性を保証する。複数テーブルにまたがる整合性（例：注文と在庫の同時更新）が要求される業務システムに適するが、スキーマ変更のコストが高く、単一ノードでの垂直スケールが限界に近づくと水平方向の拡張が難しいという制約がある。
• NoSQL＝スキーマを厳密に固定せず（キーバリュー型・ドキュメント型・カラム指向型・グラフ型等）、多くの実装は複数ノードへの水平分散を前提に設計されている。厳密なACID特性よりBASE特性（結果整合性を許容してでも可用性とスケーラビリティを優先）を志向する製品が多く、大量データ・高頻度アクセス・スキーマが流動的な要件（例：ログデータ、商品カタログ、セッション情報）に適する反面、複数レコードにまたがる強い整合性の保証は苦手とする実装が多い。
• 選択の判断軸は「複数エンティティにまたがる強い整合性が業務上必須か」対「データ量/アクセス量の水平拡張が優先か」。決済や在庫のように整合性を欠くと業務上致命的な領域はRDB、大量のログや行動履歴のように整合性より書き込みスループットと拡張性を優先すべき領域はNoSQL、というように同一システム内でも領域ごとに使い分ける（ポリグロットパーシステンス）のが実務的である。