規劃適用於 PostgreSQL 的 Azure 資料庫部署以提升運營效能

雲端運算徹底改變了資料庫託管的格局。它讓團隊能夠獲得過去無法取得的可擴展性、韌性、全球觸及能力。團隊現在不必再因規劃最大工作量（並從第一天起承擔）而產生龐大成本與間接費用，而是能依需求調整所需的精確規模，並在需求變化時調整。

Introduction

能夠靈活選擇適當資源平衡，對於 PostgreSQL 資料庫部署尤其有價值。 PostgreSQL 資料庫工作負載可能從小規模開始，快速成長，季節性激增，從大量讀取轉向以寫入為主，或從交易型工作負載演變成即時的混合營運與分析系統。適用於 PostgreSQL 的 Azure 資料庫透過提供涵蓋計算、儲存、可用性、複寫、安全性、備份及營運管理等多元選擇，確保您的解決方案達成目標。

但擁有這些權力也伴隨著責任，尤其是在規劃部署時。為了達到最佳效能，你的部署決策必須符合整體工作負載的需求。

成功的適用於 PostgreSQL 的 Azure 資料庫部署，不僅僅是選擇「我們需要最多的核心與記憶體」的問題。相反地，最大的營運效能來自於理解應用程式的行為、客戶端的行為、運算、儲存和資料庫成長特性，以及這些特性如何相互交織與互動。

最好的架構是這些部分有意識地排列在一起。

雲端效能規劃是一項共同責任

遷移到可信雲端平台的主要好處之一是共同責任模式。 Microsoft 提供全球基礎建設、管理服務、硬體創新、可靠性、安全性及營運工程。您的團隊具備特定的應用情境專業知識：業務關鍵性、工作負載行為、資料模型設計、網路流量輪廓、成長預期、復原目標，以及終端使用者體驗需求。

當這兩股力量結合時，最強的結果就會產生。

Azure 提供高度可擴展的 Postgres 基礎架構，但您的團隊必須為以下領域帶來洞察：

在正常時段和高峰期，預計會有多少同時使用者？
最重要的操作是讀取為主、寫入為主，還是混合操作？
需求會在月底、季度末、假日、新品發表或報告時段激增嗎？
資料集成長速度如何？
哪些操作對延遲敏感？
哪些查詢或工作能容忍較長的執行時間？
工作量主要是 OLTP、OLAP 還是混合式？
客戶是位於資料庫區域附近、全球分布，還是集中在同一地理區域？

這些細節應在部署前擷取，而非生產事件後。雲端部署讓擴展更容易，但即使是效能最高、最具成本效益的設計，仍是從完善的需求蒐集與妥善規劃開始。在大多數情況下，這些問題可歸結為跨同時連線的關係、最大IOPS及所需吞吐量。

效能有多層次

資料庫效能很少由單一設定決定。成功的部署經驗依賴多個層次的協同合作：

應用層效能。
此層包含應用程式程式碼、查詢模式、索引覆蓋率、觸發器使用、資料分割、連線處理、快取、重試邏輯、池化、ORM 行為、交易設計及背景工作行為。
客戶端與網路層的效能。
此層包括用戶端所在位置、連線方式、請求是否跨區域與可用性區域、網路延遲、TLS 開銷、連線流失，以及應用程式是否有效使用連線池。
資料庫平台效能。
此層包含 Postgres 部署設定、運算容量、記憶體、CPU、儲存類型、儲存容量、儲存 IOPS、儲存吞吐量、高可用性、副本及維護操作。

本文主要聚焦第三層：規劃 Azure Postgres 資料庫部署，使運算與儲存選項能支援所需的效能配置。

適用於 PostgreSQL 的 Azure 資料庫提供彈性，但規劃是必須的

適用於 PostgreSQL 的 Azure 資料庫彈性伺服器提供多種部署選項，包括：

部署區域	可選選項
Compute	計算層級、虛擬機（VM）世代、通用配置，以及記憶體最佳化配置。
儲存體	Azure Premium SSD v1、Premium SSD v2、儲存擴展、IOPS 配置和吞吐量設定。
Availability	高可用性、備份與還原，以及支援配置下的地理冗餘備份。
Replication	閱讀複本和地理複本。
安全性	客戶管理的金鑰與企業安全整合。

