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

# 在 Amazon Aurora 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/AuroraUserGuide/AuroraPostgreSQL.BestPractices.html#AuroraPostgreSQL.BestPractices.Autovacuum)。使用 [postgres\$1get\$1av\$1diag 公用程式](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/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.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/AuroraUserGuide/blue-green-deployments.html)，因為邏輯複寫依賴 WAL 來擷取和傳輸變更。閱讀如何設定 Aurora PostgreSQL 以[複寫未記錄資料表](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-postgresql-unlogged-tables.html#aurora-postgresql-unlogged-tables-logicalrep)的詳細資訊。

**影響：讀取器節點**  
您只能從 Aurora 資料庫叢集中的寫入器節點存取未記錄的資料表。如需完整詳細資訊，請參閱[在 Aurora PostgreSQL 中使用未記錄的資料表](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-postgresql-unlogged-tables.html)。

**一般最佳實務：**
+ 未記錄資料表在 Aurora 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/AuroraUserGuide/PostgreSQL.ManagingTempFiles.html)，請參閱管理暫存檔案。如果您的工作負載產生大量這些檔案，可能會有幾項影響。

**影響：FreeLocalStorage 耗用量**  
當查詢結果無法容納 work\$1mem 時，暫存檔案是 PostgreSQL 的必要部分。一般而言，這沒問題。不過，當工作負載廣泛使用時，表示大型查詢會持續執行，而您將觀察到 FreeLocalStorage 減少。如需詳細資訊，請參閱[管理暫存檔案](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL.ManagingTempFiles.html)。

**一般最佳實務：**
+ 使用 [Performance Insights ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/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)。

**影響：延長切換時間**  
如果您計劃將 [藍/綠部署](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/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/AuroraUserGuide/blue-green-deployments.html)組態中，這表示藍色環境中的大型物件不會複寫至綠色環境。

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

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

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

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

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