DynamoDB、Aurora 與向量儲存用於 ML 服務

DynamoDB、Aurora 和向量存放區構成了操作資料層，每當工作負載需要亞毫秒級讀取、交易式寫入或對嵌入 (embeddings) 進行相似性搜尋時，AWS 資料工程師就會將其接入管道。在 DEA-C01 考試中，網域 2 任務 2.1 經常測試一個單一決策：給定工作負載描述，哪種存放區是正確的？陷阱在於 DynamoDB、Aurora 和向量存放區看起來都像資料庫，但它們具有不同的延遲剖析、不同的模型一致性、不同的擴展原語以及完全不同的成本形態。如果資料工程師為每秒 10 萬次寫入的 IoT 擷取端點選擇 Aurora，將會浪費金錢且無法滿足 SLA；如果為複雜的 10 表關係聯結選擇 DynamoDB，則會在查詢表達能力上碰壁。

本指南透過資料工程師與 MLOps 工作的視角深入探討 DynamoDB、Aurora 和向量存放區家族（Aurora pgvector、MemoryDB、OpenSearch k-NN）— 選擇資料存放區、將 CDC 連接到管道中、匯出到資料湖以及饋送 ML 服務路徑。內容涵蓋了 DynamoDB 容量模式與串流 (Streams)、Aurora MySQL 與 PostgreSQL 及 Aurora Serverless v2 的對比、用於嵌入搜尋的 pgvector、用於亞毫秒級向量查閱的 MemoryDB、用於混合關鍵字加向量檢索的 OpenSearch k-NN、定義 DynamoDB 或 Aurora 何時不適用的 OLTP 與 OLAP 界限，以及圍繞 DynamoDB 分析、向量索引類型和零 ETL (zero-ETL) 整合的規範 DEA-C01 陷阱。

資料存放區選擇框架 — OLTP、OLAP、串流、向量

每個 DEA-C01 存放區選擇問題都可以透過將工作負載對應到以下四種模式之一來回答。

OLTP — 交易式讀取與寫入

線上交易處理 (Online Transaction Processing) 指的是具有個位數毫秒延遲、可預測的每請求金鑰以及高並行性的短暫讀寫。範例：購物車更新、使用者個人檔案讀取、IoT 裝置狀態、下單。DynamoDB 和 Aurora 都是 OLTP 存放區；DynamoDB 具備無限的水平擴展能力，而 Aurora 則透過垂直擴展和讀取複本提供更嚴格的關係型語義。

OLAP — 分析型聚合

線上分析處理 (Online Analytical Processing) 指的是對數百萬或數十億行進行聚合、跨多個資料表聯結以及按欄掃描的長時間讀取。Redshift、Athena 和 EMR 是 OLAP 引擎。針對 DynamoDB 執行 OLAP 查詢是規範的錯誤答案陷阱。

串流 (Streaming) — 持續事件流

串流工作負載以高頻率存入事件，並具有亞秒級的新鮮度期望。Kinesis Data Streams、MSK 和 DynamoDB Streams 是串流原語。特別是 DynamoDB Streams，它兼作饋送 Lambda 或 Kinesis 管道的 CDC 來源。

向量 (Vector) — 針對嵌入的相似性搜尋

向量工作負載儲存高維度浮點陣列（來自 Bedrock Titan 或 OpenAI 等模型的嵌入），並提供近似最近鄰 (ANN) 查詢以尋找 K 個最相似的向量。Aurora pgvector、MemoryDB 向量搜尋和 OpenSearch k-NN 是 AWS 的選項。RAG（檢索增強生成）和推薦系統是規範的使用案例。

Amazon DynamoDB — 鍵值與文件 NoSQL

DynamoDB 是 AWS 原生的全受管 NoSQL 服務，也是考試中預設的 OLTP 存放區。

延遲與處理量剖析

DynamoDB 在任何規模下都能提供個位數毫秒的 P99 讀寫延遲 — AWS 的行銷主張在維運上是真實的，因為儲存引擎在 SSD 上進行分區分片 (partition-sharded)，且 API 旨在將每場請求路由到單個分區。無需調整叢集大小，除了按請求計費外沒有最低成本。

容量模式 — 按需對比佈建

DynamoDB 資料表以兩種容量模式之一執行。按需 (On-demand) 模式按請求自動擴展讀寫並按請求單元計費；對於不可預測的工作負載或沒有流量歷史的新應用程式非常理想。佈建 (Provisioned) 模式每秒預留讀取和寫入容量單元 (RCU 和 WCU)，在持續負載下每請求成本較低，並支援自動擴展規則。DEA-C01 的陷阱在於成本計算：流量穩定可預測的工作負載，按需模式的成本大約是等效佈建模式的 5 到 7 倍。流量穩定後應從按需切換為佈建。

分區鍵與熱分區

每個 DynamoDB 項目都有一個分區鍵（以及可選的排序鍵構成複合鍵）。DynamoDB 對分區鍵進行雜湊處理，以將項目分配到特定分區。如果工作負載將 90% 的項目寫入同一個分區鍵，則會建立一個「熱分區 (hot partition)」，無論佈建容量多少都會導致節流 — 這是規範的反模式。請選擇高基數的分區鍵（user_id, device_id, order_id），避免低基數的金鑰（region, status, date）。

全域資料表 (Global Tables) — 跨區域主動-主動

DynamoDB 全域資料表跨區域非同步複寫寫入，並採用「最後寫入者勝 (last-writer-wins)」衝突解決機制。使用案例：需要在全球範圍內實現低延遲讀取的全球分佈式使用者群、無需手動容錯移轉的災難復原。考試中常設陷阱，建議使用全域資料表來實現跨區域的交易一致性 — 這是錯誤的，該模型是最終一致性的。

作為 OLTP 來源的 DynamoDB — 非分析型存放區

DynamoDB 非常擅長點查閱 (point lookups) 和分區內的範圍掃描。它不擅長全表聚合、多表聯結和隨機分析。正確模式：DynamoDB 為應用程式提供交易式讀取，下游管道（透過 DynamoDB 匯出至 S3 或 DynamoDB Streams）將資料匯出到 S3，以便在 Athena、Redshift 或 EMR 中進行分析。

DynamoDB Streams — 管道的 CDC 來源

DynamoDB Streams 是變更資料擷取 (CDC) 饋送，它將 DynamoDB 轉變為串流來源。

工作原理

啟用後，DynamoDB Streams 會將每個項目級別的寫入（插入、更新、刪除）擷取到每個分區 24 小時的排序日誌中。取用者 — 通常是 Lambda 函數或透過 DynamoDB-to-Kinesis 連接器的 Kinesis Data Streams — 讀取串流並對更改做出反應。串流視圖類型控制每條記錄包含的內容：KEYS_ONLY、NEW_IMAGE、OLD_IMAGE 或 NEW_AND_OLD_IMAGES。

Lambda 觸發器模式

最常見的 DEA-C01 模式：DynamoDB Streams 觸發 Lambda 函數，該函數將項目更改扇出到下游目的地 — 寫入 S3 進行分析、發送 SNS 通知、更新 OpenSearch 索引以進行全文檢索。Lambda 處理重試、批次處理（每次呼叫最多 1 萬筆記錄）以及並行化（每個碎片一個並行呼叫）。

用於 DynamoDB 的 Kinesis Data Streams

對於高流量資料表或更長的保留需求，DynamoDB 可以將項目更改直接發佈到 Kinesis Data Stream（與 DynamoDB Streams 分開）。這為您提供了完整的 Kinesis 生態系統 — 多天保留、透過增強型扇出支援多個取用者、與 Managed Service for Apache Flink 整合 — 代價是在 DynamoDB 之上增加了 Kinesis 計費。

DynamoDB 匯出至 S3

對於時間點分析而非持續 CDC，DynamoDB 支援一次性匯出到 S3，格式為 DynamoDB JSON 或 ION，對資料表效能無影響。配合 Glue 或 Athena 執行分析，然後排程每日匯出以獲取歷史快照。

零 ETL (Zero-ETL) 整合

新型 DynamoDB 與 OpenSearch 及 Redshift 的零 ETL 整合無需編寫管道程式碼即可持續複寫資料表更改。考試指南明確提到了零 ETL — DynamoDB 到 OpenSearch 用於搜尋，DynamoDB 到 Redshift 用於分析。

Amazon Aurora — 具有 MPP 風格儲存的關係型資料庫

Aurora 是一款相容 MySQL 和 PostgreSQL 的受管關係型資料庫，結合了熟悉的 SQL 語義與雲端原生儲存。

架構 — 運算與儲存分離

Aurora 的底層儲存是一個分佈式的日誌結構磁碟區，跨三個可用區域 (AZ) 複寫，每一頁有六個複本。運算節點（寫入者和最多 15 個讀取複本）從共享儲存層讀取，因此增加讀取複本不會增加儲存成本。容錯移轉可在 30 秒或更短時間內將讀取複本切換為寫入者角色。

Aurora MySQL 對比 Aurora PostgreSQL

Aurora MySQL 相容 MySQL 8.0，具有自動擴展儲存和更快的復原能力。Aurora PostgreSQL 相容 PostgreSQL 14/15/16，適用於需要 PostgreSQL 功能（進階類型、pgvector 等擴充功能、JSONB 索引）的工作負載。根據應用程式相容性進行選擇 — 兩者在效能上並無絕對優劣。

Aurora Serverless v2

Aurora Serverless v2 根據負載以 0.5 ACU (Aurora 容量單元) 為增量自動擴展運算容量，擴展範圍從 0.5 ACU 到 128 ACU。定價按每 ACU 秒計費。使用案例：負載變化的應用程式、開發/測試環境、每個租戶資料庫流量不可預測的多租戶 SaaS。Aurora Serverless v2 支援與佈建模式相同的功能 — 讀取複本、全域資料庫、pgvector — 無需手動容量管理。

Aurora 全域資料庫 (Global Database)

Aurora 全域資料庫將主要叢集複寫到最多五個次要區域，複寫延遲低於一秒，容錯移轉 RPO 為一分鐘。使用案例：全球讀取擴展、區域級災難復原。與主動-主動模式的 DynamoDB 全域資料表不同，Aurora 全域資料庫是單寫入者模式，次要區域為唯讀。

Aurora 與 Redshift 的零 ETL 整合

Aurora MySQL 和 Aurora PostgreSQL 支援零 ETL 整合，可將交易資料持續複寫到 Redshift。複寫是受管的 — 您無需執行 Glue 或 DMS 作業。考試將此設為「無需 ETL 管道開銷即可對交易資料進行近乎即時分析」的正確答案。

Aurora 對比 RDS

RDS 是較舊的受管服務，執行 MySQL, PostgreSQL, MariaDB, Oracle, SQL Server。Aurora 是 AWS 原生的，僅限 MySQL/PostgreSQL，並提供更好的效能、更快的容錯移轉和分離式儲存。當工作負載需要 Oracle, SQL Server 或 MariaDB 時，RDS 是正確答案；否則 Aurora 是正確答案。

具有 pgvector 的 Aurora PostgreSQL — 向量相似性搜尋

pgvector 擴充功能將 Aurora PostgreSQL 轉變為用於 ML 檢索工作流程的向量資料庫。

pgvector 的功能

pgvector 向 PostgreSQL 增加了 vector 欄位類型，並支援 <-> (L2 距離)、<=> (餘弦距離) 和 <#> (內積) 運算子進行相似性搜尋。結合 PostgreSQL 索引（HNSW 或 IVFFlat），您可以直接在 SQL 中執行近似最近鄰查詢：SELECT * FROM documents ORDER BY embedding <=> '[0.1, 0.2, ...]' LIMIT 10。

何時 pgvector 是正確答案

當應用程式已在 Aurora PostgreSQL 上執行，且向量工作負載是現有資料模型的一個特徵時（具有嵌入欄位的產品表、文件塊嵌入表），pgvector 是正確的。它避免了執行獨立向量資料庫的維運開銷。權衡：在極大量向量的情況下，pgvector 的速度不如 MemoryDB，擴展性不如 OpenSearch k-NN。

何時 pgvector 是錯誤的

對於具有數億個向量、亞毫秒級延遲要求或複雜的混合關鍵字加向量搜尋的工作負載，OpenSearch k-NN 或 MemoryDB 是更好的選擇。考試會根據規模測試這一點 — 對於「與交易資料並存且使用餘弦搜尋的 10 萬個向量」，pgvector 勝出；對於「P99 亞毫秒級且具備 10 億個向量」，MemoryDB 或 OpenSearch 勝出。

用於 Redis 的 Amazon MemoryDB — 持久化向量搜尋

MemoryDB 是一款相容 Redis 的持久化記憶體內資料庫，AWS 將其定位為快取替代方案和低延遲向量存放區。

MemoryDB 對比 ElastiCache

ElastiCache for Redis 是一款非持久化快取，節點故障時資料可能會丟失。MemoryDB 則是持久化的 — 寫入在得到確認前會提交到跨多個 AZ 複寫的交易日誌中，因此 MemoryDB 可以作為主要資料庫使用，而不僅僅是快取。兩者都相容 Redis；當持久化至關重要時，MemoryDB 是正確答案。

使用 HNSW 進行向量搜尋

MemoryDB 支援使用 HNSW (Hierarchical Navigable Small World) 演算法的向量索引。HNSW 構建了一個多層圖，其中每個節點具有少量長距離邊和多個短距離邊，從而在非常高的召回率 (recall) 下實現亞毫秒級的 ANN 搜尋。MemoryDB 向量搜尋是需要在生產級延遲下進行即時嵌入查閱的 AI 應用程式的正確答案。

向量索引類型 — HNSW 對比 IVF

DEA-C01 考試指南明確提到了向量索引類型。HNSW 是基於圖的，查詢速度最快，記憶體佔用較大，構建較慢。IVF (倒排檔案索引) 將向量聚類到 Voronoi 單元中並搜尋最近的單元 — 記憶體佔用較小，構建較快，但在相同速度下召回率低於 HNSW。權衡問題：針對穩定語料庫的低延遲線上服務選擇 HNSW；針對記憶體受限或快速變化的語料庫選擇 IVF。

Amazon OpenSearch Service k-NN — 混合搜尋

OpenSearch Service 是受管的 Elasticsearch 分支，其 k-NN 外掛程式可實現用於 ML 檢索的向量搜尋。

k-NN 外掛程式

OpenSearch k-NN 增加了 knn_vector 欄位類型，並支援 HNSW、IVF 和 Lucene 引擎變體。查詢結合了向量相似性與關鍵字過濾 — 對文字欄位進行 match，對嵌入欄位進行 knn — 使 OpenSearch 成為混合檢索的規範選擇。建置在 Bedrock 上的 RAG 管道通常使用 OpenSearch 作為檢索存放區。

何時 OpenSearch k-NN 是正確的

混合關鍵字加向量搜尋、極大量的向量（1 億以上）、相似性旁邊的聚合（按類別過濾的 top-K 向量），以及已在使用 Elasticsearch/OpenSearch 的情況。OpenSearch 在維運上比 MemoryDB 更重（叢集調優、索引管理），但靈活性更高。

OpenSearch Serverless

OpenSearch Serverless 自動擴展運算和儲存，並按 OCU (OpenSearch 運算單元) 計費。向量引擎是針對嵌入工作負載最佳化的專用模式。考試中可能會出現「具有混合搜尋功能的受管無伺服器向量存放區」，這是選擇 OpenSearch Serverless 向量引擎的觸發詞。

DynamoDB、Aurora 與向量存放區的常見考試陷阱

請記住這五個。

陷阱 1 — 將 DynamoDB 用於分析

情境描述了對大型客戶表進行複雜的聚合查詢。錯誤答案：DynamoDB。正確答案：匯出至 S3（透過 DynamoDB 匯出或 Streams 到 Kinesis 到 S3）並使用 Athena 或 Redshift 查詢。DynamoDB 擅長點查閱，而非分析型掃描。

陷阱 2 — 為每秒 10 萬次寫入選擇 Aurora

情境描述了每秒 10 萬次寫入的 IoT 擷取。Aurora 在最大的寫入者執行個體上經過大量調優也只能達到約每秒 20 萬次寫入；DynamoDB 則具備無限的水平擴展能力。對於高處理量的鍵值寫入，正確答案是：DynamoDB。

陷阱 3 — 為十億級向量工作負載選擇 pgvector

情境描述了一個處理十億個文件塊的 RAG 管道。pgvector 在技術上支援，但效能會下降。正確答案：根據混合搜尋需求選擇 OpenSearch k-NN 或 MemoryDB。

陷阱 4 — 為強一致性選擇 DynamoDB 全域資料表

情境要求強一致性的跨區域寫入。DynamoDB 全域資料表在區域間是最終一致性的。正確答案：DynamoDB 中沒有強一致性的跨區域解決方案 — 應使用 Aurora 全域資料庫並將寫入路由到主要區域，或者接受具備衝突解決機制的最終一致性。

陷阱 5 — 為新的 PostgreSQL 工作負載選擇 RDS 而非 Aurora

情境描述了一個需要 PostgreSQL 的新應用程式。陷阱選項建議使用 RDS for PostgreSQL，因為它「更標準」。正確答案：Aurora PostgreSQL — 相容性相同，但速度更快、更持久、容錯移轉更好、在大規模情況下成本更低。

資料工程管道中的 DynamoDB 與 Aurora

除了存放區選擇外，DEA-C01 考試還測試這些存放區如何與資料工程管道整合。

模式 1 — 從 DynamoDB Streams 到 S3 資料湖

DynamoDB → Streams → Lambda → Firehose → S3 (Parquet) → Glue 目錄 → Athena。這是將交易更改導入分析資料湖且不影響生產表的規範 CDC 管道。

模式 2 — 從 Aurora 零 ETL 到 Redshift

Aurora MySQL 或 PostgreSQL → 零 ETL → Redshift。將交易資料持續複寫到分析倉儲中，無需 Glue 作業，無需 DMS 複寫執行個體。限制：並非所有資料類型都能複寫（如大型物件、某些自定義類型）。

模式 3 — 用於每日分析的 DynamoDB 匯出至 S3

DynamoDB → 按需匯出 → S3 (DynamoDB JSON) → Glue ETL 轉換為 Parquet → Athena/Redshift。當持續 CDC 過於繁重且每日快照已足夠時，這是正確的模式。

模式 4 — 用於報告的 Aurora 讀取複本

Aurora 寫入者 → Aurora 讀取複本 → BI 工具 (QuickSight)。使用讀取複本作為報告端點，以避免影響交易延遲。權衡：存在複寫延遲，查詢會看到略微過時的資料。

模式 5 — 用於 RAG 的向量管道

S3 文件 → Glue/Lambda 分塊 → Bedrock Titan 嵌入 → OpenSearch k-NN 或 pgvector → 查詢時應用程式檢索。DEA-C01 的考點在於資料工程的「管道對接」，而非 LLM 推論（那是 MLA-C01 的領域）。

白話文解釋 DynamoDB、Aurora 與向量存放區

三個具體的類比使這些存放區變得直觀。

類比 1 — 櫃檯對比餐廳對比侍酒師

DynamoDB 就像速食店櫃檯。你走上前說「3 號漢堡套餐，分區鍵 47，排序鍵 02」，櫃檯人員精確地知道從保溫架的哪個位置拿取，你在 7 秒內就拿到了食物。每分鐘 1 萬個客戶？增加更多收銀機；每個收銀機獨立處理自己的隊列。但櫃檯無法為你準備多道菜的品嚐菜單。Aurora 就像正式餐廳 — 每次造訪較慢，但廚房可以準備配有葡萄酒、考慮飲食限制並有桌邊表演的五道菜大餐。餐廳透過增加桌子（讀取複本）來擴展，但最終主廚（寫入者執行個體）只有一個人。向量存放區就像侍酒師：你用模糊的語言描述你想要的酒（「泥土氣息、低單寧、類似去年春天喝過的那款黑皮諾」），侍酒師從酒窖中返回最接近的五個匹配項 — pgvector 就像一位剛好也負責餐廳服務的侍酒師，MemoryDB 是酒窖地圖全在腦子裡且毫不猶豫的侍酒師，OpenSearch k-NN 是帶有卡片目錄且能同時按區域、年份和價格過濾的侍酒師。DEA-C01 的陷阱是把五道菜的聚會送到速食櫃檯（用 DynamoDB 進行分析），或要求正式餐廳每秒處理一千個訂單（用 Aurora 進行 IoT 擷取）。

類比 2 — 帶有書架、閱覽室和禮賓服務的圖書館

DynamoDB 就像圖書館的索書號查詢系統：你給出一個杜威十進位編號，管理員在 5 秒內取回那本書。對於已知金鑰的檢索極快，但對於「尋找氣氛類似《湖濱散記》的書」則毫無用處。Aurora 就像按主題組織書架的閱覽室，管理員在那裡可以執行複雜的交叉引用查詢 — 尋找 1850 到 1880 年間由波士頓出版社出版且引用了愛默生作品的所有書籍 — 但這需要幾分鐘，且由管理員操作。向量存放區就像具備嵌入能力的禮賓員：你帶來一段範例段落並詢問「還有什麼讀起來像這樣的？」，禮賓員根據語義相似性而非關鍵字重疊返回五本匹配的書。pgvector 是兼職閱覽室管理員的禮賓員（一個人，兩份工，適合小圖書館）。MemoryDB 是擁有照相式記憶的禮賓員 — 每本書的嵌入都緩存在大腦中，瞬間回憶。OpenSearch k-NN 是既有嵌入卡又有主題分類的禮賓員，能返回「語義上與此段落相似且標記為 19 世紀美國文學的書」。DynamoDB Streams 就像門鈴，每當書被借出或歸還時都會響起，以便另一個房間的辦事員更新庫存日誌。

類比 3 — 具有快遞、大宗郵件和追蹤無人機的郵政系統

DynamoDB 就像具備全球地址編碼的快遞公司：每個包裹都有唯一的追蹤號碼（分區鍵），快遞員將號碼雜湊到一個配送站，包裹在幾毫秒內到達 — 但每秒百萬件包裹僅在沒有單個配送站過載（熱分區陷阱）時才有效。Aurora 就像區域郵政中心，多個分局（讀取複本）共享一個倉庫（儲存磁碟區） — 中心處理複雜的路由邏輯（聯結、交易、外鍵）並透過增加分局來擴展，但只有中心可以發布派送單（寫入進入寫入者執行個體）。Aurora Serverless v2 就像擁有根據需求出現或消失的租用裝卸平台的郵政中心。DynamoDB Streams 是捕捉每筆包裹移動並將其饋送給下游系統的傳送帶 — Lambda 路由器將更新扇出到庫存儀表板、S3 資料湖、OpenSearch 索引。Aurora 零 ETL 到 Redshift 就像專用的貨運列車，無需手動裝載即可將每筆交易直接複製到分析倉儲。向量存放區就像包裹相似性搜尋 — 你用模糊詞彙描述包裹內容（「大約這麼大的電子裝置，看起來很貴」），系統返回它見過的 K 個最相似包裹，pgvector 是內建在中心內部的搜尋，MemoryDB 是獨立的超快速查閱台，OpenSearch 則是同時按郵遞區號、重量級別和宣告價值進行過濾的搜尋台。

關鍵數字與必須記住的事實

DynamoDB

• 任何規模下 P99 個位數毫秒延遲
• 項目最大 400 KB
• 分區鍵限制 1024 位元組
• DynamoDB Streams 保留 24 小時
• 按需模式：按請求計費，無需容量規劃
• 佈建模式：按秒 RCU/WCU，持續負載下便宜約 5 倍
• 全域資料表：最終一致性的跨區域，最後寫入者勝
• 熱分區限制：每個分區約 3000 RCU / 1000 WCU

Aurora

• 多達 15 個讀取複本共享單一儲存磁碟區
• 儲存空間自動擴展至 128 TiB
• 跨 3 個 AZ 進行 6 向複寫
• 30 秒自動化容錯移轉
• Aurora Serverless v2：最小 0.5 ACU，最大 128 ACU，0.5 ACU 增量
• Aurora 全域資料庫：跨區域複寫 < 1 秒，RPO 1 分鐘
• 到 Redshift 的零 ETL：持續、受管

向量存放區

• pgvector：HNSW 或 IVFFlat 索引，實際應用達約 1000 萬個向量
• MemoryDB 向量搜尋：僅 HNSW，P99 亞毫秒級
• OpenSearch k-NN：HNSW + IVF + Lucene，數十億個向量，混合搜尋
• HNSW：基於圖，查詢快，記憶體大，建置慢
• IVF：聚類，記憶體小，建置快，召回率較低

FAQ — DynamoDB、Aurora 與向量存放區常見問題

Q1 — 為新應用程式選擇 DynamoDB 還是 Aurora 時該如何考慮？

當存取模式是鍵值或簡單的鍵加範圍、處理量極高或不可預測、需要亞 10 毫秒延遲，且應用程式不需要跨多個資料表的聯結或交易時，請選擇 DynamoDB。當應用程式需要 SQL 語義、多表聯結、外鍵關係、複雜交易或符合業務實體層次結構的關係型結構描述時，請選擇 Aurora。決策規則：如果你 90% 的時間能將工作負載表示為 根據金鑰獲取項目 或 根據分區鍵加範圍條件查詢項目，則 DynamoDB 是正確的。如果工作負載常規地在單場查詢中聯結三個或更多資料表，則 Aurora 是正確的。DEA-C01 考試會透過明確描述存取模式的情境來考驗這一點 — 請仔細閱讀是否有「基於鍵的查閱」(DynamoDB) 與「多表聯結」(Aurora) 等關鍵字。

Q2 — 我該如何在不影響生產表的情況下對 DynamoDB 執行分析？

兩種模式：持續和定期。持續：啟用 DynamoDB Streams，附加 Lambda 或使用 DynamoDB-to-Kinesis 選項，將更改寫入 Firehose 到 S3 並轉為 Parquet 格式，在 Glue 資料目錄中註冊該表，使用 Athena 查詢或載入 Redshift。該管道以近乎即時的方式運行，且絕不觸碰生產表。定期：使用 DynamoDB 按需匯出至 S3 獲取 DynamoDB JSON 格式的時間點快照，使用 Glue 轉換為 Parquet，使用 Athena 查詢。匯出不消耗資料表的讀取容量。對於這兩種模式，切勿針對動態的 DynamoDB 表執行分析查詢 — 那會消耗 RCU，可能導致生產讀取受限，且在大規模情況下成本高昂。DEA-C01 考試將此設為「生產 OLTP 加分析」情境，錯誤答案是「針對 DynamoDB 使用 Athena 聯合查詢」 — 那僅適用於隨機隨機分析，不適用於生產分析。

Q3 — 何時應使用 Aurora Serverless v2 而非佈建型 Aurora？

當工作負載多變或不可預測時（如開發/測試環境、每個租戶資料庫負載不可預測的多租戶 SaaS、具有突發模式的應用程式），請使用 Aurora Serverless v2。當工作負載穩定且可預測時（如具有穩定高峰的已知生產流量），請使用佈建型 Aurora。權衡點在於成本：Serverless v2 按每 0.5 ACU 秒計費，在穩定負載下約為等效佈建成本的 1.5 到 2 倍，但在空閒期間可以節省資金，因為它可以縮減到最小 0.5 ACU。對於固定 RPS 的 24/7 生產 OLTP，佈建型在成本上勝出；對於每天使用 8 小時的開發環境，Serverless v2 勝出。Aurora Serverless v2 支援與佈建型相同的功能（讀取複本、全域資料庫、pgvector），因此功能並非決定因素。

Q4 — 如何在 pgvector、MemoryDB 向量搜尋和 OpenSearch k-NN 之間做選擇？

根據工作負載大小和整合度進行決策：當向量在現有 PostgreSQL 應用程式中與關係型資料並存、向量數量在 1000 萬以下且注重維運簡單性（一個資料庫、一個連線池）時，pgvector 是正確的。當需要 P99 亞毫秒級延遲、向量數量在數千萬級別且 HNSW 召回率權衡可接受時，MemoryDB 向量搜尋 是正確的。當向量數量超過 1 億、需要混合關鍵字加向量搜尋（帶有元資料過濾的 RAG），或者團隊已經在執行 OpenSearch 用於日誌分析時，OpenSearch k-NN 是正確的。特別是對於 RAG 管道，OpenSearch 是規範選擇，因為它支援在單場查詢中實現「按文件類型過濾，然後按語義相似性排名」的模式。向量索引類型：HNSW 適用於語料庫穩定下的最快查詢，IVF 適用於記憶體受限或語料庫快速變化的場景。

Q5 — DynamoDB 全域資料表在區域間是否具有強一致性？

不是。DynamoDB 全域資料表跨區域非同步複寫寫入，並使用基於時間戳屬性的最後寫入者勝衝突解決機制。在單個區域內，如果你請求強一致性讀取 (ConsistentRead=true)，DynamoDB 支援強一致性；但在區域間，模型是最終一致性的，你必須設計應用程式來容忍它。對於真正需要強一致性跨區域寫入的工作負載，答案不是 DynamoDB — 請考慮 Aurora 全域資料庫，將所有寫入路由到主要區域，並接受跨區域寫入延遲。DEA-C01 考試會描述「需要強一致性的全球分佈式使用者群」的情境來設置陷阱 — 正確答案是質疑一致性需求（大多數全球分佈式應用程式實際上可以容忍具備衝突解決機制的最終一致性），或者使用具有區域讀取複本和主要區域寫入的 Aurora 全域資料庫。

Q6 — DynamoDB 與 OpenSearch 的零 ETL 整合是如何運作的？

DynamoDB 到 OpenSearch 的零 ETL 整合建立了一個受管複寫，無需編寫管道程式碼即可將 DynamoDB 資料表更改持續同步到 OpenSearch 索引。AWS 負責處理轉換、錯誤重試以及從現有資料表進行回填。你在 DynamoDB 主控台中組態整合，指向 OpenSearch 目的地，讓 AWS 保持同步。使用案例：對 DynamoDB 項目進行全文檢索、需要對交易資料進行 OpenSearch 聚合的儀表板、將 DynamoDB 金鑰查閱與 OpenSearch 向量搜尋配對的 AI 應用程式。這種整合在精神上類似於 Aurora 到 Redshift 的零 ETL — 兩者都消除了 Glue/DMS 管道開銷。DEA-C01 考試中可能會將此作為「無需受管管道開銷即可在 DynamoDB 上建立近乎即時搜尋索引」的正確答案。

Q7 — 什麼是 DynamoDB 熱分區，我該如何避免它？

熱分區是指讀取或寫入份額不成比例地集中在單個 DynamoDB 分區（由雜湊分區鍵值定義），超過了每個分區的處理量限制（約 3000 RCU / 1000 WCU）。結果是即使資料表級別的佈建容量遠未耗盡，請求也會受限。原因：低基數分區鍵（狀態、區域、日期字串）、單個熱門項目被每位使用者讀取、以當前日期為鍵的時間序列資料。避免方法：選擇高基數分區鍵（user_id, device_id, order_id）、為常見金鑰增加隨機後綴（status#42，其中 42 是隨機的 0-99 貯體）、使用能分配負載的複合鍵（使用 user_id + timestamp 而非單獨的 timestamp）。DEA-C01 考試會以效能問題考驗這一點 — 錯誤答案建議擴展容量；正確答案則是重新設計分區鍵。

延伸閱讀 — 官方 AWS 文件

權威的 AWS 來源包括 DynamoDB 開發人員指南（資料建模、容量模式、串流、全域資料表、匯出至 S3）、Aurora 使用者指南（架構、Aurora Serverless v2、全域資料庫、零 ETL）、Aurora PostgreSQL pgvector 文件（向量類型、HNSW 與 IVFFlat 索引、相似性運算子）、MemoryDB 向量搜尋指南（HNSW 組態、向量類型、FT.SEARCH 命令）、OpenSearch Service k-NN 文件（knn_vector 欄位、HNSW vs IVF、混合查詢）以及 AWS 大數據部落格關於零 ETL 整合的系列文章。AWS Well-Architected Data Analytics Lens 在資料存放區選擇指南中涵蓋了 DynamoDB 與 Aurora。Skill Builder DEA-C01 Exam Prep Standard Course 有專門針對網域 2 的模組，涵蓋資料存放區選擇與向量索引類型 — 請在考前複習。