Microsoft AZ-305: 資料儲存與資料庫解決方案 — 學習指南

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

屬於 Microsoft Azure Solutions Architect Expert AZ-305 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

在 Azure 上設計資料儲存時，需要在多種資料庫和儲存選項之間權衡一致性、延遲、可用性、營運複雜度和成本。此平台涵蓋了全受控的關聯式資料庫、全球分佈的 NoSQL、具備資料生命週期治理的物件儲存、高吞吐量的分析資料湖，以及記憶體內快取。您的架構設計應從工作負載的特性開始——交易型 vs. 分析型、全球觸及 vs. 區域性、結構描述的剛性、讀寫模式、規模與速度——並選擇符合這些限制，同時又能滿足安全性、彈性和治理要求的服務與組態。

Azure 上的關聯式資料服務

Azure SQL Database 提供兩種購買模型。DTU 模型將 CPU、記憶體和 I/O 組合到一個跨越 Basic、Standard 和 Premium 層的混合單位中；它很簡單，但在容量規劃上不夠透明。vCore 模型則將運算、記憶體和儲存分開，提供硬體選擇、可預測的擴展性，以及如 Azure Hybrid Benefit 和保留容量等成本槓桿。在 vCore 模型下，主要的服務層級有 General Purpose (運算和遠端儲存解耦，成本均衡)、Business Critical (具備 Always On 複本的本機 SSD，提供低延遲 I/O 和快速容錯移轉)，以及 Hyperscale (採用日誌結構化架構，具備頁面伺服器和分散式儲存，適用於數 TB 等級的規模和快速的快照式操作)。適用於 General Purpose 的 Serverless 會在設定的最小和最大值之間自動擴展運算資源，並可在閒置時自動暫停；您只需按運算秒數和儲存空間付費。這非常適合間歇性或開發工作負載，但在恢復時會產生冷啟動和快取暖機的成本。

彈性集區 (Elastic pools) 讓多個資料庫共享一個運算預算和 I/O 餘裕，從而平滑化尖峰負載，並為許多小型、負載多變的資料庫降低成本。DTU 和 vCore 模型中都有集區；正確的規模設定需要了解總體並行性以及每個資料庫的突發限制，以避免吵雜鄰居效應 (noisy-neighbor effects)。

Azure SQL 的彈性模式包括作用中異地複寫 (active geo-replication) 和自動容錯移轉群組 (auto-failover groups)。作用中異地複寫以非同步方式在任何 Azure 區域中維護最多四個可讀取的次要資料庫，容錯移轉是針對每個資料庫啟動。自動容錯移轉群組將跨成對邏輯伺服器的多個資料庫作為一個單元進行管理，提供讀寫和唯讀的接聽程式端點，並處理計劃性或非計劃性的容錯移轉，且可設定寬限期——非常適合多租戶 SaaS。區域備援 (Zone redundancy) 可在 Business Critical (和 Hyperscale) 層級中使用，以跨越一個區域內的可用性區域 (Availability Zones)，從而提高區域內的容錯能力。

Azure SQL Managed Instance (MI) 的目標是達到近 100% 的 SQL Server 相容性 (SQL Agent、跨資料庫查詢、Linked Servers、CLR、Service Broker)。它在您的虛擬網路內部一個專用、委派的子網路 (Microsoft.Sql/managedInstances) 中執行。執行個體僅使用私有 IP；請設定網路安全性群組和路由表，以允許管理流量通往 Azure 控制平面，以及資料流量通往您的應用程式。與 Azure Private DNS (或自訂 DNS) 整合，以便用戶端能解析受控執行個體的私有 FQDN。對於混合式連線和遷移，請確保透過 site-to-site VPN 或 ExpressRoute 建立直接連線。遷移路徑包括使用原生備份/還原至 Azure Blob Storage (WITH COPY_ONLY, WITH MOVE)、使用 Azure Database Migration Service (DMS) 進行線上或離線遷移，以及在適當情況下使用交易式複寫或日誌傳送。MI 的 Business Critical 層級增加了低延遲儲存和高可用性；General Purpose 則提供具成本效益的遠端磁碟儲存。

Azure Database for PostgreSQL 和 MySQL 的 Flexible Server 提供對維護時段的精細控制、可停止/啟動以節省成本，以及透過 VNet 整合實現網路隔離。高可用性選項包括用於最快容錯移轉的同區域同步待命，以及可承受區域性故障的區域備援 HA (具備自動容錯移轉的同步複寫)。讀取複本 (區域內，且對許多版本而言也支援跨區域) 可分擔讀取工作負載並支援近乎即時的分析；它們是非同步的，不適用於要求嚴格一致性讀取的場景。根據 IOPS/延遲目標選擇運算和儲存層級，並在用戶端函式庫中規劃連線容錯移轉的處理方式。

