Tsurugi 1.0.0-BETA2について(commit levelの変更)

イマサラですが、明けましておめでとうございます。
本年もよろしくお願い致します。

さて、記事としては遅れてしまいましたが、内容はほぼDBTechShowcaseで話したβ2の内容とそのフォローになります。

β2のリリースノートはこちらになります。
https://github.com/project-tsurugi/tsurugidb/discussions/12
もうすぐβ3が出てしまうので、その前までにということで。

---

β2の主なポイントはメジャーバグの回収と機能追加、またcommit levelの変更になります。この記事ではcommit levelの変更について記述します。

β2よりデフォルトのcommit levelをavailableからstoredに変更しました。またにこれに伴いデフォルトのepoch timeを40msecから3msecに変更しています。

commit level がavailableの場合、トランザクションはcommitableとなった段階で、epoch終了時にまとめられ、commitとしてクライアントに返されます。また、同時にSSDへの書き込みが非同期で行われます。
storedでは、クライアントへのcommit backはさらにSSDへの書き込みが終わった段階で通知されます。availableではACIDが完全に保証されるわけではなく（遅延書き込みによる保証になります）、commit返却時にタイミングによってはデータロストの可能性がありましたが、このβ2では完全に永続化されます。
　
storedのcommit levelは、availableのそれに比べて、追加的に書き込み分の遅延が乗ることになるので、特にOCCでは遅延が大きくなります。
これはOCCのvalidationが極めて軽いためにepoch waitまでの時間に対して書き込み完了までの時間が相対的に大きいことによります。

これに対して、LTXではそもそも書き込み以前のcommit validationの時間コストが支配的であるためOCCほどの影響はありません。

availableとstoredの実行結果の差は以下になります。

TPC-C：NewOrder
Available：CB-TPC-C-Threads on:spr112 w:128 d:180 threads:all --v=30 tsurugi_config: #138
Stored：CB-TPC-C-Threads on:spr112 w:128 d:180 threads:all --v=30 tsurugi_config: #141

Storedになることで20-25%程度のパフォーマンス劣化が起きています。

次にbatch処理です。Tsurugiのベンチマークである原価計算処理になります。
Available
Benchmark-for-Publish on:spr112 #12

117.25%はavailableにおけるバッチとオンラインの混在時のバッチ側の劣化度合いです

Benchmark-for-Publish on:spr112 #14
Stored

storedでは、まずバッチだけについては、availableに対して109.2%程度の劣化です。

また、storedでのオンラインとバッチの混在についてのバッチの劣化は108.03%で、この時のavailableに対する劣化度合いは100.6%でほぼ劣化はありません。
バッチとオンラインの混在による劣化度合の変化は、92.1%程度に向上しています。（100.6%/109.2%）つまり、storedの場合は、より混在しているときの劣化度合いが軽減されています。

総じて、バッチ処理に対する劣化度合いは低いと言えるでしょう。

通常であればメモリーベースでcommitを返す処理に対して、永続化ベースでのcommitは相当の遅延が乗ります。これが軽減している理由は主にepoch timeの短縮によるものです。

epoch timeの短縮による影響は以下になっています。

Epoch

実線が基準となるavailable-40msのベースパフォーマンスです。
これに対してstoredでのepoch time を20ms→10ms→5ms→2.5ms→1msと短縮していくとパフォーマンスが向上し、最終的にはavailable-40msに近づいていきます。

この恩恵によりcommit levelをavailableからstoredに変更してもその追加遅延が最小限に軽減されることになっています。
なお、それだったらそもそもavailableでもepoch timeを短縮すればいいのでは？というアイデアもあるかと思いますが、残念ながら40ms→5msでもそれほどの恩恵はありません（なくはないですが、storedほどの大きなメリットはありません。commit timingの“乗り遅れ“のリカバリーが短縮される程度です。）

総じて、β2によるcommit levelの、availableからstoredへの変更はOCCの低遅延系の処理では2－3割の劣化、LTXのバッチ処理への劣化は10%以下、というのが現時点での状態です。
もちろん、これはワークロードによるので、正確なベンチマークが必要な場合は、それぞれの実際のワークロードで実行し、その結果を参照する必要があります。

なお、現在のH/W環境では超低遅延N/Wの遅延オーダーはSSDの書き込み遅延オーダーとほぼ同等ないしは、極めてcompetitiveな状況だと認識しています。よって、今後のTsurugiの分散処理ではこのstoredでのパフォーマンスが分散処理でのひとつの目標（できるかどうかはわかりませんが）になるとも考えられます。