劔"Tsurugi"最大の特徴である以下の点を活かし、業務バッチ処理の考え方を大きく変えます。
- ロックを取らずに、インメモリー・コアで分散する処理を実行する
- バッチ実行中にオンライン処理を行っても劣化を抑えて処理を実行できる
これらの特徴から、業務バッチ処理の高速化と、バッチ処理中でもオンライン処理が実行することが可能になります。具体的には、バッチ処理を実行しているときに、その処理中のデータを変更しても一貫性を失わず、バッチ処理と変更が同時に動いて正しい結果が得られる、ということが可能になります。
原価計算バッチの高速化：
これを実証するために、株式会社アンデルセンサービスのデータの原価計算バッチ処理を劔"Tsurugi"で高速化する実証を行いました。
（この実証に関しては、劔"Tsurugi"の公式解説本 に詳細を記載しています）
この原価計算のバッチ処理は、BOM（Bill of Material）で、製品品目管理のマスタデータの更新と、全品目の積み上げ計算を行うものです。
本実証では、この原価計算のバッチ処理に加えて、日々のオンライン処理を同時に実行してみる、というものになります。
図：木構造のバッチ処理
この"日々のオンライン処理"とは、BOMの木構造に対して、木構造自体を変更する（新商品の追加・原材料変更・生産数の変更）ものと、木構造の変更を受けた原価変更・在庫変動の計算をするもの、バッチ処理中に行う検索（商品の原価を調べる、など）といったようなものを指します。
要するにバッチ処理中にバッチ内で使われているデータを変更したり、データを検索したりすることです。
図：実証バッチの全体像
従来のデータベースでは、バッチ処理中はデータの変更ができないようにロックをかけて、データの変更ができないようにしたり、処理を後回しにしてバッチを優先するような動きをします。
劔"Tsurugi"では、このバッチ処理とオンライン処理をロックフリーで同時に動かして、なおかつ、データ一貫性を担保する、さらには、処理速度がそれほど劣化しない、という特徴があります。これを実証しました。
実証の結果：
本実証では、もともとの原価計算のデータを大幅に増やして実証を行っています。
おおよそ3億件のデータ構成される木構造のデータを全部読み込んで原価計算のバッチ処理を行いながら、その木構造自体の改変を行います。同時に、構成を計算して2億件の書き込みを行いました
表：原価計算のデータ概要
バッチ処理自体は、製品ごとに繰り返し木構造をたどって積み上げ計算をしていく形になるので、木構造内の品目や品目構成のマスタデータの変更を行うことは、積み上げ計算と衝突することになります。これをロックフリーの劔"Tsurugi"で実行しています。
バッチ処理中に実行する木構造を変更するオンライン処理は、新商品の追加・原材料変更・生産数変更です。これらを同時実行した際に、バッチ処理がどのくらい劣化したのかをを示します。
上記の表から、下記の結果がわかります。
- バッチ処理をそのまま実行した結果：87分
- オンライン処理を併存したバッチ処理：98分
およそ、バッチ処理中にオンライン処理が行われても、11％程度の劣化しか起こっていないことがわかります。
一方で、バッチ処理中に、オンライン処理がどのくらい劣化したのかを下記の表で示します。
まずは、上の3つです。
木構造自体の変更：新商品の追加・原材料変更・生産数変更のオンライン処理の結果、以下の通り、オンライン処理が成功しています。
劣化度合いは、110〜78％で、パフォーマンスが向上している部分もありました。
- new-item（新商品追加） 28件成功
- update-manufacturing（生産数の変更） 300万件成功
- update-material(原材料の変更) 300万件成功
次に、下の2つです。木構造の変更を受けてのオンライン計算：原価変更・在庫変動のオンライ処理の結果は、以下の通り、オンライン処理が成功しています。
劣化度合いは、ほぼ0%で少し向上しているような結果となっています。
- update-cost-add(在庫増加/原価変更） 948件成功
- update-cost-sub(在庫減少/原価変更） 936件成功
先に述べたように、従来のデータベースでは、バッチ処理中に木構造を変更するようなオンライン処理は、データベースがロックをとるために行うことはできません。
劔"Tsurugi"はロックフリーなので、バッチ処理中でもオンライン処理が実行でき、かつ、それほど性能が劣化せずに処理が実行できます。この特徴から、バッチ処理のこれまでの常識が大きく変わることがわかります。
業務バッチでの劔"Tsurugi"の活用：
今まで、バッチ処理はシステムが使われていない時間帯に行って、なるべく、業務中の利用を妨げないように考えられてきました。夜間の間にバッチ処理に関連するトラブルも含めてすべて対応する前提で、システム構築・運用が行われていました。
劔"Tsurugi"を利用することで、以下のような可能性が広がります。
- バッチ処理の高速化が行われる
○ 夜間でなくてもバッチ処理が実行できる
○ バッチのリトライの負荷が極小化される - バッチ処理とオンライン処理が同時に行える
○ 業務時間帯でもバッチ処理が実行できる
これまでのバッチ処理の常識とてしては、"システムを誰も使っていない夜間に、システム担当者がこっそり片付けておき、業務に迷惑をかけない。
そのための必要なコストはかけていく"というものでした。
これを劔"Tsurugi"では大きく覆すことが可能です。
例えば、"バッチ処理実行の回数を増やして（業務時間中にもバッチ処理を実行する）、実績を短いスパンで確認できるようにする"、"保守体制の再検討を行いシステムの運用コストを下げる"など、これまでとは考え方を変えて、バッチ処理と向き合うことを可能にします。