非關聯式與全球分散式儲存

Azure Cosmos DB 是一項全受控、多模型、全球分散式的資料庫，提供一站式全球複寫，並能在 99 百分位數下達到個位數毫秒的讀寫延遲。請根據生態系的契合度與資料模型選擇 API：Core (SQL) API 用於文件與類 SQL 查詢，並提供豐富的 SDK 支援；MongoDB API 用於 Mongo 線路通訊協定相容性；Cassandra API 用於寬欄式工作負載；Gremlin API 用於圖形周遊；Table API 則用於鍵/屬性情境。輸送量以要求單位 (request units, RU) 佈建，可使用固定或自動調整規模模式；設計分割區與索引時，應以最小化 RU 消耗為目標。

分割是基礎。選擇一個高基數的分割區索引鍵，它能均勻分佈儲存與流量、避免熱分割區，並與您的存取模式對齊 (例如，多租戶寫入時使用 tenantId 或 userId，或使用合成複合鍵來平衡讀取)。邏輯分割區在大小與輸送量上有所限制；建立模型時應讓熱門工作集保持分散。容器的分割區索引鍵在建立後無法變更；若要遷移，需要建立新容器並進行資料搬遷。

Cosmos 的一致性橫跨五個可調整的層級：強式 (Strong) (可線性化，RU/延遲最高)、限定過時 (Bounded Staleness) (可預測的延遲或版本視窗)、會話 (Session) (以用戶端為中心，可讀取自己的寫入，為熱門的預設選項)、一致性前置 (Consistent Prefix) (讀取不會亂序)，以及最終 (Eventual) (最大化可用性與效能，但可能出現異常)。您可以為每個帳戶選擇預設值，並在需要時針對每個請求覆寫。多區域寫入可實現真正的多主機架構，以達成低延遲的全球寫入與更高的可用性；衝突解決可透過「後寫者優先 (Last-Writer-Wins)」(基於指定屬性)、自訂原則，或使用預存程序與衝突摘要的應用程式邏輯來處理。

在選擇正確的資料儲存時，需將需求與功能對應。嚴格的關聯式完整性、複雜的聯結與交易保證，適合選擇 Azure SQL Database 或 Managed Instance。大規模的全球擴展、彈性的結構描述與低延遲的地理存取，則適合 Cosmos DB。圖形問題 (如社交、推薦、網路拓撲) 可對應至 Cosmos DB Gremlin API，或當關聯式共置有益時，可使用 Azure SQL 中的圖形功能。高擷取量的時間序列遙測、臨時性探索與近乎即時的分析，則與 Azure Data Explorer 相符。非結構化的 blob、媒體與大型二進位承載，應存放在 Azure Blob Storage 或 ADLS Gen2 中，並將中繼資料存於互補的資料庫。

物件與分析儲存

Azure Blob Storage 是非結構化資料的基礎。存取層將儲存成本與存取模式對齊：經常性 (Hot) 層用於頻繁存取，非經常性 (Cool) 層用於不頻繁存取 (至少保留 30 天)，封存 (Archive) 層則用於長期冷儲存 (至少保留 180 天，且重新凍結需數小時)。建於 SSD 上的 Premium 區塊 blob 帳戶可提供低延遲、高交易量的工作負載，例如擷取管線。生命週期管理原則會根據規則——如上次修改時間、blob 索引標籤或前置詞——自動化資料轉換與刪除，無需手動介入即可降低成本。

區塊 blob 的物件複寫功能，可在儲存體帳戶之間 (相同或不同區域) 非同步地鏡像物件及其版本。它要求來源與目的地都啟用 blob 版本設定，並由每個容器配對的原則驅動，支援合規性與多區域分佈，同時保持與帳戶層級備援選項的獨立性。不變性 (WORM) 可在容器或 blob 範圍內透過以時間為基礎的保留與法律保留來強制執行，並提供如 allowProtectedAppendWrites 等選項以支援僅附加日誌。版本層級不變性可保護過去的狀態免於竄改與勒索軟體的威脅。

