本当にtransactionは必要なのか？ - 急がば回れ、選ぶなら近道

前提 前提ですが。 transaction=Consistency/Isolationを担保する仕組みの話とする。 一般にtransactionが持つべき属性はACIDと言われる。C/Iに比べて、A/Dが“わかりやすい”のでAtomic/Durableの属性の方が人口に膾炙しているが、現在のtransactionではA/Dネタはあまり話題にならない。A/Dネタはローカルだけで見るのであれば普通にfile system /storageの話になる。元来Atomic/Durableはtransactionのコンテクストでは専らlogging / recoveryの話だった。そして、これは非同期のepoch-basedになるとそれ自体の取り扱い優先度が下がる。現代的なtransactionでは、「現時点ではread committedが保証されているFS/storageでA/Dの問題は(ある程度

[turanukimaru]

DDDでAggregation 単位で更新を管理しようとすると必要に決まってる…のだが例えばユーザに処理が戻るとか別システムとか非同期処理が関わるとかDBのTransactionじゃ足りないしそこまで管理できるプログラマは少ない。

[BlueSkyDetector]

DBって奥が深いなあ、という浅いコメントをしてしまう。たしかに結構みんな雰囲気でtransaction使ってる気がする。 / ところでブコメ見て、たしかにIT系じゃない人が見たらそもそもITに関することかすら分からないかも。笑

[inose660]

こんなハイコンテキストな文章が多く読まれるのであれば、前提に書くべきは『ANSI定義のserializableは現実的には遅すぎるしskewの問題は解決出来ていない(けど、そもそもそんなレベルのトランザクション必要？)』あたりか

[versatile]

transaction こそが rdb を使う理由だと思ってるけど、そうでも無いのか

[gonsuke777]

Spanner や TiDB/CockroachDB の 分散DB もレイテンシーを犠牲にしている訳だし、全てに万能なデータストアってのは存在し得ないとは思うんですけどね。彡(ﾟ)(ﾟ)

[denqueue]

分散化が進む今後のアーキテクチャではlockのコストが問題となるという指摘、納得感がある。

[rgfx]

Raftの話をするのかなと思ったらもっと手前の話だった

[open_your_eyes]

ACIDやロングトランザクションとか、あんま深く考えた事ない楽観と悲観レベルの設計しか経験ない。MQのトランザクションとかフレーム側でやるのが楽だと思うけど、衝突した時にコスト見合いで合議したら？

[knitcapmann]

RDBにtransactionが必要かという議論が成立する世界観もあるのか

[daishi_n]

DBトランザクションのロールバックだけでなく取り消し処理も必要になってるからね。

[seal2501]

結論、アプリロックでDBは結果性合成でおけってことでよい？？

[pullphone]

気軽に垂直分割しがちなソシャゲ業界ではDB単位でトランザクション取っても？という感じなので、全く使わないか、アプリ層で工夫することが多い（そしてそれも Dynamo や Spanner の出現で過去のものになりつつある）

[rkosaka]

少なくとも今関わってるサービスでは必要だと思うけど、洗練させれば実はいらないのかも。

[tmdtky]

こんな文章初めて見た。何を言いたいのかさっぱり分からん。

[nabecho]

大柴さん…

[j1nsuke]

50年後の日本語みたいになってて凄い(宜蘭クレオール的な)(最早英語で書いたほうが良いのでは？)