Isolation Level
예제
예제1
Dirty read : commit되지 않은 데이터를 읽은 경우
nonserial로 트랜잭션들이 겹쳐서 실행되고 x에 y값을 더한 후 y값에 대해 rollback이 일어나면 데이터 정합성이 충족되지 않는다.
예제2
Non-repeatable read : 같은 데이터의 값이 달라진다.
트랜잭션끼리는 서로 고립 isolation되어야 하는데 트랜잭션2가 트랜잭션1에 영향을 준다.
예제3
Phantom read : 없던 데이터가 생긴다.
트랜잭션1이 첫 조회했을 경우에는 튜플1만 반환되지만, 트랜잭션2가 v의 값을 10으로 바꾼 후 나머지 작업을 하던 트랜잭션1이 튜플1과 튜플2를 반환하게 된다.
이상현상 해결
위 3가지 문제점들이 발생하지 않도록 설정하는게 좋지만, 그렇게 되면 동시성이 많이 떨어지게 되어 성능이 저하된다.
해결법 위 3가지 현상을 방지하는 특징에 따라 isolation level을 생성한다.
Serializable은 위 3가지 이상현상을 방지. 즉, 모든 이상현상이 발생하지 않는다. 하지만, 성능이 가장 좋지 않다.
새롭게 생긴 이상현상
Dirty write
커밋되지 않은 데이터를 write한다.
x의 초기값이 0인 경우 각 트랜잭션이 write 후 롤백을 하는경우 x의 롤백 후 값이 정확하지가 않다.
모든 트랜잭션 isolation level에서 dirty write를 허용해서는 안된다.
Lost update
각 트랜잭션이 작업 후 업데이트를 덮어 쓰기 때문에 업데이트한 데이터가 사라지게 된다.
또다른 Dirty read
rollback이 발생하지 않아도 dirty read가 될 수 있다.
Read skew
첫 x와 y의 값이 50인 경우 트랜잭션2가 x,y를 read하면 50,50이 나와야한다. 하지만, x를 read하고 트랜잭션1이 이체 후 커밋한 경우 x=10, y=90인 상태에서 트랜잭션2의 결과값은 x=50, y=90이다.
Write skew
데이터 write 후 정합성을 충족시키지 못한다.
서로 x,y값을 읽은 후 write한 경우 read시점에는 제약조건이 충족되지만, 각 트랜잭션에서 write한 이후부터는 제약조건이 성립되지 않는다.
Snapshot isolation
각 트랜잭션은 데이터를 read할 때 해당 데이터에 대한 스냅샷을 가지고 있는다. 그 후 write하게 되어도 스냅샷에 적용을 하고 commit을 할 경우 그 때 데이터베이스에 반영한다.
하지만, 자신의 트랜잭션의 스냅샷과 데이터베이스의 데이터가 정합성이 맞지 않는 경우 rollback을 한다.
MVCC : Multi Version Concurrency Control. 여러가지 스냅샷, 버전을 통해 동시성을 관리한다.
실무에서 isolation level
MySQL
oracle
PostgreSQL
