![Database Migration Service の Source に MongoDB が選択可能になりました!](https://devio2023-media.developers.io/wp-content/uploads/2016/01/eyecatch_dms.png)
Database Migration Service の Source に MongoDB が選択可能になりました!
菊池です。
Database Migration Service(DMS)の移行元データベース(Source)としてMongoDBが設定可能になりました。
- AWS Database Migration Service Adds Support for MongoDB and Amazon DynamoDB
- Using MongoDB as a Source for AWS Database Migration Service
試してみた
早速試してみます。
SourceとしてEC2で動作するMongoDBのレプリカセット、TargetとしてS3を利用します。
前提条件
移行元のMongoDBの前提条件です。
- Version 2.6.x または 3.x
- レプリカセット構成でOplogにアクセス可能なユーザが必要
マイグレーションモード
公式ドキュメントによると、MongoDBからのマイグレーションには2つのモードがあります。MongoDBはJSON形式のドキュメント(RDBのレコードに相当)でデータを扱いますので、それをどのような形式で出力するかが異なります。
- ドキュメントモード:JSONドキュメントを1つのカラムとしてそのまま出力
- テーブルモード:JSONドキュメントのキー毎にカラムを設定して出力
今回は上記の2つのパターンで、それぞれどのように出力されるか見てみたいと思います。
エンドポイントの作成
Source/Targetのエンドポイントを作成します。
TargetとなるS3は、バケット/フォルダと権限のあるIAMロールを設定します。
次に、SourceとなるMongoDBです。サーバ名にはマイグレーションインスタンスから解決可能な名前を、ポートはMongoDBデフォルトの27017を設定しました。SSLは今回はVPC内のため設定しません。
ユーザ名、パスワードはあらかじめMongoDBに作成したものを設定します。ユーザにはバックアップに必要な権限を付与しておきます。今回はrootのロールを設定しました。Authentication sourceは認証するユーザが登録されたデータベースを設定します。通常はadminです。
Metadata modeには、前述のtableとdocumentがあります。今回は両方のパターンを試しました。
タスクの実行
準備ができたらタスクを実行します。
出力データの確認
DMSで出力したデータを確認してみます。
移行元のMongoDBのデータベース、main
には、以下のようなuser
コレクションとデータがあります。
s0-rs0:PRIMARY> db.users.find() { "_id" : ObjectId("58dddfc7e87a9d84c86068ed"), "userid" : 10000, "name" : "hoge1", "age" : 19 } { "_id" : ObjectId("58dddfc7e87a9d84c86068ee"), "userid" : 20000, "name" : "hoge2", "age" : 33 } { "_id" : ObjectId("58dddfc7e87a9d84c86068ef"), "userid" : 30000, "name" : "hoge3", "age" : 41 } { "_id" : ObjectId("58dddfc7e87a9d84c86068f0"), "userid" : 40000, "name" : "hoge4", "age" : 24 } { "_id" : ObjectId("58dddfc7e87a9d84c86068f1"), "userid" : 50000, "name" : "hoge5", "age" : 50 } { "_id" : ObjectId("58dddfc8e87a9d84c86068f2"), "userid" : 60000, "name" : "hoge6", "age" : 16 } { "_id" : ObjectId("58dde7c9c1a34a4d588ce97d"), "userid" : 70000, "name" : "hoge7", "age" : 55 }
DMSでS3に出力されたデータを確認します。データベース、コレクションのフォルダが作成され、csv形式で保存されています。
ドキュメントモードの出力
$ cat LOAD00000001.csv "{ "_id" : { "$oid" : "58dddfc7e87a9d84c86068ed" }, "userid" : 10000, "name" : "hoge1", "age" : 19 }" "{ "_id" : { "$oid" : "58dddfc7e87a9d84c86068ee" }, "userid" : 20000, "name" : "hoge2", "age" : 33 }" "{ "_id" : { "$oid" : "58dddfc7e87a9d84c86068ef" }, "userid" : 30000, "name" : "hoge3", "age" : 41 }" "{ "_id" : { "$oid" : "58dddfc7e87a9d84c86068f0" }, "userid" : 40000, "name" : "hoge4", "age" : 24 }" "{ "_id" : { "$oid" : "58dddfc7e87a9d84c86068f1" }, "userid" : 50000, "name" : "hoge5", "age" : 50 }" "{ "_id" : { "$oid" : "58dddfc8e87a9d84c86068f2" }, "userid" : 60000, "name" : "hoge6", "age" : 16 }" "{ "_id" : { "$oid" : "58dde7c9c1a34a4d588ce97d" }, "userid" : 70000, "name" : "hoge7", "age" : 55 }"
JSONドキュメント毎に単一のレコードが作成されています。
テーブルモードの出力
$ cat LOAD00000001.csv "58dddfc7e87a9d84c86068ed",+1.0000000000000000e+04,"hoge1",+1.9000000000000000e+01 "58dddfc7e87a9d84c86068ee",+2.0000000000000000e+04,"hoge2",+3.3000000000000000e+01 "58dddfc7e87a9d84c86068ef",+3.0000000000000000e+04,"hoge3",+4.1000000000000000e+01 "58dddfc7e87a9d84c86068f0",+4.0000000000000000e+04,"hoge4",+2.4000000000000000e+01 "58dddfc7e87a9d84c86068f1",+5.0000000000000000e+04,"hoge5",+5.0000000000000000e+01 "58dddfc8e87a9d84c86068f2",+6.0000000000000000e+04,"hoge6",+1.6000000000000000e+01 "58dde7c9c1a34a4d588ce97d",+7.0000000000000000e+04,"hoge7",+5.5000000000000000e+01
元のJSONドキュメントのキー:$oid
、userid
、name
、age
の単位で、csv形式でデータが入っていることが確認できました。
さいごに
いかがでしょうか。
まさか、DMSでMongoDBがサポートされるとは思っていませんでした。今回は基本的なデータのエクスポートのみでしたが、ネストしたJSONデータの移行やchange data capture (CDC)なども試してレポートしていきたいと思います。
また、先に対応したS3へのマイグレーションと合わせることで、データのバックアップやEMR/Athenaを使った分析といった応用もできそうなので、現在運用しているMongoDBの活用の幅が広がりそうです!