大体20msecがepochだとして、5minバッチだと、15000epoch。こんなdurationで処理が継続するとはSILOは想定しない。物理GCクラスでの単位になる。epoch跨ぎをどうするか、それも複数跨ぎになるが、というのはちょっと問題としては大きい。これは既存のSILOの枠組みを超えるものになる。端的に言えば、epochをまたぐバッチ処理中のread/writeとepochの中に閉じているtxとの整合性をどうするか?という問題にある。普通に考えれば問題は山積。-read上書きの処理。普通にロングバッチ処理中に読んだ値が、どんどんconcurrentに更新される。こっちはepoch跨ぎなので、バッチ処理より先にcommitされる。orderを後ろに持ってくることはできないので、簡単に詰む。違う枠組みを導入しないと無理。-writeバッチの処理中でのwriteを読んだconcurentなtxが先コミットになる。semanticsの維持が面倒。orderで逆順であれば、さすがに打つ手がない。orderが前にくることが強制になるので、これも詰む。read/writeの両者で手が詰む。現在のところのアイデアとしては、readについては従来と違う枠組みを考える必要がある、一応ベースになるアイデアはあるので検討中。orderが整合できないtxには読ませない、というプロトコルで対応する。いうことでいろいろ検討中というのが目下の状況。いずれにしてもSILO-OCCのようなシンプルに物理で殴るという方法ではなく、ある程度テクニカルな仕組みを理論的な枠組みから構築していくという方向になる。要するにAsakusa以前に、そもそもバッチ的処理をRDB(OLTP)で行う、ということのハードルが高く、そのための準備がかなり前人未到系になっているという感じだ。これは従来のRDBでも同じ問題はあって、MVCCよりも制約が強い既存の1VベースRDBではほぼ絶望的だと思う。heavyなバッチ処理は実装以前の話として、理論的な枠組みからして無理だろうな、というのが今の実感。)今後の検討課題は以下-serialzation空間としてはMVSRを前提にする。個人的にはMVSRを目標とする。まともに行くとNP-完全なので、どういう制約をうまく利用するか?になると思う。時代の流れもこちらを向いている。protocol基本3層protocolの構成をベースに検討。recently程度の理論・実装しかない。onlyが関の山なので、こちらも普通にいろいろ検討する必要がある。protocolだけなので、それではもうダメです。commitを利用する方針で、その拡張を行う。orderは明確に分ける。committedなものが発生するということになる。committedのみだと思う。-実装物理レイヤーこれは弊社および某Prjの超絶優秀なエンジニア諸氏にまずはお任せするしかないので、初手から「一番いいやつを頼む」としか言えない。線形リストはもうダメな気がする。すんません、実装とか全部入りで最初から考えてたら、とても精神がもたないので、まじで勘弁してください。その上で以上が揃った上で初めて、AsakusaをOLTP上で動かす、ということを検討する、という段になる。いやー、なかなか遠大な道のりだが、そんなもんだ。見ようによっては「たかだか、RDBでちゃんとバッチ動かします」ぐらいの話でしかないのだが。その上でのAskausaの話だ。Asakusaは現在のところ、できてほぼ10年近くになるが、いまだに「業務系の複雑な処理を、SIを前提にして、分散処理環境で効率的に設計・実装・実行するフレーワーク」はAsakusa以外に存在しない。その意味では存在意義はあると思っている。実績・完成度もある上にOSSなので、これから別の商用プロダクトができるとは思えない。今後10年もその意義は続くだろう。検討すべき価値が十分にあると個人的には思っている。その意味ではかなり迂遠は道のりであるが、そのOLTPの上でのバッチ処理→Asakusaの検討はありうると思っている。なんかもっといろいろ別物になるくらいの勢いになると思う。Tx制御はもちろん、なんやらいろいろ。あとは、特にtest周りとかどーすんか?とか思うけど。初手から「一番いいやつを頼む」としか言えない。ありすぎてちょっとなんとも。既存の枠組みではできなかったことも低コストでできるようになる「はず」なので、その辺の検討か。型・DAGあたりはまぁ基本だとして、それ以外で、という感じか。やり残りもあるので、その辺り含めてか。SQL処理との兼ね合いはどうするか?という話はいくらでも出てくる。そもそもストプロとはなんなのか?というところの議論からスタートか。