這種彈性非常強大，因為不同工作負載需要不同的能力。以寫入為主的交易系統不需要像以報告為主的系統那樣的設定檔。全球性的 SaaS 應用程式不需要與內部區域應用相同的設計。一個每年成長 5% 的資料庫，不需要和一個每月成長 200% 的資料庫相同的儲存方案。

規劃目標是識別您的工作負載效能配置需求，並在計算與儲存選項間實施適當的選擇，以成功交付端到端解決方案。

從工作負載設定開始

在選擇運算或儲存之前，先定義工作負載。有用的規劃考量包括：

規劃區域	需要回答的問題
地理位置	使用者、應用程式、副本和整合資料都位於哪裡？
Concurrency	預期同時連線和主動查詢數量是多少？
數據大小	目前的資料庫規模是多少？預期的成長率是多少？
變化速率	數據每月增長的速度有多快？會產生多少預先寫入日誌（WAL）？
工作負載類型	系統是 OLTP、OLAP、報表重、批次重還是混合型？
讀寫混合	有多少比例的操作是讀取與寫入？
峰值行為	是否有可預測的商業週期、季節性高峰或批次時段？
延遲敏感度	哪些交易是面向使用者且延遲關鍵的？
吞吐量需求	是否有大型資料掃描、匯出、匯入，或是擷取、轉換與載入（ETL）流程？
調整期望值	工作量需要暫時的爆發還是持續的更高表現？

目標不是完美預測未來。目標是避免盲目設計。

了解三大核心儲存效能概念

Azure 儲存效能規劃通常歸結為三個相關但不同的概念：IOPS、吞吐量與延遲。這些因素對應用程式效能規劃至關重要。

IOPS

IOPS 指的是每秒的輸入/輸出運算。它衡量資料庫每秒可傳送多少讀寫操作到儲存。

IOPS 對於 OLTP 工作負載尤其重要。這些系統經常執行許多小型隨機讀寫，例如插入、更新、索引查詢、點讀取及短交易。即使每個操作都很小，交易型工作負載中有數千名並行使用者，也可能需要高 IOPS。

常見的 IOPS 敏感情境包括：

高量訂單處理
使用者檔案更新
庫存系統
事件導入
支付或計費系統
高並發的 SaaS 應用程式

Throughput

吞吐量，有時稱為頻寬，衡量隨時間可從儲存讀取或寫入的資料量。它以MB/s來表示。

當操作移動大量資料時，吞吐量很重要。分析查詢、備份、還原、批次工作、索引建置、資料表掃描和 ETL 工作流程可能需要高吞吐量，即使不需要最高 IOPS。

常見的吞吐量敏感情境包括：

大型資料表上的報告查詢
散裝進出口
資料倉儲式掃描
備份與還原作業
大型索引建立或重建操作
批次處理

延遲

延遲是指單一 I/O 請求完成所需的時間。低延遲對於面向使用者的資料庫操作至關重要，尤其當許多小型操作串連成交易時。

系統理論上可能有很高的 IOPS，但如果延遲很高，仍然會感覺很慢。對於 Postgres 工作負載，儲存延遲會直接影響查詢回應時間、交易提交行為、檢查點行為以及整體應用程式的響應速度。

備註

高級 SSD v1 硬碟設計為大多數 I/O 操作的單位數毫秒延遲，值得注意的是，磁碟快取能進一步降低 4 TB 以下磁碟配置的讀取延遲。 Premium SSD v2 和 Ultra Disk 提供亞毫秒延遲。

IOPS、吞吐量與延遲必須共同考量

IOPS 和吞吐量是連結的。一個工作負載發出多個小型 8 KiB 操作時，可能會帶來高 IOPS，但吞吐量不高。若工作負載能發出多 MB 運算，可能會以較低的 IOPS 帶來高吞吐量。

一個簡單的思考方式：

IOPS x I/O 大小 = 吞吐量

對 Postgres 而言，實際意義是工作負載儲存規劃應基於觀察或估計的工作負載行為，而非僅僅資料庫大小。例如：

