高效能資料庫解決方案

高效能資料庫解決方案是每一道 SAA-C03 情境題的核心，只要題目提到低延遲寫入、以讀取為主的儀表板，或是全球分散的使用者群體，都脫不開這個主題。考試藍圖中的任務說明 3.3 要求你在 Amazon RDS、Amazon Aurora、Amazon DynamoDB、Amazon ElastiCache、Amazon DAX、Amazon MemoryDB for Redis 與 Amazon Redshift 之間做出正確選擇，並調整每一個旋鈕——執行個體類型、IOPS、read replica、自訂端點、分區鍵設計、快取策略、資料分佈風格——直到工作負載符合服務等級協議（SLA）。這份 SAA-C03 學習指南涵蓋 AWS 高效能資料庫解決方案組合中每一個效能調校方向，比較常見的考試陷阱，最後以 SAA 等級的 FAQ 收尾。如果你只粗略看過 CLF-C02 的資料庫服務筆記，請把這份文件當作深入探討的起點：SAA-C03 考試獎勵的是能說清楚「不只選哪個高效能資料庫解決方案，還能說明怎麼調校」的架構師。

什麼是 AWS 高效能資料庫解決方案

AWS 上的高效能資料庫解決方案，是指那些設定旋鈕直接影響 throughput、延遲、並發數與成本效益的受管資料存放服務。SAA-C03 任務說明 3.3 要求你針對特定工作負載選出高效能資料庫解決方案，這代表你必須同時掌握四個面向：引擎選擇（關聯式 vs NoSQL vs 記憶體內 vs 欄位式）、規格（執行個體類型、佈建容量、儲存 IOPS）、存取路徑最佳化（索引、分區鍵、資料分佈風格），以及拓撲（Multi-AZ、read replica、global tables、自訂端點）。高效能資料庫解決方案的定義，始終是在保留足夠尖峰緩衝空間的前提下，以最低成本滿足工作負載的 SLA。

SAA-C03 考試所測試的四個效能面向

每一道 SAA-C03 高效能資料庫解決方案的情境題，都對應到以下一個或多個面向：

1. 垂直規格 — 選擇正確的 DB 執行個體類型或容量模式，確保引擎本身不是瓶頸。
2. 儲存 throughput — 選擇正確的 EBS 磁碟區類型、provisioned IOPS 或 Aurora 儲存架構，確保磁碟 I/O 不是瓶頸。
3. 讀取擴展 — 將讀取流量分散到 replica、快取或分散式分片，避免熱讀熔斷主節點。
4. 全球分佈 — 跨 Region 複寫資料，讓跨洲使用者取得低延遲讀取。

為何 SAA-C03 把效能視為首要考量

SAA-C03 的題目很少問「Amazon RDS 是什麼？」——那是 CLF-C02 的問題。SAA-C03 考試改為描述一個具有特定故障模式的工作負載（例如「連線數突增至 50,000」、「新加坡使用者的讀取延遲達到 400 ms」、「某個分區承接 80% 的寫入流量」），並期待你使用正確的 AWS 旋鈕提出高效能資料庫解決方案。熟記各個調校旋鈕、限制數字，以及高效能資料庫解決方案之間的正確搭配，才是這門考試的核心。

白話文解釋 High-Performing Database Solutions

以下三個類比，能在深入各 AWS 高效能資料庫解決方案細節之前幫你建立整體概念。考試當天，選一個最容易記住的來用。

類比一：夜市攤位大排長龍

把高效能資料庫解決方案想像成一個永遠不能讓客人等太久的夜市。Amazon RDS 是由老闆一人掌廚的單一攤位——客人少的時候沒問題，一旦人潮湧入，你就多請幾個學徒（read replica）來負責端菜與結帳，老闆專心處理需要火候的料理（寫入）。Amazon RDS Proxy 是站在攤位前的號碼牌叫號員，統籌有限的爐台讓一波波客人輪流使用，避免同時大量湧入讓廚房當機。Amazon Aurora 是整個攤位換用六組備份瓦斯爐台，廚房料理的每一道菜都同時寫在三個備用小黑板上。Aurora 自訂端點像是夜市裡的分流動線——一條通道給現場熟客點餐，另一條給訂位制的包廂桌，各走各的，互不干擾。Amazon DynamoDB 是自助販賣機：每格抽屜對應一個商品號碼，毫秒取件，但前提是你必須事先知道號碼。DAX 是放在販賣機旁邊、已備好今日最熱門商品的開放式取物架，讓常客可以微秒級拿走。Amazon ElastiCache 是夜市入口的小冰箱，存放最常點的飲料，讓客人不必每次都走到最深處的廚房取貨。Amazon Redshift 則是夜市背後的帳房，所有歷史帳本按欄位整理歸檔，方便主計長一次彙總好幾年的銷售數字。

類比二：全球物流網路

把應用程式資料想像成貨運。Amazon RDS 搭配 Multi-AZ，就像在隔壁鎮備有一座隨時待命的熱備倉庫——主倉若發生意外，備倉兩分鐘內接手，但備倉平時對外不開放。Amazon RDS read replica 是分散在各地的衛星發貨站，讓瀏覽中的顧客能就近查詢庫存，不必擠進主收貨碼頭。Aurora Global Database 是國際貨運網路：主倉在某個 Region 透過專用海底儲存鏈路把貨品送往最多五個次要 Region，複寫延遲通常不到一秒，讓新加坡的顧客直接從新加坡貨架取貨。DynamoDB global tables 則是反過來——每個 Region 都有一座同等地位的倉庫，任何一邊的入庫動作都會在幾秒內同步到其他 Region，實現 active-active 複寫。DynamoDB Streams 是貨物動態通報系統，每當任何品項移動，下游系統立刻收到通知。ElastiCache 是門市前端的暢銷品展示架，確保熱賣前百名的商品不必每次都跑到後倉撿貨。

