ほげにっき

hogedigoの日記

READ UNCOMMITTEDが有効なシーン

データベースのトランザクション分離レベルにREAD UNCOMMITTEDというものがある。これは他トランザクションが更新してコミットする前のデータを読み込むもので、更新ロックとの競合(ロック待ち)が起きないというメリットがある反面、ダーティリード(取得したデータが後でロールバックされる可能性がある)のリスクがある。


今までMVCC採用のDBしか使ってなかったので、ほとんど(というか全く)UNCOMMITTED READを行うことはなかったのだが、今回のプロジェクトではMVCC非採用のDB(IBMのアレ)を使うことになったので、パフォーマンス向上の為にUNCOMMITTED READも検討する必要が出てきた。
なので、UNCOMMITTED READが有効なシーンをちょっと考えてみることにする。(どのシーンもメリットはパフォーマンスね)

座席予約システムの空席照会とか

空席照会時にダーティリードしたとしても、席が埋まった状態で表示されるだけなので、システム上問題はない(機会損失はあるかもしれないけど)。最終的に予約確定する段階で情報を保証すれば良い。

株価情報とか

売り上げ情報とか、リアルタイムで変化する情報を表示する場合。ダーティリードしたものを表示しても、その値はすぐに変化するので問題ない。ダーティリードした値も、何らかの原因でロールバックしただけで、更新時にはおそらく正しい値であっただろうし。
もちろん表示する場合のみ。当たり前だけど、その値を使って約定とかしちゃダメ。

統計情報とか

データの種類によるが、多少のダーティリードを許しても、統計の結果にほとんど変化がない場合。グラフ表示のみだとなお可。

ポーリングとか

これは最近思いついた。ステータスの変化をポーリングしながら待つケースなど。ポーリングはUNCOMMITTED READで行い、ステータス変化を検知したら改めてCOMMITTED READで読み直して再確認する。ステータスが変化するまでのポーリング回数が多くなる場合には結構有効では・・。

過去情報の照会

履歴やログの照会など・・。もう変更される可能性のない情報を照会する場合。でもこれはそもそも更新とロック競合することもないはずだから、あまり効果ないかな。


他にもあれば追記していくぞね。