高並行 OLTP 系統可能需要更高的 IOPS 和更低的延遲。
報告量大的系統可能需要更高的吞吐量。
混合系統可能需要兩者，尤其是在尖峰週期。
高並行 OLTP 系統可能需要更高的 IOPS 和更低的延遲。
報告量大的系統可能需要更高的吞吐量。
混合系統可能需要兩者，尤其是在尖峰週期。

你的部署選擇直接影響儲存效能

一個常見錯誤是將儲存空間設定為目標效能數值，卻未充分考慮你所選的運算 SKU 是否能驅動相同的效能水準。

Azure 儲存效能有多項考量。這些詳細資料包括：

計算能力設定（最大運算IOPS與吞吐量限制）。
儲存世代（SSD v1、SSD v2、超強磁碟）。
儲存磁碟大小（當 SSD v1 磁碟小於 4,096 GB 時，會包括主機快取功能，這允許 IOPS 的突發性能超出標準基準值）。
儲存的 IOPS 容量。
儲存吞吐量容量。

實際上： 你的有效效能上限是鏈條中最低的相關限制。

如果儲存配置能提供 80,000 IOPS，但運算 SKU 只能驅動 20,000 IOPS，那麼部署就不會達到 80,000 IOPS。相反地，如果虛擬機世代支援高 IOPS，但所選儲存層級的上限較低，則該儲存層級成為限制。

運算與儲存規劃應該同時進行。

高效能 SSD v1：具備強勁的基線效能與重要的快取特性

Premium SSD v1 是生產環境 Azure Postgres 工作負載中常見的選擇，這些工作負載需要可預測且已配置的效能。 Azure Postgres SSD v1 儲存支援最高 32 TB 空間、20,000 IOPS，以及 900 MB/s 吞吐量。

高級 SSD v1 對於需要主機快取的工作負載來說表現良好。 Azure Postgres 支援 SSD v1 磁碟容量小於 4,096 GB 的主機快取。任何配置最多到 4,095 GB 的磁碟都可以從主機快取中受益。一旦儲存空間配置到 4,096 GB 或以上，主機快取就不支援。 這個界線很重要。 對於 4 TB 以下的高級 SSD v1 部署，快取可以提升讀取效能並降低讀取延遲。這種快取對於讀取量大或混合工作負載且低於快取門檻的環境，創造了極佳的成本效益。

為什麼 4TB 的邊界很重要

當高級 SSD v1 部署超出快取支援範圍時，效能配置可能會改變：

讀取操作不再受益於主機快取。
更多讀取操作直接來自底層磁碟。
讀取次數計入磁碟 IOPS 和吞吐量限制。
延遲敏感的讀取負載可能會有不同的行為。
先前高效的配置可能需要更多配置 IOPS、更高吞吐量、計算擴展、查詢調整或不同的儲存選項。

超過4TB還不錯，但你必須 提前做好準備 。

如果你預期資料庫會超過 4 TB，請考慮架構設計時的未來狀態。若設計在 2 TB 有快取時表現良好，則可能需要在 5 TB 無快取時採用不同的效能計畫。

突增能力有助於應對高峰，但無法取代持續的容量

Azure Postgres Premium SSD v1 在儲存分配低於 4-TB 時支援主機快取加速，這在以下情境下有幫助：

創業活動
短批次工作
交通激增
月末處理
臨時工作量激增

雖然爆破很有用，但要小心使用。爆裂可以吸收暫時的峰值，但不應該成為持續工作量需求的基礎。如果工作負載經常超過基準值，最好是設定更高的效能層級、調整儲存效能設定、擴展運算規模，或重新設計工作負載模式。

一個好的規劃問題是： 這是暫時的高峰，還是已成為新常態？

暫時性的高峰可能是爆裂的好可能。透過有意識的容量規劃來應對持續需求。

高級 SSD v2 將容量、IOPS 與吞吐量分離

Premium SSD v2 透過將磁碟大小、IOPS 和吞吐量解耦來改變規劃模式。適用於 PostgreSQL 的 Azure 資料庫彈性伺服器 Premium SSD v2 支援：

容量從 32 GB 到 64 TB。
最高可達 80,000 IOPS。
最高可達 1,200 MB/s 的吞吐量。
以 1 GB 為單位進行細緻容量調整。
彈性的 IOPS 與吞吐量配置。
延遲比高級 SSD v1 低。
不啟用主機快取。