類比三：重要考試的開卷備考

想像一個正在應付高風險開卷考的學生。Amazon RDS 是裝訂厚實的課本——穩固，但三千個學生同時翻同一頁，書就會爛。Read replica 是把最常被查的章節複印後發給每第三位學生。RDS Proxy 是圖書館員，幫學生把書翻到正確頁面並在學生之間傳遞，避免每個人都從頭翻起浪費時間。Aurora 是同一本課本印在複寫紙上，每一條螢光筆劃線都同步出現在三個書架的六本副本裡。Aurora parallel query 是在需要彙整全書資料時，讓課本自己同時掃描六個書架。DynamoDB 是幾千張索引卡的集合——知道卡號就能瞬間取得，但完全無法用來回答申論題。DAX 是學生桌旁的口袋，放著今天最常用的那幾張卡，隨手可取、毫秒級響應。Redshift 是整個學期的筆記存檔，按欄位重新整理，讓教授能在毫秒內統計全年某個概念出現的次數。

Amazon RDS 效能調校旋鈕

Amazon RDS 是高效能資料庫解決方案最常見的起點，因為它執行的引擎（MySQL、PostgreSQL、MariaDB、Oracle、SQL Server）正是開發團隊熟悉的那些。SAA-C03 考試關心的是你能在標準引擎之上調整哪些旋鈕。

RDS 執行個體類型 — 讓計算資源對應工作負載

Amazon RDS 支援三個執行個體系列：db.m（通用型，CPU 與記憶體均衡）、db.r（記憶體最佳化——每 vCPU 配備更多記憶體，適合大型工作集與快取）以及 db.x（極大記憶體，適用於 Oracle 或 SAP HANA on RDS 等記憶體內分析工作負載）。當工作負載受限於緩衝池大小（熱工作集很大，必須留在記憶體以避免磁碟讀取），選 db.r。均衡 OLTP 選 db.m。查詢模式以 CPU 為瓶頸（大量 JOIN、預存程序邏輯）時，選更多 vCPU 數量。

RDS 儲存類型與 IOPS

Amazon RDS 儲存底層由 Amazon EBS 磁碟區支撐，提供三種儲存選項：

• General Purpose SSD（gp2/gp3） — gp3 是較新的預設選項，無論磁碟區大小皆提供 3,000 IOPS 基準值，且允許 IOPS 與容量獨立佈建。gp2 的 IOPS 與磁碟區大小掛鉤，為每 GB 3 IOPS。
• Provisioned IOPS SSD（io1/io2） — 當工作負載需要超過 16,000 IOPS 或需要持續高 I/O 且低變異數時使用。io2 Block Express 在支援的引擎上可達每磁碟區 256,000 IOPS。
• Magnetic — 舊式類型，不建議用於高效能資料庫解決方案。

Amazon RDS 儲存自動擴展功能會在可用空間低於 10% 且低空間狀態持續至少五分鐘時，自動擴大已分配的儲存空間，上限為你設定的最大儲存閾值。這能防止「凌晨三點磁碟滿」的故障，但不會自動縮小儲存空間。

RDS Read Replica — 跨 AZ 與跨 Region 的讀取擴展

Amazon RDS read replica 使用引擎原生的非同步複寫來分流讀取流量。SAA-C03 考試的關鍵限制數字：

• MySQL、MariaDB 與 PostgreSQL 每個來源最多支援 15 個 read replica（AWS 已將舊有的 5 個上限提高）。
• MySQL、MariaDB、PostgreSQL 與 Oracle 支援跨 Region read replica。
• Read replica 可提升為獨立 DB 執行個體，用於災難復原或引擎升級流程。
• 複寫為非同步，因此讀取可能略微落後——應用程式設計時須能容忍 replica lag。

RDS Proxy — 為 Serverless 與突發性工作負載提供 Connection Pooling

Amazon RDS Proxy 是一個全受管、高可用的資料庫 Proxy，位於應用程式用戶端與 RDS 或 Aurora 資料庫之間。它透過 pooling 與共享資料庫連線，解決高效能資料庫解決方案面臨的兩種故障模式：

1. Serverless 湧入 — AWS Lambda 或 ECS Fargate 任務從零擴展至數千個並發執行，每個都開啟全新的資料庫連線。若缺乏 pooling，資料庫會耗盡連線，新的呼叫將失敗。
2. 容錯移轉韌性 — RDS Proxy 在 Multi-AZ 容錯移轉期間自動將新連線路由至新的主節點，根據 AWS 數據，感知到的容錯移轉時間最多可縮短 66%。

RDS Proxy 在 RDS 與 Aurora 上皆支援 MySQL、MariaDB、PostgreSQL 與 SQL Server。身分驗證與 AWS Secrets Manager 及 IAM 資料庫驗證整合。對於 SAA-C03 情境題中提到「Lambda 函數開啟過多連線」或「連線耗盡」的情況，RDS Proxy 是標準答案。

Amazon Aurora 效能深度解析

