data-systems-architecture

データシステムアーキテクチャ

概要

基本原則： 優れたデータシステムアーキテクチャでは、信頼性（障害発生時も正しく動作すること）、スケーラビリティ（増大に柔軟に対応できること）、保守性（時間の経過とともに効率的に変更できること）のバランスが取れています。アーキテクチャ上のあらゆる決定には、これらの要素間のトレードオフが伴います。

このスキルでは、次の3つの基礎的な書籍の知識を統合しています。

• Designing Data-Intensive Applications（Kleppmann）- 分散システム、ストレージエンジン、スケーリング
• The Art of PostgreSQL（Fontaine）- PostgreSQL 固有のパターン、プログラミング言語としての SQL
• PostgreSQL Query Optimization（Dombrovskaya ほか）- 実行計画、パフォーマンスチューニング

使用する場面

症状	まず読むもの
新しいデータベース／スキーマを設計する	01-foundational-principles.md
正規化と非正規化の判断	02-data-modeling.md
OLTP と OLAP の違いを理解する	03-storage-engines.md
クエリが遅い、インデックスを選定する	04-indexing.md
成長への備え、読み取りレプリカ	05-scaling-patterns.md
競合状態、デッドロック、分離レベルの問題	06-transactions-concurrency.md
N+1 クエリ、ORM の問題、アプリケーションとの統合	07-application-integration.md

ナビゲーション

リファレンスファイル（必要に応じて読み込み）

01-foundational-principles.md    - Reliability/Scalability/Maintainability, load parameters
02-data-modeling.md              - Normalization, denormalization, schema design patterns
03-storage-engines.md            - B-trees, LSM-trees, OLTP vs OLAP, PostgreSQL internals
04-indexing.md                   - Index types, compound indexes, covering indexes, maintenance
05-scaling-patterns.md           - Replication, partitioning, sharding strategies
06-transactions-concurrency.md   - ACID, isolation levels, MVCC, locking patterns
07-application-integration.md    - ORM pitfalls, N+1, business logic placement, batch processing

クイック判断フレームワーク

New system design?
├─ Yes → Read 01, then 02 for data model
└─ No → What's the problem?
         ├─ "Queries are slow" → Read 04 (indexing) + 03 (storage patterns)
         ├─ "Data is inconsistent" → Read 02 (modeling) + 06 (transactions)
         ├─ "Can't handle the load" → Read 05 (scaling) + 03 (OLTP vs OLAP)
         ├─ "App makes too many queries" → Read 07 (N+1, ORM patterns)
         └─ "Race conditions/deadlocks" → Read 06 (concurrency)

中核となる概念（クイックリファレンス）

3つの柱

懸念事項	定義	主な問い
信頼性	障害発生時もシステムが正しく動作する	障害が発生したらどうなりますか？
スケーラビリティ	増大に柔軟に対応できる	負荷が10倍になったらどうなりますか？
保守性	運用や進化が容易である	新しいエンジニアが理解できますか？

データモデルの選択

モデル	最適な用途	避ける場面
リレーショナル	多対多の関係、結合、一貫性	高度に階層化されたデータ、頻繁なスキーマ変更
ドキュメント	自己完結型ドキュメント、ツリー構造	結合が必要な場合、多対多の関係
グラフ	高度に関連し合うデータ、再帰クエリ	単純な CRUD、関係のたどり直しが不要な場合

OLTP と OLAP

項目	OLTP	OLAP
クエリパターン	特定の値の検索、少数の行	集計、多数の行
最適化	WHERE で使用するすべての項目にインデックスを設定	インデックスは少なめにし、全件スキャンも許容
ストレージ	行指向	列指向を検討

インデックス型のクイックリファレンス

型	用途	PostgreSQL
B-tree	等価比較、範囲検索、ソート	デフォルト、ほとんどのクエリ
Hash	等価比較のみ	完全一致の検索を高速化
GIN	配列、JSONB、全文検索	@>、@@ 演算子
GiST	幾何データ、範囲型	PostGIS、最近傍検索
BRIN	自然な順序を持つ大規模テーブル	時系列データ

分離レベル

レベル	防止するもの	PostgreSQL のデフォルト？
Read Committed	ダーティリード	はい
Repeatable Read	+ 非反復読み取り	いいえ
Serializable	すべての異常	いいえ（SSI を使用）

設計チェックリスト

データアーキテクチャを確定する前に、次を確認してください。

• 負荷パラメーターを特定した（読み取り／書き込み比率、データ量、レイテンシ要件）
• 適切なデータモデルを選択した（リレーショナル／ドキュメント／グラフのハイブリッド？）
• まず第3正規形（3NF）まで正規化し、測定に基づく根拠がある場合にのみ非正規化した
• 実際のクエリパターンに合わせてインデックスを設計した（仮定に基づくものではない）
• 10倍の成長シナリオを検討した
• 分離レベルの要件を定めた
• ビジネスロジックをどこに配置するかを定めた（アプリケーション、データベース、または両方）
• 運用（バックアップ、監視、マイグレーション）を計画した

参考文献

• Kleppmann, M. Designing Data-Intensive Applications（O'Reilly、2017）
• Fontaine, D. The Art of PostgreSQL（第2版、2020）
• Dombrovskaya, H., Novikov, B., Bailliekova, A. PostgreSQL Query Optimization（Apress、2021）