這項變革是一項重大轉變。 Premium SSD v1 的效能與磁碟容量之間的關聯更加緊密。 Premium SSD v2 可以更直接地根據工作負載需求來設定效能。

例如，一個交易密集型資料庫可能需要高 IOPS，卻不需要大量儲存空間。 Azure Postgres 提供基線 IOPS 與吞吐量且無需額外費用，且可額外付費提供額外的 IOPS 與吞吐量。 Premium SSD v2 提供：

最高 399 GB 的磁碟可獲得 3,000 IOPS 和 125 MB/s 的基準速度。
400 GB 或以上的磁碟基線為 12,000 IOPS 與 500 MB/s。
當磁碟擴充至至少 160 GB 可用空間時，最高可達 80,000 IOPS 。
吞吐量可擴展至 1,200 MB/s。

當您需要更精確控制成本與效能時，高級 SSD v2 通常很有吸引力。與其為了解鎖效能而擴充儲存容量，不如更有意識地配置效能。

超高階磁碟（預覽版）：高端 Azure 磁碟性能等級

超大型磁碟是效能最高的磁碟選項。 Azure Ultra Disk 提供最高效能等級：

400,000 IOPS
10,000 MB/s 吞吐量
64 TB 容量
亞毫秒延遲設計目標
獨立可設定容量、IOPS 與吞吐量

超強磁碟儲存設計用以支援頂尖資料庫、SAP Hana 及交易密集系統的 IO 密集型工作負載。這項全新儲存方案為您的關鍵任務負載提供頂尖效能。然而，您的團隊在規劃部署時必須考慮一些關鍵部署能力、區域可用性限制及配置選項：

使用超光碟的伺服器不支援儲存空間自動擴充
使用客戶管理金鑰的資料加密不支援於擁有 Ultra Disk 的伺服器
超大磁碟不支援磁碟快取

了解超強磁碟功能作為 Azure 儲存效能整體的一部分非常重要。不過，你必須驗證你特定 Azure Postgres 工作負載的服務可用性與支援。請向你的 Microsoft 代表確認 Ultra Disk 預覽版是否適用於你的 Azure Postgres 部署。

實務上的結論是：Ultra Disk 代表Azure儲存效能的上限，但你的端對端 Postgres 設計必須包含針對所選計算 SKU、區域及版本等級的可比支援組合。

虛擬機世代很重要：V5 與 V6 的運算儲存上限不同

計算生成會顯著影響儲存效能。當你探索 Azure 儲存效能的最高端時，請避免誤以為「大型運算」自動等同於「最大儲存空間」。你必須驗證所選的運算 SKU 是否符合預期儲存層級。我們以兩個大小相近的計算世代來說明這一點， Ddsv5 並且 Ddsv6：

Ddsv5系列在虛擬機家族層級支援進階儲存體（含快取）、Premium SSD v2 及超強磁碟。然而，虛擬機的總體遠端儲存限制仍舊確定了該虛擬機所能運行的上限。 Ddsv5系列提供最高 80,000 IOPS 與 2,600 MB/s 的儲存效能。

Ddsv6系列提供更高的儲存空間，最高可達 400,000 IOPS 與 12,000 MB/s。 V6 系列運算能力也比前幾代更具擴展性，最高可達 192 顆 vCPU 與 768 GiB 記憶體。

這種世代的變化對高效能 Postgres 設計非常重要。若目標架構需要高儲存效能，選擇集合儲存上限較低的運算世代，可能會阻礙部署充分發揮儲存能力。

範例：為何端對端對齊很重要

考慮一個以 400,000 IOPS 為理想目標的 PostgreSQL 工作負載。

在磁碟層，Azure Ultra Disk 支援每片磁碟最高 400,000 IOPS。 Premium SSD v2 支援每顆硬碟最高可達 80,000 IOPS，而較高階的聚合器設計則可能需要多顆硬碟或平台層級的抽象，視服務支援而定。

但僅有儲存能力是不夠的。

V5系列配置的儲存上限可能低於目標。如前所述，V5 系列 SKU 支援最高 260,000 IOPS 的高級 SSD 遠端磁碟吞吐量。在這種情況下，選擇 V5 系列計算層作為目標目標，成為達成 400,000 IOPS 目標前的限制因素。