Amazon Aurora 是 AWS 原生為 MySQL 相容與 PostgreSQL 相容工作負載設計的高效能資料庫解決方案。Aurora 將計算（DB 執行個體）與儲存（共享的分散式 SSD 儲存架構，在三個可用區域中儲存六份資料副本並自動修復）分離。SAA-C03 要求你熟悉下列 Aurora 專屬旋鈕。

Aurora 端點 — Cluster、Reader、Custom 與 Instance

Aurora 提供四種對效能路由有影響的端點類型：

• Cluster endpoint（writer endpoint） — 始終指向目前的主節點；用於寫入。
• Reader endpoint — 在所有 Aurora Replica 之間進行負載平衡；用於一般讀取流量。
• Custom endpoint — 由你定義的 reader DB 執行個體子集所支撐的端點。這是 SAA-C03 的差異化考點。
• Instance endpoint — 指向特定 DB 執行個體；在應用程式碼中應避免使用，因為它不能在容錯移轉時保持韌性。

Aurora 自訂端點讓你切割出異質的 reader 池。典型模式：兩台大型 db.r6g.8xlarge reader 透過 analytics-endpoint 提供給商業智慧團隊，加上四台小型 db.r6g.large reader 透過 app-endpoint 提供給 Web 層。兩個池不會競用相同硬體，每個團隊都擁有一個穩定的 DNS 名稱，並自動排除不健康的執行個體。

Aurora Serverless v2 — 以 ACU 為單位的精細自動擴展

Aurora Serverless v2 是一種部署選項，容量以 0.5 Aurora Capacity Unit（ACU）為增量持續擴展。一個 ACU 大約等於 2 GB 記憶體加上相應比例的 CPU 與網路資源。v2 在不到一秒內完成擴展，支援 Multi-AZ、read replica、Global Database（有部分限制）以及 Aurora Serverless v1 所缺乏的所有 Aurora 功能。最小容量可設定為 0.5 ACU；每個執行個體最大可達 128 ACU。

適合使用 Aurora Serverless v2 的情況：

• 難以預測或具突發性的工作負載，佈建容量在低谷期會造成浪費。
• 開發與測試環境，夜間應縮小規模。
• 每個租戶使用量有明顯差異的多租戶 SaaS 後端。

若工作負載有穩定的基準使用量，使用 Reserved Aurora Provisioned 執行個體每小時的成本更低，此時應避免使用 Aurora Serverless v2。

Aurora Global Database — 跨 Region 低延遲讀取

Aurora Global Database 讓你將單一 Aurora 叢集複寫至最多五個次要 Region，典型複寫延遲不到一秒，且儲存層級的複寫完全繞過 DB 執行個體層。SAA-C03 高效能資料庫解決方案的重要特性：

• 全球使用者的讀取擴展 — 每個次要 Region 以個位數毫秒延遲提供本地讀取服務。
• 受管 Region 容錯移轉 — 在不到一分鐘內將次要 Region 提升為主節點，進行災難復原，典型復原點目標（RPO）不到一秒，復原時間目標（RTO）不到一分鐘。
• Write forwarding — 在次要 Region 執行的應用程式可以發出寫入，並透明地轉發至主要 Region（Aurora MySQL 功能）。

Aurora Global Database 在兩個面向上優於跨 Region read replica：複寫延遲（次秒級 vs MySQL 跨 Region replica 可能達數分鐘）以及容錯移轉速度。

Aurora Parallel Query — 下推至儲存層

Aurora MySQL parallel query 將述詞評估與聚合運算推送至 Aurora 儲存層本身，跨數千個儲存節點平行處理。對於在主要以 OLTP 為主的 Aurora MySQL 叢集上掃描大型資料表（GB 至 TB 等級）的分析查詢，parallel query 能將執行時間縮短一個數量級，且無需將資料移至獨立的資料倉儲。Parallel query 可按 session 或按語句選擇性啟用，是 SAA-C03 的核心陷阱答案——當情境描述「混合 OLTP 與偶發的大型聚合查詢，且不想將資料移至 Redshift」時，正是它的用武之地。

Amazon DynamoDB 效能工程

Amazon DynamoDB 是 AWS 上的 serverless NoSQL 高效能資料庫解決方案。在你佈建的 throughput（或在 On-Demand 模式下的任意請求速率）範圍內，它能以個位數毫秒的 P99 延遲進行擴展——但前提是底層的分區設計必須健康。SAA-C03 情境題一再懲罰那些認為 DynamoDB 能自動解決所有效能問題的考生。

分區鍵設計 — DynamoDB 最重要的旋鈕

DynamoDB 依照分區鍵的雜湊值在實體上對資料進行分片。每個實體分區每秒最多能處理 3,000 read capacity units（RCU）與 1,000 write capacity units（WCU）（這些是自適應容量基準值；實際 throughput 可透過自適應容量突發至更高）。DynamoDB 上的高效能資料庫解決方案始終圍繞著選擇一個能將流量均勻分散到各分區的分區鍵。指導原則：

• 高基數分區鍵（例如 userId、deviceId）能將負載均勻分散到許多分區。
• 低基數分區鍵（例如 status = 'ACTIVE'、tenantId（其中某個租戶佔 90% 流量））會將負載集中在單一分區。
• 複合分區鍵（例如透過 write sharding 產生 tenantId#shard0..shard9）可將高流量租戶的寫入分散到最多 N 個合成分區。

