Contents

• • English
• pg_bulkload ホームページへようこそ
• ドキュメント
• 性能測定結果
  • 結果1 : 初期ロード
  • 結果2 : 追加ロード
  • 結果3 : パラメータ、各種機能による性能影響
  • 測定条件
  • English
• pg_bulkload ホームページへようこそ
• ドキュメント
• 性能測定結果
  • 結果1 : 初期ロード
  • 結果2 : 追加ロード
  • 結果3 : パラメータ、各種機能による性能影響
  • 測定条件

---

pg_bulkload ホームページへようこそ

pg_bulkload は PostgreSQL 向けの高速データロードユーティリティです。

Here is an English page.

---

ドキュメント

• 高速データローダ: pg_bulkload ドキュメント
  • 一定の制約条件の下で大量のデータを高速にロードするためのプログラムです。
• オプションツール: pg_timestamp ドキュメント
  • タイムスタンプ文字列のパースのオーバヘッドをスキップするための追加モジュールです。

---

性能測定結果

COPY と pg_bulkload の比較のため、以下の条件で測定を行いました。 PostgreSQL サーバは、基本的なチューニングを済ませた状態です。 詳細な環境条件については末尾に記載しています。

テーブル定義

TPC-C ベンチマークの簡易実装である DBT-2 の、customer テーブルと同じ構成です。

インデックス定義

2つのインデックスを定義しています。 1つ目は、integer 1列を含む昇順の主キーです。 2つ目は、integer 1列を含むランダム・キーから成る非ユニークインデックスです。

測定パターンは以下です。

1. 空のテーブルへの 4GB のデータの初期ロード
2. 既に 4GB のデータを持つテーブルへの、1GB の追加ロード
3. maintenance_work_mem、FILTER 機能の性能への影響

結果1 : 初期ロード

pg_bulkload の PARALLEL モードを用いることで、COPY に比べて半分程度の時間でロードを行うことができています。 COPY を用いる場合でも、インデックス定義なしで COPY することで処理時間を 2/3 程度にまで短縮することが可能です。 これは pg_bulkload の DIRECT モードとほぼ同等の効果があります。

初期ロード(4GB)

項目	時間	時間比
COPY with indexes	500 sec	-
COPY without indexes + CREATE INDEX	333 sec (229 sec + 51 sec+ 53 sec)	66.7 %
pg_bulkload (DIRECT) with indexes	334 sec	66.8 %
pg_bulkload (PARALLEL) with indexes	221 sec	44.2 %

結果2 : 追加ロード

pg_bulkload を用いることで、インデックスを付けたままのロードでも、COPY と比較して DIRECT モードで 2/3 程度、PARALLEL モードで半分程度の時間での実施が可能です。 追加ロードの COPY では、インデックスを落としてロードを行う手段は有効ではありません。 インデックスの再作成の際に既存のデータもインデックスしなければならないためです。

追加ロード(1GB)

項目	時間	時間比
COPY with indexes	140 sec	-
COPY without indexes + CREATE INDEX	187 sec (62 sec + 60 sec + 65 sec)	133.6 %
pg_bulkload (DIRECT) with indexes	93 sec	66.4 %
pg_bulkload (PARALLEL) with indexes	70 sec	50.0 %

結果3 : パラメータ、各種機能による性能影響

pg_bulkload は インデックス作成処理において maintenance_work_mem の影響を受けます。 この値を大きくすることでさらにロードが高速になる可能性があります。 ここでは、maintenance_work_mem が 64 MB と 1 GB の場合で 15 % 程度処理時間に差が出ています。

pg_bulkload の FILTER 機能を用いることで、入力データを柔軟に編集しながらロードすることができますが、性能へのトレードオフがあります。 この検証では、SQL関数を利用する場合には2倍以上、C言語関数を利用する場合には 1.3倍強 までロード時間が増加しました。

maintenace_work_mem、 FILTER 機能の性能への影響

項目		時間
		初期ロード(4GB)	追加ロード(1GB)
MWM = 64 MB	DIRECT	397 sec	109 sec
MWM = 1 GB
	DIRECT	334 sec	93 sec
	DIRECT with SQL FILTER	801 sec	216 sec
	DIRECT with C FILTER	456 sec	126 sec

測定条件

項目	値
Server	Dell PowerEdge R410
CPU	Intel Xeon E5645 (2.4GHz) 12 core * 2
Memory	32GB
Disks	SAS 10000rpm 2TB * 4
OS	CentOS 6.2 (64bit)
PostgreSQL version	9.3.4
pg_bulkload version	3.1.6
shared_buffers	3210MB
checkpoint_segments	300
checkpoint_timeout	15min
work_mem	1MB
maintenance_work_mem	1GB
Table definition	DBT-2 customer table
Indexed columns	c_id (PRIMARY KEY)
	c_d_id (non-unique B-Tree)
Constraints	NOT NULL for all columns
Input file format	CSV

---

Copyright (c) 2007-2024, NIPPON TELEGRAPH AND TELEPHONE CORPORATION