Azure Data Lake Storage Gen2 為 Blob 儲存新增了階層式命名空間，提供了真正的目錄、不可部分完成的重新命名，以及最佳化的檔案操作。細微度的類 POSIX ACL 可在目錄與檔案層級控制存取，包含存取 ACL 與預設 ACL，並與 Azure RBAC 一同進行評估。使用 Azure AD 與 OAuth2 進行驗證，以實現最低權限與可稽核性。與分析服務的整合是原生的：Azure Synapse Analytics 與 Azure Databricks 透過 ABFS 驅動程式存取 ADLS Gen2，具備可擴展的輸送量；而 Azure Data Factory、Azure Purview 與 Azure Machine Learning 等服務則整合用於協調流程、治理與模型訓練。設計資料夾結構與 ACL 繼承時，應隔離不同領域並支援多團隊治理，並利用變更摘要與虛刪除等功能來進行譜系追蹤與復原。

快取與效能加速

Azure Cache for Redis 提供次毫秒級的資料存取、發佈/訂閱 (pub/sub) 與分散式鎖定功能。其層級對應到可用性與擴展需求。基本 (Basic) 層為單一節點，適用於開發/測試。標準 (Standard) 層新增了具備自動容錯移轉的雙節點主要/複本架構。高階 (Premium) 層則引入了跨分區的叢集化、持續性 (RDB 快照與 AOF)、VNet 支援，以及主動–被動拓撲中的異地複寫。Enterprise 與 Enterprise Flash (Redis Enterprise) 層新增了使用 CRDT 的主動–主動異地複寫以支援多區域寫入、更大的記憶體空間、多執行緒效能與模組支援；Flash 層則用 NVMe 擴充 DRAM，以較低成本提供巨量快取。請選擇符合索引鍵 TTL 與工作負載的收回原則：當並非所有索引鍵都有 TTL 時，使用 allkeys-lru/allkeys-random；當只有會過期的索引鍵應被收回時，使用 volatile-lru/volatile-ttl；當寫入失敗比收回資料更可接受時，則使用 noeviction。持續性可減少容錯移轉時的資料遺失，但代價是 I/O 與延遲的額外負荷；僅在需要時啟用，並調整快照間隔。

將 Redis 作為旁路快取 (aside cache) 整合，用於儲存資料庫查詢結果、會話狀態與速率限制計數器。確保資料填入是冪等的，應用適當的 TTL，並實作斷路器。對於叢集式快取，應確定性地分區索引鍵；對於 Enterprise 主動–主動模式，則需測試衝突解決語意。

安全性、存取與彈性模式

Azure Storage 的存取委派使用 SAS 權杖與原則。服務 SAS 授予對特定資源（容器、blob、檔案共用、佇列或資料表）的限定範圍存取權。帳戶 SAS 則橫跨帳戶中的多個服務，功能強大，需謹慎保護。使用者委派 SAS（僅限 Blob 服務）源自 Azure AD 與使用者委派金鑰，能夠實現無需帳戶金鑰的個別使用者存取控制——這對於多租用戶應用程式和短期授權是理想的選擇。預存存取原則（可在容器、共用、佇列和資料表上設定）將 SAS 權杖綁定到伺服器端的原則，讓您可以在不輪替帳戶金鑰的情況下撤銷或縮短存取權限；沒有預存存取原則的 SAS 只能透過權杖到期或輪替金鑰來撤銷。

在加密方面，Azure Storage 預設使用服務端加密。儲存在 Azure Key Vault 或 Managed HSM 中的客戶管理的金鑰 (CMK) 提供了集中的金鑰生命週期控制與可稽核性。加密範圍允許在同一個儲存體帳戶內，依容器或前綴使用不同的 CMK，支援依租用戶的金鑰管理。若要進行個別 blob 的用戶端控制，可以在請求中提供客戶提供的金鑰 (CPK)。可視需求將帳戶或範圍層級的 CMK 與 CPK 結合使用，以達到法規隔離的要求。

Azure SQL 的安全性與彈性建立在前面已描述過的平台層級與複寫功能之上。使用自動容錯移轉群組來進行協調的跨區域容錯移轉與專屬接聽程式端點，並在可用時啟用區域備援以抵禦區域性故障。對於敏感資料，可應用動態資料遮罩來對非特權使用者的查詢結果中的 PII 進行混淆，並考慮使用 Always Encrypted 搭配安全記憶體保護區，在必須防止管理員檢視明文時，對資料行進行用戶端保護。應根據您所選層級的複寫行為來監控 RPO/RTO 目標，並定期測試容錯移轉。

