譯者 | 陳峻
審校 | 重樓
最近許多組織都在尋求 DynamoDB 的替代方案。其主要原因除了最常提到的成本因素之外，節(jié)流、硬限制（hard limit）和供應(yīng)商鎖定等方面，也是遷移的各種動(dòng)機(jī)。那么，當(dāng)你需要將數(shù)據(jù)從DynamoDB 遷移到另一個(gè)數(shù)據(jù)庫(kù)時(shí)，你是否會(huì)簡(jiǎn)單地從概念上認(rèn)為，只需從一個(gè)數(shù)據(jù)源讀取，轉(zhuǎn)為寫入另一個(gè)數(shù)據(jù)源即可呢？當(dāng)你被要求保持遷移的一致性和安全性時(shí)，你是否會(huì)考慮到“雙重寫入（Dual-Write）”？鑒于一旦忽略了某個(gè)重要細(xì)節(jié)，就可能功虧一簣，你是否會(huì)想到選用工具，來協(xié)助解決此類問題？其中又有哪些典型的注意事項(xiàng)呢？
下面，我將從概述數(shù)據(jù)庫(kù)遷移的原理出發(fā)，向你介紹與 DynamoDB 遷移相關(guān)的各項(xiàng)特定和重要特征，然后討論用于與其他數(shù)據(jù)庫(kù)集成、以及無縫遷移到其他數(shù)據(jù)庫(kù)所采用的相關(guān)策略。
數(shù)據(jù)庫(kù)遷移的工作原理
大多數(shù)數(shù)據(jù)庫(kù)的遷移都遵循如下嚴(yán)格的步驟：
首先，捕獲曾對(duì)源數(shù)據(jù)庫(kù)做過的所有更改，以保證任何數(shù)據(jù)的delta修改都可以被后續(xù)予以重放（replay）。
其次，通過從源數(shù)據(jù)庫(kù)讀取并寫入目標(biāo)數(shù)據(jù)庫(kù)的方式，進(jìn)行數(shù)據(jù)復(fù)制。當(dāng)然，你也可以先導(dǎo)出源數(shù)據(jù)庫(kù)的備份，再簡(jiǎn)單地將其旁路加載（side-load）到目標(biāo)數(shù)據(jù)庫(kù)中。
至此，在初始數(shù)據(jù)被加載之后，目標(biāo)數(shù)據(jù)庫(kù)將會(huì)包含源數(shù)據(jù)庫(kù)中的大部分記錄。之所以稱為“大部分”，是因?yàn)槟切┰诖似陂g發(fā)生數(shù)據(jù)更改，將無法被加載進(jìn)去。對(duì)此，下一步便是將源數(shù)據(jù)庫(kù)生成的所有增量，重放到目標(biāo)數(shù)據(jù)庫(kù)中。一旦完成，這兩個(gè)數(shù)據(jù)庫(kù)便完全同步了。后續(xù)，你就可以開始切換應(yīng)用了。
數(shù)據(jù)庫(kù)遷移的工作原理
需要雙重寫入嗎？
如果你熟悉 Cassandra 遷移，那么你可能聽說過使用“雙重寫入”來完成遷移工作的建議。也就是說，你需要將代理源數(shù)據(jù)庫(kù)中的每個(gè)寫入器突變（writer mutation），以相同的記錄寫入目標(biāo)數(shù)據(jù)庫(kù)。
不過，并非每個(gè)數(shù)據(jù)庫(kù)都實(shí)現(xiàn)了像 CQL 協(xié)議那樣，允許寫入器檢索或操作記錄時(shí)間戳的概念。這將阻止你在使用歷史數(shù)據(jù)回填（back-filling）目標(biāo)數(shù)據(jù)庫(kù)時(shí)，對(duì)應(yīng)用實(shí)施雙重寫入。畢竟，此舉可能最終導(dǎo)致遷移的不一致，即：某些目標(biāo)項(xiàng)可能無法反映其在源數(shù)據(jù)庫(kù)中的最新狀態(tài)。
那么，這是否意味著在 DynamoDB 遷移中使用雙重寫入屬于錯(cuò)誤之舉呢？當(dāng)然不是！考慮到你的 DynamoDB 數(shù)據(jù)表會(huì)讓記錄（TTL）每 24 小時(shí)過期一次。在這種情況下，使用簡(jiǎn)單地雙重寫入，并在 TTL 到期之后切換讀取器的方式，去回填數(shù)據(jù)庫(kù)的確沒有意義。不過，如果你的 TTL 更長(zhǎng)（比如一年），那么等待其過期顯然不是移動(dòng)數(shù)據(jù)的有效方法。
回填歷史數(shù)據(jù)
雖然回填歷史數(shù)據(jù)是大多數(shù)遷移中的強(qiáng)制步驟，但到底是否需要，則主要取決于你的用例。通常，你可以通過如下 3 種主要方式，回填 DynamoDB 中的歷史數(shù)據(jù)：
ETL
為了實(shí)現(xiàn)ETL（提取-轉(zhuǎn)換-加載），Apache Spark之類的工具會(huì)從掃描數(shù)據(jù)表開始，逐頁(yè)讀取結(jié)果，并使用結(jié)果來推斷源表的架構(gòu)（schema）。接著，它會(huì)用到 DynamoDB 數(shù)據(jù)表的生成讀取器，而寫入器會(huì)將檢索到的數(shù)據(jù)攝入到目標(biāo)數(shù)據(jù)庫(kù)中。
這種方法非常適合執(zhí)行那些簡(jiǎn)單的遷移，同時(shí)允許你在進(jìn)行過程中轉(zhuǎn)換（也就是ETL中的 T）數(shù)據(jù)。不過，此舉容易出現(xiàn)如下問題：
- 架構(gòu)推理：由于DynamoDB 表是無架構(gòu)的，因此很難推斷出其架構(gòu)。所有表的屬性（其中哈希鍵和排序鍵除外）可能不會(huì)顯示在初始掃描的第一頁(yè)上。此外，給定項(xiàng)的所有屬性也可能不會(huì)投影到另一個(gè)項(xiàng)中。
- 成本：由于提取數(shù)據(jù)需要對(duì) DynamoDB 數(shù)據(jù)表進(jìn)行完全掃描，因此不可避免地會(huì)消耗 RCU（Read-Copy-Update）。如果 DynamoDB 的運(yùn)能不足，就可能會(huì)對(duì)你的應(yīng)用產(chǎn)生上游影響，因此它最終會(huì)片面地推高遷移的成本。
- 時(shí)間：遷移數(shù)據(jù)所需的時(shí)間往往與數(shù)據(jù)集的體量成正比。這意味著，如果你的遷移時(shí)間超過了 24 小時(shí)，則會(huì)超出 AWS 能夠保證的事件可用性時(shí)段，因此也就可能無法在遷移后直接從 DynamoDB 數(shù)據(jù)流中進(jìn)行重放。
數(shù)據(jù)表掃描
顧名思義，數(shù)據(jù)表的掃描只會(huì)在數(shù)據(jù)被加載到目標(biāo)數(shù)據(jù)庫(kù)之后，才從源 DynamoDB 表中檢索所有的記錄。與前面的 ETL 方法不同，這種方法的“提取”和“加載”部分是耦合的。數(shù)據(jù)會(huì)隨著過程的推進(jìn)而被寫入，而且這里的每個(gè)步驟都是以分階段的方式執(zhí)行的。
好消息是該方法非常簡(jiǎn)單，你只需運(yùn)行如下單個(gè)命令即可。一旦完成，你就得到了所有數(shù)據(jù)。
$ aws dynamodb scan --table-name source > output.json然后，你將最終得到一個(gè)包含了源表中所有現(xiàn)有項(xiàng)的 JSON 文件。據(jù)此，你可以便捷地實(shí)施迭代并寫入目標(biāo)。除非你計(jì)劃轉(zhuǎn)換數(shù)據(jù)，否則你無需擔(dān)心數(shù)據(jù)架構(gòu)，畢竟你已事先知曉了所有鍵的屬性。
注意，此方法僅適用于中小型數(shù)據(jù)表。與之前的 ETL 方法類似，它在掃描較大的數(shù)據(jù)表時(shí)，可能耗時(shí)較長(zhǎng)，而且尚未包括你對(duì)其解析，以及后續(xù)將其加載到目的數(shù)據(jù)庫(kù)所花費(fèi)的時(shí)間。
S3 數(shù)據(jù)導(dǎo)出
如果你擁有大型數(shù)據(jù)集，或者是擔(dān)心 RCU的使用會(huì)對(duì)實(shí)時(shí)流量產(chǎn)生影響的話，則可以將 DynamoDB 數(shù)據(jù)導(dǎo)出到 Amazon S3。此舉可以讓你輕松地轉(zhuǎn)儲(chǔ)數(shù)據(jù)表的全部?jī)?nèi)容，而不會(huì)影響 DynamoDB 表的性能。此外，如果你的回填過程的用時(shí)超過了 24 小時(shí)，那么你可以到后續(xù)再請(qǐng)求增量導(dǎo)出。
在實(shí)踐中，若要請(qǐng)求將 DynamoDB 完整地導(dǎo)出至 S3，你只需運(yùn)行如下命令：
$ aws dynamodb export-table-to-point-in-time --table-arn arn:aws:dynamodb:REGION:ACCOUNT:table/TABLE_NAME --s3-bucket BUCKET_NAME --s3-prefix PREFIX_NAME --export-format DYNAMODB_JSON如果存在指定的 S3 存儲(chǔ)桶的話，導(dǎo)出過程將在后臺(tái)運(yùn)行。你可以運(yùn)行如下命令，來檢查其完成情況。
$ aws dynamodb list-exports --table-arn arn:aws:dynamodb:REGION:ACCOUNT:table/source
{
"ExportSummaries": [
{
"ExportArn": "arn:aws:dynamodb:REGION:ACCOUNT:table/TABLE_NAME/export/01706834224965-34599c2a",
"ExportStatus": "COMPLETED",
"ExportType": "FULL_EXPORT"
}
]
}該過程完成后，源表中的數(shù)據(jù)將會(huì)在之前指定的 S3 存儲(chǔ)桶/前綴中可用。在里面，你將可以找到一個(gè)名為 AWSDynamoDB 的目錄，其結(jié)構(gòu)如下類似：
$ tree AWSDynamoDB/
AWSDynamoDB/
└── 01706834981181-a5d17203
├── _started
├── data
│ ├── 325ukhrlsi7a3lva2hsjsl2bky.json.gz
│ ├── 4i4ri4vq2u2vzcwnvdks4ze6ti.json.gz
│ ├── aeqr5obfpay27eyb2fnwjayjr4.json.gz
│ ├── d7bjx4nl4mywjdldiiqanmh3va.json.gz
│ ├── dlxgixwzwi6qdmogrxvztxzfiy.json.gz
│ ├── fuukigkeyi6argd27j25mieigm.json.gz
│ ├── ja6tteiw3qy7vew4xa2mi6goqa.json.gz
│ ├── jirrxupyje47nldxw7da52gnva.json.gz
│ ├── jpsxsqb5tyynlehyo6bvqvpfki.json.gz
│ ├── mvc3siwzxa7b3jmkxzrif6ohwu.json.gz
│ ├── mzpb4kukfa5xfjvl2lselzf4e4.json.gz
│ ├── qs4ria6s5m5x3mhv7xraecfydy.json.gz
│ ├── u4uno3q3ly3mpmszbnwtzbpaqu.json.gz
│ ├── uv5hh5bl4465lbqii2rvygwnq4.json.gz
│ ├── vocd5hpbvmzmhhxz446dqsgvja.json.gz
│ └── ysowqicdbyzr5mzys7myma3eu4.json.gz
├── manifest-files.json
├── manifest-files.md5
├── manifest-summary.json
└── manifest-summary.md52 directories, 21 files
那么，我們又該如何從這些文件中恢復(fù)呢？在此，你需要使用 DynamoDB 低級(jí) API。值得慶幸的是，你無需深入研究其詳細(xì)信息，因?yàn)樽鳛橐环N入門的方式，AWS 已提供了 LoadS3toDynamoDB的示例代碼。你只需使用目標(biāo)數(shù)據(jù)庫(kù)的寫入器邏輯，去覆蓋 DynamoDB 連接即可。
流式處理 DynamoDB 更改
無論你是否需要回填數(shù)據(jù)，可能都希望從 DynamoDB 處捕獲事件，以確保兩者彼此同步。對(duì)此，DynamoDB 數(shù)據(jù)流可被用于捕獲在源 DynamoDB 表中執(zhí)行的任何更改。
DynamoDB Streams Kinesis Adapter
AWS 提供了 DynamoDB Streams Kinesis Adapter，以便你通過 Amazon Kinesis 客戶端庫(kù)，比如 Apache Spark 中的 kinesis-asl 模塊，處理來自 DynamoDB Streams 的各種事件。除了歷史數(shù)據(jù)的遷移，你只需將事件從 DynamoDB 數(shù)據(jù)流傳輸?shù)侥繕?biāo)數(shù)據(jù)庫(kù)，便可實(shí)現(xiàn)兩個(gè)數(shù)據(jù)存儲(chǔ)的同步。
盡管這種方法可能會(huì)引入陡峭的學(xué)習(xí)曲線，但作為迄今為止最靈活的方法，它甚至允許你使用 AWS 生態(tài)系統(tǒng)的外部事件。而這對(duì)于想要切換到不同的提供商尤為重要。對(duì)此，AWS 提供了有關(guān)如何使用源 DynamoDB 表到目標(biāo)表中的事件的一套演示流程。
AWS Lambda
如你所知，Lambda 函數(shù)既易于上手，又可自行處理所有檢查點(diǎn)的邏輯，還能與 AWS 生態(tài)系統(tǒng)無縫集成。使用該方法，你只需將應(yīng)用邏輯封裝在 Lambda 函數(shù)中即可。這可以讓你將事件寫入目標(biāo)數(shù)據(jù)庫(kù)，而無需處理諸如檢查點(diǎn)或流中的分片數(shù)等 Kinesis API 邏輯。
通過該方法，你可以將捕獲到的事件直接加載到目標(biāo)數(shù)據(jù)庫(kù)中。而如果存在 24 小時(shí)保留限制的問題，你也可以便捷地在Amazon SQS等其他服務(wù)中，流式傳輸和保留這些記錄，以便后續(xù)進(jìn)行重放。有關(guān)如何使用 Lambda 函數(shù)的示例，請(qǐng)參閱 AWS 文檔。
小結(jié)
上文和你深入探討了 DynamoDB 遷移的工作原理，以及它與其他數(shù)據(jù)庫(kù)的區(qū)別。我們也討論了回填歷史數(shù)據(jù)，并將數(shù)據(jù)流更改傳輸?shù)搅硪粋€(gè)數(shù)據(jù)庫(kù)的不同方法。最后，我們還利用你可能熟悉的 AWS 工具探討了端到端遷移。綜上所述，鑒于我們有著多種不同的方法來完成遷移，而且每一種都會(huì)存在一系列的優(yōu)缺點(diǎn)，因此在開始數(shù)據(jù)庫(kù)遷移之前，我們需要仔細(xì)規(guī)劃，綜合比較遷移所需的所有工具和策略，并對(duì)過程中涉及的各個(gè)步驟有著透徹的理解。
譯者介紹
陳峻（Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項(xiàng)目實(shí)施經(jīng)驗(yàn)，善于對(duì)內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控，專注傳播網(wǎng)絡(luò)與信息安全知識(shí)與經(jīng)驗(yàn)。
原文標(biāo)題：DynamoDB: How To Move Out，作者：Pratik Patel