熱分區故障模式

熱分區發生在某個分區鍵值（或一組緊密相關的值）承接了不成比例的大量流量時。症狀包括：ProvisionedThroughputExceededException 錯誤、P99 延遲突增，或 Lambda 呼叫超時。修復方式：

• Write sharding — 對高流量寫入的鍵附加隨機後綴（例如 0..9），讓十個邏輯分區承接原本一個分區的流量。
• 更換索引鍵 — 重新設計 schema，讓熱實體的存取模式改由更高基數的屬性來達成。
• 加入快取 — DAX（見下文）在讀取熱點到達 DynamoDB 之前先吸收掉。
• 啟用自適應容量 — 預設開啟，自動隔離熱分區，但這不是萬靈丹：若底層鍵設計有誤，自適應容量只能軟化故障，無法根治。

DynamoDB 容量模式 — On-Demand vs Provisioned

DynamoDB 提供兩種計費與容量模式：

• Provisioned — 你設定每秒的 RCU 與 WCU；可啟用 Auto Scaling，依據使用率目標（預設 70%）在上下限之間調整。對於可預測的穩定工作負載更具成本效益。Reserved Capacity 可為 1 年或 3 年承諾提供最高 77% 的折扣。
• On-Demand — 按請求讀取與請求寫入計費。無需規劃容量。在持續負載下，每請求成本最高可達 Provisioned 的 2.5 倍，但非常適合難以預測、具突發性或全新的工作負載。On-Demand 可在 30 分鐘內無需預熱即擴展至前次峰值的兩倍。

每張資料表每 24 小時允許切換一次 On-Demand → Provisioned 或 Provisioned → On-Demand。SAA-C03 情境指引：流量模式未知、具突發性或全新時，選 On-Demand；流量可預測且持續，尤其是團隊能承諾 Reserved Capacity 時，選 Provisioned。

DynamoDB Accelerator（DAX）

DAX 是一個全受管、write-through、與 DynamoDB 相容的記憶體內快取，為快取項目提供微秒級讀取（相較於直接從 DynamoDB 讀取的個位數毫秒）。DAX 以叢集方式在你的 VPC 內的 DAX 節點上執行。應用程式變更幅度最小——DAX SDK 與 DynamoDB SDK 的 API 相容，因此應用程式碼能透明地從 DAX 讀取。重點：

• DAX 只快取 DynamoDB — 它不是通用快取。若要快取 DynamoDB 查詢結果以外的任何內容，請使用 ElastiCache。
• Item cache 儲存 GetItem 與 BatchGetItem 的結果。
• Query cache 儲存 Query 與 Scan 操作的結果。
• Write-through — 寫入穿透 DAX 傳遞至 DynamoDB，同時更新快取項目，保持 DAX 的一致性。
• Multi-AZ — DAX 叢集可跨可用區域部署以實現高可用性。

DynamoDB Global Tables

Global tables 使用 last-writer-wins 衝突解決機制提供 active-active 多 Region 複寫。任何 Region 的寫入都會在數秒內傳播至所有其他 Region。使用 global tables 的時機：

• 使用者分散於各地，本地 Region 延遲至關重要。
• 你希望實現 Region 故障隔離，且無需明確容錯移轉——每個 Region 都是主節點。
• 你能接受 last-writer-wins 語意（並發的衝突寫入以掛鐘時間戳記解決）。

Global tables 建立在 DynamoDB Streams 之上——每個 Region 將其變更日誌寫入 Stream，由受管複寫器將這些變更套用至對等 Region。

DynamoDB Streams

DynamoDB Streams 是資料表上每一個建立、更新與刪除操作的有序、按時間排列的變更日誌。Streams 保留記錄 24 小時，並與 AWS Lambda 原生整合以實現事件驅動模式。SAA-C03 使用場景：

• 跨 Region 複寫（global tables 底層使用 Streams）。
• 將實體化視圖同步至 Amazon OpenSearch 或 Amazon Redshift。
• 稽核軌跡，以及透過 EventBridge 向下游微服務進行扇出分發。

Amazon ElastiCache — 記憶體內加速

Amazon ElastiCache 是 AWS 高效能資料庫解決方案的記憶體內快取層。ElastiCache 提供兩種引擎——Redis 與 Memcached——各有不同的功能集。

ElastiCache for Redis vs Memcached

SAA-C03 預設選擇：選 Redis，除非情境明確提到「在大型執行個體上使用多執行緒的純鍵值快取」，那才指向 Memcached。

ElastiCache for Redis Cluster Mode

ElastiCache for Redis 提供兩種部署拓撲：

• Cluster mode 關閉（單一分片） — 一個主節點加最多 5 個 replica 節點。所有寫入集中在單一主節點；replica 提供讀取服務。透過新增 replica 來擴展讀取；僅能透過升級節點類型（垂直擴展）來擴展容量。
• Cluster mode 開啟（sharding） — 最多 500 個分片，每個分片有一個主節點加最多 5 個 replica。資料依鍵的雜湊槽跨分片分區。這是水平擴展——新增分片以處理更多寫入與更大的總資料集大小。

當資料集超過最大單一節點的記憶體大小、當寫入 throughput 必須擴展至超過一個主節點，或當你想要將租戶隔離在不同主節點時，選 cluster mode 開啟。當資料集能放入單一節點且只需要讀取擴展加上高可用性時，選 cluster mode 關閉。

ElastiCache 上的加密與安全性

