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

# 在 Amazon RDS for PostgreSQL 中管理高物件計數
<a name="PostgreSQL.HighObjectCount"></a>

雖然 PostgreSQL 限制是理論上的，但資料庫中具有極高的物件計數會對各種操作造成顯著的效能影響。本文件涵蓋數種常見的物件類型，當總計數過高時，可能會導致數種影響。

下表提供物件類型及其潛在影響的摘要：


**物件類型和潛在影響**  

| 物件的類型 | 自動清空 | 邏輯複寫 | 主要版本升級 | pg\$1dump / pg\$1restore | 一般效能 | 執行個體重新啟動 | 
| --- | --- | --- | --- | --- | --- | --- | 
| [關係](#PostgreSQL.HighObjectCount.Relations) | x |  | x | x | x |  | 
| [暫時資料表](#PostgreSQL.HighObjectCount.TempTables) | x |  |  |  | x |  | 
| [未記錄的資料表](#PostgreSQL.HighObjectCount.UnloggedTables) |  | x |  |  |  | x | 
| [分區](#PostgreSQL.HighObjectCount.Partitions) |  |  |  |  | x |  | 
| [暫存檔案](#PostgreSQL.HighObjectCount.TempFiles) |  |  |  |  | x |  | 
| [序列](#PostgreSQL.HighObjectCount.Sequences) |  | x |  |  |  |  | 
| [大型物件](#PostgreSQL.HighObjectCount.LargeObjects) |  | x | x |  |  |  | 

## 關係
<a name="PostgreSQL.HighObjectCount.Relations"></a>

PostgreSQL 資料庫中的資料表數量沒有特定的硬性限制。理論限制非常高，但在資料庫設計期間需要記住其他實際限制。

**影響：自動清空落後**  
與工作量相比，自動清空可能會難以跟上交易 ID 成長或資料表膨脹的情況。  
**建議的動作：**調整自動清空有幾個因素，可以正確跟上指定數量的資料表和指定工作負載。如需如何判斷適當自動清空設定的建議[，請參閱使用 PostgreSQL autovacuum](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) 。使用 [postgres\$1get\$1av\$1diag utility](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html)來監控交易 ID 成長的問題。

**影響：主要版本升級/pg\$1dump 和還原**  
Amazon RDS 在 pg\$1upgrade 執行期間使用「--link」選項，以避免必須複製資料檔案，結構描述中繼資料仍需要還原至新版本的資料庫。即使使用平行 pg\$1restore，如果有大量關聯，這也會增加停機時間。

**影響：一般效能降低**  
由於目錄大小而降低的一般效能。每個資料表及其相關聯的資料欄都會新增至 `pg_attribute`，`pg_class`以及常用於一般資料庫操作的`pg_depend`資料表。不會顯示特定的等待事件，但共用緩衝區效率會受到影響。  
**建議的動作：**定期檢查這些特定資料表的資料表膨脹，並偶爾在這些特定資料表`VACUUM FULL`上執行 。請注意，在目錄資料表`VACUUM FULL`上需要`ACCESS EXCLUSIVE`鎖定，這表示在操作完成之前，其他查詢都無法存取它們。

**影響：檔案描述項耗盡**  
錯誤：「檔案描述項不足：系統中開啟的檔案太多；發行並重試」。PostgreSQL 參數`max_files_per_process`會決定每個程序可以開啟的檔案數量。如果連接大量資料表的連線數量較多，則可能達到此限制。  
**建議的動作：**  
+ 降低 參數的值`max_files_per_process`可能有助於減輕此錯誤。每個程序和子程序 （例如平行查詢） 都可以開啟此數量的檔案，如果查詢正在聯結多個資料表，則會耗盡此限制。
+ 減少連線總數，並使用連線集區，例如 [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) 或其他解決方案，例如 PgBouncer。如需進一步了解，請參閱 [PgBouncer](https://www.pgbouncer.org/) 網站。

**影響：Inode 耗盡**  
錯誤：「裝置上沒有剩餘空間」。如果觀察到這種情況，表示有足夠的可用儲存空間，這是因為索引用盡。[Amazon RDS 增強型監控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)可為使用中的節點提供可見性，以及主機可用的最大數量。

**大約閾值：**[百萬](#PostgreSQL.HighObjectCount.Note)

## 暫時資料表
<a name="PostgreSQL.HighObjectCount.TempTables"></a>

使用暫存資料表對於測試資料或中繼結果很有用，而且是許多資料庫引擎中常見的模式。必須了解 PostgreSQL 中大量使用的影響，以避免某些陷阱。每個暫存資料表的建立和捨棄都會將資料列新增至系統目錄資料表，當資料表膨脹時，會導致一般效能問題。

**影響：自動清空落後**  
暫時資料表不會由自動清空清空，但會在交易 IDs存在期間保留，若未移除，可能會導致包裝。  
**建議的動作：**暫時資料表會在建立它們的工作階段期間持續運作，或可以手動捨棄。避免使用暫存資料表長時間執行交易的最佳實務，可防止這些資料表產生最大使用的交易 ID 成長。

**影響：一般效能降低**  
由於目錄大小而降低的一般效能。當工作階段持續建立和捨棄暫存資料表時，它會新增至 `pg_attribute`，`pg_class`以及常用於一般資料庫操作的`pg_depend`資料表。不會顯示特定的等待事件，但共用緩衝區效率會受到影響。  
**建議的動作：**  
+ 定期檢查這些特定資料表的資料表膨脹，並偶爾在這些特定資料表`VACUUM FULL`上執行 。請注意，在目錄資料表`VACUUM FULL`上需要`ACCESS EXCLUSIVE`鎖定，這表示在操作完成之前，其他查詢都無法存取它們。
+ 如果大量使用暫存資料表，在主要版本升級之前，強烈建議使用這些特定目錄資料表`VACUUM FULL`的 ，以減少停機時間。

**一般最佳實務：**
+ 使用常見的資料表表達式來產生中繼結果，以減少暫時資料表的使用。這些有時可能會使所需的查詢複雜化，但會消除上述影響。
+ 使用 `TRUNCATE`命令來清除內容，而不是執行捨棄/建立步驟，以重複使用暫存資料表。這也會消除暫時資料表造成交易 ID 成長的問題。

**大約閾值：**[數十萬](#PostgreSQL.HighObjectCount.Note)

## 未記錄的資料表
<a name="PostgreSQL.HighObjectCount.UnloggedTables"></a>

未記錄的資料表可以提供效能提升，因為它們不會產生任何 WAL 資訊。必須仔細使用它們，因為它們在資料庫損毀復原期間不會提供任何耐用性，因為它們將被截斷。這是 PostgreSQL 中的昂貴操作，因為每個未記錄的資料表都是序列截斷的。雖然對少量未記錄的資料表而言，此操作速度很快，但當它們以千為單位編號時，它可以開始在啟動期間新增顯著的延遲。

**影響：邏輯複寫**  
邏輯複寫通常不包含未記錄的資料表，包括[藍/綠部署](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)，因為邏輯複寫依賴 WAL 來擷取和傳輸變更。

  


**影響：復原期間延長停機時間**  
在涉及資料庫損毀復原的任何資料庫狀態期間，例如具有容錯移轉的異地同步備份重新啟動、Amazon RDS point-in-time復原和 Amazon RDS 主要版本升級，將發生截斷未記錄資料表的序列化操作。這可能會導致比預期高出許多的停機時間體驗。  
**建議的動作：**  
+ 將未記錄資料表的使用量降至最低，僅限於資料庫損毀復原操作期間可遺失的資料。
+ 將未記錄資料表的使用降至最低，因為序列截斷的目前行為可能會導致資料庫啟動需要大量時間。

**一般最佳實務：**
+ 未記錄的資料表不會安全當機。啟動涉及損毀復原point-in-time復原會在 PostgreSQL 中花費大量時間，因為這是截斷每個資料表的序列程序。相較於標準 PostgreSQL，

**大約閾值：**[數千](#PostgreSQL.HighObjectCount.Note)

## 分區
<a name="PostgreSQL.HighObjectCount.Partitions"></a>

分割可以提高查詢效能並提供資料的邏輯組織。在理想情況下，會組織分割區，以便在查詢規劃和執行期間使用分割區剔除。使用太多分割區可能會對查詢效能和資料庫維護產生負面影響。應謹慎選擇如何分割資料表，因為查詢規劃和執行的效能可能會受到設計不佳的負面影響。如需分割的詳細資訊，請參閱 [PostgreSQL 文件](https://www.postgresql.org/docs/current/ddl-partitioning.html)。

**影響：一般效能降低**  
有時，規劃時間額外負荷會增加，並解釋查詢的計劃會變得更加複雜，導致難以識別調校機會。對於 18 之前的 PostgreSQL 版本，具有高工作負載的許多分割區可能會導致`LWLock:LockManager`等待。  
**建議動作：**判斷可讓您完成資料組織，同時提供效能查詢執行的分割區數量下限。

**影響：維護複雜性**  
非常大量的分割區會導致維護問題，例如建立前和移除。自動清空會將分割區視為一般關係，且必須執行定期清除，因此需要足夠的工作者來完成任務。  
**建議的動作：**  
+ 請確定您預先建立分割區，以便在需要新分割區 （例如，每月型分割區） 且舊分割區推出時，不會封鎖工作負載。
+ 確保您有足夠的自動清空工作者，可執行所有分割區的正常清除維護。

**大約閾值：**[數百](#PostgreSQL.HighObjectCount.Note)

## 暫存檔案
<a name="PostgreSQL.HighObjectCount.TempFiles"></a>

與上述的暫存資料表不同，當複雜的查詢可能同時執行數個排序或雜湊操作時，PostgreSQL 會建立暫存檔案，每個操作會使用執行個體記憶體將結果儲存到 `work_mem` 參數中指定的值。當執行個體記憶體不足時，會建立暫存檔來儲存結果。如需[暫存](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html)檔案的詳細資訊，請參閱管理暫存檔案如果您的工作負載產生大量這些檔案，可能會有數種影響。

  


**影響：檔案描述項耗盡**  
錯誤：「檔案描述項不足：系統中開啟的檔案太多；發行並重試」。PostgreSQL 參數`max_files_per_process`會決定每個程序可以開啟的檔案數量。如果連接大量資料表的連線數量很高，則可能達到此限制。  
**建議的動作：**  
+ 降低 參數的值`max_files_per_process`可能有助於緩解此錯誤。每個程序和子程序 （例如平行查詢） 都可以開啟此數量的檔案，如果查詢正在聯結多個資料表，則會耗盡此限制。
+ 減少連線的整體數量，並使用連線集區器，例如 [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) 或其他解決方案，例如 PgBouncer。如需進一步了解，請參閱 [PgBouncer](https://www.pgbouncer.org/) 網站。

**影響：Inode 耗盡**  
錯誤：「裝置上沒有剩餘空間」。如果觀察到這種情況，表示有足夠的可用儲存空間，這是因為索引用盡。[Amazon RDS 增強型監控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)可為使用中的節點提供可見性，以及主機可用的最大數量。

**一般最佳實務：**
+ 使用 [Performance Insights](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)監控您的暫存檔案用量。
+ 調校正在產生重要暫存檔案的查詢，以查看是否可以減少暫存檔案的總數。

**大約閾值：**[數千](#PostgreSQL.HighObjectCount.Note)

## 序列
<a name="PostgreSQL.HighObjectCount.Sequences"></a>

序列是用於在 PostgreSQL 中自動遞增資料欄的基礎物件，可為資料提供唯一性和金鑰。這些可用於個別資料表，在正常操作期間不會產生任何後果，但邏輯複寫除外。

在 PostgreSQL 中，邏輯複寫目前不會將序列的目前值複寫至任何訂閱者。若要進一步了解，請參閱 [ PostgreSQL 文件中的限制頁面](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)。

**影響：延長切換時間**  
如果您計劃將 [Amazon RDS 藍/綠部署](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)用於任何類型的組態變更或升級，請務必了解大量序列對切換的影響。切換的最後一個階段之一將同步序列的目前值，如果有數千個，這將增加整體切換時間。  
**建議的動作：**如果您的資料庫工作負載允許使用共用 UUID 而非sequence-per-table的方法，這會在切換期間減少同步步驟。

**大約閾值：**[數千](#PostgreSQL.HighObjectCount.Note)

## 大型物件
<a name="PostgreSQL.HighObjectCount.LargeObjects"></a>

大型物件存放在名為 pg\$1largeobject 的單一系統資料表中。每個大型物件在系統資料表 pg\$1largeobject\$1metadata 中也有一個項目。這些物件的建立、修改和清除與標準關係截然不同。大型物件不是由自動清空處理，必須透過稱為 vacuumlo 的個別程序定期清理。如需管理大型物件的範例，請參閱使用 lo 模組管理大型物件。

**影響：邏輯複寫**  
在邏輯複寫期間，目前不會在 PostgreSQL 中複寫大型物件。若要進一步了解，請參閱 [ PostgreSQL 文件中的限制頁面](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)。在[藍色/綠色](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)組態中，這表示藍色環境中的大型物件不會複寫至綠色環境。

**影響：主要版本升級**  
如果有數百萬個大型物件，且執行個體無法在升級期間處理它們，則升級可能會耗盡記憶體並失敗。PostgreSQL 主要版本升級程序包含兩個大階段：透過 pg\$1dump 傾印結構描述，並透過 pg\$1restore 還原結構描述。如果您的資料庫有數百萬個大型物件，您需要確保您的執行個體在升級期間有足夠的記憶體來處理 pg\$1dump 和 pg\$1restore，並將其擴展到更大的執行個體類型。

**一般最佳實務：**
+ 定期使用 vacuumlo 公用程式移除您可能擁有的任何孤立大型物件。
+ 考慮使用 BYTEA 資料類型將大型物件存放在資料庫中。

**大約閾值：**[百萬](#PostgreSQL.HighObjectCount.Note)

## 大約閾值
<a name="PostgreSQL.HighObjectCount.Note"></a>

本主題中提到的大約閾值僅用於提供特定資源可擴展程度的估計。它們代表一般範圍，其中描述的影響變得更有可能，但實際行為取決於您的特定工作負載、執行個體大小和組態。雖然可能超過這些預估值，但必須遵守注意和維護，以避免列出的影響。