Miniposts

2026/10/21

論文を読んだ.

https://arxiv.org/html/2610.15793v1 (opens in a new tab)

The Case for Single-Version Concurrency Control in the Cloud

敬愛するViktor Leis 先生とPhil Bernstein 先生が著者に入っている,MVCC (MultiVersion Concurrency Control) 批判(?)の論文.MVCCの理論面を構築したのはまさにこのBernstein先生であるから,味わい深い論文. この論文では,MVCCはPostgreSQLのドキュメントの20%超を占めていて理解のコストが高いとか,MVCCはSVCC (Single-Version Concurrency Control) に比べてテスト量が2倍になるとか,メタデータやGCのためにオーバヘッドが複雑だとか, そもそもオブジェクトストレージにログを保存するうえ Log is the database である現代のクラウドネイティブデータベースではMVCCの重要機能(Consistent Read / Snapshot / PITR) はオブジェクトストレージからのリカバリだけで実現できるとか,もっと言えばOLAPクエリはSnowflakeなどのDWHに流すからなおさらnonblockingなreadは必要ないよね,とか,そもそも論でMVCCが役目を終えたと主張している. 全部理解できる.面白いのは評価実験でClaudeを使ってSVCCとMVCCをそれぞれ実装させたときの出力コードの行数などを載せているところで,なるほどそういう測り方もあるかと参考になった.

しかし,ロングトランザクションが苦しいという問題はSVCCだろうがMVCCだろうが変わらず癒えることはない問題である.そのためにはMVCCの理論をexploitしたSVCCをデザインすることが重要だと思われる.

2026/03/11

論文を読んだ。

https://www.vldb.org/cidrdb/papers/2026/p9-stonebraker.pdf (opens in a new tab)

Consistency and Correctness in Data-Oriented Workflow Systems (CIDR '26)

Stonebraker 御大のSagaに関する論文。 ワークフローシステム・・・というか単一の巨大なトランザクションを諸々の事情(途中で人が介入するとか、外部APIを呼び出すとか、現実世界で不可逆な操作が発生するとか)によって複数のワークフローに分割したシステムでは、補償処理が重要で、伝統的なトランザクションのAbort/Rollbackの実装はあまり役に立たない。 いわゆるSaga的なデザインパターンが支持されていてRDBMSのトランザクションが下火になるのもこのあたりの事情があるが、しかしSagaは書くのがしんどい。そこで、DBOSにタイムトラベル機能を追加することで、ワークフローに任意の時点まで巻きもどってリトライする機能を与えよう・・・という論文。

アプローチはなんだかちょっと違う気がするが、任意の(コミット済みの)トランザクションが一発でRevertできる関数が提供できれば、世の中のアプリケーションは結構救われるのではという感覚はわかる。

2026/03/02

DEIM で論文を発表した。

以前書いた anomalyに関する記事へのアンサーというか、自分がぼんやりと考えていたことを論文にまとめたもの。 個人的に、トランザクション処理のなかでも concurrency control はもうアプリケーションユーザを抜きにして議論することは不可能なトピックになっており、古典的な「強い一貫性を提供すればユーザは何も気にしなくてOK!!」という世界観を維持するのはかなり厳しいと思っている。

アプリケーションユーザが concurrency control に関与することを前提とするならば、そもそも isolation level は何がいいんだっけ(serializableはtoo muchなのでは)という話からやり直しになるし、弱い一貫性で役に立つシステムやデザインパターンを構築していくことが大事だ。

なんてことは業務でシステムを構築している人はみんなわかっていて、それでも辛酸を嘗めきったからこそ後進のために分散トランザクションに戻ってきているのだろう。 だが私は若手の時代にずっとconcurrency controlをやってきていて、それが理解できていなかった。

Archives

© nikezono.devRSS