劔""Tsurugi"（以下、Tsurugi）の最大の特長の一つがバッチ処理に強い、という点です。

以下、Tsurugiのターゲットベンチマークである(株)アンデルセン様の業務系のバッチ処理の内容・実行結果を見ながら、Tsurugiが実際にどの程度バッチに強いのか？どのようにこの処理を行っているのかを2回に分けて解説していきます。

まず、今回は「そもそもバッチ処理に強い」という点を見ていきます。

尚、このバッチ処理は詳細仕様・コード含めてOSSとしてTsurugiとともに10/5に公開されるので、実際に読者が手元の環境で実行し、また手を入れることも可能になっています。

原価計算バッチ処理の概要

以下のベンチマークは、一般のDBのベンチマーク・プログラムとは異なり、比較的「実際の業務に近い」つくりになっています。これは、Tsurugiで現実の業務系バッチ処理のワークロードを実行した場合、「実際のところどうなるのか？」を検証することが目的です。また、このバッチ処理は、今後のTsurugiの開発のクライテリアにもなっています。

実際の原価計算システムのバッチ処理の部分を可能な限りそのまま抜き出して実装しているため、ビジネス・ロジックは比較的複雑になっており、ユーザ企業の固有のロジックがそのまま実装されています。データモデル・テーブル数も、かなり簡略化したとはいえ、ビジネス・ロジックに手を入れるには、ある程度の業務知識（BOM）が前提になっています。

バッチ処理としては、製品の部品・原材料・中間品の構成を木構造で表したデータ群について、全体あるいは個別に設定された製品群の各製品の原価および所要量を計算します。大規模かつ複雑な木構造について、full scan または range scan を行いつつ、再帰的にトラバースし、結合処理を行って行きます。

一般に、木構造を再帰的にトラバースし結合処理を行う処理は、RDBでは時間のかかる処理の代表例になります。加えて、業務系のバッチ処理であるため一貫性担保が重要です。

このため、通常は、この種の木構造のトラバースのバッチ処理の最中は、構成データの更新は行いません。データを引き抜いで別計算を行うことが通例です。実際、アンデルセン様においても同様の運用になっています。

Tsurugiでは、この「木構造の再帰的トラバースによる集計」と「木構造の構成部品データの更新」を「高いパフォーマンスを維持し、一貫性を保ちつつ、同時に行うこと」ができます。

処理概要

1、メインのバッチ処理
処理対象品目に対し、品目構成マスターを再帰的に走査し、原料となる子孫品目を全て取得し、木構造データを作成し、その木構造を再帰的に取得することで、各品目の重量・所要量・原価計算を実行する。計算結果を結果テーブルに書き込む。

2．構成部品のデータおよび部品構成自体の変更（更新・新規追加）を、1の処理の最中に継続して行う。2-1新商品の追加：新規の商品を追加して、木構造を変更する(new-item)
2-2．生産数の変更：製造品目マスターの要素を変更する(update-manufacturing)
2-3．原材料の変更：品目構成マスターの構成を変更し、木構造を変更する(update-material)
2-4．在庫の増減による原価変更：原価マスターを変更し、木構造の要素の値の変更する(update-cost-add/ update-cost-sub)
2-5．照会処理（重量:show-weight・所要量:show-quantity・原価:show-cost）：計算結果を照会する

3 オンラインバッチ処理
追加的に集計バッチ処理を行う（在庫履歴作成）。原価マスターをトラバースして、実績のコピーを行う。
メインのバッチ処理を行っている最中に実行する。(update-stock)

原価計算処理詳細

・ER

テーブルサイズ：対象処理のテーブルのサイズは以下です。

ほぼ 6 千万件のマスターデータを参照・結合のトラバースをしながら、4千万件の結果を書き込むバッチ処理になります。

・実行環境
CPU：Intel(R) Xeon(R) Platinum 8480+ × 2（112 コア）
Memory: DDR5-4800 64GB × 16 (Total 1TB)
DISK: INTEL SSDPE2KX010T8 NVMe 1TB SSD

・実行結果
実行結果は以下になります。

A）単独でのバッチ処理：1 のメインのバッチ処理のみを実行します。
バッチの処理時間の終了までの実行時間を計測します。

B）単独でのオンライン処理：2 および 3 の処理のみを実行します。
各オンライン処理・オンラインバッチ処理の遅延時間を計測します。（固定時間内：1700s）

C）1 のメインのバッチ処理を実行し、実行中に 2 と 3 のオンライン処理を可能な限り投入します。
投入結果を A）と比較し、どの程度バッチ処理・オンライン処理が劣化したか、評価します。

・バッチ処理

A の単独実行に比べて、C のバッチとオンラインでの混在実行での、バッチの実行時間の延長は 101%ですので、 ほぼ劣化はなしです。
つまりオンラインと混在させても、特にバッチ側には問題は発生していません。

・オンライン処理の比較

オンライン処理の劣化は、ほぼ平均が 105%-120%の中に収まっています。

オンライン処理において、通信処理 の遅延が遅延コストについて支配的である場合は、ほぼ影響のない範囲に収めることが可能なレベルです。

Tsurugi においては、従来のようにオンライン処理をとめてバッチ処理を行う、という配慮をする必要はありません。なんらかの業務的な必要性がある場合を除き、夜間バッチのようにわざわざバッチウインドウを開けて、 重たい処理を流すという DB の運用を行うことも回避できるでしょう。

ただし、これはそれなりのサーバ・パワーがあることが前提です。
また軽微とはいえ、オンライン側でも遅延の影響はでます。したがって、バッチとオンラインの完全同時実行はある程度運用テストをおこなった上での実 施が望ましいと言えます。

リソースが必要であるとはいえ、Tsurugi を利用することで、バッチ自体のかなりのスピードで終わることや、 バッチの処理中にオンライン処理を挟み込めることができます。従来のシステムの運用・あり方を大きく変えることが可能になるでしょう。

▽後編はコチラから

※※※お知らせ※※※

次世代高速RDB 劔"Tsurugi" のオープンソース版のリリース日が、
2023年10月5日に決定しました！

また、日経BP社より発売される 劔"Tsurugi" 解説本の発売日も10月5日に決定しました！

600Pにわたり、劔"Tsurugi"の利用法、バッチ処理の実際から始まり、
劔"Tsurugi"のインターフェースのすべて、内部構造や実装アルゴリズムの詳細まで解説しています。

また、東京、札幌、福岡で、OSS版リリース記念イベントの開催も決定しました！

詳しくは、劔"Tsurugi"コミュニティサイト をご覧ください。