Quantcast
Channel: huskyの備忘録 » PostgreSQL
Viewing all articles
Browse latest Browse all 4

PostgreSQLの高速データロードユーティリティpg_bulkloadを使ってみた

0
0

先ほど公開した、「PostgreSQLの高速データロードユーティリティpg_bulkloadのインストール

の記事でインストールした、pg_bulkloadを使用してデータ投入のパフォーマンスをちょこっとだけ検証してみました。

 

検証内容としましては、日本郵便が配布している全国の郵便番号、住所等の

CSVファイルのデータを、INSERT、COPY、pg_bulkloadそれぞれを使用して投入する。

というものです。

月次バッチという想定で、既存データを一旦全削除してから、再投入します。

CSVファイルのデータは、

  • 15カラム
  • 122883レコード
  • だいたい15MBくらい

といった感じです。

 

測定用に作成したもの。

3種類のデータベースアクセスプログラム

  • INSERT用
  • COPY用
  • pg_bulkload用

データベースアクセスプログラムを使用したテストクラス

 

これを実行した結果がこちら。

bulkload_result.JPG

INSERTとCOPYでの差が激しいですが、pg_bulkloadはそれよりさらに高速に処理できています

というか、INSERTの処理遅いな。。。

データ量が多くなればかなりの差になり、かなり魅力的な数字になるのではないでしょうか。

そして、わざわざこんなことしなくても、オフィシャルページにもっと詳細な測定結果載ってるし!

という結果が得られました。

 

でおしまい。では切ないので、実際に使ってみた所感でも。

 

ほんとに早い。

 

いろいろな制約があるのである程度適用要件が限定される。

 

OSコマンドによるデータ投入なのでトランザクション制御が必要なケースでは別途考慮する必要がある。

実際今回の更新処理では、本来、削除、更新が1トランザクションであるべきところを

削除でトランザクションを閉じてしまっているので実際の運用には適用できない。

 

OSコマンドによるデータ投入なのでパラレルで大量のpg_bulkloadを実行する場合、

コネクション上限に達してしまいエラーとなる。別途制御が必要となる。

結構面倒だと思われる。 

 

PostgreSQLのパーティショニングには対応しないため、直接各テーブルへデータを投入する必要がある。

こうなると、PostgreSQLのパーティショニングをあきらめ自前で実装する必要がある為、結構面倒だと思われる。


といったところでしょうか。

かなりのトレードオフ具合ですが、どうしても必要な場面もありそうです。

 


Viewing all articles
Browse latest Browse all 4

Latest Images

Trending Articles





Latest Images