本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 決策矩陣
<a name="matrix"></a>

若要決定您應該搭配 PostgreSQL 使用的多租戶 SaaS 分割模型，請參閱下列決策矩陣。矩陣會分析這四個分割選項：
+ Silo – 每個租用戶的個別 PostgreSQL 執行個體或叢集。
+ 與個別資料庫橋接 – 單一 PostgreSQL 執行個體或叢集中每個租用戶的個別資料庫。
+ 與個別結構描述橋接 – 單一 PostgreSQL 執行個體或叢集中單一 PostgreSQL 資料庫中每個租用戶的個別結構描述。
+ 集區 – 單一執行個體和結構描述中租用戶的共用資料表。


****  

| **** | **孤立** | **與個別資料庫橋接** | **使用個別結構描述橋接** | **集區** | 
| --- | --- | --- | --- | --- | 
| 使用案例 | 完全控制資源用量的資料隔離是一項關鍵要求，或者您有非常大且非常重視效能的租戶。 | 資料隔離是關鍵要求，而且需要有限或不需要租用戶資料的交叉參考。 | 具有中等資料量的中等租用戶數量。如果您必須跨參考租用戶的資料，這是偏好的模型。 | 每個租用戶的資料較少的大量租用戶。 | 
| 新租戶加入敏捷性 | 非常慢。（每個租用戶都需要新的執行個體或叢集。) | 中度緩慢。（需要為每個租用戶建立新的資料庫，以存放結構描述物件。) | 中度緩慢。（需要為每個租用戶建立新的結構描述來存放物件。) | 最快選項。（需要最低設定。) | 
| 資料庫連線集區組態工作量和效率 | 需要大量努力。（每個租用戶一個連線集區。)<br />效率較低。（租用戶之間沒有資料庫連線共用。)  | 需要大量努力。（除非您使用 [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html)，否則每個租用戶一個連線集區組態。) <br />效率較低。（租用戶與連線總數之間沒有資料庫連線共用。 所有租用戶的使用量會根據資料庫執行個體類別而受到限制。) | 需要的精力較少。（適用於所有租用戶的一個連線集區組態。) <br />效率適中。（僅在工作階段集區模式中透過 `SET ROLE`或 `SET SCHEMA`命令重複使用連線。使用 Amazon RDS Proxy 時， `SET`命令也會導致工作階段鎖定，但可以消除用戶端連線集區，並且可以為每個請求進行直接連線以提高效率。) | 需要最少的努力。<br />最有效率。（適用於所有租用戶的一個連線集區，以及適用於所有租用戶的高效連線重複使用。 資料庫連線限制是以資料庫執行個體類別為基礎。) | 
| 資料庫維護 ([清空管理](https://www.postgresql.org/docs/current/routine-vacuuming.html)) 和資源使用量 | 更簡單的管理。 | 中等複雜性。（可能會導致高資源耗用量，因為在 之後，必須為每個資料庫啟動清空工作者vacuum\_naptime，這會導致高自動清空啟動器 CPU 用量。 清空每個資料庫的 PostgreSQL 系統目錄資料表也可能產生額外的額外負荷。) | 大型 PostgreSQL 系統目錄資料表。（總pg\_catalog大小，以十 GBs 為單位，取決於租戶和關係的數量。 可能需要修改清空相關參數，以控制資料表膨脹。) | 資料表可能很大，取決於每個租用戶的租用戶數量和資料。（可能需要修改清空相關參數，以控制資料表膨脹。) | 
| 延伸模組管理工作 | 大量努力 （針對個別執行個體中的每個資料庫）。 | 大量努力 （在每個資料庫層級）。 | 最小努力 （在通用資料庫中一次）。 | 最小努力 （在通用資料庫中一次）。 | 
| 變更部署工作 | 大量努力。（連接至每個個別執行個體並推出變更。) | 大量努力。（連接至每個資料庫和結構描述，並推出變更。) | 中度努力。（連接至通用資料庫並推出每個結構描述的變更。) | 最少的努力。（連接至通用資料庫並推出變更。) | 
| 變更部署 – 影響範圍 | 最小。（單一租戶受影響。) | 最小。（單一租戶受影響。) | 最小。（單一租戶受影響。) | 非常大。（受影響的所有租戶。) | 
| 查詢效能管理和工作 | 可管理的查詢效能。 | 可管理的查詢效能。 | 可管理的查詢效能。 | 可能需要大量精力來維持查詢效能。（隨著時間的推移，由於資料表大小增加，查詢執行速度可能會變慢。 您可以使用資料表分割和資料庫碎片來維持效能。) | 
| 跨租用戶資源影響 | 沒有影響。（租用戶之間沒有資源共用。) | 中度影響。（租用戶共用常見的資源，例如執行個體 CPU 和記憶體。) | 中度影響。（租用戶共用常見的資源，例如執行個體 CPU 和記憶體。) | 嚴重影響。（租用戶在資源、鎖定衝突等方面互相影響。) | 
| 租用戶層級調校 （例如，為每個租用戶建立其他索引，或針對特定租用戶進行資料庫參數調校） | 可能。 | 有些可能。（可以為每個租用戶進行結構描述層級變更，但資料庫參數適用於所有租用戶。) | 有些可能。（可以為每個租用戶進行結構描述層級變更，但資料庫參數適用於所有租用戶。) | 無法。（所有租用戶都會共用資料表。) | 
| 效能敏感租用戶的重新平衡工作 | 最小。（不需要重新平衡。 擴展伺服器和 I/O 資源以處理此案例。) | 中等。（使用邏輯複寫或 pg\_dump 匯出資料庫，但停機時間可能會很長，具體取決於資料大小。 您可以使用 Amazon RDS for PostgreSQL 中的可傳輸資料庫功能，更快速地在執行個體之間複製資料庫。) | 中等但可能涉及長時間的停機時間。（使用邏輯複寫或 pg\_dump 匯出結構描述，但停機時間可能會很長，具體取決於資料大小。) | 重要，因為所有租用戶共用相同的資料表。（碎片資料庫需要將所有項目複製到另一個執行個體，以及清除租戶資料的額外步驟。) <br />最可能需要變更應用程式邏輯。 | 
| 主要版本升級的資料庫停機時間 | 標準停機時間。（取決於 PostgreSQL 系統目錄大小。) | 停機時間可能較長。（視系統目錄大小而定，時間會有所不同。 PostgreSQL 系統目錄資料表也會跨資料庫複製） | 停機時間可能較長。（視 PostgreSQL 系統目錄大小而定，時間會有所不同。) | 標準停機時間。（取決於 PostgreSQL 系統目錄大小。) | 
| 管理開銷 （例如，用於資料庫日誌分析或備份任務監控） | 大量努力 | 最少的努力。 | 最少的努力。 | 最少的努力。 | 
| 租戶層級可用性 | 最高。（每個租戶都會失敗並獨立復原。) | 影響範圍更高。（如果發生硬體或資源問題，所有租戶都會失敗並一起復原。) | 影響範圍更高。（如果發生硬體或資源問題，所有租戶都會失敗並一起復原。) | 影響範圍更高。（如果發生硬體或資源問題，所有租戶都會失敗並一起復原。) | 
| 租戶層級備份和復原工作 | 最少的努力。（每個租用戶都可以獨立備份和還原。) | 中度努力。（為每個租用戶使用邏輯匯出和匯入。 需要一些編碼和自動化。) | 中度努力。（為每個租用戶使用邏輯匯出和匯入。 需要一些編碼和自動化。) | 大量努力。（所有租用戶共用相同的資料表。) | 
| 租戶層級point-in-time復原工作 | 最少的努力。（使用快照來使用時間點復原，或在 Amazon Aurora 中使用恢復。) | 中度努力。（使用快照還原，後面接著匯出/匯入。 不過，這會是慢速操作。) | 中度努力。（使用快照還原，後面接著匯出/匯入。 不過，這會是慢速操作。) | 大量的精力和複雜性。 | 
| 統一結構描述名稱 | 每個租用戶的相同結構描述名稱。 | 每個租用戶的相同結構描述名稱。 | 每個租用戶的不同結構描述。 | 常見結構描述。 | 
| 每個租用戶自訂 （例如，特定租用戶的其他資料表資料欄） | 可能。 | 可能。 | 可能。 | 複雜 （因為所有租用戶共用相同的資料表）。 | 
| 物件關聯映射 (ORM) 層的目錄管理效率 （例如 Ruby) | 有效率 （因為用戶端連線專屬於租用戶）。 | 有效率 （因為用戶端連線專屬於資料庫）。 | 效率適中。（根據使用的 ORM、使用者/角色安全模型和search\_path組態，用戶端有時會快取所有租用戶的中繼資料，導致高資料庫連線記憶體用量。) | 有效率 （因為所有租用戶共用相同的資料表）。 | 
| 合併租戶報告工作 | 大量努力。（您必須使用外部資料包裝函式 【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 叢集整體計數器）。 | 高。（例如，單一資料表可以達到 40 億 TOAST OID 限制，取決於out-of-line資料欄的數量。) |