在規劃端對端架構時，應統一身分識別（為 SQL、儲存體和分析使用 Azure AD），透過 RBAC 和 ACL 應用最低權限原則，使用 Private Link 或 VNet 整合將資料保留在公用網際網路之外，並實作生命週期、不可變性與複寫原則，以滿足資料保留與災難復原 (DR) 的目標。

實務問題情境

Contoso Retail 正在推出一個全球電子商務平台，其特點是日間流量波動劇烈、有嚴格的 PII 管控、產品媒體達 PB 等級的規模，以及需要近乎即時的個人化功能。他們要求全球低延遲讀取、最低的停機時間，以及受監管的資料分析。

將交易型錄與訂單資料庫放置在 Azure SQL Database 上，並使用 vCore 模型：

層級選擇：訂單資料庫使用 Business Critical（低延遲儲存與快速容錯移轉），型錄資料庫使用 General Purpose serverless（流量有突增且有閒置時段）。
原因：vCore 提供可預測的規模調整與 Hybrid Benefit；Business Critical 滿足訂單所需的延遲/HA 需求；serverless 在低活動期間將運算成本降至最低。

為這兩個資料庫設定跨配對區域的自動容錯移轉群組，並啟用區域備援：

原因：統一的讀寫接聽程式簡化了應用程式的容錯移轉；區域備援可防止區域性中斷；跨區域複本滿足 DR 需求，並為報表提供讀取擴展。

將產品圖片與影片儲存在 Azure Blob Storage (general-purpose v2) 中，並搭配生命週期管理與物件複寫：

原則：活躍項目使用 Hot 層，30 天後移至 Cool 層，180 天後移至 Archive 層；透過物件複寫將資料複製到次要區域。
原因：隨時間推移將儲存成本降至最低，同時提供與帳戶備援無關的非同步區域性分發；透過針對法律資產的不可變性（以時間為基礎的 WORM）滿足保留要求。

在 Azure Cosmos DB (Core API) 上建立客戶個人資料與購物車服務，並採用多區域寫入與 Session 一致性：

設計：依 userId 進行分割以分散寫入；啟用自動調整 RU。
原因：多重主機為全球使用者提供低延遲寫入與高可用性；Session 一致性確保每個使用者都能「讀取自己的寫入」，提供強大的使用者體驗保證與高效率的 RU 使用。

引入 Azure Cache for Redis Enterprise 來處理工作階段狀態、產品詳細資料快取與速率限制：

模式：叢集搭配 Active-Active 地理備援，以實現多區域寫入。
原因：次毫秒級的存取速度與基於 CRDT 的衝突解決機制，讓工作階段與計數器在跨區域間保持一致，無需單一寫入主機。

將點擊流與操作日誌存放在 Azure Data Lake Storage Gen2 中，並使用階層式命名空間與 POSIX ACL：

整合：串流擷取將資料寫入策劃整理的資料夾；Databricks 與 Synapse 透過 ABFS 讀取；啟用變更摘要與虛刪除。
原因：細微性的目錄/檔案 ACL 支援多團隊治理；階層式命名空間優化了檔案操作；原生的分析整合縮短了洞察時間。

使用 Azure Database for PostgreSQL Flexible Server 來建置推薦微服務：

HA：區域備援的同步待命；佈建讀取複本以進行功能實驗。
原因：豐富的 Postgres 擴充功能生態系與 JSONB 功能適合此服務；受控的 HA 保持低 RTO；複本可分擔讀取負載。

透過使用者委派 SAS 保護暫時性媒體上傳的存取，並為每個租用戶使用 CMK 搭配加密範圍來確保安全：

原因：消除了帳戶金鑰的曝險，並實現了依租用戶的密碼編譯隔離與可稽核性。

將地端 SQL Server 的舊有訂單資料遷移至 Azure SQL Managed Instance，以進行封存處理與由代理程式驅動的任務：

步驟：使用 Data Migration Assistant 進行評估；透過 DMS 執行線上遷移；透過 ExpressRoute 連接。
原因：MI 保留了 SQL Agent 作業與跨資料庫操作，簡化了現代化過程，同時讓封存工作負載靠近雲端資料。

此設計透過 Cosmos DB 的多區域寫入與 Redis Enterprise 實現了全球效能，利用 ADLS Gen2 的 ACL 與 Storage 的不可變性強制執行治理，藉由 Azure SQL 的不同層級與自動容錯移轉群組提供了交易完整性與快速容錯移轉，並透過 serverless 運算與生命週期原則優化了成本。

← 身分、治理與合規性 · 所有領域 · 運算與應用程式架構 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →