OCCとLTX
Tsurugiのトランザクション処理は、同時に複数（二つ）のアルゴリズムが動き、それぞれで整合性とりつつ、かつ同時に動かしても整合性をとる、というHybrid Concurrency Controlの仕組みを採用しています。
一つはOCCと呼ばれる軽量のアルゴリズム、他方はLTXと呼ばれる比較的重量級のアルゴリズムです。
この両者のOCCとLTXの「違い」はどういうものなのか？を知ることが、Tsurugiをうまく使う上での重要なポイントになります。
それぞれのトランザクションを投入するときには、このOCCとLTXのどちらかを選択する必要があります。通常なにも選択をしない場合はデフォルトでOCCでキックされる設定になっています。
なお、このドキュメントでは、両者の内容は簡単な紹介にとどめています。詳細については、書籍の方を参照してください。
◆OCCとLTXでは対応しているワークロードが違う
あまりの負荷のない状態や単発のSQLの発行等であれば、OCCとLTXでは挙動の違いはありますが、パフォーマンスについてはそれほど差がありません。テスト的に動かすのであれば、意図的に違いが出るようなSQLを実行しない限り、どちらを選んでも問題はないでしょう。
違いが出てくるのは、高負荷の処理や同時並行的に多数の処理を行った場合です。
端的に言えばOCCは比較的軽い単純なSQLをオンライン的にどんどん投げ込んでいくワークロードを想定し、LTXはバッチ処理のような重たい処理でSQLの「カタマリ」のような処理を実行するワークロードを想定しています。そのため、各トランザクションに対して、OCC/LTXのどちらを選ぶかで全体のパフォーマンスが変わって来ます。
・OCCは楽観ロック
OCCは楽観ロックを利用して、最小手順で一貫性を担保している、極めて軽いアルゴリズムです。おそらく数あるトランザクションのアルゴリズムの中で、メカニズムが最小のものになるでしょう。
内容は、単純に「自分の読んだreadの上書き(over-writer)があればabortする」だけです。“楽観ロック”なので“ロックを取ったふり”をします。他のトランザクションにより自分のreadが壊れていればトランザクションの失敗をさせてretryしましょう、という仕組みです。（ただしretryは自分で実行する必要があります。）なお、read対象は最新のコミット済み（pre committed）のversionを読みます。
・LTXは正統派MVCC
対して、LTXは「自分の読んだreadの上書き（over-writer）があれば、自分自身の論理順序を適当に操作して、なんとか一貫性を保つように論理空間を探査する」仕組みです。この探査の計算手順は、まぁまぁ複雑なアルゴリズムなので、詳細は書籍の方を参照してください。
読んでいるversionとは異なるversionの書き込みを許すため、Multi-version Concurrency Control（MVCC）と呼ばれているアルゴリズムになります。なお、read対象はconflictを低減させるため、開始時点のepoch単位で作られる最新のsnapshotとなります。
OCCは軽さ勝負で、あまり深く考えずにダメならそうそうギブアップして、もう一回挑戦する、というスタイルで、LTXはそうそう簡単にはギブアップせずに多少コストをかけてもベストを探査しましょう、というやり方になっています。つまり、単純にすばやく終わる処理はOCCで、他方、重くてそうそう簡単にギブアップできないバッチ処理のようなものはLTXで、ということになります。
◆実際にどの程度のパフォーマンスの違いがあるか？
では実際のところ、軽量なOCCと重装備のLTXではどの程度の差があるのか？を見て行きましょう。
アルゴリズム的な計算ステップの違いは、両者ともにover-writerを認識するところまでは一緒ですが、LTXはそのあとに順序探査とwriteサイドからのvalidationも入るため、ロジカルな手続きとしてはOCCの5倍程度のコストがかかっていると見て妥当でしょう。とはいえ、実装上は様々な最適化を行うため、両者の差は実際に計測してみないとなんとも言えません。
以下に、Tsurugiの開発で実行されているベンチマークでの結果を見てみます。
・read
まずreadだけでの違いを見ます。
OCCはreadは即時に実行されますが、LTXは対象となるデータセットのアラインメントを揃えるため一旦ステージングされてから実行されます。OCCとLTXのreadの差はこの違いによります。
競合のwriteがないワークロードでの純粋なreadのプロトコルの違いだけでのパフォーマンスの影響を見ましょう。
単純なSELECTでのパフォーマンス比較です。おなじく32スレッドで実行しています。対象データ件数は2000万件程度です。
point readでOCCはLTXに対して5倍弱のパフォーマンスの差です。
これは単純にOCCが即時pre commitのversionをアサインできるのに対して、LTXが対象のsnapshotをそろえるためのステージングにかかる時間の差だと思われます。なお、現在のところはepochの間隔（epoch period）が40msecに設定されているので、この差が顕著ですが、epoch periodが短くなるとこの差は少なくなると推定されます。
また、range scanでは、同等ないしは場合によってはLTXの方が高速です。
これはrange scanがpoint readに比べて場合によっては10倍以上の時間がかかり、プロトコルの実行コストよりも scanのコストが支配的なため、OCCとLTXの違いがほぼなくなっていることによります。
・write
Validationのコストがもっともかかる、すなわちアルゴリズムの軽重の差が顕著にでるのがwriteになります。
単純なINSERTとUPDATEのパフォーマンス比較です。データサイズは200byte程度でkey長は複合8byteです。それぞれ、32スレッドで60秒の実行結果です。なお、INSERTは純粋に性能を図るためにkeyの競合がないことを保証して（ただCC上は必ず一意制約確認が入ります）実行しています。
・バッチ処理
次に実際の大規模バッチ処理での違いを見てみましょう。
ただし、実行としてOCC・LTXともにオンラインからの競合の一切ない状態での単一処理の実行結果になります。これも32スレッドで実行しています。Tsurugiの公式ベンチマークである。原価計算バッチ処理を実行しています。
CB-Large-on-spr112 on:spr112 #122
cost-accounting-benchmark - large10
対象データです。
OCCに対してLTXは1.5倍程度のオーバーヘッドがかかっています。単純な低遅延の処理と比べて、データサイズや実行時間の大きな処理になるとOCCとLTXの実行アルゴリズムのコストの差は小さくなっていきます。
◆現在のところはOCCとLTXは実質的に4-5倍程度の実行性能の差がある。
上記の結果は、あくまでTsurugiの開発におけるベンチマークの結果なので、実際のシステムの実行時の結果とは異なることが多いと思われます。
ただし、純粋なベンチマークの結果として、低遅延な小さな処理では、OCCとLTXは概ね4-5倍程度のコスト差がある、ということは抑えておいて方がいいかもしません。アルゴリズムのステップの複雑さから見ても妥当と言えます。
よってまず、基本的なOCCとLTXの選択戦略は、まず基本は、ベースコストの安いOCCになります。
ただしワークロードのconflictが嵩んでくるとOCCはabort率が上昇し、結果として、retryまで含めた成功までのレイテンシーが増大し、スループットも悪化します。この時はLTXを選択していくことが無難でしょう。
なお、TsurugiのJava の外部インターフェース・ライブラリであるIceaxeは、abort/retryの手法選択も含めて柔軟にトランザクションの挙動をコントロールすることが可能です。積極的に利用してことが望ましいです。
また、abortのコストがあからさまに高いバッチ処理のようなものは、最初からLTXでトランザクションを開始したほうが無難です。
バッチとオンラインの中間のような「やや重めのオンライン」は迷うところではありますが、いずれにしろ実際のワークロードのテスト実行が欠かせません。その結果を見た上で、OCCからretryの状況をみてLTXにスイッチするか、OCCのままretryを重ねるかの処理の選択を行うか、または最初からLTXでキックするかを検討していった方がいいかもしれません。
大事なことは、OCCとLTXではベースパフォーマンスが違うということと、そのコストとメリットを理解しておくことです。この選択を間違えただけでTsurugiのパフォーマンスは4-5倍以上に簡単にかわってしまうということになります。
次世代高速RDB 劔"Tsurugi" は現在オープンソースで公開中です。
概要やダウンロードは、劔"Tsurugi"コミュニティサイトをご覧ください。
▽劔"Tsurugi"コミュニティサイト
▽劔"Tsurugi"の解説本も日経BPより発売中です。https://www.amazon.co.jp/dp/4296203231/
是非ご活用ください。
この記事が気に入ったらサポートをしてみませんか？