ElastiCache for Redis 透過 AWS KMS 支援靜態加密，並透過 TLS 支援傳輸中加密。Redis AUTH token 提供密碼型存取控制，而 ElastiCache 在 ElastiCache 上的 Redis 7+ 與 AWS IAM 整合。將 ElastiCache 部署在 VPC 內，並使用安全群組，只允許應用程式子網路存取。對於 HIPAA、PCI 或 GDPR 工作負載，請在建立叢集時同時啟用傳輸中與靜態加密——你無法在不透過備份還原遷移的情況下，對現有叢集補加靜態加密。

Amazon MemoryDB for Redis — 具持久性的近親

Amazon MemoryDB for Redis 是一個與 Redis 相容、具持久性的記憶體內資料庫，它將寫入持久化到 Multi-AZ 的交易日誌中。與 ElastiCache for Redis（它是放在持久性主資料庫前面的快取）不同，MemoryDB 本身就是一個能提供微秒級讀取與個位數毫秒級寫入的持久性主資料庫。SAA-C03 情境觸發詞：「與 Redis 相容的主資料庫，具備 Multi-AZ 持久性」→ Amazon MemoryDB for Redis。

Amazon Redshift 效能架構

Amazon Redshift 是 AWS 的 PB 級欄位式資料倉儲，用於線上分析處理（OLAP）。在 SAA-C03 中，只要情境提到「跨 TB 資料的分析」、「歷史資料的 BI 儀表板」或「跨大型事實資料表的 JOIN」，Redshift 就會出現。以下是 SAA-C03 等級的效能調校旋鈕。

Redshift 資料分佈風格

Redshift 依據資料表的分佈風格，將資料表資料儲存在各個計算節點上。正確的選擇決定了查詢時需要重新分佈多少資料（即 EXPLAIN 計畫中的 DS_BCAST 與 DS_DIST 步驟）。四種風格：

• KEY 分佈 — 具有相同分佈鍵值的資料列落在同一個分片上。當兩個大型資料表頻繁在同一欄位上 JOIN 時使用（共置 JOIN——零重新分佈）。
• ALL 分佈 — 資料表的完整副本儲存在每個節點上。用於與許多事實資料表 JOIN 的小型維度資料表；避免重新分佈，但會倍增儲存空間。
• EVEN 分佈 — 資料列以循環方式分佈到各分片。預設值，適用於不做 JOIN 的暫存資料表。
• AUTO 分佈 — Redshift 根據資料表大小與查詢模式自行選擇 KEY、ALL 或 EVEN。新資料表的預設值，除非你明確覆寫。

錯誤的分佈風格是 Redshift 效能問題的第一大原因。若每夜 JOIN 掃描兩個 1 TB 的資料表，且兩者都使用 EVEN 分佈，每次查詢都會在節點網路間廣播 TB 級的資料。將兩者都改為在 JOIN 欄位上使用 KEY 分佈，同一個查詢就會變成本地的共置 JOIN。

Redshift 排序鍵

排序鍵對每個 1 MB 區塊內的資料列進行實體排序。Redshift 為每個區塊儲存區域圖（zone-map）元資料，因此當查詢在排序鍵上有述詞時，可以跳過區域圖不與述詞範圍重疊的整個區塊。兩種排序鍵類型：

• Compound sort key（預設） — 先按第一個排序欄位排序，再依次按第二個，以此類推。當查詢始終按前導欄位過濾時效果最佳。
• Interleaved sort key — 對每個排序欄位給予同等權重。當查詢可能按多個欄位中的任何一個過濾時效果更好，但維護成本較高（需要 VACUUM REINDEX）。

對於時間序列資料表，務必在時間戳記欄位上定義排序鍵——幾乎所有分析查詢都包含 WHERE event_time >= ... 述詞，在 event_time 上使用 compound sort key 可讓 Redshift 每次查詢跳過數百個區塊。

Redshift 節點類型 — RA3 及更新世代

RA3 節點將計算與儲存分離：計算節點按 vCPU 與記憶體計費，而資料存放在 Redshift Managed Storage（RMS）的類 S3 持久分層儲存中。RA3 規格（SAA-C03 參考）：

• ra3.xlplus — 最小的 RA3，適用於 ~32 TB 以下的工作負載。
• ra3.4xlarge — 中階。
• ra3.16xlarge — 最大，適用於多 PB 叢集。

舊式 DC2（密集計算）與 DS2（密集儲存）節點類型仍然存在，但 RA3 是預設推薦選項，因為計算與儲存可獨立擴展——調整計算規格無需複製 TB 級資料。

Redshift Serverless

Redshift Serverless 完全移除叢集的概念：你只在查詢執行時為計算付費，以 Redshift Processing Unit（RPU）計量。Serverless 非常適合：

• 難以預測的分析工作負載。
• 否則需要 24/7 運行 DC2 或 RA3 叢集的開發／測試環境。
• 同一時刻只有少數租戶在查詢的多租戶 SaaS 分析場景。

對於穩定、可預測的工作負載，佈建 RA3 搭配 Reserved Instance 定價仍是正確選擇，可解鎖最高 75% 的折扣。

跨高效能資料庫解決方案的快取策略

快取是改善資料庫效能最具成本效益的方式。SAA-C03 題目中有兩種模式最為主導：

Cache-Aside（Lazy Loading）

應用程式先檢查快取。若發生快取未命中，應用程式從資料庫讀取，將結果以 TTL 寫入快取，再回傳結果。簡單、能抵禦快取故障，但啟動時有「冷快取」代價。大多數 ElastiCache for Redis 與 Memcached 的部署使用 cache-aside。

Write-Through

應用程式在同一個操作中同時寫入快取與資料庫；讀取永遠命中快取。保持快取熱備，但寫入成本加倍，且要求快取絕不能與來源分歧。DAX 對 DynamoDB 使用 write-through。

Read-Through 與 Write-Behind

在 SAA-C03 中較不常見，但值得認識。Read-through 將「未命中時載入」的責任委派給快取服務本身（某些第三方快取）。Write-behind 在快取中緩衝寫入，並非同步地將其持久化到資料庫——寫入延遲低，但若快取故障，可能有資料遺失的風險窗口。

TTL 與驅逐策略

每種快取策略都需要 TTL 政策。太短會浪費快取容量在重新載入資料上。太長則會提供過期資料。Redis 支援 LRU、LFU、TTL 與隨機驅逐策略——對一般讀取快取選擇 LRU 或 LFU，並依工作集大小調整。

資料庫遷移效能注意事項

在不停機的情況下遷移至高效能資料庫解決方案，需使用 AWS DMS 搭配 change data capture（CDC）。SAA-C03 的效能考量角度：

• 同質遷移（MySQL 至 RDS MySQL、PostgreSQL 至 Aurora PostgreSQL）——DMS 完整載入 + CDC，停機時間僅需數分鐘。
• 異質遷移（Oracle 至 Aurora PostgreSQL）——使用 AWS Schema Conversion Tool（SCT）處理 schema，再使用 DMS 處理資料。
• 大型資料集初始載入 — 使用 DMS 搭配平行完整載入區段；若資料集大小除以可用頻寬超過約 30 天，則使用 AWS Snowball Edge 離線傳送初始資料集。

SAA-C03 必背關鍵數字

• RDS Multi-AZ 容錯移轉 — 通常 60 至 120 秒，透過 DNS 變更完成。
• RDS read replica — MySQL、MariaDB、PostgreSQL 每個來源最多 15 個；Aurora 最多 15 個。
• RDS 儲存自動擴展閾值 — 可用空間低於 10% 且持續至少 5 分鐘時觸發。
• Aurora 儲存 — 跨 3 個可用區域的 6 份副本，自我修復，最高自動擴展至 128 TiB（Aurora MySQL/PostgreSQL）。
• Aurora Global Database — 最多 5 個次要 Region，典型複寫延遲不到 1 秒，RTO 不到 1 分鐘。
• Aurora Serverless v2 ACU — 以 0.5 ACU 為增量擴展，範圍為 0.5 至 128 ACU。
• DynamoDB 分區限制 — 每個分區 3,000 RCU 與 1,000 WCU（基準值；自適應容量可突發至更高）。
• DynamoDB 項目大小限制 — 每個項目 400 KB。
• DynamoDB global table 複寫 — Region 之間通常不到 1 秒。
• DAX — 快取項目的 P99 讀取延遲為微秒級。
• ElastiCache for Redis cluster mode — 最多 500 個分片，每個分片有 1 個主節點加最多 5 個 replica。
• Redshift RA3 — 計算與 Redshift Managed Storage 分離；調整 RA3 叢集大小無需複製資料。
• Redshift 區塊大小 — 1 MB（與排序鍵帶來的區域圖跳過行為相關）。

SAA-C03 高效能資料庫解決方案常見考試陷阱

陷阱一：Multi-AZ vs Read Replica

Multi-AZ 用於可用性（自動容錯移轉）。Read replica 用於讀取擴展。兩者都使用複寫；但只有 read replica 提供讀取服務給用戶端。

陷阱二：DAX vs ElastiCache

DAX 只快取 DynamoDB。ElastiCache 可快取任何東西。若主要資料庫不是 DynamoDB，DAX 就是錯誤答案。

陷阱三：Aurora 自訂端點 vs Reader 端點

Reader 端點在所有 reader 之間均等負載平衡。自訂端點讓你鎖定特定子集——當 reader 工作負載在規格或 SLA 上有差異時，使用自訂端點。

陷阱四：DynamoDB 容量 vs 分區設計

佈建更多 WCU 無法解決熱分區問題。重新設計分區鍵或應用 write sharding。

陷阱五：到處都用 Aurora Serverless v2

Serverless v2 並非永遠更便宜。對於 Aurora Provisioned 搭配 Reserved Instance 定價的全天候穩定工作負載，成本往往比相同 throughput 的 Serverless v2 更低。Serverless v2 適用於突發性或難以預測的負載。

陷阱六：Redshift 用於低延遲讀取

Redshift 是欄位式且以批次分析為導向。點查詢與單筆資料列更新效能不佳。OLTP 請使用 Aurora 或 DynamoDB。

陷阱七：Global Tables vs Aurora Global Database

Global tables（DynamoDB）是 active-active 搭配 last-writer-wins。Aurora Global Database 是一個主要 Region 加最多 5 個唯讀次要 Region（搭配可選的 write forwarding）。若情境需要多 Region 寫入且衝突解決複雜度要低，用 DynamoDB global tables。若需要關聯式資料庫加上全球讀取分佈，用 Aurora Global Database。

陷阱八：RDS Proxy vs ElastiCache

Proxy 做的是 connection pooling。ElastiCache 做的是查詢結果快取。兩者解決的是不同的問題，答案也截然不同。

