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