database-design-patterns について
リレーショナルおよびNoSQLシステムのスキーマや永続化レイヤーを設計する開発者向けのガイダンススキルです。データモデリング、クエリ性能、スケーリング、一貫性の判断をテーマ別の資料で扱います。
主な機能
- 01スキーマとデータモデリングの指針
- 02ACID、BASE、CAPの概念
- 03インデックスとクエリ最適化
- 04パーティショニング、シャーディング、レプリケーション
- 05キャッシュとコネクションプーリングの実践
- 06テーマ別のリファレンスファイル
活用シーン
- 01新規アプリケーションのスキーマ設計
- 02遅いクエリやインデックスの調査
- 03データベースの拡張と複製の計画
- 04一貫性と永続化方式の選択
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/database-design-patternsを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/core-principles.mdindexing-strategies.mdpartitioning-patterns.mdquery-optimization.mdreplication-patterns.mdschema-design-patterns.md詳細
データベース設計パターン
リレーショナルデータベースと NoSQL データベース全般にわたる、スケーラブルなデータベーススキーマの設計、クエリパフォーマンスの最適化、堅牢なデータ永続化レイヤーの実装に関する専門的なガイダンスです。
このスキルを使用する場面
- 新しいアプリケーションのデータベーススキーマを設計するとき
- 遅いクエリやデータベースのパフォーマンスを最適化するとき
- 正規化戦略と非正規化戦略のどちらを採用するか選ぶとき
- パーティショニング、シャーディング、レプリケーション戦略を実装するとき
- データベース技術を移行するとき（SQL から NoSQL、またはその逆）
- 高可用性と災害復旧を考慮して設計するとき
- キャッシュ戦略や読み取りレプリカを実装するとき
- データベースを水平または垂直にスケーリングするとき
- 分散システムでデータの一貫性を確保するとき
基本概念
データモデリング
ビジネスドメイン、アクセスパターン、一貫性の要件を反映したスキーマを設計します。ワークロードの特性に基づき、正規化（データの整合性）と非正規化（読み取りパフォーマンス）のバランスを取ります。
ACID と BASE
- ACID（リレーショナル）：原子性、一貫性、分離性、耐久性――強い保証
- BASE（NoSQL）：基本的に利用可能、ソフト状態、結果整合性――柔軟性
CAP 定理
分散システムでは、整合性、可用性、分断耐性の3つのうち2つを選択します。
ポリグロット永続化
ユースケースごとに適切なデータベースを使用します。トランザクションには PostgreSQL、ドキュメントには MongoDB、キャッシュには Redis、検索には Elasticsearch、時系列データには Cassandra、グラフには Neo4j を使用します。
クイックリファレンス
| タスク | リファレンスを読み込む |
|---|---|
| データベースの基本原則（ACID、BASE、CAP） | skills/database-design-patterns/references/core-principles.md |
| スキーマパターン（正規化、スター・スキーマ、ドキュメント） | skills/database-design-patterns/references/schema-design-patterns.md |
| インデックスの種類と戦略（B-tree、ハッシュ、カバリング） | skills/database-design-patterns/references/indexing-strategies.md |
| パーティショニングとシャーディングの手法 | skills/database-design-patterns/references/partitioning-patterns.md |
| レプリケーションモード（プライマリ・レプリカ、マルチリーダー） | skills/database-design-patterns/references/replication-patterns.md |
| クエリの最適化とキャッシュ | skills/database-design-patterns/references/query-optimization.md |
ワークフロー
フェーズ 1：要件分析
- アクセスパターンを特定します（読み取り中心か書き込み中心か）
- 一貫性の要件を判断します（強整合性か結果整合性か）
- データ量と増加率を見積もります
- SLA 要件を定義します（レイテンシ、可用性）
フェーズ 2：スキーマ設計
- エンティティとリレーションシップをモデル化します
- ワークロードに基づいて正規化のレベルを選びます
- ストレージだけでなく、クエリパターンも考慮して設計します
- データ分散戦略（パーティショニング／シャーディング）を検討します
フェーズ 3：パフォーマンス最適化
- クエリ実行計画を分析します（
EXPLAIN ANALYZE） - 頻繁に実行されるクエリにインデックスを追加します
- 適切な場合はキャッシュを実装します
- コネクションプーリングを設定します
- 監視し、反復的に改善します
フェーズ 4：スケーリング戦略
- 読み取り負荷を分散するために読み取りレプリカを実装します
- 大規模なテーブル（>100M rows）ではパーティショニングを検討します
- 水平スケーリングに向けたシャーディング戦略を計画します
- レプリケーションによる高可用性を考慮して設計します
よくある間違い
過剰な正規化：結合が多すぎると読み取りが遅くなります。読み取り中心のワークロードでは非正規化します。
インデックスの不足：クエリパターンを分析し、頻繁に使われる WHERE／JOIN カラムにインデックスを追加します。
不適切なインデックスの種類：正しいカラム順序（等価条件を先に、その後に範囲条件）で複合インデックスを使用します。
レプリケーションラグの無視：読み取り後に書き込みを読むパターンを使って、結果整合性に対処します。
不適切なパーティショニングキー：データが均等に分散され、クエリパターンにも合うキーを選びます。
N+1 クエリ：ループ内でクエリを実行する代わりに、JOIN またはバッチ読み込みを使用します。
非効率なページネーション：大規模なデータセットでは OFFSET ではなく、キーセットページネーションを使用します。
コネクションの枯渇：ワークロードに合ったサイズのコネクションプーリングを実装します。
ベストプラクティス
- アクセスパターンに合わせてモデル化する - データのクエリ方法に合わせてスキーマを設計します
- 戦略的にインデックスを作成する - 頻繁にクエリされる列にはインデックスを作成し、過剰なインデックス作成は避けます
- 大きなテーブルをパーティション分割する - 1 億行を超えるテーブルや時系列データに使用します
- 読み取り用にレプリケーションする - 読み取りのスケーリングにはプライマリ・レプリカ構成を、地理的な分散にはマルチリーダー構成を使用します
- クエリを最適化する - 実行計画を分析し、N+1を避け、適切なページネーションを使用します
- 頻繁にアクセスされるデータをキャッシュする - 適切なTTLを設定したアプリケーションレベルのキャッシュを使用します
- 接続をプールする - ワークロードに基づいてコネクションプールのサイズを決定します
- 継続的に監視する - クエリのパフォーマンス、インデックスの使用状況、レプリケーションの遅延を追跡します
- 成長を見越して計画する - 現在の負荷の3倍に対応できるように設計します
- 整合性を慎重に選択する - ビジネス要件に適した整合性レベルを選びます
リソース
書籍：
- "Designing Data-Intensive Applications"（Kleppmann）
- "High Performance MySQL"（Schwartz）
サイト：
- use-the-index-luke.com
- PostgreSQL のドキュメント
- MongoDB のドキュメント
ツール：
- EXPLAIN ANALYZE
- pg_stat_statements
- Percona Toolkit
- pt-query-digest