使用 適用於 PostgreSQL 的 Azure 資料庫 單一伺服器建置應用程式的最佳做法
適用於：
適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器
重要
適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器位於淘汰路徑上。 強烈建議您升級至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。 如需移轉至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器的詳細資訊，請參閱單一伺服器 適用於 PostgreSQL 的 Azure 資料庫 發生什麼事？。
以下是一些最佳做法，可協助您使用 適用於 PostgreSQL 的 Azure 資料庫 建置雲端就緒的應用程式。 這些最佳做法可減少應用程式的開發時間。
應用程式和資料庫資源的設定
將應用程式和資料庫保留在相同的區域中
在 Azure 中部署應用程式時，請確定您的所有相依性都位於相同區域中。 將執行個體分散在不同區域或可用性區域會造成網路延遲，可能會影響應用程式的整體效能。
保護您的 PostgreSQL 伺服器安全
將您的 PostgreSQL 伺服器設定為 安全 且無法公開存取。 使用下列其中一個選項來保護您的伺服器：
為了安全性，您必須一律透過SSL連線到PostgreSQL伺服器，並將PostgreSQL伺服器和應用程式設定為使用TLS 1.2。 請參閱如何設定 SSL/TLS。
使用環境變數來取得連線資訊
請勿將資料庫認證儲存在應用程式程式代碼中。 視前端應用程式而定，請遵循指引來設定環境變數。 如需 App Service 使用方式，請參閱 如何設定應用程式設定 和 Azure Kubernetes 服務，請參閱 如何使用 Kubernetes 秘密。
效能和復原
以下是一些工具和做法，可用來協助偵錯應用程式的效能問題。
使用 連線 集區
使用連線共用時，會在啟動時建立一組固定的連線，並維護。 這也有助於減少伺服器上由資料庫伺服器上建立的動態新連線所造成的記憶體分散。 如果應用程式架構或資料庫驅動程式支援連線共用，則可以在應用程式端設定連線共用。 如果不支援，另一個建議的選項是利用 Proxy 連線共用器服務，例如 在應用程式外部執行的 PgBouncer 或 Pgpool ，並連線到資料庫伺服器。 PgBouncer 和 Pgpool 都是與 適用於 PostgreSQL 的 Azure 資料庫 搭配運作的社群式工具。
重試邏輯以處理暫時性錯誤
您的應用程式可能會遇到暫時性錯誤，其中資料庫連線會中斷或間歇性遺失。 在這種情況下，伺服器會在 5 到 10 秒內重試一到兩次之後啟動並執行。 最佳做法是在第一次重試之前等候 5 秒。 然後在每次重試之後，逐漸增加等候時間，最多 60 秒。 限制應用程式將作業考慮為失敗的重試次數上限，以讓您接著進一步調查。 若要深入了解，請參閱如何針對連線錯誤進行疑難排解。
啟用讀取複寫以減輕容錯移轉
您可以在容錯移轉案例中使用資料輸入複寫。 當您使用讀取複本時，來源與複本伺服器之間不會進行自動容錯移轉。 您會注意到來源與複本之間的延遲，因為複寫屬於非同步。 網路延遲可能會受到許多因素影響，例如在來源伺服器上執行的工作負載數量，以及資料中心之間的延遲。 在多數情況下，複本延遲會是幾秒鐘到幾分鐘。
資料庫部署
設定 CI/CD 部署管線
有時候，您必須將變更部署至資料庫。 在這種情況下，您可以透過 PostgreSQL伺服器的 GitHub Actions 使用持續整合 （CI），藉由對其執行自定義腳本來更新資料庫。
定義手動資料庫部署程式
在手動資料庫部署期間，請遵循下列步驟以將停機時間降到最低，或降低部署失敗的風險：
- 使用pg_dump在新資料庫上建立生產資料庫的複本。
- 使用資料庫所需的新結構描述變更或更新來更新新的資料庫。
- 將生產資料庫置於唯讀狀態。 在部署完成之前，您不應該對生產資料庫執行寫入作業。
- 使用步驟 1 中新更新的資料庫測試您的應用程式。
- 部署應用程式變更，並確定應用程式現在使用具有最新更新的新資料庫。
- 保留舊的生產資料庫，以便復原變更。 然後，您可以評估是否刪除舊的生產資料庫，或視需要將其匯出至 Azure 儲存體。
注意
如果應用程式類似電子商務應用程式，而且您無法將其置於唯讀狀態，則請在進行備份之後直接在生產資料庫上部署變更。 這些變更應該在離峰時段且應用程式低流量的時間執行，以將影響降到最低，因為某些使用者可能會遇到失敗的要求。 請確定您的應用程式碼也會處理任何失敗的要求。
資料庫結構描述和查詢
當您建置資料庫結構描述和查詢時，以下是一些要記住的祕訣。
將 BIGINT 或 UUID 用於主鍵
建置自定義應用程式或某些架構時，他們可能會使用 INT 而非 BIGINT 主鍵。 當您使用 INT時，會執行資料庫中值可能超過數據類型儲存 INT 容量的風險。 對現有的生產應用程式進行這項變更，可能需要花費更多開發時間。 另一個選項是針對主鍵使用 UUID 。這個識別元會使用自動產生的 128 位字串，例如 a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11。 深入瞭解 PostgreSQL 數據類型。
使用索引
Postgres 中有許多類型的 索引 ，可透過不同方式使用。 使用索引可協助伺服器尋找和擷取特定數據列的速度比沒有索引還要快。 但是索引也會增加資料庫伺服器的額外負荷，因此請避免索引太多。
使用 autovacuum
您可以在 適用於 PostgreSQL 的 Azure 資料庫 伺服器上使用自動資料清理來優化伺服器。 PostgreSQL 允許更大的資料庫並行存取，但每次更新都會導致插入和刪除。 針對刪除，記錄會以虛標示，稍後將會清除。 若要執行這些工作，PostgreSQL 會執行真空作業。 如果您不不時抽空，累積的無效 Tuple 可能會導致：
- 數據膨脹，例如較大的資料庫和數據表。
- 較大的次佳索引。
- 增加 I/O。
深入瞭解 如何使用自動數據清理進行優化。
使用pg_stats_statements
Pg_stat_statements是預設在 適用於 PostgreSQL 的 Azure 資料庫 中啟用的PostgreSQL擴充功能。 延伸模組提供一種方法來追蹤伺服器所執行之所有 SQL 語句的執行統計數據。 請參閱 如何使用 pg_statement。
使用 查詢存放區
適用於 PostgreSQL 的 Azure 資料庫中的 查詢存放區 功能提供追蹤查詢統計數據的方法。 我們建議此功能作為使用 pg_stats_statements的替代方案。
優化大量插入和使用暫時性數據
如果您有涉及暫時性數據的工作負載作業，或大量插入大型數據集，請考慮使用未記錄的數據表。 它預設會提供不可部分完成性和持久性。 不可部分完成性、一致性、隔離和持久性構成 ACID 屬性。 瞭解如何 優化大量插入。