相比之下，Ddsv6 系列文件提供高達 400,000 IOPS 與 12,000 MB/s 的傳輸速率。這使得 V6 系列及更新一代產品對於需要將運算與儲存整合到最高儲存效能等級的設計來說具有戰略重要性。

這個教訓很簡單： 最大資料庫效能是端對端的特性，而非僅是儲存的特性。

要規劃商業週期，而不只是穩定狀態

許多系統沒有單一的效能配置檔。他們有好幾個：


平日正常的交通。	高峰營業時間。
月末或季末處理。	假期或季節性需求。
產品發表會。	報告時段
維護期間。	Azure Batch 引入期間。
備份與還原案例。	災難復原事件。

一個以平均使用率為基準的資料庫，在最重要的時刻可能會表現不佳。相反地，一個資料庫若為每月一次的高峰而永久設定大小，可能會是不必要的昂貴。

Azure 的彈性讓團隊能做出更細膩的決策。例如：

使用 Premium SSD v2 來隨著工作負載需求變化調整 IOPS 和吞吐量。
在適當情況下，使用讀取副本來卸載大量讀取的工作負載。
用比例計算已知的高峰期。
在擴展基礎設施前，先調整查詢、索引和連線池。
利用可觀察性來辨識瓶頸是 CPU、記憶體、IOPS、吞吐量、鎖爭用、連線壓力或查詢設計。

最好的部署不一定是規模最大的部署。這是與工作量相匹配且可以安全發展的設計。

可觀察性是架構的一部分

績效規劃不應該只停留在部署。 Postgre 的工作負載會隨時間改變。資料會成長，查詢模式會改變，新功能會上線，客戶流量會變動，營運工作也會累積。

監視區域	待檢討的訊號
Compute	CPU 利用率與記憶體壓力。
連接	主動連線、閒置連線，以及連線池行為。
查詢	查詢時長、查詢計畫變更及索引使用。
儲存體	儲存百分比、讀取延遲、寫入延遲、IOPS 利用率及吞吐量統計。
Maintenance	表格膨脹、索引膨脹、WAL 特性、備份排程與維護排程。
Replication	複刻延遲，如果相關。

適用於 PostgreSQL 的 Azure 資料庫文件強調透過 Azure 入口網站或 Azure CLI 監控 I/O 消耗，包括儲存限制、儲存百分比、使用量儲存空間及 I/O 百分比。

這些指標有助於回答最重要的營運問題： 究竟是哪一層真正限制了效能？

沒有可觀察性，團隊可能會選擇錯誤的擴展。查詢計畫的問題看起來像是儲存問題。連線風暴可能會產生類似 CPU 壓力的情況。缺少索引可能會看起來像是 IOPS 不足。區域客戶端放置問題可能看起來像是資料庫延遲。

監控幫助團隊做出有針對性的改變，而非昂貴的猜測。

實務規劃檢查清單

在選擇生產版適用於 PostgreSQL 的 Azure 資料庫配置前，請先擷取以下資訊。

類別	規劃投入
工作負載類型	OLTP、OLAP、混合、報表、批次與匯入。
讀寫混合	百分比讀取、寫入、隨機輸入輸出和順序輸入輸出。
目前表現	基準的 IOPS、吞吐量、延遲、CPU、記憶體和連線。
巔峰表現	第90百分位和第99百分位的工作量要求。
數據大小	目前規模、預期成長、大型物件使用率及指數成長。
成長率	月比月比及年比儲存預測。
Concurrency	活躍會話、閒置會話，以及連線池行為。
商業週期	日常、每週、每月、季節性及因產品推出引發的高峰。
Availability	高可用性、副本、災難復原、備份、還原、復原點目標（RPO）及復原時間目標（RTO）。
儲存選擇	高級 SSD、高級 SSD v2、支援區域及支援功能。
快取影響	Premium SSD v1 主機快取是否適用於低於 4 TB 的容量。
計算生成	所選 SKU 是否能驅動所需的 IOPS 與吞吐量。
縮放模型	手動縮放、排程縮放、效能調整與複本。
可觀察性	指標、警示、查詢洞察與工作負載審查流程。

實際效能測試：比較負載下的儲存配置

