始めに
db tech showcase Tokyo 2018 (db tech showcase Tokyo 2018 | db tech showcase)
今後のDBのトランザクション処理のあり方について徹底討議する ～"InvisibleWriteRule: トランザクションの書込み最適化" を中心に
にパネラーとして参加してきました。その記録を残します。
きっかけ
きっかけは神林さんからの Twitter DM でした。それまでは私から神林さんを一方的に存じ上げているだけでしたので、神林さんから DM が来た時には何事かと、以前にまとめた記事（急がば回れ、選ぶなら近道 TX記事 読解メモ - ぱと隊長日誌）のことで何かお叱りを受けるのではないかと、ビクビクしていました。
実際には今回の討論会に参加しないか、とのお誘いでした。それにしても人違いではないかと心配していたのですが、人違いではないし、トランザクションに興味があって勉強していれば十分とのお言葉があり、せっかくのチャンスに乗ろうと決意しました。
伝えたかったこと
今回のパネルで話せたこと、話せなかったことも含め、私の意見をまとめておきます。
引用及びリンクは参考にした資料や記事などです。
InvisibleWriteRule (IWR) の説明で用いられたスライドです（ただし、多少中身の異なる点があります）。
IWR はスライドで補足されている通り、UPDATEでしか有効とならない。だが、競合の発生率が低い場合でも性能が向上している。なので、適したワークロードの範囲は広いとみている。
スライドには Update-Heavy な例として Database for Sensor Network が挙げられている。これが適用される分野としてIoTが思い浮かぶ。センサーのデータは残す(INSERT)ケースが多いのではと思っていたが、実例を見ていると捨てている(UPDATE)ケースもある模様。こういうアプリケーションであれば向いているのではないか。
また、神林さんが触れていたようにステータス管理等ではとてもマッチするはず。
また1工場あたり1日のデータ量がペタバイトクラスになるデータのほとんどは蓄積していない。インテルはデータ分析をエッジ部で実行し、そのPC が製造装置を監視し、装置の正常稼働状態が維持できていることを確保している。すべてが正常と判断されれば、データ蓄積は行わない。ただ統計的工程管理（SPC）の目的用途としてのみこれに要するデータを残している。
工場への機械学習・AI 導入の9ステップ－インテルIoT ワークショップ報告（2） | ARC Advisory Group
one-shot request はストアドプロシージャをイメージするとよい。リクエストをまとめて投げて、レスポンスをまとめて受け取る。これまでのインタラクティブな（SELECTを投げてその結果に応じてUPDATEするような）実装が変わってくるはず。ただ、変化を受け入れない現場が想像以上に多い中で受け入れられるか？
トランザクション分離レベルを開発者が意識し、それを適切に扱うのはやはり困難ではないか。Serializable がデフォルトで、それでもパフォーマンスが出るような時代が来てほしい。
セッションの最後に中園さんがそういう未来を目指しているとお話ししてくれたことは本当にうれしい。
A critique of ansi sql isolation levels 解説公開用
- 「世の中一般にはserializableは遅いので使うな」という言い方がされることがあるが、DB屋的にはこれは普通に屈辱（のはず。）
- lockレスで、そのまま放り込めば、concurrentなままserializableなスケジュールを組みあげるというのが、最適な実装。
現実的なアプリケーションのパフォーマンスをどう測定すべきか？今のメジャーなベンチマークが現実に即していないとするならば、何を持ってすれば測れるのか？ベンチマーク最適な研究が進んでしまったりしないか？
ベンチマークスペシャル - nikezono
理論の段階からロングトランザクションへの考慮をしてほしい。アボートした時のペナルティが大きすぎる。かといって、アプリが合わせに行く、例えばトランザクションの粒度を小さくして、自力でリカバリ処理を行うというやり方は本末転倒だと思う。
long transactionはWeb Serviceで一度注目されたけれど、トランザクションの先端技術では常にわき役。ただ、研究レベルはもう少し実世界の要求を学ぶべきだと思うし、逆に、実務家は研究レベルで何が問題でどう解決しようと考えているか方向性を理解すべきだと思う。
— Masayoshi Hagiwara (@masayh) 2018年9月19日
Abort rate は数字の大小よりその中身が重要だと思う。ロングトランザクションを犠牲にしてショートトランザクションをバンバン流せば Abort rate は見かけ上よくなる。でも、それが評価として正しいとは思えない。
Fariness の研究が進むことに期待したい。
我々のような開発者やDBAも、DB研究がどのような方向に進み、5年後か10年後かそれ以上先かもしれないが、どんな形で商用化されるかをイメージし、そこに備えておく必要がある。
参加してどうだったか
今回求められていたポジションは現場で活躍されているDBAの皆様と同じ目線でコメントしてほしいとのことでした。とはいえ、理論について議論しているところに現場の話を持ってくるというのは中々に難しく、前半は苦しいコメントとなってしまいました。
後半は若干開き直り、多少テーマを外れても好きにしゃべることにしました。「（理論の）現状の問題点」を「現場の現状の問題点」に言い換えてしゃべったときはさすがにまずいかと冷や汗かいていましたが、隣にいた神林さんがウンウンとうなずきつつ、それでいい、とつぶやいてくださり、ホッとしました。
現場とつなぐ、という意味で初見ではわかりにくいところを補足できればよかったな、というのが反省点です。例えば、 R∞設定 とか one-shot request とか、いきなり言われてもよくわからないですよね。間違った解説をしても周囲がプロなので速攻訂正されたでしょうし、やってみてもよかったなと思っています。
慣れてきた後半はリスナーの方の様子を見ながら話していたのですが、うなずきながら聞いてくれる方のありがたさをひしひしと感じました。分かってくれる方もいるんだ、と思うだけで不安とか緊張がかなり解消されました。
スピーカーの皆さんのすごさ
論文の読み解き方
私のレベルでも字面を追って理解した気にはなれます。ですが、スピーカーの皆さんのレベルになると、その記述に込められた意味まで的確にくみ取っていました。その具体例が神林さんのブログ（急がば回れ、選ぶなら近道）なり発表に現れています。
関連研究の知識の広さと深さ
手法の議論をする際にあれと一緒だよね、でお互いに伝わっていました。
そして、知らないことは知らないといえること、それに対して教え合う姿勢があることも素敵でした。誰もググれなんていいません。その打ち合わせに臨む以上、準備はしてきているはずだし、それで知らないのであれば教え合おう、という雰囲気があったように感じました。
課題への取り組み方
事前打ち合わせを2回実施しましたが、1回目での課題をそのまま次回へ持ち越す事はありえませんでした。それまでに課題に対して調査と検討を行い、自分なりの答えを持って次回に臨まれていました。
当たり前のことかもしれませんが、中々できないことではないかと。
最後に
お誘いを受けた時は自分の力量不足に自覚があり、迷惑をかけるのではないかと悩みましたが、今となっては参加できて本当に良かったです。
特によかったのが、トランザクションに興味を持つ方のコミュニティに参加できたということです。今まではわからないことを延々と悩んでいましたが、考え抜いてもわからなかったことを相談できる、というのは大変ありがたいことでした。
参加するにあたり、自分の知識・経験不足を言い訳にしないことを決めていました。それは甘えでしかありません。それよりも、セッションが終わるその瞬間まで、自分がやれる精一杯のことをやるべきだと考えていました。それを貫き通せたことは自信にもつながりました。
今後も、研究と実務の間の橋渡し役として、微力ながら貢献させていただきます。
