本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
在 Amazon RDS for PostgreSQL 中管理高物件計數
雖然 PostgreSQL 限制是理論上的，但資料庫中具有極高的物件計數會對各種操作造成顯著的效能影響。本文件涵蓋數種常見的物件類型，當總計數過高時，可能會導致數種影響。
下表提供物件類型及其潛在影響的摘要：
關係
PostgreSQL 資料庫中的資料表數量沒有特定的硬性限制。理論限制非常高，但在資料庫設計期間需要記住其他實際限制。
- 影響：自動清空落後
-
與工作量相比，自動清空可能會難以跟上交易 ID 成長或資料表膨脹的情況。
建議的動作：調整自動清空有幾個因素，可以正確跟上指定數量的資料表和指定工作負載。如需如何判斷適當自動清空設定的建議，請參閱使用 PostgreSQL autovacuum 。使用 postgres_get_av_diag utility來監控交易 ID 成長的問題。
- 影響：主要版本升級/pg_dump 和還原
-
Amazon RDS 在 pg_upgrade 執行期間使用「--link」選項，以避免必須複製資料檔案，結構描述中繼資料仍需要還原至新版本的資料庫。即使使用平行 pg_restore，如果有大量關聯，這也會增加停機時間。
- 影響：一般效能降低
-
由於目錄大小而降低的一般效能。每個資料表及其相關聯的資料欄都會新增至
pg_attribute，pg_class以及常用於一般資料庫操作的pg_depend資料表。不會顯示特定的等待事件，但共用緩衝區效率會受到影響。建議的動作：定期檢查這些特定資料表的資料表膨脹，並偶爾在這些特定資料表
VACUUM FULL上執行 。請注意，在目錄資料表VACUUM FULL上需要ACCESS EXCLUSIVE鎖定，這表示在操作完成之前，其他查詢都無法存取它們。
- 影響：檔案描述項耗盡
-
錯誤：「檔案描述項不足：系統中開啟的檔案太多；發行並重試」。PostgreSQL 參數
max_files_per_process會決定每個程序可以開啟的檔案數量。如果連接大量資料表的連線數量較多，則可能達到此限制。建議的動作：
降低 參數的值
max_files_per_process可能有助於減輕此錯誤。每個程序和子程序 （例如平行查詢） 都可以開啟此數量的檔案，如果查詢正在聯結多個資料表，則會耗盡此限制。減少連線總數，並使用連線集區，例如 Amazon RDS Proxy 或其他解決方案，例如 PgBouncer。如需進一步了解，請參閱 PgBouncer
網站。
- 影響：Inode 耗盡
-
錯誤：「裝置上沒有剩餘空間」。如果觀察到這種情況，表示有足夠的可用儲存空間，這是因為索引用盡。Amazon RDS 增強型監控可為使用中的節點提供可見性，以及主機可用的最大數量。
大約閾值：百萬
暫時資料表
使用暫存資料表對於測試資料或中繼結果很有用，而且是許多資料庫引擎中常見的模式。必須了解 PostgreSQL 中大量使用的影響，以避免某些陷阱。每個暫存資料表的建立和捨棄都會將資料列新增至系統目錄資料表，當資料表膨脹時，會導致一般效能問題。
- 影響：自動清空落後
-
暫時資料表不會由自動清空清空，但會在交易 IDs存在期間保留，若未移除，可能會導致包裝。
建議的動作：暫時資料表會在建立它們的工作階段期間持續運作，或可以手動捨棄。避免使用暫存資料表長時間執行交易的最佳實務，可防止這些資料表產生最大使用的交易 ID 成長。
- 影響：一般效能降低
-
由於目錄大小而降低的一般效能。當工作階段持續建立和捨棄暫存資料表時，它會新增至
pg_attribute，pg_class以及常用於一般資料庫操作的pg_depend資料表。不會顯示特定的等待事件，但共用緩衝區效率會受到影響。建議的動作：
定期檢查這些特定資料表的資料表膨脹，並偶爾在這些特定資料表
VACUUM FULL上執行 。請注意，在目錄資料表VACUUM FULL上需要ACCESS EXCLUSIVE鎖定，這表示在操作完成之前，其他查詢都無法存取它們。如果大量使用暫存資料表，在主要版本升級之前，強烈建議使用這些特定目錄資料表
VACUUM FULL的 ，以減少停機時間。
一般最佳實務：
使用常見的資料表表達式來產生中繼結果，以減少暫時資料表的使用。這些有時可能會使所需的查詢複雜化，但會消除上述影響。
使用
TRUNCATE命令來清除內容，而不是執行捨棄/建立步驟，以重複使用暫存資料表。這也會消除暫時資料表造成交易 ID 成長的問題。
大約閾值：數十萬
未記錄的資料表
未記錄的資料表可以提供效能提升，因為它們不會產生任何 WAL 資訊。必須仔細使用它們，因為它們在資料庫損毀復原期間不會提供任何耐用性，因為它們將被截斷。這是 PostgreSQL 中的昂貴操作，因為每個未記錄的資料表都是序列截斷的。雖然對少量未記錄的資料表而言，此操作速度很快，但當它們以千為單位編號時，它可以開始在啟動期間新增顯著的延遲。
- 影響：邏輯複寫
-
邏輯複寫通常不包含未記錄的資料表，包括藍/綠部署，因為邏輯複寫依賴 WAL 來擷取和傳輸變更。
- 影響：復原期間延長停機時間
-
在涉及資料庫損毀復原的任何資料庫狀態期間，例如具有容錯移轉的異地同步備份重新啟動、Amazon RDS point-in-time復原和 Amazon RDS 主要版本升級，將發生截斷未記錄資料表的序列化操作。這可能會導致比預期高出許多的停機時間體驗。
建議的動作：
將未記錄資料表的使用量降至最低，僅限於資料庫損毀復原操作期間可遺失的資料。
將未記錄資料表的使用降至最低，因為序列截斷的目前行為可能會導致資料庫啟動需要大量時間。
一般最佳實務：
-
未記錄的資料表不會安全當機。啟動涉及損毀復原point-in-time復原會在 PostgreSQL 中花費大量時間，因為這是截斷每個資料表的序列程序。相較於標準 PostgreSQL，
大約閾值：數千
分區
分割可以提高查詢效能並提供資料的邏輯組織。在理想情況下，會組織分割區，以便在查詢規劃和執行期間使用分割區剔除。使用太多分割區可能會對查詢效能和資料庫維護產生負面影響。應謹慎選擇如何分割資料表，因為查詢規劃和執行的效能可能會受到設計不佳的負面影響。如需分割的詳細資訊，請參閱 PostgreSQL 文件
- 影響：一般效能降低
-
有時，規劃時間額外負荷會增加，並解釋查詢的計劃會變得更加複雜，導致難以識別調校機會。對於 18 之前的 PostgreSQL 版本，具有高工作負載的許多分割區可能會導致
LWLock:LockManager等待。建議動作：判斷可讓您完成資料組織，同時提供效能查詢執行的分割區數量下限。
- 影響：維護複雜性
-
非常大量的分割區會導致維護問題，例如建立前和移除。自動清空會將分割區視為一般關係，且必須執行定期清除，因此需要足夠的工作者來完成任務。
建議的動作：
請確定您預先建立分割區，以便在需要新分割區 （例如，每月型分割區） 且舊分割區推出時，不會封鎖工作負載。
確保您有足夠的自動清空工作者，可執行所有分割區的正常清除維護。
大約閾值：數百
暫存檔案
與上述的暫存資料表不同，當複雜的查詢可能同時執行數個排序或雜湊操作時，PostgreSQL 會建立暫存檔案，每個操作會使用執行個體記憶體將結果儲存到 work_mem 參數中指定的值。當執行個體記憶體不足時，會建立暫存檔來儲存結果。如需暫存檔案的詳細資訊，請參閱管理暫存檔案如果您的工作負載產生大量這些檔案，可能會有數種影響。
- 影響：檔案描述項耗盡
-
錯誤：「檔案描述項不足：系統中開啟的檔案太多；發行並重試」。PostgreSQL 參數
max_files_per_process會決定每個程序可以開啟的檔案數量。如果連接大量資料表的連線數量很高，則可能達到此限制。建議的動作：
降低 參數的值
max_files_per_process可能有助於緩解此錯誤。每個程序和子程序 （例如平行查詢） 都可以開啟此數量的檔案，如果查詢正在聯結多個資料表，則會耗盡此限制。減少連線的整體數量，並使用連線集區器，例如 Amazon RDS Proxy 或其他解決方案，例如 PgBouncer。如需進一步了解，請參閱 PgBouncer
網站。
- 影響：Inode 耗盡
-
錯誤：「裝置上沒有剩餘空間」。如果觀察到這種情況，表示有足夠的可用儲存空間，這是因為索引用盡。Amazon RDS 增強型監控可為使用中的節點提供可見性，以及主機可用的最大數量。
一般最佳實務：
使用 Performance Insights監控您的暫存檔案用量。
調校正在產生重要暫存檔案的查詢，以查看是否可以減少暫存檔案的總數。
大約閾值：數千
序列
序列是用於在 PostgreSQL 中自動遞增資料欄的基礎物件，可為資料提供唯一性和金鑰。這些可用於個別資料表，在正常操作期間不會產生任何後果，但邏輯複寫除外。
在 PostgreSQL 中，邏輯複寫目前不會將序列的目前值複寫至任何訂閱者。若要進一步了解，請參閱 PostgreSQL 文件中的限制頁面
- 影響：延長切換時間
-
如果您計劃將 Amazon RDS 藍/綠部署用於任何類型的組態變更或升級，請務必了解大量序列對切換的影響。切換的最後一個階段之一將同步序列的目前值，如果有數千個，這將增加整體切換時間。
建議的動作：如果您的資料庫工作負載允許使用共用 UUID 而非sequence-per-table的方法，這會在切換期間減少同步步驟。
大約閾值：數千
大型物件
大型物件存放在名為 pg_largeobject 的單一系統資料表中。每個大型物件在系統資料表 pg_largeobject_metadata 中也有一個項目。這些物件的建立、修改和清除與標準關係截然不同。大型物件不是由自動清空處理，必須透過稱為 vacuumlo 的個別程序定期清理。如需管理大型物件的範例，請參閱使用 lo 模組管理大型物件。
- 影響：邏輯複寫
-
在邏輯複寫期間，目前不會在 PostgreSQL 中複寫大型物件。若要進一步了解，請參閱 PostgreSQL 文件中的限制頁面
。在藍色/綠色組態中，這表示藍色環境中的大型物件不會複寫至綠色環境。 - 影響：主要版本升級
-
如果有數百萬個大型物件，且執行個體無法在升級期間處理它們，則升級可能會耗盡記憶體並失敗。PostgreSQL 主要版本升級程序包含兩個大階段：透過 pg_dump 傾印結構描述，並透過 pg_restore 還原結構描述。如果您的資料庫有數百萬個大型物件，您需要確保您的執行個體在升級期間有足夠的記憶體來處理 pg_dump 和 pg_restore，並將其擴展到更大的執行個體類型。
一般最佳實務：
定期使用 vacuumlo 公用程式移除您可能擁有的任何孤立大型物件。
考慮使用 BYTEA 資料類型將大型物件存放在資料庫中。
大約閾值：百萬
大約閾值
本主題中提到的大約閾值僅用於提供特定資源可擴展程度的估計。它們代表一般範圍，其中描述的影響變得更有可能，但實際行為取決於您的特定工作負載、執行個體大小和組態。雖然可能超過這些預估值，但必須遵守注意和維護，以避免列出的影響。
