時間内にしゃべれないので分離したスライド。 自重しないで書いてる。

1. Transaction Puzzlers
Advanced Topics
appengine ja night #4
@ashigeru

2. 2種類の並⾏性制御
悲観的並⾏性制御 楽観的並⾏性制御
リソースを独占し、 リソースを独占できな
他人を待たせる かったら、やり直し
特徴 特徴
他人に迷惑をかける 他人に迷惑をかけない
成功確率が⾼い 失敗し続ける場合も
常にオーバーヘッド 成功すれば速い
誰に迷惑が掛かるか、という点で異なる
2010/01/22 appengine ja night #4 - @ashigeru 59

3. その他のパターン
Sharding
エンティティを複数のEGに分散
Long Running Transaction
リクエストをまたぐ⻑いトランザクション
Software Global Transaction
ソフトウェアで2PCプロトコルを実装
Software MVCC
ソフトウェアでMVCCを実装
2010/01/22 appengine ja night #4 - @ashigeru 60

4. トランザクション設計のポイント
データの局所性を生かす
更新頻度を意識する
本当の制約を⾒極める
2010/01/22 appengine ja night #4 - @ashigeru 61

5. ポイント: データの局所性を生かす
ユーザ情報はユーザごとに独⽴している
同一ユーザは同時にリクエストしないことが多い
多くのユーザを同時に捌いても並⾏稼動
「複数のユーザが共有するリソース」に注意
カウンタなどは典型例
チケット予約なども該当する
ユースケース分析は重要
単一ユースケースの並列性から考える
いざとなれば非正規化+Eventual Consistency
2010/01/22 appengine ja night #4 - @ashigeru 62

6. ポイント: 更新頻度を意識する
更新頻度の観点でエンティティを分類
稀に更新/常に更新のプロパティを共存させない
更新しないプロパティはどこに混ぜてもいい
マスタ/トランザクションデータでは不十分
トランザクションデータも参照系と更新系に
参照系はトランザクション処理しなくてもよい場合
がある
もちろん、更新に局所性があれば問題ない
ローカルトランザクションを衝突させない設計
2010/01/22 appengine ja night #4 - @ashigeru 63

7. ポイント: 本当の制約を⾒極める
Strong Consistencyはオーバースペック
どの程度の不整合がどの順で許されるか考える
自動販売機の支払い/商品受け取り (数秒)
コンビニの支払い/商品受け取り (数十秒)
ファーストフードの支払い/食事 (数分)
レストランの支払い/食事 (▲数十分)
同時にアプリケーション作成コストも考える
不整合の許容は制御することが増えすぎる
提供先のビジネス特性を考慮し、合意を得る必要性
あらゆる観点で「必要十分」に
2010/01/22 appengine ja night #4 - @ashigeru 64