本文所述的原則並非理論性的。為了展示運算、儲存與工作負載在實務中的互動，本節總結 pgbench 了在受控、測量條件下比較儲存配置與計算層級的基準測試。

基準設定與方法論

這些基準測試使用 pgbench標準 PostgreSQL 基準工具，模擬五種不同儲存與運算配置的交易工作負載。測試開始時有 500 條並行連線，初期階段後逐步增加至 750 條並行連線，並維持此較高的連線負載直到測試視窗的剩餘時間。這種加速模式模擬了隨著流量增加，許多真實應用程式會隨時間增加負載，並衡量資料庫對初始流量激增與持續高並發的反應。

所有基準測試皆在適用於 PostgreSQL 的 Azure 資料庫 Flexible Server 上執行，且在同一區域、同一可用性區域內，使用相同的測試資料庫與工作負載配置檔。透過將儲存與運算作為變數，您可以確保效能差異反映的是實際平台能力，而非網路、應用程式或工作負載的差異。

設定詳細資料

測試五種不同的配置，並改變儲存層級與運算大小，以說明關鍵規劃概念。

Configuration	計算 SKU	vCores	Memory	最大運算IOPS	儲存體類型	Capacity	IOPS	Throughput
組態 1	Standard_D16ds_v5	16	64 GB	25,600（40,000 次爆發）	高級 SSD（P50）	4,095 GB	7,500	250 MB/秒
配置 2	Standard_D16ds_v5	16	64 GB	25,600（40,000 次爆發）	高級 SSD（P50）	4,096 GB	7,500	250 MB/秒
配置 3	Standard_D16ds_v5	16	64 GB	25,600（40,000 次爆發）	高級 SSD（P80）	32 TB	20,000	900 MB/秒
組態 4	Standard_D16ds_v5	16	64 GB	25,600（40,000 次爆發）	進階 SSD v2	4,095 GB	40,000	1200 MB/s
配置 5	Standard_D32ds_v5	32	128 GB	51,200	進階 SSD v2	4,095 GB	60,000	1200 MB/s

配置設計中的主要觀察：

配置1與配置2： 這些配置僅在儲存容量上有所不同，分別為 4,095 GB 與 4,096 GB。此比較測試了高級 SSD v1 硬碟的主機快取邊界。
設定2與設定3： 兩種配置皆使用 SSD v1，但配置 3 可擴展至 32 TB 容量，以解鎖更高的 IOPS 與吞吐量。
配置 3 與設定 4： 兩種配置使用相同的運算資源，但 Config 4 展現了 Premium SSD v2 靈活的 IOPS 與吞吐量，且不受容量限制。
Config 4 與 Config 5： Config 5 將計算 SKU 加倍，以展示高階計算如何解放更多儲存效能空間。

表現成績

配置 1：4,095 GB 高階 SSD v1 搭配主機快取

配置 1 採用 4,095GB 的 Premium SSD v1 規格，該規格在 Premium SSD v1 上享有主機快取功能。在工作負載期間，此配置保持穩定運行：

最大 IOPS： 24,773 IOPS，Premium SSD v1 配置後最高 7,500 IOPS，快取提升效能。
最大讀取IOPS： 21,330，利用主機快取以進行大量讀取操作。
最大寫入IOPS： 7,610。

主機快取增強讀取效率，因此即時的 IOPS 效能會暫時超過硬碟配置的 7,500 IOPS 限制，並達到運算儲存的限制。

配置 2：4,096 GB 進階 SSD v1，無主機快取

配置 2 採用 4,096 GB 的 Premium SSD v1 容量，跨越快取邊界，失去主機快取優勢。影響可見：

最大IOPS： 因為缺少快取，效能 IOPS 比 Config 1 低。
最大讀取 IOPS： 沒有主機快取時，會大幅降低。
最大寫入IOPS： 7,610，未變。

此配置展現了 4TB 快取邊界的實際重要性。從 4,095 GB 升級到 4,096 GB 會改變效能配置，移除快取讀取。對於逐漸接近這個門檻的資料庫，請提前規劃。

配置 3：32TB 高級 SSD v1，IOPS 更高

配置 3 透過擴展至 32 TB 容量，解決 Premium SSD v1 的最高 IOPS 與吞吐量限制。此配置達成：