真實世界模式：多層高效能資料庫架構

一個實際的 SAA-C03 解決方案會結合多種高效能資料庫解決方案：

• Aurora PostgreSQL 叢集，一個 writer 加三個 reader，透過 reader 端點服務交易層（訂單、庫存、客戶資料）。
• Aurora 自訂端點 analytics-endpoint 指向兩台大型 db.r6g.8xlarge reader，專門供 BI 團隊使用，避免其查詢與 Web 層搶奪 CPU。
• RDS Proxy 放在 Aurora 前面，為處理訂單建立 webhook 的 Lambda 層服務，防止連線耗盡。
• DynamoDB 存放 Session 狀態、購物車與商品目錄查詢，前面加上 DAX 以實現微秒級商品頁面渲染。
• DynamoDB global tables 跨三個 Region 部署，讓購物車能跟著使用者全球同步。
• ElastiCache for Redis cluster mode 開啟，用於限流、OAuth token 快取與排行榜。
• Redshift RA3 用於跨五年歷史資料的每夜銷售報表，在 customer_id 上使用 KEY 分佈，讓訂單與客戶資料的 JOIN 成為共置 JOIN。
• Amazon MemoryDB for Redis 用於需要持久性的即時詐騙偵測狀態。

SAA-C03 考試不會在單一題目中要求你設計這整個組合，但它會讓你進入其中某一層，並問「選哪個服務、調哪個旋鈕」。

跨高效能資料庫解決方案的安全性與可觀測性

所有 AWS 高效能資料庫解決方案都與 AWS IAM（身分驗證）、AWS KMS（靜態加密）、Amazon CloudWatch（指標）、Performance Insights（RDS 與 Aurora 的查詢等級可觀測性）以及 AWS CloudTrail（API 稽核）整合。對於每個你部署的高效能資料庫解決方案，請調整以下設定：

• CloudWatch 警示，監控 CPU、連線數、replica lag、驅逐次數與節流事件。
• Performance Insights，適用於 RDS 與 Aurora——Top-SQL 視圖用於定位昂貴的查詢。
• Enhanced Monitoring — 最高以 1 秒粒度提供作業系統層級指標。
• DynamoDB Contributor Insights — 顯示流量最高的分區鍵，用於診斷熱分區。
• Redshift Advisor — 根據查詢歷史記錄推薦分佈風格與排序鍵的變更。

同時影響效能的成本調校旋鈕

成本與效能在幾道 SAA-C03 題目中相互交叉：

• Aurora I/O-Optimized — 按每 ACU 小時的固定定價，消除每次 I/O 的費用；對於否則會累積高額 I/O 費用的 I/O 密集型工作負載更有利。
• DynamoDB Reserved Capacity — 承諾 1 年或 3 年的 Provisioned RCU/WCU，最多節省 77%。
• Redshift Reserved Instances — 1 年或 3 年承諾相較於 On-Demand 最多節省 75%。
• ElastiCache Reserved Nodes — 對穩定快取容量的類似 RI 節省。
• Aurora Serverless v2 縮小規模 — 在夜間將非生產叢集縮至 0.5 ACU，成本趨近於零。

FAQ — 高效能資料庫解決方案常見問題

1. 何時應選擇 Aurora Serverless v2 而非 Aurora Provisioned？

當工作負載具突發性、難以預測，或有長時間閒置窗口時，選 Aurora Serverless v2——例如開發與測試環境、每個租戶負載變化明顯的多租戶 SaaS，以及流量在商業時間後幾乎歸零的應用程式。Aurora Serverless v2 以 0.5 ACU 為增量在不到一秒內完成擴展，並支援 Multi-AZ、read replica 與 Global Database。當工作負載為全天候穩定運行，且能以 1 年或 3 年鎖定 Reserved Instance 時，選 Aurora Provisioned——在持續高負載下，Reserved Provisioned 的成本往往低於 Serverless v2。在 SAA-C03 中，「難以預測」或「開發／測試」等關鍵詞幾乎都指向 Aurora Serverless v2。

2. 如何在不更換資料庫的情況下修復 DynamoDB 熱分區問題？

重新設計分區鍵。標準修復方式是 write sharding：在分區鍵後附加一個小整數後綴（例如 0 至 9），讓 tenant#acme 這樣的單一邏輯鍵變成 tenant#acme#0 至 tenant#acme#9 十個實體鍵，各自落在不同的分區上。需要查詢某個邏輯實體所有項目時，對所有分片發出平行查詢後再合併結果。增加更多佈建的 WCU 沒有幫助，因為無論資料表層級的總數為何，每個實體分區的上限都固定在 1,000 WCU。若讀取流量是熱點所在，在前面加入 Amazon DynamoDB Accelerator（DAX），以微秒延遲吸收重複讀取。若 sharding 與快取都無法解決問題，表示存取模式對 DynamoDB 而言並不合適，工作負載很可能更需要 Aurora 或 Redshift。

3. 何時 Amazon DAX 是正確選擇，而非 Amazon ElastiCache？

