本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
從關聯式資料庫移轉到 DynamoDB
將關聯式資料庫移轉至 DynamoDB 需要謹慎規劃，才能確保實現成功的結果。本指南有助您了解此程序的運作方式、可用哪些工具，以及如何評估潛在移轉策略，並選取符合需求的策略。
主題
移轉至 DynamoDB 的原因
對企業和組織來說，移轉至 Amazon DynamoDB 有各種絕佳的優勢。以下是 DynamoDB 為理想資料庫移轉選項的一些主要優勢：
-
可擴展性：DynamoDB 專為處理大量工作負載及無縫擴展而設計，以容納不斷增長的資料磁碟區和流量。使用 DynamoDB，您可以根據需求輕鬆擴展或縮小資料庫，確保應用程式可以在不影響效能的情況下處理流量突增的情況。
-
效能：DynamoDB 提供低延遲的資料存取，讓應用程式能夠以卓越的速度擷取和處理資料。其分散式架構可確保讀取和寫入操作分散在多個節點，即使在高請求率下也能提供一致的個位數毫秒級回應時間。
-
全受管：DynamoDB 是由 AWS提供的全受管服務。這表示 會 AWS 處理資料庫管理的操作層面，包括佈建、組態、修補、備份和擴展。這可讓您更專注於開發應用程式，而非資料庫管理任務。
-
無伺服器架構：DynamoDB 支援 DynamoDB 隨需無伺服器模型，您只需為應用程式提出的實際讀取和寫入請求付費，無需預先佈建容量。這種按需付費的模式可確保成本效益和最低的營運開銷，因為您只為消耗的資源付費，而不需要佈建和監控容量。
-
NoSQL 彈性：不同於傳統關聯式資料庫，DynamoDB 遵循 NoSQL 資料模型，提供結構描述設計的靈活性。DynamoDB 可讓您存放結構化、半結構化和非結構化的資料，因此非常適合處理多樣化和不斷演進的資料類型。這種靈活性可加快開發週期，更輕鬆因應不斷變化的業務需求。
-
高可用性與耐久性：DynamoDB 會跨區域內的多個可用區域複寫資料，以確保高可用性和資料耐久性。其可自動處理複寫、容錯移轉和復原，將資料遺失或服務中斷的風險降至最低。DynamoDB 提供高達 99.999% 的可用性 SLA。
-
安全性與合規：DynamoDB 整合 AWS Identity and Access Management 以進行精細存取控制。其提供靜態和傳輸中加密，可確保資料的安全性。DynamoDB 亦符合多項合規標準，包括 HIPAA、PCI DSS 與 GDPR，協助您符合法規要求。
-
與 AWS 生態系統整合：作為 AWS 生態系統的一部分，DynamoDB 與其他 AWS 服務無縫整合，例如 AWS Lambda CloudFormation和 AWS AppSync。此整合可讓您建置無伺服器架構、利用基礎設施即程式碼，以及建立即時資料驅動型應用程式。
將關聯式資料庫移轉至 DynamoDB 時的考量事項
關聯式資料庫系統和 NoSQL 資料庫各有優劣：這些差異導致兩種系統之間的資料庫設計不同。
| 任務類型 | 關聯式資料庫 | NoSQL database (NoSQL 資料庫) |
|---|---|---|
| 查詢資料庫 | 關聯式資料庫可以彈性地查詢資料，但查詢相對昂貴，而且在高流量的狀況下擴展不易 (請參閱 在 DynamoDB 中製作關聯式資料模型的第一步)。關聯式資料庫應用程式可能會在預存程序、SQL 子查詢、大量更新查詢和彙總查詢中實作商業邏輯。 | 在如 DynamoDB 這類的 NoSQL 資料庫中，可以少數方式有效地查詢資料，但在外部的查詢就非常昂貴而且速度緩慢。寫入 DynamoDB 是單例。先前在預存程序中執行的應用程式業務邏輯必須重構為在 DynamoDB 外部執行，並在主機上執行自訂程式碼，例如 Amazon EC2 或 AWS Lambda。 |
| 設計資料庫 | 您可以專注於設計的靈活性，而不用擔心實作細節或效能。查詢最佳化通常不會影響結構描述設計，但標準化相當重要。 | 您會特別設計結構描述，盡可能以最快、最便宜的方式進行常用與重要的查詢。系統會打造您的資料結構，以符合企業使用案例的特定要求。 |
設計 NoSQL 資料庫時，您必須採用與設計關聯式資料庫管理系統 (RDBMS) 不同的思維。針對 RDBMS，您可以建立標準化的資料模型，而不需考量存取模式。您可以在稍後有新問題與查詢要求時擴展此模型。您可以將每種資料整理至其資料表。
使用 NoSQL 設計時，您可以針對 DynamoDB 需要回答的問題來設計結構描述。了解企業問題和應用程式讀取及寫入模式至關重要。此外，您的目標應該是盡可能在 DynamoDB 應用程式中維護越少資料表。擁有較少的資料表可讓事物更具擴展性，需要較少的許可管理，並減少 DynamoDB 應用程式的額外負荷。它還可以幫助降低整體備份成本。
我們會以個別主題來說明建立 DynamoDB 關聯式資料模型和建置新版本前端應用程式的任務。本指南假設您已建置使用 DynamoDB 的新版本應用程式，但仍需判斷如何以最佳方式在切換期間移轉和同步歷史資料。
規模調整考量因素
DynamoDB 資料表中存放的每個項目 (資料列) 大小上限為 400KB。如需詳細資訊，請參閱Amazon DynamoDB 中的配額。項目大小取決於項目中所有屬性名稱和屬性值的大小總計。如需詳細資訊，請參閱DynamoDB 項目大小和格式。
如果應用程式需要在項目中存放的資料超過 DynamoDB 大小限制，請將項目分成項目集合、壓縮項目資料，或以物件形式將項目存放在 Amazon Simple Storage Service (Amazon S3)，同時將 Amazon S3 物件識別碼存放在 DynamoDB 項目中。請參閱 在 DynamoDB 中儲存大型項目與屬性的最佳實務。更新項目的成本取決於項目的完整大小。若是需要頻繁更新現有項目的工作負載，更新 1 KB 或 2 KB 小項目的成本會更新大項目低。如需項目集合的詳細資訊，請參閱 物品集合 - 如何在 DynamoDB 中建立一對多關係的模型。
在您選擇分割區和排序索引鍵屬性、其他資料表設定、項目大小和結構，以及是否建立次要索引時，請務必檢閱 DynamoDB 建模文件以及 最佳化 DynamoDB 資料表上的成本 指南。請務必測試移轉計畫，確保 DynamoDB 解決方案具成本效益，並符合 DynamoDB 的功能和限制。
了解移轉至 DynamoDB 的運作方式
在檢閱可用的移轉工具之前，請思考 DynamoDB 處理寫入的方式。
預設和最常見的寫入操作是單一 PutItem API 操作。您可以在迴圈中執行 PutItem 操作來處理資料集。DynamoDB 支援幾乎無限的並行連線，因此假設您設定和執行大量多執行緒載入常式，例如 MapReduce 或 Spark，寫入速度只會受限於目標資料表的容量 (通常也是無限的)。
將資料載入 DynamoDB 時，請務必了解載入器的寫入速度。如果您要載入的項目 (資料列) 小於 1KB，則此速度單純為每秒的項目數。接著，可使用足夠的 WCU (寫入容量單位) 佈建目標資料表，以處理此速率。如果載入器在任何給定秒內超過佈建容量，則額外的請求可能會受到限流或完全遭拒。您可以在 CloudWatch 圖表中檢查限流情況，其位於 DynamoDB 主控台的監控索引標籤。
第二個可執行的操作是使用名稱為 BatchWriteItem 的相關 API。BatchWriteItem 可讓您將最多 25 個寫入請求合併為一個 API 呼叫。服務會接收這些呼叫，並以對資料表的個別 PutItem 請求形式處理。目前，當您選擇 時BatchWriteItem，在使用 進行單一呼叫時，您不會獲得軟體 AWS 開發套件中包含的自動重試的優點PutItem。因此，如果有任何錯誤 (例如限流例外狀況)，您必須在回應呼叫 BatchWriteItem 上尋找任何寫入失敗的清單。如需在 CloudWatch 限流圖表偵測到限流警告時處理限流警告的詳細資訊，請參閱 在 Amazon DynamoDB 中針對限流問題進行疑難排解。
第三種類型的資料匯入可透過從 S3 匯入 DynamoDB 功能PutItem，其必須使用上游程序，以您選擇的格式將資料寫入 Amazon S3 儲存貯體。
協助移轉至 DynamoDB 的工具
您可以使用數種常見的移轉和 ETL 工具，將資料移轉至 DynamoDB。
Amazon 提供許多可用於移轉的資料工具，包括 AWS Database Migration Service (DMS)、AWS Glue、Amazon EMR 和 Amazon Managed Streaming for Apache Kafka。這所有工具都可用來執行停機時間移轉，並利用關聯式資料庫的「變更資料擷取 (CDC)」功能來支援線上移轉。選擇工具時，請考慮組織擁有的技能組合和體驗，以及每個工具的功能、效能和成本。
許多客戶選擇撰寫自己的移轉指令碼和作業，以便為移轉程序建立自訂資料轉換。如果您打算執行具大量寫入流量或一般大量載入作業的大量 DynamoDB 資料表，建議您自行撰寫移轉程式碼，以更熟悉 DynamoDB 在大量寫入流量下的行為。執行實務移轉時，可在專案初期體驗限流處理和高效資料表佈建等案例。
選擇移轉至 DynamoDB 的適當策略
大型關聯式資料庫應用程式可能跨越數百個資料表，並支援數個不同的應用程式函數。處理大型移轉時，請考慮將應用程式分成較小的元件或微型服務，並一次移轉一小組資料表。然後，您可以將其他元件波次移轉至 DynamoDB。
選取移轉策略時，各種因素可能會引導您在不同解決方案之間抉擇。我們可以在決策樹中呈現這些選項，根據需求和資源來簡化可用的選項。以下簡要提及相關概念 (但指南稍後會更深入介紹)：
| If | 及 | THEN |
|---|---|---|
| 您可以在維護時段關閉應用程式一段時間，以執行資料移轉。這是離線移轉。 |
使用 AWS DMS 並使用完全載入任務執行離線遷移。視需要使用 SQL |
|
| 您可以在移轉期間以唯讀模式執行應用程式。這是混合移轉。 | 停用應用程式或來源資料庫中的寫入。使用 AWS DMS 並使用完全載入任務執行離線遷移。 | |
| 您可以在移轉期間執行應用程式的讀取和新記錄插入，但不更新或刪除。這是混合移轉。 | 您具備應用程式開發技能，可以更新現有的關聯式應用程式，以執行所有新記錄的雙重寫入，包括寫入至 DynamoDB | 使用 AWS DMS 並使用完全載入任務執行離線遷移。同時，部署現有應用程式的版本，允許讀取和執行雙重寫入。 |
| 您需要停機時間最短的移轉。這是線上移轉。 |
|
使用 AWS DMS 執行線上資料遷移。執行大量載入任務，接著執行 CDC 同步任務。 |
| 您需要停機時間最短的移轉。這是線上移轉。 |
|
在 SQL 資料庫中建立 NoSQL 就緒資料表。使用 JOIN、UNION、VIEW、觸發條件、預存程序來填入和同步。 |
| 您需要停機時間最短的移轉。這是線上移轉。 |
|
考慮混合或離線移轉方法。 |
| 您需要停機時間最短的移轉。這是線上移轉。 | 您可以略過移轉歷史交易資料，或將其封存在 Amazon S3 中以取代移轉。您只需要移轉幾個小型靜態資料表。 | 撰寫指令碼或使用任何 ETL 工具來移轉資料表。視需要使用 SQL VIEW 預先塑造來源資料。 |
執行 DynamoDB 離線移轉
如果可以允許停機時間來執行移轉，即適用離線移轉。關聯式資料庫每月至少要花一些停機時間進行維護和修補，也可能需要更長的停機時間來升級硬體或主要版本。
Amazon S3 可在移轉期間作為暫存區。若是以 CSV (逗號分隔值) 或 DynamoDB JSON 格式儲存的資料，可以使用從 S3 匯入 DynamoDB 功能，自動將其匯入新的 DynamoDB 資料表。
建議您結合資料表以運用唯一 NoSQL 存取模式 (例如，將四個舊版資料表轉換為單一 DynamoDB 資料表)。進行單一索引鍵值文件請求或預先分組項目集合的查詢，傳回時的延遲情況通常會比執行多資料表聯結的 SQL 資料庫更好。不過，這會使移轉任務更加困難。SQL 檢視可以在來源資料庫中執行工作，以準備單一資料集，在一個集合中表示所有四個資料表。
此檢視可以非標準化形式顯示 JOIN 資料表，也可以讓實體標準化，並使用 SQL UNION 堆疊資料表。此影片
計劃
使用 Amazon S3 執行離線移轉
工具
-
擷取和轉換 SQL 資料並將其存放在 S3 儲存貯體的 ETL 作業，例如：
-
AWS Database Migration Service是一項服務，可大量載入歷史資料，亦可處理變更資料擷取 (CDC) 記錄，以同步來源和目標資料表。
-
AWS Glue
-
Amazon EMR
-
自己的自訂程式碼
-
-
從 S3 匯入 DynamoDB 功能
離線移轉步驟：
-
建置可查詢 SQL 資料庫、將資料表資料轉換為 DynamoDB JSON 或 CSV 格式，並將其儲存至 S3 儲存貯體的 ETL 作業。
-
系統會調用從 S3 匯入 DynamoDB 功能，來建立新的資料表，並自動從 S3 儲存貯體載入資料。
完全離線移轉簡單明瞭，但應用程式擁有者和使用者可能不常用。如果應用程式可以在移轉期間提供較低的服務水準，而不是完全沒有服務，這可能對使用者較有利。
您可以新增功能，在離線移轉期間停用寫入，同時允許持續正常讀取。在移轉關聯式資料時，應用程式使用者仍可以安全地瀏覽及查詢現有資料。如果這是您要尋找的內容，請繼續閱讀了解混合移轉。
執行 DynamoDB 混合移轉
雖然所有資料庫應用程式都會執行讀取和寫入操作，但在規劃混合或線上移轉時應考慮要執行的寫入操作類型。資料庫寫入可以分為插入、更新和刪除三種儲存貯體。有些應用程式可能不需要立即處理刪除。舉例來說，這些應用程式可以將刪除延遲到月底進行大量清除程序。您可以更輕鬆移轉這類應用程式，同時允許部分運行時間。
計劃
使用應用程式雙重寫入執行混合式線上/離線移轉
工具
-
擷取和轉換 SQL 資料並將其存放在 S3 儲存貯體的 ETL 作業，例如：
-
AWS DMS
-
AWS Glue
-
Amazon EMR
-
自己的自訂程式碼
-
混合移轉步驟：
-
建立目標 DynamoDB 資料表。此資料表會同時收到歷史大量資料和新的即時資料
-
建立舊版應用程式，停用刪除和更新，同時以雙重寫入 SQL 資料庫和 DynamoDB 形式執行所有插入
-
開始 ETL 任務或 AWS DMS 任務，以回填現有資料並同時部署新的應用程式版本
-
當回填作業完成時，DynamoDB 即具備所有現有和新的記錄，並就緒可進行應用程式切換
注意
回填作業會直接從 SQL 寫入 DynamoDB。我們無法如離線移轉範例一樣使用 S3 匯入功能，因為該功能建立的新資料表要等 DynamoDB 載入資料之後才是即時狀態。
透過 1:1 方式移轉每個資料表，執行 DynamoDB 線上移轉
許多關聯式資料庫具有名稱為「變更資料擷取 (CDC)」的功能，其中資料庫可讓使用者請求在特定時間點之前或之後發生的資料表變更清單。CDC 使用內部日誌來啟用此功能，且資料表不需要任何時間戳記欄即可運作。
將 SQL 資料表的結構描述移轉至 NoSQL 資料庫時，建議您將資料合併並重新塑造至較少的資料表。這樣做可讓您在單一位置收集資料，並避免在多步驟讀取操作中手動聯結相關資料。不過，您不一定要塑造單一資料表的資料，有時可以將資料表一對一移轉至 DynamoDB。這些 1:1 資料表移轉較不複雜，因為您可以使用支援這種移轉類型的常見 ETL 工具，利用來源資料庫 CDC 功能。每一個資料列的資料仍可以轉換為新格式，但每個資料表的範圍保持不變。
請考慮將 SQL 資料表 1:1 移轉至 DynamoDB，請注意 DynamoDB 不支援伺服器端聯結。您需要將邏輯新增至應用程式，才能合併來自多個資料表的資料。
計劃
使用 將每個資料表線上遷移至 DynamoDB AWS DMS
工具
線上移轉步驟：
-
識別來源結構描述中要移轉的資料表
-
使用與來源相同的索引鍵結構，在 DynamoDB 中建立相同數量的資料表
-
在 中建立複寫伺服器， AWS DMS 並設定來源和目標端點
-
定義每個資料列所需的轉換 (例如串連資料欄或將日期轉換為 ISO-8601 字串格式)
-
為每個資料表建立適用於完全載入和變更資料擷取的移轉任務
-
監控這些任務，直到進行中複寫階段開始為止
-
此時，您可以執行任何驗證稽核，然後將使用者切換至讀取和寫入 DynamoDB 的應用程式
使用自訂暫存資料表線上移轉至 DynamoDB
如同上述離線移轉案例，您可以選擇結合資料表以運用唯一 NoSQL 存取模式 (例如，將四個舊版資料表轉換為單一 DynamoDB 資料表)。SQL VIEW 可以在來源資料庫中執行工作，以準備單一資料集，在一個集合中表示所有四個資料表。
不過，若是具有即時變更資料的線上移轉，您無法利用 CDC 功能，因為 VIEW 不支援這些功能。如果您的資料表包含上次更新的時間戳記欄，且這些資料表已納入 VIEW 中，則您可以建置自訂 ETL 作業，以使用這些作業及同步來達成大量載入。
因應此挑戰的創新方法是使用標準 SQL 功能，例如檢視、預存程序和觸發條件，以建立最終所要的 DynamoDB NoSQL 格式新 SQL 資料表。
如果您的資料庫伺服器有備用容量，可以在移轉開始之前建立此單一暫存資料表。您可以撰寫預存程序來讀取現有資料表、視需要轉換資料以及寫入新的暫存資料表。您可以新增一組觸發條件，即時將資料表中的變更複寫到暫存資料表。如果公司政策不允許觸發條件，您也可以變更預存程序以達到相同結果。您可以新增幾行程式碼至任何寫入資料的程序，額外將相同變更寫入暫存資料表。
將此暫存資料表與舊版應用程式資料表完全同步，就是即時移轉的理想起點。現在可以針對此資料表使用使用資料庫 CDC 來完成即時遷移的工具 AWS DMS，例如 。此方法的優點是，其使用關聯式資料庫引擎常見的 SQL 技能和功能。
計劃
使用 SQL 預備資料表執行線上遷移 AWS DMS
工具
-
自訂 SQL 預存程序或觸發條件
線上移轉步驟：
-
確認來源關聯式資料庫引擎中有額外的磁碟空間和處理容量。
-
在 SQL 資料庫中建立新的暫存資料表，並啟用時間戳記或 CDC 功能
-
寫入並執行預存程序，將現有的關聯式資料表資料複製到暫存資料表
-
部署觸發條件或修改現有程序，在執行現有資料表正常寫入同時，雙重寫入至新的暫存資料表
-
執行 AWS DMS 以將此來源資料表遷移並同步至目標 DynamoDB 資料表
本指南提供若干考量事項及方法，可將關聯式資料庫資料移轉至 DynamoDB，並把重點放在使用常見的資料庫工具和技術，將停機時間降至最低。如需詳細資訊，請參閱下列內容：
