Archive for 8月, 2010

このページの目次

Postgresで大量のラージオブジェクトデータをコピーする

木曜日, 8月 12th, 2010

こんにちは、なかわけです。

いまpostgresのlargeobjectを大量にコピーする作業をしています。
元のデータベースに3000万行くらいあってそれをまるっとそっくりコピーのデータベースに流し込みます。

INSERT INTO pg_largeobject
       SELECT *
         FROM dblink('dbname=元データベース', SELECT * FROM pg_largeobject')
           AS t1 (loid oid, pageno integer, data bytea);

最初一回でコピーしようとしたらメモリエラーで失敗しました。そりゃそうですよねw

それで3000万行を10万行ずつに分割して書いたクエリのテキストファイルを読み込ませて
データを流し込むことにしました。たとえば、以下はその中のひとつのクエリ。

INSERT INTO pg_largeobject
       SELECT *
         FROM dblink(
                  'dbname=元データベース',
                  'SELECT * FROM pg_largeobject ORDER BY loid, pageno LIMIT 100000 OFFSET 200000')
           AS t1(loid oid,pageno integer,data bytea);

始めの方は10万行を挿入するのに1、2分程度で処理されていましたが、だんだん処理が遅くなり、
1000万行を挿入し終わったあたりでは10万行挿入するのに15分程度かかるようになってしまいました。

時間がかかってしょうがないです。どうしたものか。

ところが、とあるところからいい方法を教えてもらいました。

INSERT INTO pg_largeobject
           SELECT *
           FROM dblink(
                   'dbname=元データベース',
                   'SELECT * FROM pg_largeobject WHERE loid BETWEEN n AND m')
           AS t1(loid oid,pageno integer,data bytea);

ORDERしてLIMIT、OFFSETするのではなく、BETWEENを使うんですね!
確かにこっちの方が処理が少ない分早そうだし、実際めちゃ早かったです。
あーよかったよかった!

Linux、Postgresで最近学んだこと

日曜日, 8月 8th, 2010

こんにちは、なかわけです。

ここ1週間エンジニアリグな作業ばかりしていましたが、
LinuxとPostgresで学んだことを箇条書き。誰得記事です。

  1. CPUの使用率が90%を超えるとパフォーマンスが極端に落ちる
  2. メモリの使用率が90%を超えるとパフォーマンスが落ちる
  3. データ容量が90%を超えるとパフォーマンスが落ちる
  4. わからないコトはいろんな記事を比較して調べる
  5. 必ずバックアップを取ってからファイルを削除する
  6. ラージオブジェクトを使う場合はそのときのリスクを考える
  7. pg_dumpは不正データもdumpする可能性がある
  8. ラージオブジェクトを含むdumpデータはrestoreに時間がかかる

この1週間かなり勉強になったがもう二度とやりたくない。