本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
從關聯式資料庫移轉至 DynamoDB
將關聯式資料庫移轉至 DynamoDB 需要仔細規劃，以確保成功取得成功。本指南將協助您瞭解此程序的運作方式、您擁有哪些工具，以及如何評估潛在的移轉策略，並選取符合您需求的移轉策略。
主題
遷移至 DynamoDB 支援的原因
遷移到 Amazon DynamoDB 可為企業和組織帶來一系列令人信服的優勢。以下是 DynamoDB 成為資料庫移轉的吸引力選擇的一些關鍵優勢：
-
可擴充性：DynamoDB 專為處理大量工作負載而設計，並可無縫調整以適應不斷增長的資料量和流量。使用 DynamoDB，您可以根據需求輕鬆擴展或縮減資料庫，確保應用程式能夠處理突然尖峰的流量，而不會影響效能。
-
效能：DynamoDB 提供低延遲資料存取，讓應用程式能夠以優異的速度擷取和處理資料。它的分散式架構可確保讀取和寫入操作分佈在多個節點上，即使在高請求率下也能提供一致的 10 毫秒回應時間。
-
全受管：DynamoDB 是由. AWS這表示可以 AWS 處理資料庫管理的作業層面，包括佈建、組態、修補、備份和擴展。這可讓您更專注於開發應用程式，減少資料庫管理工作。
-
無伺服器架構：DynamoDB 支援無伺服器模型 (稱為 DynamoDB 隨需)，您只需為應用程式發出的實際讀取和寫入請求付費，無需預先佈建容量。此 pay-per-request 模型提供了成本效益和最低的營運開銷，因為您只需支付消耗的資源費用，而無需佈建和監控容量。
-
NoSQL 彈性：與傳統的關聯式資料庫不同，DynamoDB 遵循 NoSQL 資料模型，提供結構描述設計的彈性。使用 DynamoDB，您可以存放結構化、半結構化和非結構化資料，因此非常適合處理各種不斷發展的資料類型。這種靈活性使開發週期更快，更容易適應不斷變化的業務需求。
-
高可用性和耐久性：DynamoDB 可跨區域內多個可用區域複寫資料，確保高可用性和資料耐久性。它會自動處理複寫、容錯移轉和復原，將資料遺失或服務中斷的風險降到最低。DynamoDB 提供高達 99.999% 的可用性 SLA。
-
安全性和合規性：DynamoDB 與之整合，可 AWS Identity and Access Management 提供精細的存取控制。它提供靜態和傳輸中的加密，以確保數據的安全性。DynamoDB 也遵守各種合規性標準，包括 HIPAA、PCI DSS 和 GDPR，讓您能夠符合法規要求。
-
與 AWS 生態系統整合：DynamoDB 是 AWS 生態系統的一部分，可與其他 AWS 服務 (例如 AWS Lambda AWS 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 資料表中的每個項目 (列) 的大小上限為 400 KB。如需詳細資訊，請參閱 Amazon DynamoDB 中的服務、帳戶和資料表配額。項目大小由項目中所有屬性名稱和屬性值的總大小決定。如需詳細資訊，請參閱 DynamoDB 項目大小和格式。
如果您的應用程式需要在某個項目中存放超過 DynamoDB 大小限制允許的資料，請將該項目分解為項目集合、壓縮項目資料，或將該項目作為物件存放在 Amazon Simple Storage Service (Amazon S3) 中，同時將 Amazon S3 物件識別碼存放在 DynamoDB 項目中。請參閱儲存大型項目和屬性的最佳實務。更新項目的成本取決於項目的完整大小。對於需要頻繁更新現有項目的工作負載，具有一個或兩個 KB 的小項目的更新成本將比較大的項目低。項目集合-如何在 DynamoDB 中 one-to-many建立關係的模型如需項目集合的詳細資訊，請參閱。
選擇分區和排序關鍵屬性、其他表格設定、項目大小和結構，以及是否要建立次要索引時，請務必檢閱 DynamoDB 建模文件以及的指南。最佳化 DynamoDB 資料表上的成本請務必測試您的移轉計劃，以便 DynamoDB 解決方案具有成本效益，並符合 DynamoDB 的功能和限制。
了解移轉至 DynamoDB 的運作方式
在檢閱我們可用的移轉工具之前，請考慮 DynamoDB 如何處理寫入。
注意
DynamoDB 會自動將您的資料分片並分配到多個共用伺服器和儲存位置，因此無法直接將大量資料集直接匯入生產伺服器。
默認和最常見的寫操作是單個 PutItemAPI 操作。您可以在迴圈中執行PutItem作業來處理資料集。DynamoDB 支援幾乎無限制的並行連線，因此假設您可以設定和執行大規模多執行緒載入常式 (例如 MapReduce 或 Spark)，寫入速度僅受目標資料表容量的限制 (通常也是無限制的)。
將資料載入 DynamoDB 時，瞭解載入器的寫入速度非常重要。如果您載入的項目 (列) 大小為 1KB 或更小，則此速度只是每秒的項目數。然後可以使用足夠的 WCU (寫入容量單位) 佈建目標資料表來處理此速率。如果您的載入器在任何一秒鐘內超過佈建的容量，則可能會限制或完全拒絕額外的要求。您可以在 DynamoDB 主控台監控索引標籤中的 CloudWatch 圖表中查看節流。
可以執行的第二個操作是使用調用的相關 API BatchWriteItem。 BatchWriteItem允許您將最多 25 個寫入請求合併到一個 API 調用中。這些資料會由服務接收，並以個別要PutItem求的形式處理至資料表。選擇時BatchWriteItem，在使用進行單例調用時，您將無法獲得 AWS SDK 隨附的自動重試的優勢。PutItem因此，如果有任何錯誤（例如節流異常），則必須在響應調用中查找任何失敗寫入的列表。BatchWriteItem如需在節流圖表中偵測到節流警告時處理節 CloudWatch 流警告的詳細資訊，請參閱。DynamoDB 支援的節流問題
使用 DynamoDB 從 S3 匯入功能可執行第三種類型的資料匯入
協助移轉至 DynamoDB 的工具
您可以使用數種常見的移轉和 ETL 工具將資料移轉至 DynamoDB。
許多客戶選擇撰寫自己的移轉指令碼和工作，以便為移轉程序建立自訂資料轉換。如果您計劃操作具有大量寫入流量或常規大型批量負載工作的大容量 DynamoDB 表，您可能希望自己建置遷移工具，以便在大量寫入流量下對 DynamoDB 的行為充滿信心。執行實務移轉時，可以在專案早期體驗例如節流處理和有效率的資料表佈建等案例。
Amazon 提供了一系列可以利用的數據工具，包括 Apache Kafka 的數據 AWS Database Migration Service（DMS）AWS Glue，Amazon EMR 和 Amazon 託管流。所有這些工具都可用於執行停機時間遷移，而某些可以利用關聯式資料庫變更資料擷取 (CDC) 功能的工具也可以支援線上移轉。在選擇最佳工具時，將有助於考慮組織在每種工具上的技能和經驗，以及每種工具的功能，性能和成本。
選擇適當的策略以移轉至 DynamoDB
大型關聯式資料庫應用程式可能會跨越一百或多個表格，並支援多種不同的應用程式功能 進行大型移轉時，請考慮將應用程式分解為較小的元件或微型服務，並一次移轉一小組資料表。然後，您可以在浪潮中將其他元件移轉到 DynamoDB。
選取移轉策略時，某些參數可能會引導您使用一個或另一個解決方案。鑑於我們的需求和可用資源，我們可以在決策樹中展示這些選項，以簡化可用的選項。這裡簡要提到了這些概念（但將在指南後面進行更深入的介紹）：
| If | 及 | 然後 | ||||
|---|---|---|---|---|---|---|
| 在維護時段期間，您可以將應用程式關閉一段時間，以執行資料移轉。這是離線遷移 |
使用完整載入工作來使用 AWS DMS 和執行離線移轉。 |
|||||
| 您可以在移轉期間以唯讀模式執行應用程式。這是一個混合遷移 | 停用應用程式或來源資料庫內的寫入。使用完整載入工作來使用 AWS DMS 和執行離線移轉。 | |||||
| 在遷移期間，您可以使用讀取和新記錄插入來執行應用程式，但不會進行更新或刪除。這是一個混合遷移 | 您具備應用程式開發技能，並且可以更新現有的關聯式應用程式，以執行雙重寫入，包括對所有新記錄的 DynamoDB | 使用完整載入工作來使用 AWS DMS 和執行離線移轉。同時，部署允許讀取和執行雙重寫入的現有應用程式版本。 | ||||
| 您需要以最少的停機時間進行遷移。這是線上移轉 | 您正在將來源表格 1 對 1 移轉至 DynamoDB，而無需進行重大結構描述變更 | 用 AWS DMS 於執行線上資料移轉。執行批量載入工作，然後執行 CDC 同步工作 | ||||
| 您正在按照單一資料表理念將來源資料表合併為較少的 DynamoDB 資料表 | 您在 SQL 主機上具備後端資料庫開發技能和備用容量 | 在 SQL 數據庫中創建 NoSQL 就緒表。填充並使用 JOIN，聯合，視圖，觸發器，存儲過程同步 | ||||
| 您沒有 SQL 主機上的後端資料庫開發技能和備用容量 | 考慮混合式或離線移轉方法 | |||||
| 您可以略過遷移歷史交易資料，或將其存檔到 Amazon S3 中以代替遷移。您只需要遷移幾個小型靜態表 | 撰寫指令碼或使用任何 ETL 工具移轉資料表。VIEW如果需要，請使用 SQL 預先塑形源數據。 |
|||||
執行離線 DynamoDB 至
離線移轉適用於允許停機時間視窗執行移轉的情況。關聯式資料庫通常每個月至少需要一些停機時間進行維護和修補，或者硬體升級或主要發行版本升級可能需要較長的停機時間。
Amazon S3 可以用作移轉期間的暫存區域。您可以使用從 S3 匯入功能，將以 CSV (逗號分隔值) 或 DynamoDB JSON 格式儲存的資料自動匯入到新的 DynamoDB 表格中。
計劃
使用 Amazon S3 執行離線遷移
工具
-
擷取和轉換 SQL 資料並將其存放在 S3 儲存貯體的 ETL 任務，例如：
-
AWS Glue
-
Amazon EMR
-
您自己的自訂程式碼
-
-
從 S3 匯入功能
離線遷移步驟：
-
建立可查詢 SQL 資料庫的 ETL 任務、將資料表資料轉 DynamoDB JSON 或 CSV 格式，然後將其儲存至 S3 儲存貯體。
-
會叫用 DynamoDB 從 S3 匯入功能來建立新表格，並自動從 S3 儲存貯體載入資料。
完全離線遷移既簡單又直接，但應用程式擁有者和使用者可能不受歡迎。如果應用程式可以在移轉期間提供降低等級的服務，而不是完全沒有服務，使用者將會受益。
您可以新增功能以在離線移轉期間停用寫入，同時允許正常繼續讀取。在移轉關聯式資料時，應用程式使用者仍然可以安全地瀏覽和查詢現有資料。如果這是您要尋找的內容，請繼續閱讀以了解混合式遷移。
執行與 DynamoDB 支援的混合式移轉
雖然所有資料庫應用程式都執行讀取和寫入作業，規劃混合式或線上移轉時，應考慮所執行的寫入作業類型。資料庫寫入可分為三個儲存貯體：插入、更新和刪除。某些應用程式不會對現有記錄執行任何更新。其他應用程式可能不需要立即處理刪除作業，例如，可能會在月底將刪除項目延遲至大量清理程序。這些類型的應用程式可以更輕鬆地遷移，同時允許部分運作時間。
計劃
使用應用程式雙重寫入執行混合線上/離線移轉
工具
-
擷取和轉換 SQL 資料並將其存放在 S3 儲存貯體的 ETL 任務，例如：
-
AWS Glue
-
Amazon EMR
-
您自己的自訂程式碼
-
混合式移轉步驟：
-
建立目標 DynamoDB 資料表。此表格將接收歷史大量資料和新的即時資料
-
建立舊版應用程式版本，在對 SQL 資料庫和 DynamoDB 進行雙重寫入時執行所有插入作業時停用刪除和更新
-
開始 ETL 工作以移轉現有資料並同時部署新的應用程式版本
-
ETL 工作完成時，DynamoDB 將擁有所有現有和新記錄，並準備好進行應用程式切換
注意
ETL 工作會直接從 SQL 寫入 DynamoDB 料庫。我們無法像離線遷移範例中那樣使用 S3 匯入功能，因為在整個匯入完成之前，目標資料表不會變為公開且可用於其他寫入。
透過 1:1 移轉每個表格來執行線上移轉至 DynamoDB
許多關聯式資料庫都有一項稱為「變更資料擷取」(CDC) 的功能，其中資料庫可讓使用者要求對特定時間點之前或之後發生的資料表變更清單。CDC 會使用內部記錄檔來啟用此功能，而且不需要資料表具有任何時間戳記資料行即可運作。
將 SQL 表的結構定義遷移到 NoSQL 數據庫時，您可能需要將數據合併並重新塑形為較少的表格。這樣做可讓您在單一位置收集資料，並避免在多步驟讀取作業中手動聯結相關資料。但是，並非總是需要單一表格資料整形，有時您會將表格 1 對 1 移轉到 DynamoDB。這些 1 對 1 資料表移轉不太複雜，因為您可以利用來源資料庫 CDC 功能，使用支援此類移轉類型的常見 ETL 工具。每行的數據仍然可以轉換為新格式，但每個表的範圍保持不變。
請考慮將 SQL 表格 1 對 1 移轉至 DynamoDB，並注意沒有伺服器端聯結。
計劃
使用下列方法，將每個表格線上移轉至 DynamoDB AWS DMS
工具
-
AWS Database Migration Service (DMS) 是一種 ETL 工具，可以大量載入歷史資料，也可以利用 CDC 同步處理來源和目標資料表
線上移轉步驟：
-
識別將要移轉的來源結構描述中的表格
-
在具有類似索引鍵結構的 DynamoDB 中建立相同數量的表格
-
在中建立複製伺服器 AWS DMS 並設定來源端點和目標端點
-
定義所需的任何每行轉換（例如連接列或將日期轉換為 ISO-8601 字符串格式）
-
針對「全載」和「變更資料擷取」的每個表格建立移轉任務
-
監視這些工作，直到進行中的複寫階段已開始
-
此時，您可以執行任何驗證稽核，然後將使用者切換到讀取和寫入 DynamoDB 的應用程式
使用自訂臨時資料表執行線上移轉至 DynamoDB
您可能希望合併資料表以利用唯一的 NoSQL 存取模式 (例如，將四個舊版資料表轉換為單一 DynamoDB 表格)。單一索引鍵值文件要求或預先群組項目集合的查詢傳回通常會比執行多資料表聯結的 SQL 資料庫具有更好的延遲時間。但是，這會使遷移任務變得更加困難。SQL VIEW 可以在源數據庫中完成工作，以準備表示一個集合中所有四個表的單個數據集。
此視圖可能會將JOIN表格轉換為非規範化的形式，或者可以使用 SQL 將實體標準化並堆疊表。UNION本影
但是，對於具有即時變更資料的線上移轉，您無法利用 CDC 功能，因為它們僅支援單一VIEW資料表查詢，而不支援. 如果您的資料表包含上次更新的時間戳記資料行，而且這些資料行已合併到中VIEW，則您可以建置自訂 ETL 工作，使用這些工作來透過同步處理實現大量載入。
應對此挑戰的一個新穎方法是使用標準 SQL 功能 (例如檢視、預存程序和觸發程序)，以建立採用最終所需 DynamoDB NoSQL 格式的新 SQL 表格。
如果您的資料庫伺服器可以配置額外的儲存空間，則可以在移轉開始之前建立此單一臨時資料表。這可透過撰寫將從現有資料表讀取的預存程序、視需要轉換資料，以及寫入新的臨時資料表來完成。可以添加一組觸發器，以實時將表中的更改複製到臨時表中。如果每個公司原則不允許觸發程序，變更預存程序也可以達到相同的結果。您可以在任何寫入資料的程序中加入幾行程式碼，以便另外將相同的變更寫入暫存資料表。
將此暫存資料表與舊版應用程式資料表完全同步化，將為您提供即時移轉的絕佳起點。使用資料庫 CDC 來完成即時移轉的工具，例如 AWS DMS，現在可以針對此資料表使用。這種方法的優點是它使用關聯式資料庫引擎中已知的 SQL 技能和功能。
計劃
使用 SQL 臨時資料表執行線上移轉 AWS DMS
工具
-
自訂 SQL 預存程序或觸發程序
-
AWS Database Migration Service (DMS)，可將即時臨時資料表移轉至 DynamoDB 的 ETL 工具
線上移轉步驟：
-
在來源關聯式資料庫引擎中，請確定有一些額外的磁碟空間和處理容量。
-
在 SQL 資料庫中建立新的臨時資料表，並啟用時間戳記或 CDC 功能
-
撰寫並執行預存程序，將現有的關聯式資料表資料複製到臨時資料表
-
在對現有資料表執行正常寫入時，部署觸發程序或修改現有程序，以雙重寫入新的臨時資料表
-
執行 AWS DMS 以將此來源表格移轉並同步至目標 DynamoDB 表格
本指南介紹了將關聯式資料庫資料移轉至 DynamoDB 的幾個考量和方法，重點是將停機時間降至最低，並使用常見的資料庫工具和技術。如需詳細資訊，請參閱下列內容：
