意思決定マトリックス

PostgreSQL で使用すべきマルチテナント SaaS パーティショニングモデルを決定するには、以下の決定マトリックスを参照してください。このマトリックスでは、次の 4 つのパーティショニングオプションが分析されます。

• サイロ — テナントごとに異なる PostgreSQL インスタンスまたはクラスタ。

• 個別のデータベースとのブリッジ — 単一の PostgreSQL インスタンスまたはクラスター内のテナントごとに個別のデータベース。

• 個別のスキーマによるブリッジ — 単一の PostgreSQL データベース、単一の PostgreSQL インスタンスまたはクラスタ内のテナントごとに個別のスキーマを作成します。

• プール — 単一インスタンスとスキーマ内のテナント用の共有テーブル。

	サイロ	個別のデータベースとのブリッジ	個別のスキーマを使ったブリッジ	プール
ユースケース	リソースの使用状況を完全に制御しながらデータを分離することが重要な要件です。また、テナントが非常に大規模でパフォーマンスに敏感な場合は、重要な要件となります。	データの分離は重要な要件であり、テナントのデータの相互参照は限られているか、まったく必要ありません。	中程度の数のテナントと中程度のデータ量。テナントのデータを相互参照する必要がある場合は、このモデルが適しています。	テナント数が多く、テナントあたりのデータ量が少ない。
新しいテナントのオンボーディングアジリティ	非常に遅い。(テナントごとに新しいインスタンスまたはクラスターが必要です)。	中中。中。中。中。(スキーマオブジェクトを格納するには、テナントごとに新しいデータベースを作成する必要があります)。	中中。中。中。中。(オブジェクトを保存するには、テナントごとに新しいスキーマを作成する必要があります)。	最速のオプション。(最低限の設定が必要です。)
データベース接続プール構成の労力と効率性	多大な労力が必要です。(テナントごとに 1 つの接続プール) 効率が悪い。(テナント間でデータベース接続を共有することはできません。)	多大な労力が必要です。(Amazon RDS プロキシを使用しない限り、テナントごとに 1 つの接続プール設定) 効率が悪い。(テナント間でのデータベース接続の共有や接続の総数はありません。 すべてのテナントでの使用量は、DB インスタンスクラスによって制限されます。)	必要な労力が少なくて済みます。(すべてのテナントに 1 つの接続プール構成) 適度に効率的です。（SET ROLESET SCHEMAまたはコマンドによる接続の再利用は、セッションプールモードでのみ。 SETAmazon RDS Proxy を使用する場合、コマンドによってセッションが固定されることもありますが、クライアント接続プールは不要で、各リクエストに対して直接接続を行うことができるため、効率が向上します。)	必要な労力は最小限です。 最も効率的です。(1 つの接続プールですべてのテナントが使用でき、すべてのテナントで接続を効率的に再利用できます。 データベース接続の制限は、DB インスタンスクラスによって異なります。)
データベースメンテナンス (バキューム管理) とリソース使用量	よりシンプルな管理。	中中中。中。中 （後でデータベースごとにバキュームワーカーを起動する必要があるため、リソースの消費量が大きくなる可能性があります。これによりvacuum_naptime、autovacuum Launcher の CPU 使用率が高くなります。 また、各データベースの PostgreSQL システムカタログテーブルのバキューム処理に関連する追加のオーバーヘッドが発生することもあります。)	大規模な PostgreSQL システムカタログテーブル。（テナント数とリレーション数によりますが、pg_catalog合計サイズは 10 GB 単位です。 テーブルの膨張を抑えるには、バキューム関連のパラメーターの変更が必要になる可能性があります。)	テナント数とテナントごとのデータによっては、テーブルが大きくなる場合があります。(テーブルの膨張を抑制するには、バキューム関連のパラメーターの変更が必要になる可能性が高い)。
拡張機能管理の労力強化	多大な労力（データベースごとに別々のインスタンスで）。	多大な労力（各データベースレベルで）。	最小限の労力（共通データベースで 1 回）。	最小限の労力（共通データベースで 1 回）。
導入労力を変更	労力労力を。(個々のインスタンスConnect し、変更をロールアウトします。)	労力労力を。(各データベースとスキーマConnect し、変更をロールアウトします。)	中中中。中。中 (共通のデータベースConnect し、各スキーマの変更をロールアウトします。)	労力中。(共通データベースConnect し、変更をロールアウトします。)
導入の変更 — 影響範囲	最小限。(単一テナントが影響を受けます。)	最小限。(単一テナントが影響を受けます。)	最小限。(単一テナントが影響を受けます。)	非常に大きい。(すべてのテナントが影響を受けます。)
クエリパフォーマンスの管理と作業	管理可能なクエリパフォーマンス。	管理可能なクエリパフォーマンス。	管理可能なクエリパフォーマンス。	クエリのパフォーマンスを維持するには、多大な労力が必要になる可能性があります。(時間が経つにつれて、テーブルのサイズが大きくなるため、クエリの実行速度が遅くなる可能性があります。 テーブルパーティショニングとデータベースシャーディングを使用してパフォーマンスを維持できます。)
テナント間のリソースへの影響	影響なし。(テナント間でのリソースの共有はありません。)	中中中中中中。(テナントはインスタンスの CPU やメモリなどの共通リソースを共有します。)	中中中中中中。(テナントはインスタンスの CPU やメモリなどの共通リソースを共有します。)	強いインパクト。(リソースやロックの競合などの観点から、テナント同士が相互に影響を及ぼします)。
テナントレベルのチューニング (テナントごとの追加インデックスの作成や特定のテナントの DB パラメーターの調整など)	可能な。	中。可能な、中。(スキーマレベルの変更はテナントごとに行うことができますが、データベースパラメータはすべてのテナントで共通です)。	中。可能な、中。(スキーマレベルの変更はテナントごとに行うことができますが、データベースパラメータはすべてのテナントで共通です)。	可能な、不可能な。（テーブルはすべてのテナントで共有されます。）
パフォーマンス重視のテナントのリバランス作業	最小限。（バランスを取り直す必要はありません。 このシナリオに対応するようにサーバーリソースと I/O リソースをスケーリングします。)	中中中中中 （pg_dump論理レプリケーションまたはを使用してデータベースをエクスポートしますが、データサイズによってはダウンタイムが長くなる場合があります。 Amazon RDS for PostgreSQL のトランスポータブルデータベース機能を使用すると、インスタンス間でデータベースをすばやくコピーできます。)	中程度ですが、ダウンタイムが長くなる可能性があります。(pg_dump論理レプリケーションまたはを使用してスキーマをエクスポートしますが、データサイズによってはダウンタイムが長くなる場合があります)。	すべてのテナントが同じテーブルを共有しているので重要です。(データベースをシャーディングするには、すべてを別のインスタンスにコピーし、テナントデータをクリーンアップするための追加手順が必要です)。 ほとんどの場合、アプリケーションロジックの変更が必要です。
メジャーバージョンアップグレードによるデータベースのダウンタイム	標準ダウンタイム。(PostgreSQL システムカタログのサイズによって異なります。)	ダウンタイムが長くなる可能性があります。(システムカタログのサイズによって、時間は異なります。 PostgreSQL のシステムカタログテーブルもデータベース間で複製されます）	ダウンタイムが長くなる可能性があります。（PostgreSQL システムカタログのサイズによって、時間は異なります。）	標準ダウンタイム。(PostgreSQL システムカタログのサイズによって異なります。)
管理オーバーヘッド (データベースログ分析やバックアップジョブの監視など)	労力労力を	労力中。	労力中。	労力中。
テナントレベルのアベイラビリティ	最大。（各テナントは個別に障害が発生し、回復します。）	影響範囲が広い。（ハードウェアまたはリソースの問題が発生すると、すべてのテナントで障害が発生し、同時に復旧します。）	影響範囲が広い。（ハードウェアまたはリソースの問題が発生すると、すべてのテナントで障害が発生し、同時に復旧します。）	影響範囲が広い。（ハードウェアまたはリソースの問題が発生すると、すべてのテナントで障害が発生し、同時に復旧します。）
テナントレベルのバックアップとリカバリの作業	労力中。(テナントごとにバックアップと復元が可能です。)	中中中。中。中 (テナントごとに論理的なエクスポートとインポートを使用してください。 ある程度のコーディングと自動化が必要です。)	中中中。中。中 (テナントごとに論理的なエクスポートとインポートを使用してください。 ある程度のコーディングと自動化が必要です。)	労力労力を。(すべてのテナントが同じテーブルを共有します。)
point-in-time テナントレベルの復旧作業	労力中。(スナップショットを使用してポイントインタイムリカバリを使用するか、Amazon Aurora でバックトラッキングを使用してください)。	中中中。中。中 (スナップショットのリストアを使用してから、エクスポート/インポートを行います。 ただし、これは処理に時間がかかります。)	中中中。中。中 (スナップショットのリストアを使用してから、エクスポート/インポートを行います。 ただし、これは処理に時間がかかります。)	多大な労力と複雑さ。
統一スキーマ名	テナントごとに同じスキーマ名。	テナントごとに同じスキーマ名。	テナントごとに異なるスキーマ。	共通スキーマ。
テナントごとのカスタマイズ (特定のテナントのテーブル列の追加など)	可能な。	可能な。	可能な。	複雑 (すべてのテナントが同じテーブルを共有しているため)。
オブジェクトリレーショナルマッピング (ORM) レイヤー (Ruby など) でのカタログ管理の効率性	効率的 (クライアント接続はテナントごとに異なるため)。	効率的 (クライアント接続はデータベースに固有であるため)。	適度に効率的です。(使用する ORM、ユーザー/ロールのセキュリティモデル、search_pathおよび構成によっては、クライアントはすべてのテナントのメタデータをキャッシュすることがあり、DB 接続のメモリ使用量が多くなります)。	効率的 (すべてのテナントが同じテーブルを共有するため)。
テナント報告の統合作業	労力労力を。(すべてのテナントのデータを統合するか、[ETL] を別のレポートデータベースに抽出、変換、ロードするには、外部データラッパー [FDW] を使用する必要があります)。	労力労力を。(すべてのテナントまたはETLのデータを別のレポートデータベースに統合するには、FDWを使用する必要があります)。	中中中。中。中 (ユニオンを使用すると、すべてのスキーマのデータを集約できます)。	労力中。(すべてのテナントデータは同じテーブルにあるため、レポートは簡単です。)
レポート用のテナント固有の読み取り専用インスタンス (サブスクリプションベースなど)	労力中。(リードレプリカを作成します。)	中中中。中。中 (AWS論理レプリケーションまたはDatabase Migration Service [AWS DMS] を使用して構成できます。)	中中中。中。中 (論理レプリケーションを使用することもAWS DMS、構成することもできます)。	複雑 (すべてのテナントが同じテーブルを共有しているため)。
データ分離	最高。	ベスト。(データベースレベルの権限は PostgreSQL ロールを使用して管理できます。)	ベスト。(PostgreSQL ロールを使用してスキーマレベルの権限を管理できます。)	さらに悪い。(すべてのテナントが同じテーブルを共有するため、テナントを分離するための行レベルのセキュリティ [RLS] などの機能を実装する必要があります)。
テナント固有のストレージ暗号化キー	可能な。(各 PostgreSQL クラスターには、ストレージ暗号化用の独自のAWS Key Management Service [AWS KMS] キーを設定できます。)	可能な、不可能な。(すべてのテナントは、ストレージ暗号化用の同じ KMS キーを共有します。)	可能な、不可能な。(すべてのテナントは、ストレージ暗号化用の同じ KMS キーを共有します。)	可能な、不可能な。(すべてのテナントは、ストレージ暗号化用の同じ KMS キーを共有します。)
各テナントのデータベース認証にAWS Identity and Access Management (IAM) を使用する	可能な。	可能な。	可能 (各スキーマに別々の PostgreSQL ユーザーを割り当てることにより)。	できません (テーブルはすべてのテナントで共有されているため)。
インフラストラクチャコスト	最高 (何も共有されていないため)。	中中中中中	中中中中中	最中。
データの複製とストレージの使用	全テナントで最も高い集計。(PostgreSQL システムカタログテーブルとアプリケーションの静的データと共通データは、すべてのテナントで重複しています。)	全テナントで最も高い集計。(PostgreSQL システムカタログテーブルとアプリケーションの静的データと共通データは、すべてのテナントで重複しています。)	中中中中中 (アプリケーションの静的データと共通データは、共通のスキーマに格納されていて、他のテナントからもアクセスできます)。	最小限。(データの重複はありません。 アプリケーションの静的データと共通データは同じスキーマにあってもかまいません。)
テナント中心の監視 (問題の原因となっているテナントを迅速に特定)	労力中。（各テナントは個別に監視されるため、特定のテナントのアクティビティを簡単に確認できます。）	中中中。中。中 (すべてのテナントが同じ物理リソースを共有するため、特定のテナントのアクティビティを確認するには追加のフィルタリングを適用する必要があります)。	中中中。中。中 (すべてのテナントが同じ物理リソースを共有するため、特定のテナントのアクティビティを確認するには追加のフィルタリングを適用する必要があります)。	多大な労力が必要です。(すべてのテナントはテーブルを含むすべてのリソースを共有するため、バインド変数キャプチャを使用して特定の SQL クエリがどのテナントに属しているかを確認する必要があります)。
一元管理とヘルス/アクティビティモニタリング	多大な労力（中央監視と中央コマンドセンターの設置）。	中程度の労力 (すべてのテナントが同じインスタンスを共有するため)。	中程度の労力 (すべてのテナントが同じインスタンスを共有するため)。	最小限の労力 (すべてのテナントがスキーマを含む同じリソースを共有するため)。
オブジェクト識別子 (OID) とトランザクション ID (XID) のラップアラウンドが発生する可能性	最小限。	高。高。（OID、XIDはPostgreSQLクラスタ全体の単一カウンターであるため、物理データベース間で効果的にバキューム処理を行うと問題が発生する可能性があります）。	中中中中中 (OID、XID は PostgreSQL クラスタ全体にわたる単一カウンタであるため)。	高。高。（たとえば、 out-of-line 列数によっては、1つのテーブルでTOAST OIDの上限である40億に達することがあります。）