翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ディシジョンマトリックス
PostgreSQL で使用するマルチテナント SaaS パーティショニングモデルを決定するには、次の決定マトリックスを参照してください。マトリックスは、次の 4 つのパーティショニングオプションを分析します。
-
Silo – テナントごとに個別の PostgreSQL インスタンスまたはクラスター。
-
個別のデータベースとのブリッジ — 単一の PostgreSQL インスタンスまたはクラスター内のテナントごとに個別のデータベース。
-
個別のスキーマを使用したブリッジ — 単一の PostgreSQL データベース内のテナントごとに、単一の PostgreSQL インスタンスまたはクラスター内の個別のスキーマ。
-
プール – 1 つのインスタンスとスキーマ内のテナントの共有テーブル。
| サイロ | 個別のデータベースとブリッジする | 個別のスキーマでブリッジする | プール | |
|---|---|---|---|---|
| ユースケース | リソースの使用を完全に制御してデータを分離することが重要な要件であるか、非常に大規模でパフォーマンス重視のテナントがあります。 | データの分離は重要な要件であり、テナントのデータの制限付きまたは相互参照は必要ありません。 | データ量が中程度のテナントの数。これは、テナントのデータを相互参照する必要がある場合に推奨されるモデルです。 | テナントあたりのデータが少ない多数のテナント。 |
| 新しいテナントオンボーディングの俊敏性 | 非常に遅い。(テナントごとに新しいインスタンスまたはクラスターが必要です）。 | 中程度に遅い。(スキーマオブジェクトを保存するには、テナントごとに新しいデータベースを作成する必要があります）。 | 中程度に遅い。(オブジェクトを保存するには、テナントごとに新しいスキーマを作成する必要があります）。 | 最速オプション。(最小限のセットアップが必要です）。 |
| データベース接続プールの設定作業と効率 | 多大な労力が必要です。(テナントごとに 1 つの接続プール。) 効率が低下します。(テナント間のデータベース接続共有はありません）。 |
多大な労力が必要です。(Amazon RDS Proxy を使用しない限り、テナントごとに 1 つの接続プール設定。) 効率が低下します。(テナント間のデータベース接続共有と接続の合計数。 すべてのテナントでの使用は、DB インスタンスクラスに基づいて制限されます。) |
必要な労力が減ります。(すべてのテナントに 1 つの接続プール設定。) ある程度効率的です。(セッションプールモードでの |
最小労力が必要。 最も効率的です。(すべてのテナントに 1 つの接続プールがあり、すべてのテナント間で接続を効率的に再利用できます。 データベース接続の制限は DB インスタンスクラスに基づいています）。 |
| データベースメンテナンス (バキューム管理 |
よりシンプルな管理。 | 中程度の複雑さ。( の後にデータベースごとにバキュームワーカーを起動する必要があり、自動バキュームランチャーの CPU 使用率が高くなるためvacuum_naptime、リソースの消費量が高くなる可能性があります。 また、各データベースの PostgreSQL システムカタログテーブルのバキューム処理に関連する追加のオーバーヘッドが発生する場合もあります）。 |
大規模な PostgreSQL システムカタログテーブル。(テナント数とリレーション数に応じて、合計pg_catalogサイズは数十 GBs です。 テーブルの肥大化を制御するために、バキューム関連のパラメータの変更が必要になる可能性があります。) |
テナントの数とテナントあたりのデータによっては、テーブルが大きい場合があります。(テーブルの肥大化を制御するためにバキューム関連のパラメータを変更する必要がある可能性があります）。 |
| 拡張機能の管理作業 | 多大な労力 (個別のインスタンス内のデータベースごと）。 | 多大な労力 (各データベースレベル）。 | 最小労力 (共通データベースで 1 回）。 | 最小労力 (共通データベースで 1 回）。 |
| デプロイの労力を変更する | 多大な労力。(各インスタンスに接続し、変更をロールアウトします）。 | 多大な労力。(各データベースとスキーマに接続し、変更をロールアウトします）。 | 中程度の労力。(共通データベースに接続し、スキーマごとに変更をロールアウトします）。 | 最小限の労力。(共通データベースに接続し、変更をロールアウトします）。 |
| デプロイの変更 – 影響範囲 | 最小。(影響を受ける単一テナント) | 最小。(影響を受ける単一テナント) | 最小。(影響を受ける単一テナント) | 非常に大きい。(影響を受けるすべてのテナント）。 |
| クエリパフォーマンスの管理と労力 | 管理可能なクエリパフォーマンス。 | 管理可能なクエリパフォーマンス。 | 管理可能なクエリパフォーマンス。 | クエリのパフォーマンスを維持するには、かなりの労力が必要になる可能性があります。(時間の経過とともに、テーブルのサイズが大きくなるため、クエリの実行が遅くなる可能性があります。 テーブルパーティショニングとデータベースシャーディングを使用してパフォーマンスを維持できます）。 |
| クロステナントリソースへの影響 | 影響なし。(テナント間のリソース共有はありません）。 | 中程度の影響。(テナントは、インスタンス 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 接続メモリ使用率が高くなることがあります）。 |
効率的 (すべてのテナントが同じテーブルを共有するため）。 |
| 統合されたテナントレポート作業 | 多大な労力。(外部データラッパー [FDWs を使用して、すべてのテナントのデータを統合するか、[ETL] を別のレポートデータベースに抽出、変換、ロードする必要があります）。 | 多大な労力。(FDWs を使用して、すべてのテナントまたは ETL のデータを別のレポートデータベースに統合する必要があります）。 | 中程度の労力。(ユニオンを使用して、すべてのスキーマにデータを集約できます）。 | 最小限の労力。(すべてのテナントデータは同じテーブルにあるため、レポートは簡単です）。 |
| レポート用のテナント固有の読み取り専用インスタンス (サブスクリプションに基づくなど) | 最小労力。(リードレプリカを作成します。) | 中程度の労力。(論理レプリケーションまたは 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 クラスター全体のカウンターです）。 | 高 (例えば、1 つのテーブルが TOAST OID 制限の 40 億に達すると、out-of-line列の数に応じてます）。 |
