資料庫服務

🧱 白話：Read Replica 的原理是「讀寫分離」——主庫負責寫、影印幾份分身分攤讀流量（非同步抄寫，所以有複本延遲）；Multi-AZ 則是「待命備援」。SQL vs NoSQL、交易、索引、一致性這些本章會一直用到的地基，見 基礎篇 ch07 資料庫基礎。

這是 SAA 考試中最常出現的資料庫比較，必須清楚兩者的目的完全不同：

• Multi-AZ（多可用區）— 高可用 HA：在另一個 AZ 維持一個同步的 Standby 副本。主要 DB 故障時自動切換（Failover），DNS 端點不變。重點：Standby 副本不接受讀取請求，純粹是備用。
• Read Replicas（讀取副本）— 效能擴展：非同步複製到最多 5 個讀取副本，可在同 AZ、跨 AZ 或跨 Region。讀取副本可接受查詢（SELECT），分擔主要 DB 的讀取壓力。可以將 Read Replica 提升（Promote）為獨立的 DB。

• Aurora 基礎：AWS 完全自研的雲端原生關聯式資料庫，相容 MySQL（快 5 倍）和 PostgreSQL（快 3 倍）。費用比 RDS 高約 20%，但效能大幅提升。
• 儲存架構：自動跨 3 個 AZ 存 6 份資料（Quorum／法定人數機制——不必等「全部」複本都確認才算數，只要湊到「過半數」的複本回應就好，這樣即使少數複本所在的 AZ 掛掉也不影響服務）。寫入：4/6 成功即確認；讀取：3/6 即可。這兩個數字不是隨便選的：寫入門檻(4) + 讀取門檻(3) > 總數(6)，可以保證每次讀取一定會碰到至少一份「最新」的複本（因為讀寫的複本集合一定有重疊），同時就算 1 個 AZ（2 份複本）整個掛掉，剩下 4 份仍然湊得出寫入門檻，服務不中斷。單一 Volume，但自動擴展（10GB 增量，最大 128 TB）。
• Aurora Read Replicas：最多 15 個讀取副本（RDS 只有 5 個），同一底層 Storage，延遲極低（10ms 以內）。Reader Endpoint 可以自動負載平衡讀取請求。
• Aurora Serverless：自動依需求調整容量，適合不頻繁或不可預測的工作負載，按實際使用量計費（無需預配置）。
• Aurora Backtrack（倒帶）：把整個叢集原地倒帶回過去某個時間點（最多 72 小時內，秒到分鐘級完成），用來救「誤刪資料表、跑錯一支 UPDATE」這類人為失誤。關鍵差別在不會產生新實例——端點、連線字串都不變，應用程式不用改設定；相對地，快照還原（Restore）會建出一台全新實例，動輒數十分鐘且要重接端點。
  ・限制：僅 Aurora MySQL 相容版支援（PostgreSQL 版沒有），且必須建立叢集時就啟用，另外按保留的變更紀錄計費。
  ・倒帶是「可逆」的：倒過頭了還能再往前倒回來，但倒帶期間資料庫會短暫中斷。
• Aurora Global Database：一個主 Region 可寫入，最多 5 個次要 Region 只讀。次要 Region 的延遲不到 1 秒。主 Region 故障時，可在 1 分鐘內將次要 Region 提升為主要。
• Aurora Multi-Master：多個寫入節點，實現寫入高可用（預設 Aurora 只有一個可寫入節點）。

• 核心特性：完全託管的 NoSQL 鍵值 + 文件資料庫，Serverless（無需管理伺服器）。個位數毫秒延遲，自動擴展，適合任何規模。
• 主鍵：Partition Key（分區鍵）+ 可選的 Sort Key（排序鍵）。資料依 Partition Key 分散到不同分區。
• 讀取模式：Eventually Consistent（最終一致，預設，便宜）或 Strongly Consistent（強一致，貴）。
• 容量模式：Provisioned vs On-Demand（考試很愛考的二選一）：
  ・DynamoDB 的吞吐量用 RCU／WCU 計量——1 WCU = 每秒寫入 1 筆 1KB 以內的資料；1 RCU = 每秒 1 次「最終一致讀取」2 筆 4KB 以內（強一致讀取只有一半，也就是 1 筆）。
  ・Provisioned（佈建容量）：事先講好每秒要多少 RCU/WCU，照佈建量計費（用不用都要付）。可掛 Auto Scaling 依實際用量調整，但擴容需要時間，突然的尖峰仍可能被限流（throttling，回 ProvisionedThroughputExceededException）。適合流量穩定、可預估的負載，單價最便宜。
  ・On-Demand（按需容量）：不用預估，照實際請求數計費，瞬間吸收尖峰、閒置時幾乎不花錢。單價比 Provisioned 貴數倍，但省下預估與被限流的風險。適合全新、尖峰不可預測、或長時間閒置的應用。
  ・兩種模式可以隨時互換（同一張表每 24 小時可切換一次）。
