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