UNLOGGED TABLEによるCOPY性能向上効果
測定目的
9.1から入ったCREATE TABLE文のUNLOGGEDオプションはWALを出力しないということらしいので、通常のテーブルへのCOPYよりも高速になるはずなんだけど、実際、どのくらい変わってくるのかを実感するために簡単に測定してみた。
今回は別件の調査も兼ねて、XML型のデータをロードしてみることにする。XML型の場合はXMLのパース処理が重そうなので、通常の型よりはUNLOGGEDによる効果は低くなりそうだが・・・
測定環境
とりあえず手元にある環境を使って簡単に測定してみる。
HW | ないしょ |
Memory | 16GB |
OS | RH 5.3 |
PostgreSQL | 9.1.1 |
PostgreSQLの設定は殆ど弄らずに測定。変更したのは以下のみ。
パラメータ | 設定値 | 備考 |
wal_buffers | 4MB | デフォルトは32KB |
checkpoint_segments | 100 | デフォルトは3 |
logging_collector | on | ログファイル出力 |
log_directory | /tmp/pg_log | ログの出力先 |
log_min_duration_statement | 0 | サーバログにCOPYの処理時間を出すため |
COPY対象のテーブルは以下のDDLで生成する。
- 通常テーブル
CREATE TABLE orders (
data xml
);
TRUNCATE TABLE orders;
- UNLOGGEDテーブル
CREATE UNLOGGED TABLE orders (
data xml
);
TRUNCATE TABLE orders;
測定
測定方式
それぞれの方法で作成したテーブルにCOPY文でデータをロードし、そのCOPY文の処理時間をサーバログで確認する。
なお、ロードするXML型のデータ量は以下。
レコード数 | 2,592,000件 |
平均レコード長 | 393バイト |
ファイルサイズ総計 | 1,019,597,096バイト(約1GB) |
そんなに厳密な測定をするつもりはないので、測定は一発勝負で。
そういえば、1回測定ミスして分かったんだけど、COPYの背景ではXMLがWel-formedかどうかのチェックってやってないように思える・・・
間違えてフラットデータをXML型にロードしようとしたら、ロードできちゃったんだよな・・・いいのかな・・・。
測定結果
通常のテーブル | 56872.047 (ms) |
UNLOGGEDテーブル | 50955.64 (ms) |
まとめ
- UNLOGGEDテーブルにした場合、COPY文は10%程度の性能向上効果が見込めそう?
- もう少し高いのかなと思ったらそうでもない。逆に言えば、WAL書き込みが全体処理に及ぼす影響は思ったよりも大きくないということかも。
- 今回はXML型を使ったので(パース時間がそれなりに重いと仮定して)、通常のデータタイプならもう少し向上するかも・・・と思ってたけど、COPY背景ではWel-formedなチェックをしていないんだとすると、パースの問題じゃないってことか?
- COPY先のテーブルへの更新がなく、かつ入力ファイルのバックアップを保持するのであれば、クラッシュしても復元は出来るので、そういう用途であればUNLOGGEDテーブルを使う意義はありそう?