postgresqlからAurora(postgres)への移行作業時間について、圧縮形式とそのままの形式で比較する

こんにちは。
fabeee88です。
業務で、postgresqlからAurora(postgres)に移行を行うことになりました。その件ではAWS Database Migration Serviceを使用できません。エクスポート側のサーバの管理者いわく、オンプレミスのサーバでDMSの設定ができなかったとのこと。
 
初期のテストでエクスポートをしていたところ、カスタムアーカイブ方式(pg_restore)で行うよりも、普通のプレーンテキスト方式(pg_dump)の方がエクスポートとインポートの合計時間でやや速く完了する現象が多々発生。
 
試しにプレーンテキスト方式とカスタムアーカイブ方式にかかる時間を計測してみようと考えました。環境に依存する割合も多いとは思いますが。
スキーマ単位で試行します。
 
カスタムアーカイブ方式の方が、データファイルの容量ははるかに小さいですが、業務では処理時間も要求されるため、多少容量を取ろうとも、プレーンテキスト方式で行う方が良いケースも出てくると思います。
（スキーマが非常に多く存在するケースなど。現にわたくしの業務も、時間次第でpg_dumpを行う流れになっています）
 
業務のサーバで記事を書くわけにはいかないので、AWSでEC2,RDSサーバをレンタルして行います。
(AWSの、最も安い構成で行います)

スペック



エクスポート側
t2.micro
EC2ローカル
postgresql 11.6(EC2に直接インストール)　　
Amazon Linux 2
(memory1GB 2.5GHz 8GiB)


インポート側
db.r5.large
Aurora(postgresql)
postgresql 10.7
(2vCPUs 16GiB RAM EBS:3500 Mbps)

 
移行の容量は、プレーンテキスト方式とカスタムアーカイブ方式の中間ファイルのサイズを目安にさせて頂きます。
小さいスキーマ

 
大きいスキーマ

 
もっと大きなサイズも試したかったのですが、機械的に単純複製したレコードをテーブルに大量挿入しても、圧縮効率が良くなりすぎてプレーンテキスト方式とカスタムアーカイブ方式の必要時間がほぼ変わらなくなりました。
（上記のようなデータ内容の場合、サイズ的にはカスタムアーカイブ方式のファイルは、プレーンテキスト方式のファイルの100分の1以下になります）
 
手持ちの比較用に使えるデータは上記ぐらいしか無かったのですが、当然マシンのスペックを上げれば、インポート側は劇的に改善することを実際の業務で確認しました。（今回は事情により掲載を見送らせて頂きますが）
実際の業務でエクスポート側は、オンプレミスだったのでスペックの向上は確認できていません。
 
もしご担当の業務で、夜間しかサービスを止められず、DMSも使えず、わずかな時間も貴重になる状況になりましたら、プレーンテキスト方式も試されてみてはいかがでしょうか。特にエクスポート側が、古いオンプレミスの場合の移行は該当すると思います。さらに通信時間の要素がからんでくる可能性はございますが。
 
拙い記事にお付き合い頂き、誠にありがとうございました。
 
SES/受託開発のご依頼についてはこちら