트랜잭션 격리 수준이란, 하나의 트랜잭션에서 작업 중인 데이터가 다른 트랜잭션에 영향을 받지 않는 정도를 뜻한다. 반대로 하나의 트랜잭션에서 작업 중인 데이터를 다른 트랜잭션에서 어느 정도까지 접근할 수 있는 가를 나타낸다.
일반적으로 격리 수준을 낮게 생성하면 동시성은 좋아진다. 반대로 격리 수준을 높게 생성하면 동시성이 나빠진다. 하지만 격리 수준을 높임으로써 정확성을 확보할 수 있게 된다. 따라서 정확도와 동시성을 모두 확보할 수 있는 방안을 항상 고민해야 한다.
다음과 같이 4단계가 있다. 아래로 내려갈수록 격리 수준은 높은 단계다.
READ UNCOMMITTED
READ COMMITTED
REPEATABLE READ
SERIALIZABLE READ
레벨 0. READ UNCOMMITTED
SELECT 문장이 수행되는 동안 해당 데이터에 shared lock이 걸리지 않는다.
트랜잭션에 처리중이거나 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용한다.
일관성이 보장되지 못한다.
예시)
세션1이 특정 데이터를 A에서 B로 변경하는 동안, 세션2는 커밋 전의 트랜잭션이라도 이 데이터에 접근 가능함
레벨 1. READ COMMITTED
SELECT 문장이 수행되는 동안 해당 데이터에 shared lock이 걸린다.
트랜잭션이 수행되는 동안 다른 트랜잭션이 접근할 수 없고 대기하게 된다. 커밋된 트랜잭션만 조회가 가능하다.
대부분의 DBMS에서 기본값으로 사용하는 레벨이다.
예시)
세션1이 특정 데이터를 A에서 B로 변경하는 동안, 세션2는 이 데이터에 접근 불가능
레벨 2. REPEATABLE READ
트랜잭션이 시작되기 전에 커밋된 내용에 대해서만 조회할 수 있는 격리수준이다.
자신의 트랜잭션 번호보다 낮은 트랜잭션 번호에서 변경된(커밋된) 데이터만 접근 가능하다.
트랜잭션이 범위 내에서 조회한 데이터 내용이 항상 동일함을 보장한다. 다른 사용자는 트랜잭션 영역에 해당되는 데이터를 수정 불가능하다.
레벨 3. SERIALIZABLE
가장 단순하고 가장 엄격한 격리수준이다.
InnoDB에서 기본적으로 순수한 SELECT 작업은 아무런 잠금을 걸지않고 동작하는데,
격리수준이 SERIALIZABLE일 경우 읽기 작업에도 shared lock을 설정하게 되고, 이러면 동시에 다른 트랜잭션에서 이 데이터를 변경하지 못하게 된다.
* 단계 별 발생할 수 있는 문제
각 문제가 뭔지는 아래 링크에 잘 설명되어 있으므로 생략
대략 스토리를 생각해보면 다음과 같다. 큰 그림의 이해를 위해 정말 러프하게 적어본다.
격리수준 0 => 아무 제한도 걸지 말자. 그러다 보니 commit에 실패하고 roll-back하는 과정에서 이 커밋되지 않은 잘못된 데이터를 다른 세션에서 잘못 읽을 수가 있게 됨. => dirty read 문제 발생 => 어떻게 해결하지? 커밋된 데이터만을 읽기로 하자.
격리수준 1 => dirty read 문제는 해결. 근데 어떤 세션에서 트랜잭션을 시작하고 데이터를 조회했다고 해보자. 그 직후 다른 세션에 의해 해당 데이터가 바뀌고 커밋까지 됨 => 만약 동일 트랜잭션에서 데이터 조회를 한번 더 했다고 하면 이전 조회할 때랑 값이 달라짐. => non repeatable read 발생! => 어떻게 해결하지? 내 트랜잭션보다 이전 트랜잭션에서 커밋된 것만 읽자.
격리수준 2 => non repeatable read는 해결. 하지만 쓰기 잠금이 걸려있지 않으면 phantom read 현상이 발생할 수 있다. => 격리수준 3
자세히 설명한 글이 있어 참고하면 좋을 것 같다.
댓글