こんにちは！開発現場でデータベースと格闘していると、時々「うわ、やってしまった……」という瞬間に出会いませんか？
特に、数千万件ある巨大なテーブルデータをpgAdminでエクスポートしようとした瞬間、画面がフリーズし、無情にも「Out of Memory (OOM)」エラーが突きつけられる……。夜中に一人、オフィスのディスプレイの前で冷や汗をかいた経験がある方も多いはずです。
今回は、そんなpgAdminのメモリ限界をスマートに突破し、巨大データを安全かつ爆速でハンドリングするための「バッチ分割処理とバックアップ戦略」を、現場の知見をたっぷり込めてお伝えします。
これをマスターすれば、もうデカいデータの扱いで怯える必要はなくなりますよ。一緒に見ていきましょう！
—
1. なぜpgAdminで「メモリ不足」が起きるのか？
そもそも、なぜpgAdminでエクスポートやインポートをするとメモリがパンクするのでしょうか？
結論から言うと、pgAdminは「ブラウザベースの管理ツール（Webアプリ）」だからです。
pgAdminの画面から「データをダウンロードするぞ！」と操作すると、裏側でデータベースから取得した膨大なデータを一度pgAdminのサーバーメモリ（またはブラウザのメモリ）上に抱え込もうとします。数GBもあるデータをメモリ上で展開しようとするのですから、そりゃあクラッシュして当然です。
初心者の方がやりがちな罠が、「pgAdminのGUIメニューから『エクスポート』をポチる」という行為。実はこれ、数万件程度ならいいのですが、数百万件を超える本番データに対してやってはいけないアンチパターンなのです。
—
2. 【基本方針】巨大データはGUIではなく「コマンドライン」と「バッチ分割」で制す
では、どうすればいいのか？
答えはシンプルです。「pgAdminのGUIでやろうとしないこと」。そして、PostgreSQL標準の強力なツール（`pg_dump` / `psql`）や、Pythonなどのスクリプトを組み合わせて、データを「小さく分割して」処理する（バッチ処理）ことです。
ここからは、実務でそのまま使える具体的なテクニックを2つ紹介します。
—
3. テクニック①：`pg_dump` のカスタムフォーマット（`-F c`）＋ 並列処理（`-j`）を使う
まずは、pgAdminから離れてPostgreSQLが標準で持っている最強のバックアップツール `pg_dump` を使う方法です。実はpgAdminの裏側も、このコマンドをラップして動いています。
巨大データを扱う場合、プレーンなSQLテキスト形式で吐き出すとインポート時に死にます。必ずカスタムフォーマット（アーカイブ形式）を使いましょう。
エクスポートの極意（並列処理で爆速化）
-F c : カスタムフォーマット（圧縮され、個別のテーブル単位でリストア可能）
-j 4 : 4つのジョブ（CPUコア）を並列走査して高速エクスポート
pg_dump -U ユーザー名 -h ホスト名 -d データベース名 -F c -j 4 -b -v -f “huge_table_backup.dump” -t 対象のテーブル名
このカスタムフォーマットの何が凄いかというと、「必要なテーブルやスキーマだけをピンポイントで復元できる」点です。また、圧縮率も非常に高いため、ディスク容量も節約できます。
インポート（リストア）の極意
戻すときも `pg_restore` を使います。ここでも並列処理が使えます。
-j 4 で一気にリストア
pg_restore -U ユーザー名 -h ホスト名 -d データベース名 -j 4 -v “huge_table_backup.dump”
—
4. テクニック②：Pythonを使った「ID範囲指定」によるバッチ分割エクスポート
「いや、ファイル全体じゃなくて、CSV形式で一部ずつ切り出したいんだよ！」という要件もありますよね。
そんなときは、Pythonを使って主キー（ID）の範囲で細切れにデータを取得する（バッチ分割）のが最も安全で確実です。メモリを一切圧迫しません。
以下のスクリプトを参考にしてみてください。数千万件のテーブルであっても、1万件ずつチャンク（塊）に分けて安全にCSVへ書き出します。
import csv
import psycopg2
接続設定
DB_CONFIG = {
“dbname”: “your_db”,
“user”: “your_user”,
“password”: “your_password”,
“host”: “localhost”,
“port”: “5432”,
}
TABLE_NAME = “huge_sales_data”
BATCH_SIZE = 50000 # 1回あたりに処理する行数
def export_in_batches():
conn = psycopg2.connect(DB_CONFIG)
cur = conn.cursor()
# 1. データの最小IDと最大IDを取得する
print(“IDの範囲を確認中…”)
cur.execute(f”SELECT MIN(id), MAX(id) FROM {TABLE_NAME};”)
min_id, max_id = cur.fetchone()
if min_id is None:
print(“データが存在しません。”)
return
print(
f”処理対象ID範囲: {min_id} ～ {max_id} (総バッチ数予測: {(max_id – min_id) // BATCH_SIZE + 1})”
)
# 2. バッチ単位でループを回す
current_start = min_id
file_counter = 1
while current_start <= max_id: current_end = current_start + BATCH_SIZE - 1 output_filename = f"export_part_{file_counter}.csv" print( f"[{file_counter}ファイル目] ID: {current_start} ～ {current_end} の範囲を出力中..." ) # チャンクごとにデータを取得 query = f""" SELECT FROM {TABLE_NAME} WHERE id >= %s AND id <= %s ORDER BY id ASC; """ cur.execute(query, (current_start, current_end)) rows = cur.fetchall() if rows: # CSVへ書き出し with open( output_filename, mode="w", newline="", encoding="utf-8" ) as f: writer = csv.writer(f) # カラム名を取得してヘッダーにする場合 # header = [desc[0] for desc in cur.description] # writer.writerow(header) writer.writerows(rows) # 次のチャンクへ current_start = current_end + 1 file_counter += 1 cur.close() conn.close() print("すべてのバッチ処理が正常に完了しました！") if __name__ == "__main__": export_in_batches()
このスクリプトの推しポイント
- メモリ消費がほぼ一定（O(1)の空間計算量）： 一度に全データをメモリに乗せず、指定した `BATCH_SIZE`（例: 5万件）ごとにファイルへ吐き出してメモリを解放するため、OOMエラーが原理的に起きません。
- 中断・再開がしやすい: もし途中でスクリプトが止まっても、`current_start` の値を調整すれば、中途半端な場所から再開可能です。
—
5. まとめ：ツールを過信せず、適材適所で使い分けよう
pgAdminは、スキーマの確認や、日常的な数千件程度のクエリ実行・確認作業においては最高のGUIクライアントです。しかし、「数GB〜数十GB規模の巨大データ一括操作」を任せるのは、いわば軽自動車で大型トラックの荷物を運ぼうとするようなもの。車軸が折れてしまいます（＝メモリ不足）。
- 普段の管理・確認 ＝ pgAdminのGUI
- まとまったバックアップ・リストア ＝ `pg_dump` / `pg_restore` (カスタムフォーマット)
- 柔軟な条件での巨大データ分割入出力 ＝ Python等のバッチスクリプト
このように、ツールの特性に合わせて「適材適所」で使い分けられるようになると、データベースを扱うエンジニアとしての引き出しがグッと広がります。
「巨大データの壁」にぶつかったときは、ぜひ今回のバッチ分割の知見を思い出してください。あなたの毎日のデータベース運用が、より快適でストレスフリーなものになることを応援しています！