• 次要索引：GSI vs LSI——主鍵以外的欄位不能直接查（只能整表掃描 Scan，慢又貴），要用非主鍵欄位查詢就得建次要索引：
  ・GSI（Global Secondary Index，全域次要索引）：可指定和主表完全不同的 partition key / sort key，建表後可隨時新增或刪除，有自己獨立的 RCU/WCU，只支援最終一致讀取。
  ・LSI（Local Secondary Index，本地次要索引）：partition key 必須和主表相同，只能換 sort key；只能在建表當下建立、之後不能加也不能刪，共用主表的容量，支援強一致讀取。
  ・口訣：要換 partition key、或表已經上線了 → 只能 GSI；同一個 partition key 底下想換個排序方式、且還沒建表 → LSI。
• DAX（DynamoDB Accelerator）：DynamoDB 的記憶體快取，讀取延遲從毫秒降到微秒。不需要修改應用程式程式碼（相容 DynamoDB API）。
• DynamoDB Streams：捕捉表格中的變更事件（插入/修改/刪除），可用來觸發 Lambda（類似 CDC）。
• Global Tables：多 Region 的多主（Multi-Master）寫入，讓全球用戶都能就近低延遲讀寫。需要先啟用 Streams。
• TTL：設定物件的到期時間，自動刪除過期資料，不額外收費。

ElastiCache 是 AWS 管理的記憶體快取服務，提供 Redis 和 Memcached 兩種引擎：

• Redis：
  ・支援資料持久化（AOF/RDB），重啟後資料不遺失
  ・支援Multi-AZ + Read Replicas（高可用）
  ・支援複雜資料結構（List, Set, Sorted Set, Hash）
  ・支援 Pub/Sub、Lua 腳本
  ・支援 Backup/Restore
  ・適合：Session 管理、排行榜（Leaderboard）、即時分析
• Memcached：
  ・純快取，不支援持久化，重啟資料全部遺失
  ・支援多執行緒（Multi-threaded），比 Redis 更能利用多核心
  ・架構更簡單，只支援基本的 Key-Value
  ・不支援 Backup/Restore、Replication、Multi-AZ
  ・適合：大規模靜態資料快取、只需要高速讀取的場景

快取策略（Caching Strategy）：選了引擎之後，還要決定「資料什麼時候進快取」。考題常用敘述而不是名詞來問，兩種策略各自的缺點就是判斷關鍵：

• Lazy Loading（惰性載入，又稱 Cache-Aside）：應用程式先問快取，沒命中（cache miss）才回資料庫撈，撈完順手寫進快取，下次就有了。
  ・優點：只有真正被讀到的資料才佔快取空間；快取節點掛掉不會導致功能壞掉（只是變慢）。
  ・缺點：每一筆資料的第一次讀取一定是慢的（要吃 3 趟：問快取→查 DB→寫快取）；而且資料庫被改過時快取不會自己更新，可能讀到陳舊資料（stale data）。
• Write-Through（寫穿）：每次寫資料庫時，同步把新值也寫入快取。
  ・優點：快取裡的資料永遠是新的，不會有陳舊問題；讀取一律命中。
  ・缺點：每次寫入都變慢、成本變高；而且會快取到「寫了但根本沒人讀」的資料，浪費記憶體；新加的快取節點在有人寫入前是空的（missing data）。
• TTL（Time To Live，存活時間）：不是獨立的第三種策略，而是補在前兩者上的保險——給每筆快取設到期時間，時間到自動失效重抓。實務上最常見的組合就是 Lazy Loading + TTL，用可接受的過期時間換掉「無限期陳舊」的風險。

Amazon Redshift（資料倉儲）：

• OLAP（Online Analytical Processing，線上分析處理）資料倉儲，列式儲存。比 OLTP（RDS，Online Transaction Processing，線上交易處理，逐筆新增/查詢/修改單一訂單這類日常操作）快 10 倍用於分析查詢。兩者的本質差異在儲存方式：OLTP 是「行式儲存」，把同一筆資料（一整列，例如一張訂單的所有欄位）放在一起，適合快速存取單筆完整資料；OLAP 是「列式儲存」，把同一個欄位（例如所有訂單的「金額」）集中存放，分析查詢通常只需要少數幾個欄位、但要掃過大量筆數做加總/平均，只讀需要的欄位、不必連帶讀取整列其他無關資料，因此快非常多。
• 適合：BI（商業智慧）、報表、大數據分析、ETL 後的分析。
• Redshift Spectrum：直接查詢 S3 上的資料（不需要載入 Redshift），擴展 Redshift 的查詢能力。
• 支援 Multi-AZ（較新功能），原本只有單 AZ。

其他專用資料庫：

• DocumentDB：相容 MongoDB 的文件資料庫，AWS 管理版 MongoDB。
• Neptune：圖資料庫（Graph DB）。適合：社交網路、知識圖譜、推薦系統。
• ElasticSearch / OpenSearch Service：搜尋和分析引擎。適合：日誌分析、全文搜尋。
• Timestream：時間序列資料庫。適合：IoT 資料、監控指標。
• QLDB（Quantum Ledger DB）：不可更改的帳本資料庫，記錄完整歷史。適合：金融交易紀錄。