Merge pull request #1522 from future-architect/feature

PostgreSQL guidelines

Author: ma91n

source/_posts/20250530a_PostgreSQL設計ガイドラインのご紹介.md

@@ -0,0 +1,150 @@
+---
+title: "PostgreSQL設計ガイドラインのご紹介"
+date: 2025/05/30 00:00:00
+postid: a
+tag:
+  - PostgreSQL
+  - AWS
+  - Aurora
+  - DB設計
+  - ガイドライン
+category:
+  - DB
+thumbnail: /images/20250530a/thumbnail.png
+author: 宮崎将太
+lede: "フューチャー社内の有志メンバーでPostgreSQLDB設計ガイドラインを作成しました。"
+---
+# はじめに
+
+フューチャー社内の有志メンバーでPostgreSQL DB設計ガイドラインを作成しました。
+
+- [PostgreSQL設計ガイドライン | Future Enterprise Arch Guidelines](https://future-architect.github.io/arch-guidelines/documents/forDB/postgresql_guidelines.html)
+
+形になってから数ヶ月寝かせており、ある程度社内の指摘を取り込むことができたのでこのタイミングで告知します
+
+<a href="https://future-architect.github.io/arch-guidelines/documents/forDB/postgresql_guidelines.html">
+<img src="/images/20250530a/image.png" alt="" width="1200" height="800" loading="lazy">
+</a>
+
+# よくあるDB設計規約との差別化ポイント
+
+単にDB設計ガイドラインというと何を今更？感もあるので、命名規則や型桁など一般的な内容に加え、以下の点でよくあるDB設計ガイドラインから一歩踏み込んだコンテンツとなるよう心がけました。
+
+## 論理設計への踏み込み
+
+単なるテーブル定義やデータ型選択にとどまらず、より高度な論理設計の原則に焦点を当てています。
+
+### マスタ/トラン/ワーク
+
+データベース設計において、データの種類に応じてテーブルを明確に分離することは設計効率と保守性を高める上で重要ですが、意外とその定義は曖昧であり、しばしば初学者の障壁となります。本ガイドラインでは以下の通り明確に分類を定めています。
+
+* **マスタテーブル:** ビジネスの中核となる静的な情報（例：顧客情報、商品カタログ）を格納
+* **トランザクションテーブル（トランテーブル）:** ビジネスプロセスで発生する動的な出来事（例：注文履歴、在庫変動）を記録
+* **ワークテーブル:** 一時的な処理や中間結果を保持するために使用
+
+これらのデータの特性を踏まえ、それぞれについて下記の言及しています。
+
+* テーブル設計
+* インデックス戦略
+* アクセスパターン
+
+### スナップショット属性、導出属性
+
+RDBにおけるテーブルデザインといえば、基本は正規化するべしというのがスタンダードな考え方です。
+一方で、下記のように敢えて非正規化し、カラムとして保持させるべきケースもあります。
+
+* **スナップショット属性:** 特定の時点におけるエンティティの状態を記録し、履歴管理や監査に使用する
+* **導出属性:** 既存の属性から計算される情報であり、例えば、注文日の属する四半期や、顧客の累積購入金額などが該当する。
+
+本ガイドラインではこれらの属性の適切な管理方法について、以下の指針を示しています。
+
+* いつスナップショットを取得すべきか
+* 導出属性を物理的に格納するか（性能とのトレードオフ）
+
+### 業務日付
+
+中規模以上のシステムになると、以下の様なケースに耐えるためシステム日付とは別に業務日付を保持させることがあります。
+
+* 店舗の営業時間が26時などの場合に、コンピューターの持つ日付（システム日付）とずれた営業日単位で登録／集計を可能とするため
+* 日をまたぐバッチ処理や画面操作（システムメンテナンスなどを想定）に対して、データ整合性を保ちやすくする
+* 障害調査や結合テスト／負荷検証などで、特定の日付におけるテストを再現しやすくする
+
+小規模なWebアプリケーションではあまり発生しない概念ですが、本ガイドラインでは業務日付を使用するべきケース、そうでないケース、使用する場合の推奨データ型や注意点を記載しています。
+
+### 世代管理
+
+データの変更履歴を管理する世代管理は、データ復旧や過去の状態参照において重要な役割を果たします。これを実現するための具体的な方法として、以下のものが考えられます。
+
+* タイムスタンプ付きの履歴テーブルの利用
+* 論理削除フラグの活用
+
+データの重要度や変更頻度に応じて適切な世代管理戦略を選択するための基準を示しています。
+
+## その他設計パターンへの踏み込み
+
+### 排他制御
+
+複数のトランザクションが同時に同じデータにアクセスする状況下で、データの整合性を保つための排他制御は非常に重要です。
+本ガイドラインでは、以下の点について解説しています。
+
+* PostgreSQLを利用する場合のロック機能の適切な利用方法
+* デッドロックを回避するためのプラクティス
+
+### マルチテナント
+
+複数の顧客や組織が同一のアプリケーションやデータベースインスタンスを共有するアーキテクチャはマルチテナントアーキテクチャと呼ばれ、コスト効率に優れています。
+世間的に広く認知されているものの、実際に設計・実装しようとすると、以下の点が重要な課題となります。
+
+* テナント間のデータ隔離
+* セキュリティ確保
+* 性能
+
+本ガイドラインでは、複数考えられるマルチテナントアーキテクチャ設計パターンのメリット・デメリットを比較し、ケース毎に推奨される設計方針を打ち出しています。
+
+### キャッシュ戦略
+
+データベースへの負荷を軽減し、アプリケーションの応答性を向上させるためには、適切なキャッシュ戦略が不可欠です。
+本ガイドラインでは、アプリケーションの要件やデータ特性に応じて、効果的なキャッシュ戦略を選択し、実装するための指針を示しています。
+
+## クラウド（AWS）への踏み込み
+
+より具体的なガイドラインとなるよう特にAmazon Auroraを中心にクラウド特有の考慮事項に焦点を当てています。
+
+### バージョン管理
+
+基本的にはLTSを選択することになり、少なくとも3年間はLTSを使用できますが、その後はしばしば強制的なメジャーバージョンアップが要求されることもあります。
+そう何度も実施する作業ではないので対処に迷いがちなので、今回は特に以下の観点で記載しました。
+
+* アップグレード計画の策定
+* アップグレード時の注意点
+
+### サイジング
+
+アプリケーションの性能要件を満たすためには、適切な RDS インスタンスタイプ（CPU、メモリ、ストレージ）を選択することが重要です。サイジングが不適切だと、以下の問題につながる可能性があります。
+
+* 性能不足
+* コストの浪費
+
+本ガイドラインでは特に以下の点について言及しています。
+
+* ワークロードの特性（例：OLTP、OLAP）に応じたインスタンスタイプの推奨
+* 初期サイジングの見積もり方法
+* 負荷テストの重要性
+
+### スケーリング戦略
+
+アプリケーションの負荷変動に対応するため、データベースのスケーリング戦略を事前に検討しておく必要があります。Aruoraでは以下の機能を提供されています。
+
+* リードレプリカによる読み取り負荷の分散
+* インスタンスタイプの変更による垂直スケーリング
+
+本ガイドラインでは、以下の点について解説しています。
+
+* これらのスケーリングオプションの適切な選択と設定
+* スケーリング時の注意点
+
+# まとめ
+
+冒頭に記述したとおり、単にPostgreSQLの基本的な機能や設計原則を解説するだけでなく、より実践的で高度なトピックにまで踏み込見ました。
+
+PostgreSQL自体のupdateやAWSその他クラウドサービスの動向をウォッチしつつ継続的にupdateを行っていく予定です。