多くのINSERTとbyteaの更新のためにPostgreSQLを最適化する
私たちが持っているもの（ソフトウェア）：
- PostrgeSQL 9.基本構成あり（
postgresql.confは変更なし） - Windows 7 64ビット
ハードウェア：
- インテルCore i7-3770 3.9 Ghz
- 32 Gb RAM
- WDC WD10EZRX-00L4HBAtaドライブ（1000Gb、SATA III）
したがって、DB aproxにロードする必要があります。 100.000.0行にbytea列があり、さらに単純な500.000.0行（LOBなし）。 1番目のテーブルには2つのvarcharインデックスがあり（13、19の長さ）、2番目のテーブルには2つのvarcharインデックスがあります（18、10の長さ）。各テーブルのID生成のシーケンスもあります。
現在、これらの操作は、JDBCバッチサイズ50と並行して8つの接続で行われています。次の図は、システム負荷を示しています。これは、postgresqlプロセスでのゼロ負荷です。 24時間の読み込み後、1万行のみを読み込みましたが、これは非常に遅い結果です。
以下の目的でPostrgreSQL構成をチューニングするための支援を求めています。
1）この量のデータを超高速でロードする場合、これは1回のみの操作であるため、一時的な構成になる可能性があります。
2）結合やソートを行わずに、インデックスによってこれら2つのテーブルに適度な数のSELECTを実行するプロダクションモードの場合。
insertパフォーマンスについては、 PostgreSQLでの挿入パフォーマンスの高速化 および PostgreSQLでの一括挿入 を参照してください。
insertのJDBCバッチ処理で時間を無駄にしています。 PgJDBCはinsertバッチでは有用なことを何も行わず、各ステートメントを実行するだけです 。
代わりにCOPYを使用してください。 PgJDBCバッチコピー および CopyManager を参照してください。同時ローダーの数については、操作がディスクI/Oに制限されている場合は、ディスクごとに2つのローダーを目指します。おそらく8が最も望ましいでしょう。
「本番モード」の場合は、データのサンプルを読み込み、実行する予定のクエリを設定し、explain analyzeを使用してパフォーマンスを調査することをお勧めします。テスト目的でのみ、enable_ paramsを使用して、さまざまなプランの選択を調査します。クエリプランナーのコストパラメータ（random_page_cost、seq_page_cost、effective_cache_sizeなど）をシステムに適切に設定し、shared_buffersが適切に設定されていることを確認します。 auto_explainモジュール、log_min_duration_statement設定、pg_stat_statements拡張などを使用して、シミュレートされた本番ワークロードを追加しながら、引き続き監視します。
詳細については、PostgreSQLのユーザーマニュアルを参照してください。 explain analyzeクエリの実行の詳細などで、より具体的な問題が発生した場合は、ここに戻ることをお勧めします。