決策矩陣

若要決定您應該搭配 PostgreSQL 使用哪種多租用戶 SaaS 分割模型，請參閱下列決策矩陣。矩陣會分析下列四個分割選項：

• 筒倉 — 每個租用戶的個別 PostgreSQL 執行個體或叢集。

• 具有不同資料庫的橋接 — 單一 PostgreSQL 執行個體或叢集中的每個租用戶都有個別的資料庫。

• 具有不同結構描述的橋接 — 單一 PostgreSQL 資料庫、單一 PostgreSQL 執行個體或叢集中的每個租用戶的個別結構描述。

• 集區 — 單一執行個體和結構描述中租用戶的共用資料表。

	筒倉	橋接與單獨的數據庫	具有不同綱要的橋接	游泳池
使用案例	完全控制資源使用情況的資料隔離是一項關鍵要求，或者您擁有非常龐大且效能非常敏感的租用戶。	數據隔離是一項關鍵要求，租戶的數據是有限或不需要交叉引用。	具有中等數據量的中等租戶數量。如果您必須交叉引用租戶的數據，這是首選的模式。	大量租戶，每個租戶的數據較少。
新的租戶上線敏捷性	非常慢。每個租用戶都需要新的執行個體或叢集。)	適中慢。(需要為每個租用戶建立新資料庫以儲存結構描述物件。)	適中慢。(需要為每個承租人建立新結構描述以儲存物件。)	最快的選擇。(需要最低限度的設定。)
資料庫連線集區組態工作與效率	需要大量的努力。(每個租用戶有一個連線集區。) 效率較低。（租用戶之間沒有數據庫連接共享。）	需要大量的努力。(每個租用戶有一個連線集區組態，除非您使用 Amazon RDS 代理伺服器。) 效率較低。(租用戶與連線總數之間沒有資料庫連線共用。 所有租用戶的使用量是基於資料庫執行個體類別的限制。)	所需的努力更少。(適用於所有租用戶的一個連線集區組態。) 效率適中。(僅在工作階段集區模式下透過SET ROLE或SET SCHEMA命令重複使用連線。 SET使用 Amazon RDS Proxy 時，命令也會導致工作階段釘選，但可以消除用戶端連線集區，並為每個請求建立直接連線以提高效率。)	最少的努力要求。 最有效。(一個連線集區供所有租用戶使用，並有效率地重複使用所有租用戶。 資料庫連線限制是基於資料庫執行個體類別。)
數據庫維護（真空管理）和資源使用	更簡單的管理。	中度複雜。（可能會導致高資源消耗，因為之後必須為每個數據庫啟動真空工作者vacuum_naptime，從而導致高自動真空啟動器 CPU 使用率。 對於每個數據庫的 PostgreSQL 系統目錄表進行吸塵，也可能會產生額外的開銷。）	大型 PostgreSQL 系統目錄資料表。（總pg_catalog大小以數十 GB 為單位，具體取決於租戶的數量和關係。 可能需要對真空相關參數進行修改，以控制表膨脹。）	資料表可能很大，具體取決於每個租用戶的租用戶數量和資料。（可能需要對真空相關參數進行修改，以控制表膨脹。）
擴充功能的管理	顯著的努力（在單獨的實例中的每個數據庫）。	顯著的努力（在每個數據庫級別）。	最小的努力（在公共數據庫中一次）。	最小的努力（在公共數據庫中一次）。
變更部署工作量	重大努力。（Connect 到每個單獨的實例並推出更改。）	重大努力。（Connect 到每個數據庫和模式，並推出更改。）	適度的努力。（Connect 到通用數據庫並為每個模式發布更改。）	最小的努力。（Connect 到通用數據庫並推出更改。）
變更部署 — 影響範圍	極小。（單一租戶受影響。）	極小。（單一租戶受影響。）	極小。（單一租戶受影響。）	非常大。（受影響的所有租戶。）
查詢績效管理和工作量	可管理的查詢效能。	可管理的查詢效能。	可管理的查詢效能。	維護查詢效能可能需要大量的努力。(隨著時間的推移，查詢執行速度可能會因為資料表的大小增加而變慢。 您可以使用表分區和數據庫分片來保持性能。）
跨租用戶資源影響	沒有影響。（租戶之間沒有資源共享。）	適中 (租用戶會共用一般資源，例如執行個體 CPU 和記憶體)。	適中 (租用戶會共用一般資源，例如執行個體 CPU 和記憶體)。	重大影響。(租用戶在資源、鎖定衝突等方面相互影響。)
承租人層級調整 (例如，針對特定承租人建立其他索引，或針對特定承租人建立資料庫參數調整)	可能。	有可能。可以為每個承租人進行結構描述層級變更，但資料庫參數在所有承租人之間都是全域的。)	有可能。可以為每個承租人進行結構描述層級變更，但資料庫參數在所有承租人之間都是全域的。)	不可能。（表由所有租戶共享。）
重新平衡效能敏感租用戶的工作量	極小。（無需重新平衡。 擴充伺服器和 I/O 資源以處理此案例。)	適中。(使用邏輯複寫或pg_dump匯出資料庫，但停機時間可能會因資料大小而定。 您可以使用 Amazon RDS for PostgreSQL 中的可傳輸資料庫功能，更快速地在執行個體之間複製資料庫。)	中度但可能涉及冗長的停機時間。(使用邏輯複寫或pg_dump匯出結構描述，但停機時間可能會因資料大小而定。)	重要的是，因為所有租戶共享相同的表。（分片數據庫需要將所有內容複製到另一個實例，以及清理租戶數據的附加步驟。） 最有可能需要改變應用程序邏輯。
主要版本升級的資料庫停機	標準停機 (取決於 PostgreSQL 系統目錄大小。)	停機時間可能更長。（根據系統目錄大小，時間會有所不同。 PostgreSQL 系統目錄表格也會跨資料庫複製)	停機時間可能更長。(視 PostgreSQL 系統目錄大小而定，時間會有所不同。)	標準停機 (取決於 PostgreSQL 系統目錄大小。)
管理額外負荷 (例如，用於資料庫記錄分析或備份工作監督)	重大投入	最小的努力。	最小的努力。	最小的努力。
承租人層級的可用性	最高 （每個租戶失敗並獨立恢復。）	更高的影響範圍。(如果發生硬體或資源問題，所有租用戶都會失敗並一起復原。)	更高的影響範圍。(如果發生硬體或資源問題，所有租用戶都會失敗並一起復原。)	更高的影響範圍。(如果發生硬體或資源問題，所有租用戶都會失敗並一起復原。)
承租人層級備份與回復工作	最低有效。(每個租用戶可以獨立備份和還原。)	適度的努力。(針對每個承租人使用邏輯匯出和匯入。 一些編碼和自動化是必需的。）	適度的努力。(針對每個承租人使用邏輯匯出和匯入。 一些編碼和自動化是必需的。）	重大努力。（所有租戶共享相同的表格。）
租戶級別的 point-in-time 恢復工作	最小的努力。(使用快照使用點入時間復原，或在 Amazon Aurora 中使用回溯功能。)	適度的努力。（使用快照恢復，然後導出/導入。 但是，這將是一個緩慢的操作。）	適度的努力。（使用快照恢復，然後導出/導入。 但是，這將是一個緩慢的操作。）	巨大的努力和複雜性。
統一結構描述	每個租用戶的結構描述名稱相同。	每個租用戶的結構描述名稱相同。	每個租用戶的不同結構描述。	通用結構描述。
每個租用戶自訂 (例如，特定承租人的額外資料表資料行)	可能。	可能。	可能。	複雜（因為所有租戶共享相同的表格）。
物件關聯對應 (ORM) 層 (例如 Ruby) 的目錄管理效率	有效率 (因為用戶端連線專用於租用戶)。	高效（因為客戶端連接特定於數據庫）。	效率適中。(視使用的 ORM、使用者/角色安全性模型和search_path組態而定，用戶端有時會快取所有租用戶的中繼資料，進而導致資料庫連線記憶體使用量高。)	高效（因為所有租戶共享相同的表）。
合併租戶報告工作	重大努力。(您必須使用外部資料包裝函式 [FDW] 來合併所有租用戶中的資料，或擷取、轉換及載入 [ETL] 到另一個報表資料庫。)	重大努力。(您必須使用 FDW 將所有租用戶或 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) 和交易識別碼 (XID) 環繞式的機會	極小。	高。(因為 OID，XID 是單一 PostgreSQL 叢集範圍的計數器，而且可能會有在實體資料庫之間有效清除的問題)。	適中。（因為 OID，XID 是一個單一的 PostgreSQL 集群範圍內的計數器）。	高。例如，單一資料表可以達到 40 億 TOAST OID 上限，視 out-of-line 資料欄數而定。)