概要
bathoryフレームワークとバッチアプリケーションの特徴
bathroyは、SAStrutsやTeedaでオンラインアプリケーションを開発するようにバッチアプリケーションを開発することを目標として作成されたバッチフレームワークです。
バッチアプリケーションは、オンラインアプリケーションと比べて処理対象データが巨大になる傾向があります。 そのため、バッチアプリケーションは、オンラインアプリケーションといくつかの点で相違があります。 以下に相違点とbathoryフレームワークがどのような問題点に対しての機能を用意しているかの紹介をします。
フェッチ戦略
ある条件に合致したデータを取得して、結果に対して一件ずつ処理を行っていくことを考えて見ましょう。 S2JDBCで書くと以下のようになると思います。
List<Employee> results = jdbcManager.from(Employee.class) .join("department") .where("id in (? , ?)", 11, 22) .orderBy("name") .getResultList(); for (Employee employee : results) { // do something }
ここで、resultsの件数を考えてください。 通常のオンラインアプリケーションだと多くても数百件オーダであることが大半です。
これがバッチアプリケーションでは、結果が数十万・数百万件となる場合があります。 バッチアプリケーションで、上記のようなコードを記述した場合以下の問題が起きます
- 全件フェッチしてからでないと処理が行えない。
- 全件フェッチするためOutOfMemoryErrorが発生する可能性がある。
bathoryでバッチアプリケーションを構築する場合は、上記問題を考慮する必要がありません。
トランザクションの戦略
オンラインアプリケーションは、1リクエストに対して1トランザクションとすることが多いと思います。 アクションやページの処理開始時にトランザクションを開始、正常終了ならコミット、異常終了ならロールバックしていると思います。
バッチアプリケーションでは、処理対象が大量データのため、もう少し複雑なトランザクションが必要になります。 以下のような機能を持つバッチアプリケーションを想像してください。
List<Employee> results = jdbcManager.from(Employee.class) .join("department") .where("id in (? , ?)", 11, 22) .orderBy("name") .getResultList(); for (Employee employee : results) { // 社員権限テーブルの更新(1) ・・・・・・・ // 社員テーブルの更新(2) ・・・・・・・ }
バッチアプリケーションは対象データが数百万件・処理時間は数時間かかる場合があります。 そのようなアプリケーションにて、最後1件の(2)部分でエラーとなった場合以下のような理由で単純なロールバックはできません。
- ロールバック実行に膨大な時間がかかる。
- 再入に再度数時間かかってしまう。
bathoryではバッチアプリケーション特有のトランザクションを実現するため、以下の機能を用意しています。 (&用意する予定です。)
- セーブポイント
- 分割コミット
- リトライ
- リラン
並列性の戦略
オンラインアプリケーションは、1リクエストに対して1スレッドを割り当て処理を行います。 バッチアプリケーションでマルチスレッドを使用して大量のデータを効率的に処理可能です。 bathoryでは、並列実行を容易に実現するための機能を用意しています。