無料の「Oracle Database XE」で高速バッチ処理：実装のポイント

1. バッチ処理実装時のポイント

　第2回の記事「バッチ処理でデータベース活用：4つの課題と5つの解決ポイント」では、バッチ処理について共通理解を得るために、その特徴を説明しました。今回はバッチ処理を実装する際のポイントを説明します。

1-1. コンポーネント化

　第2回の説明でコンポーネント化を検討してくださいと書きましたが、ここではその具体的な方法について説明します。

　バッチ・アプリケーションの主な処理内容は大まかに言うと「入力」→「加工」→「出力」です。こう考えると非常にシンプルですよね。この抽象化した処理をコンポーネントとして用意すれば良いのです。

　先ほどの処理をもう少しブレークダウンすると次のようになります。

　これらのコンポーネントを用意できると、大概のバッチ処理はコンポーネントの組み合わせで実装することができますので、生産効率やメンテナンス性が飛躍的に向上します。

1-2. 処理はOracleで

　これでコンポーネント化のメリットを理解できたと思います。では、再利用性が高く効率の良いコンポーネントを用意するためにはどうしたら良いでしょうか。

　その近道に、データベースで処理するコンポーネントがあります。

　以前も述べましたが、現在のOracleデータベースにはデータ加工に利用できる様々な機能が実装されています。またデータベース・サーバーには高性能なハードウェアを用意していることが多いため、処理性能の向上も期待できますし、リソースを活用できることはROIの向上にも繋がります。

　テキストファイルなどの外部データが入力データの場合、まずはOracleにそのままの状態でローディングします。ローディングにはOracle純正のユーティリティであるSQL*Loaderや外部表を使うことで高速にデータの取り込みができます。ETLサーバーなどでローディングする場合とは比較にならないほど高速に取り込むことができますし、Oracleに付属する無料のツールもしくは機能ですので是非活用しましょう。

1-3. 例外処理もシンプルに

　現在稼働中のバッチ処理はタイトなスケジュールで運用されていることが多いため、エラーなどが発生して処理の途中で停止する場合には、なるべく時間をムダにしないためにリカバリするよう設計されています。つまり正常に処理したところまでは再実行せず、エラーが発生した直前から処理を再開できるような仕組みを考えているのです。

　しかし、そのような仕組みでは処理が複雑になり実装コストも膨らみます。さらにリカバリポイントを細かく設定することで、トータルの処理時間は当然のように遅くなります。

　今までは常識のように考えられ、実装されてきた例外処理の部分を大胆に見直してみましょう。

　エラーが発生したバッチ処理は、単純に再実行するというシンプルな考え方で実装できればコストが抑えられますし、運用もとても簡単になります。

　当然、既存の処理は単純に再実行できる単位に分解する必要がありますが、バッチ処理の再構築ではこの部分の設計も重要なポイントとなります。