最大IOPS： 20,000。
最大讀取 IOPS： 大約 12,000。
最大寫入 IOPS： 大約為5,000。

增加底層的Premium SSD v1儲存容量，可以提升IOPS和吞吐量。你仍然可以達到高負載運算儲存範圍的上限。

配置 4：Premium SSD v2，擁有 40,000 IOPS

配置 4 展示 Premium SSD v2 靈活的效能配置，在 4,095 GB 容量下提供 40,000 IOPS 與 1,200 MB/s 吞吐量：

最大IOPS： 由於高級 SSD v2 的延遲與吞吐量能力，能提升有效利用率。
最大讀取 IOPS： 與 Premium SSD v1 配置相比，效能有所提升。
最大寫入IOPS： 更高的持續寫入能力。

Premium SSD v2 允許在不需大容量儲存的情況下，提供高 IOPS 配置，使其在交易量大的工作負載下更有效率。

配置 5：D32ds_v5 計算實例上的 Premium SSD v2 配置，提供 60,000 IOPS

配置 5 可擴展儲存效能（60,000 IOPS）及運算能力，支援 Standard_D32ds_v5 與 32 個 vCore。此配置展示了端對端對齊原則：

最大IOPS： 比之前所有配置都高很多。
最大讀取 IOPS： 大幅提升，運算空間也增加了。
最大寫入IOPS： 持續較高的寫入能力。

透過將運算與儲存對齊至更高效能層級，此配置能達成最佳吞吐量與最低 CPU 壓力。 D32ds_v5 較高的儲存上限，讓 60,000 IOPS 的高級 SSD v2 磁碟能被更充分利用。

基準測試的啟示

這五種配置說明本文的主要原理：

4TB 快取邊界很重要。
配置1與配置2顯示，主機快取可將讀取效能提升至4,096 GB以下，而跨越4,096 GB則失去此優勢。
容量不等於效能。
Config 3 配置了 32 TB，但 IOPS 並不最高。僅靠儲存容量並不決定交易吞吐量。
高級 SSD v2 提供彈性的效能調校。
配置四在適度容量下展現了高 IOPS，驗證了 Premium SSD v2 所支援的解耦模式。
運算與儲存必須對齊。
配置五顯示，最大化儲存效能需要足夠的運算餘量。 D32ds_v5 較高的儲存上限是為了更充分利用 60,000 IOPS 的配置。

基準測試結果驗證了核心原則：最大效能是端對端的特性。沒有任何單一層級，如儲存、運算或網路，決定結果。成功需要在各層級間有意識地對齊、有針對性的驗證，以及隨著工作負載演進持續觀察。

結論

Azure Postgres 提供了一個強大且靈活的平台，用於建構現代化的雲端託管資料庫解決方案。 Azure 在運算、儲存、網路、高可用性、複寫、安全性與可觀察性等方面的工程設計，促成了一些最具性能和韌性的 Postgres 架構。

最大效能絕非偶然。

要達到最佳營運效能，則需要了解應用程式、客戶端、工作負載、資料成長曲線、讀寫組合，以及塑造需求的商業週期。同時也需要在運算與儲存選擇上協調一致，以達成 IOPS、吞吐量與延遲目標的端對端。

高級 SSD v1 能提供強大且可預測的效能，尤其當主機快取適用於 4 TB 以下的資料時。 Premium SSD v2 透過解耦容量、IOPS 與吞吐量，提供更靈活的效能配置。超大型磁碟代表了 Azure 管理磁碟中最高的效能等級，而新一代運算則為高階架構提供了顯著更高的集合遠端儲存上限。

最佳的 Azure Postgres 部署結合了平台能力、有計畫的規劃、持續監控及明確的營運所有權。擁有正確需求與架構，團隊能提供世界級的 Postgres 體驗，達到巔峰效能。

Azure 進階儲存體：專為高效能設計
Azure 磁碟爆發
Ddv5 與 Ddsv5 系列虛擬機器大小
Ddsv6 系列虛擬機器大小
進階 SSD 儲存選項，在適用於 PostgreSQL 的 Azure 資料庫中
適用於 PostgreSQL 的 Azure 資料庫的 Premium SSD v2 儲存選項
Azure 管理磁碟類型
在適用於 PostgreSQL 的 Azure 資料庫監控指標

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-05-08