Isolation Level
예제
예제1 (Dirty read)
x = 10, y = 20 일 때
트랜잭션 1 : x에 y를 더한다.
트랜잭션 2 : y를 70으로 바꾼다.
Dirty read : commit 되지 않은 데이터를 읽은 경우 (유효하지 않은 값을 read)
nonserial로 트랜잭션들이 겹쳐서 실행되고 y값을 변경한 트랜잭션2가 커밋되지 않은 상태에서 x에 y값을 더한 후 트랜잭션2가 rollback이 일어나면 데이터 정합성이 충족되지 않는다.
유효하지 않은 값을 읽은 후 x에 더해줬기 때문에 데이터 정합성이 맞지 않는다.
예제2 (Non-repeatable read)
Non-repeatable read : 같은 데이터의 값이 달라진다.
같은 데이터를 하나의 트랜잭션에서 똑같이 읽었는데 서로 다른 값을 가져온다. isolation 관점에서 발생해서는 안되는 상황이다.
트랜잭션끼리는 서로 고립 isolation되어야 하는데 트랜잭션2가 트랜잭션1에 영향을 준다.
예제3 (Phantom read)
Phantom read : 없던 데이터가 생긴다.
트랜잭션1이 첫 조회했을 경우에는 튜플1만 반환되지만, 트랜잭션2가 v의 값을 10으로 바꾼 후 나머지 작업을 하던 트랜잭션1이 튜플1과 튜플2를 반환하게 된다.
이상현상 해결
위 3가지 문제점들이 발생하지 않도록 설정하는게 좋지만, 그렇게 되면 동시성이 많이 떨어지게 되어 성능이 저하된다.
해결법 위 3가지 현상을 방지하는 특징, 몇개를 허용하는지에 따라 isolation level을 생성한다.
Serializable은 위 3가지 이상현상을 모두 방지. 즉, 모든 이상현상이 발생하지 않는다. 하지만, 성능이 가장 좋지 않다.
새롭게 생긴 이상현상
Dirty write
2개의 트랜잭션이 write를 할 때 commit 안된 데이터를 write한다.
x의 초기값이 0인 경우 각 트랜잭션이 write 후 롤백을 하는경우 x의 롤백 후 값이 정확하지가 않다.
모든 트랜잭션 isolation level에서 dirty write를 허용해서는 안된다.
Lost update
각 트랜잭션이 작업 후 데이터를 덮어 쓰기 때문에 업데이트한 데이터가 사라지게 된다.
또다른 Dirty read
x와y의 값이 write된것에는 문제가 없다.
하지만, 트랜잭션2의 실행 순서에 따라 읽는값이 달라진다. 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을 한다.
트랜잭션 1의 스냅샷에는 y의 값이 50으로 저장되어있고, 40을 추가하여 90이 되어야하는데 트랜잭션 2가 y의 값을 변경했기 때문에 현재 y의 데이터와 스냅샷이 불일치하여 롤백이 발생한다. 먼저 커밋한 트랜잭션이 영속성으로 저장된다.
MVCC : Multi Version Concurrency Control. 여러가지 스냅샷, 버전을 통해 동시성을 관리한다.
실무에서 isolation level
MySQL
oracle
PostgreSQL
정리
