- 開発技術
処理データ量の多いバッチPGの考え方
- SQL
処理データ量の多いバッチPGの考え方
【エンジニア募集中】フルリモート可◎、売上/従業員数9年連続UP、平均残業8時間、有給取得率90%、年休124日以上 etc. 詳細はこちらから>
一般的な業務システムのバッチ処理を開発する時に、データに対する処理はSQLで一括取得して、プログラム内で繰り返しながら処理をしている場合が多いでしょう。ですが、大量なデータを扱うシステムの場合も同じでしょうか?
一般的なバッチPGの作り方
バッチ処理では大まかにデータ入力>データ編集>データ出力と3つの工程に分類することができます。
①データ入力では、ファイルやDBからデータを入力しています。
②データ編集では、入力したデータをメモリ内に保持しプログラムでループしながら編集しています。
③データ出力では、編集したデータをファイルやDBに出力しています。
また、障害発生時は再実行などをしているでしょう。
データ量の多いバッチPGが優先的に考えるべきこと
・処理時間の短縮化
※大量のデータをまとめて処理することで処理時間を短縮します。
・障害発生時のリラン方法
※大量データを処理するにあたって、入力データが異常な場合や、システム自体に異常が発生した場合の防御策を考えておく必要があります。
データ量の多いバッチPGの開発方針
・インプットファイルをDBへ登録時、DBのインポート機能を使います。
例えばOracleの場合はSQL Loaderを、SQL SEVERの場合はBCPを使います。
・DBデータをファイルに出力時も、DBのエクスポート機能を使います。
・一時テーブルを作ったりして、データ加工の中間データもDB内に保存します。
・トランザクションを小さく短くして、処理速度向上を図ります。
・一定量のデータをまとめて処理して、処理時間を短縮します。
・できるだけSQLで処理を行い、メモリ使用量を減らします。
・ストアドプロシージャを活用して、処理速度向上を図ります。
・適切なインデックスを作成して、SQLの性能を向上させます。
・処理途中でエラーや異常が発生しても、可能な限り処理を継続させます。
※例えば、エラーデータにフラグを立てて、スキップしながら次のデータを処理するなど
【エンジニア募集中】フルリモートも◎(リモート率85.7%)、平均残業8時間、年休124日以上、有給取得率90% etc. 詳細はこちらから>