只有當主要資料庫是 Amazon DynamoDB 且應用程式使用 DynamoDB SDK 時，DAX 才是正確選擇。DAX 是 write-through 且與 DynamoDB API 相容，因此採用它幾乎不需要修改應用程式——只需將 SDK 用戶端切換為 DAX 用戶端即可。當快取放在 Amazon RDS、Amazon Aurora、Amazon DocumentDB、第三方 API 前面，或快取的 Session 狀態並非存放在 DynamoDB 中時，ElastiCache 是正確選擇。當你需要 DAX 不支援的豐富資料結構（有序集合、雜湊、串流）時，ElastiCache 也是正確答案。若 SAA-C03 題目說「DynamoDB 主要資料庫、需要微秒讀取、最小化程式碼變更」，選 DAX。若題目說「快取 Session token」或「快取 RDS 的查詢結果」，選 ElastiCache for Redis。

4. Aurora Global Database 與 DynamoDB global tables 在多 Region 工作負載中有何差異？

Aurora Global Database 是一個可寫入的主要 Region 加最多五個唯讀次要 Region（Aurora MySQL 支援可選的 write forwarding）。它是關聯式、符合 ACID 規範的，且典型複寫延遲不到一秒。當工作負載為關聯式、寫入集中在單一 Region，且次要 Region 提供讀取服務加上災難復原時，使用 Aurora Global Database。DynamoDB global tables 在所有參與 Region 之間都是 active-active——每個 Region 都是主節點。任何 Region 的寫入都會在數秒內使用 last-writer-wins 衝突解決機制傳播至所有其他 Region。當工作負載為鍵值或文件型、寫入分散在各地理位置，且 last-writer-wins 衝突解決機制可接受時，使用 DynamoDB global tables。在 SAA-C03 中，「關聯式」加「全球」通常對應 Aurora Global Database；「NoSQL」加「多 Region 寫入」對應 DynamoDB global tables。

5. Amazon RDS Proxy 與 Amazon ElastiCache 在高並發工作負載中有何差異？

RDS Proxy 做的是 database connection pooling。它位於應用程式用戶端（通常是 AWS Lambda、ECS Fargate 或 EKS Pod）與 RDS 或 Aurora 資料庫之間，將數千個用戶端連線多工到較小的持久資料庫連線池上。這解決了「連線耗盡」與「連線抖動」的故障模式，並加速了 Multi-AZ 容錯移轉的感知速度。RDS Proxy 不快取查詢結果。ElastiCache 在記憶體中快取查詢結果或任意應用程式狀態。兩個服務解決的是正交問題：RDS Proxy 解決連線開銷；ElastiCache 解決重複讀取的成本。在 Serverless 技術棧上的高效能資料庫解決方案通常兩者都需要——RDS Proxy 讓 Aurora 連線在 Lambda 扇出下保持健康，ElastiCache for Redis 則快取頻繁查詢的結果。

6. 我應該為兩個大型事實資料表之間的 JOIN 選擇哪種 Redshift 資料分佈風格？

對兩個資料表都在 JOIN 欄位上選擇 KEY 分佈。KEY 分佈將具有相同分佈鍵值的資料列放在同一個分片上，讓 JOIN 成為零資料重新分佈的共置 JOIN。若其中一個資料表很小（幾百 MB 以下的維度資料表），改用對小型資料表使用 ALL 分佈——每個計算節點都得到小型資料表的完整副本，完全避免重新分佈，代價是儲存空間加倍。在大型且被 JOIN 的資料表上應避免 EVEN 分佈，因為每次查詢都會觸發 DS_DIST_INNER 或 DS_BCAST 步驟，在節點網路間傳輸 TB 級資料。在 SAA-C03 中，「兩個大型資料表在同一欄位上 JOIN」是 KEY 分佈的經典觸發情境；「一個小型參考資料表與許多事實資料表 JOIN」是 ALL 分佈的觸發情境。

7. 何時應使用 ElastiCache for Redis cluster mode 開啟而非關閉？

當資料集超過最大單一 Redis 節點的記憶體大小、當寫入 throughput 必須擴展至超過一個主節點，或當租戶必須跨分片隔離時，選cluster mode 開啟（sharding）。Cluster mode 開啟支援最多 500 個分片，每個分片有一個主節點加最多五個 replica，資料依雜湊槽跨分片分區。當資料集能放入單一節點且只需要讀取擴展加上高可用性時，選cluster mode 關閉——一個主節點加最多五個 replica，所有讀取可命中 replica，容錯移轉是自動的。Cluster mode 關閉操作更簡單，是 Session store 與小型快取的預設選擇。Cluster mode 開啟是大型快取（數百 GB）、高寫入速率排行榜或多租戶隔離場景的預設選擇。

延伸閱讀

• Amazon RDS User Guide: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html
• Amazon RDS Read Replicas: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
• Amazon RDS Proxy: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html
• Amazon Aurora User Guide: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html
• Aurora Endpoints: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Endpoints.html
• Aurora Serverless v2: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html
• Aurora Global Database: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html
• Aurora Parallel Query: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html
• DynamoDB Partition Key Best Practices: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html
• DynamoDB Capacity Modes: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html
• DynamoDB Accelerator (DAX): https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.html
• DynamoDB Global Tables: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html
• ElastiCache for Redis: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html
• ElastiCache for Memcached: https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/WhatIs.html
• Amazon Redshift Developer Guide: https://docs.aws.amazon.com/redshift/latest/dg/welcome.html
• Redshift Distribution Styles: https://docs.aws.amazon.com/redshift/latest/dg/c_choosing_dist_sort.html
• Redshift Serverless: https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-whatis.html
• AWS SAA-C03 Exam Guide: https://d1.awsstatic.com/training-and-certification/docs-sa-associate/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf