1.背景

?目前，文檔型數(shù)據(jù)庫由于靈活的schema和接近關(guān)系型數(shù)據(jù)庫的訪問特點(diǎn)，被廣泛應(yīng)用，尤其是游戲、互聯(lián)網(wǎng)金融等行業(yè)的客戶使用MongoDB構(gòu)建了大量應(yīng)用程序，比如游戲客戶用來處理玩家的屬性信息；又如股票APP用來存儲(chǔ)與時(shí)間線相關(guān)的行情數(shù)據(jù)。隨著時(shí)間的推移和業(yè)務(wù)的發(fā)展，MongoDB庫越來越大，大庫治理是必須面臨的問題。

?一般來講，大庫治理有如下幾種方案。一是做冷熱數(shù)據(jù)隔離，將數(shù)據(jù)根據(jù)使用頻率分為熱、溫、冷、凍級(jí)別，超過一定時(shí)間的冷數(shù)據(jù)，轉(zhuǎn)儲(chǔ)到另一個(gè)冷庫或低成本存儲(chǔ)的數(shù)據(jù)庫；熱庫只保留近期訪問頻繁的數(shù)據(jù)；二是做垂直拆分，比如大系統(tǒng)有多個(gè)集合，按照模塊進(jìn)行垂直劃分，把不同模塊對(duì)應(yīng)的集合拆分到不同庫，實(shí)現(xiàn)數(shù)據(jù)量和訪問量的垂直分離；三是做水平拆分，比如選擇userid的哈希值，將大的集合水平拆分到多個(gè)庫，實(shí)現(xiàn)整體存儲(chǔ)和計(jì)算能力的擴(kuò)展。第四，也有部分業(yè)務(wù)，它的歷史數(shù)據(jù)的使命完成，走完生命周期，可以直接刪除。這4種方案，各有利弊，且需要根據(jù)實(shí)際業(yè)務(wù)場景進(jìn)行選型。而很多場景下，客戶會(huì)選擇水平sharding，主要原因如下：

• 很多業(yè)務(wù)需要經(jīng)常查詢歷史數(shù)據(jù)，水平sharding不需要?jiǎng)h除或分離歷史數(shù)據(jù)；

• 長遠(yuǎn)來看，水平sharding的擴(kuò)展性更好，可以支撐更大的業(yè)務(wù)規(guī)模。

?DocumentDB Elastic Cluster是亞馬遜云科技提供的一個(gè)很好的支持水平sharding的云數(shù)據(jù)庫服務(wù)。本文，主要針對(duì)客戶從MongoDB副本集架構(gòu)遷移到DocumentDB Elastic Cluster的過程中，如何進(jìn)行海量數(shù)據(jù)遷移的問題，進(jìn)行研究，并提供最佳實(shí)踐。

2.可選遷移方案

?眾所周知，含有大數(shù)據(jù)量的數(shù)據(jù)庫的遷移，是比較有挑戰(zhàn)性的問題。數(shù)據(jù)庫在不斷的讀寫，不僅需要在目標(biāo)庫完成當(dāng)前全量數(shù)據(jù)的初始化，也需要把初始化期間的數(shù)據(jù)變化同步到新庫。以下是遷移方案示意圖：

?MongoDB記錄文檔變化的方式有兩種：oplog和change stream。由于，oplog或change stream的存儲(chǔ)空間是有限的，因此全量初始化階段的遷移速度是必須要考慮的因素。另外，增量同步階段的速度也必須大于源數(shù)據(jù)庫的變化速度，這樣才能實(shí)現(xiàn)新舊數(shù)據(jù)庫的數(shù)據(jù)一致。這兩個(gè)階段，我們都需要依賴穩(wěn)定、高效的工具來完成。尤其在大型數(shù)據(jù)庫的遷移時(shí)，甚至要配合一定的數(shù)據(jù)遷移策略（比如并行、壓縮；冷、熱數(shù)據(jù)分別遷移；不同集合分別遷移等）。

亞馬遜云科技有3種可行的遷移方案：

• AWS DMS全量+增量遷移

• Mongoshake全量+增量遷移

• Mongodump/mongorestore+DMS增量遷

方案1：AWS DMS全量+增量

?DMS是亞馬遜云科技的一項(xiàng)云服務(wù)，允許遷移關(guān)系數(shù)據(jù)庫、MongoDB數(shù)據(jù)庫和其他類型的數(shù)據(jù)存儲(chǔ)。可以使用DMS執(zhí)行一次性遷移，或復(fù)制源庫正在進(jìn)行的更改以保持源和目標(biāo)同步。DMS在全量遷移階段提供了Auto segmentation和Range segmentation的方式來并行加速遷移；在CDC增量階段，3.5 bet版也支持并發(fā)方式寫入DocumentDB。

方案2：Mongoshake全量+增量

?開源的Mongoshake，也支持遷移寫入DocumentDB。由于它屬于開源產(chǎn)品，優(yōu)勢是社區(qū)活躍，遇到問題可以定制開發(fā)解決，遷移速度較快；劣勢是遇到問題可以獲得的技術(shù)支持力度較低，用戶需要自己定位或求助社區(qū)。

方案3：Mongodump/mongorestore+DMS增量

?mongodump是MongoDB官方提供的備份工具，它可以從MongoDB數(shù)據(jù)庫讀取數(shù)據(jù)，并生成BSON文件，然后通過mongorestore工具恢復(fù)到MongoDB。它也同樣支持從DocuemntDB備份數(shù)據(jù)。而mongodb-database-tools的6.1版本也支持恢復(fù)到DocumentDB Elastic Cluster。這種方案的優(yōu)勢是穩(wěn)定快速，缺點(diǎn)是增量同步能力不足。但是，可以借助DMS的增量同步能力。重點(diǎn)是需要選擇好增量同步的起始位點(diǎn)，防止數(shù)據(jù)丟失。

以上三種方案，各有優(yōu)缺點(diǎn)，如下表。

使用DMS托管服務(wù)，用戶配置遷移任務(wù)最方便，整個(gè)遷移過程，日志清晰、速度直觀，可觀測性較好。Mongoshake在增量寫入DocumentDB環(huán)節(jié)速度略慢，在TPS較高的場景不適用；而mongodump和mongorestore在MongoDB大數(shù)據(jù)庫遷移場景上，速度比DMS full load更快。大庫遷移是否成功的一個(gè)非常重要因素是遷移速度。

原標(biāo)題：大型MongoDB數(shù)據(jù)庫遷移到DocumentDB Elastic Cluster的最佳實(shí)踐

原鏈接：https://aws.amazon.com/cn/blogs/china/best-practices-for-migrating-large-mongodb-databases-to-documentdb-elastic-cluster/