1.背景

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

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

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

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

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

2.可選遷移方案

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

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

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

• AWS DMS全量+增量遷移

• Mongoshake全量+增量遷移

• Mongodump/mongorestore+DMS增量遷

方案1：AWS DMS全量+增量

?DMS是亞馬遜云科技的一項云服務，允許遷移關(guān)系數(shù)據(jù)庫、MongoDB數(shù)據(jù)庫和其他類型的數(shù)據(jù)存儲?？梢允褂肈MS執(zhí)行一次性遷移，或復制源庫正在進行的更改以保持源和目標同步。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工具恢復到MongoDB。它也同樣支持從DocuemntDB備份數(shù)據(jù)。而mongodb-database-tools的6.1版本也支持恢復到DocumentDB Elastic Cluster。這種方案的優(yōu)勢是穩(wěn)定快速，缺點是增量同步能力不足。但是，可以借助DMS的增量同步能力。重點是需要選擇好增量同步的起始位點，防止數(shù)據(jù)丟失。

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

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

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

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