트랜잭션 격리수준(Isolation Level)

 1. ACID

- 트랜잭션 격리수준을 설명하기 앞서 ACID에 대해 먼저 알아보자

· Atomicity(원자성)

- 하나의 트랜잭션 안에 data 변경이 있다면 모두 저장되거나 취소되어야 한다.

- 예) 하나의 트랜잭션에서 Update가 2번 발생했다면 2개의 Update는 모두 성공이거나 실패인 동일한 결과를 가져가야한다.

​

· Consistency(일관성)

- 데이터는 정의된 규칙에서만 저장되어야한다.

- 예) 문자 타입의 필드에는 문자 타입의 데이터만 들어가야한다.

​

· Isolation(격리성)

- 트랜잭션이 각각 수행되고 있을 때, 다른 트랜잭션에 의해 영향을 받지 말아야한다.

- ex) 잔액이 1000원인 계좌에서 A 트랜잭션에서 1000원을 출금하고, 동시에 B 트랜잭션으로 500원을 출금하게 될 때 A트랜잭션, B트랜잭션 모두 출근이 되면 안된다. 다른 요청이 관여 할 수 없어야 한다.

​

· Durability(지속성)

- 성공적으로 트랜잭션이 완료된 데이터는 데이터베이스에 영원히 반영되어야 한다.

 

 2. 트랜잭션 격리수준이란?

- 트랜잭션에서 다른 트랜잭션에 의해 변경된 데이터를 볼수 있게 허용할지 말지에 대한 수준을 이야기한다.

 

 3. 격리성 관련 문제점

· Dirty Read

1) 각각 서로 다른 트랜잭션이 존재하는 상황

2) 1번 트랜잭션에서 A값을 1→2로 변경 후 commit을 하지 않은 상태

3) 2번 트랜잭션에서 A값을 조회. A값으로 2가 조회된다.

4) 1번 트랜잭션에서 commit을 하지 않고 종료처리. A는 변경이 되지 않아 실제로 1이란 값을 가짐

5) 2번 트랜잭션은 A 값으로 2로 조회된 후 다른 로직을 수행하면서 데이터 정합성에 문제가 발생하게 된다.

 

· Non-Repeatable Read

하나의 트랜잭션에서 같은 쿼리를 두 번 수행할 때 그 사이에 다른 트랜잭션에 의해 데이터가 변경되면서 두 쿼리의 결과가 상이하게 나타나는 일관성이 깨진 현상

​

· Phantom Read

하나의 트랜잭션에서 범위가 존재하는 쿼리를 두번 이상 조회할 때, 첫번째 조회했던 데이터와 두번째 조회했던 데이터가 달라지는 경우이다.

트랜잭션 도중 새로운 데이터의 삽입을 허용하기 때문에 발생한다.

 

 4. 트랜잭션 격리수준

· READ-UNCOMMITTED

- 다른 트랜잭션에서 처리중이거나 commit 되지 않은 데이터를 조회하는 것이 허용됨

- 문제점 : Dirty Read, Non-Repeatable Read, Phantom Read 현상이 발생함

- 예시

1) '트랜잭선1' 시작 2) '트랜잭션1'에서 ID가 1인 회원의 이름을 A->B로 UPDATE 3) '트랜잭션2' 시작 4) '트랜잭션2'에서 ID가 1인 회원의 이름을 조회 : B로 조회 5) '트랜잭션1' 롤백 처리 6) '트랜잭션2' 종료 ​ -> 실제 회원의 이름은 A지만 트랜잭션2 프로세스에서는 B로 조회되는 현상이 발생함

· READ-COMMITTED

- 다른 트랜잭션에서 데이터를 처리중이라면 해당 트랜잭션에서 데이터 조회시에는 undo영역에 있는 이전 값을 참고하여 보여준다.

- 문제점 : Non-Repeatable Read, Phantom Read 현상이 발생함

- 예시

1) '트랜잭선1' 시작 2) '트랜잭션1'에서 ID가 1인 회원의 이름을 A->B로 UPDATE 3) '트랜잭션2' 시작 4) '트랜잭션2'에서 ID가 1인 회원의 이름을 조회 : A로 조회 5) '트랜잭션1' Commit 처리 6) '트랜잭션2'에서 ID가 1인 회원의 이름을 조회 : B로 조회 7) '트랜잭션2' 종료 ​ -> '트랜잭션2'에서 회원 이름이 처음에는 A, 두번째는 B로 조회되는 Non-Repeatable Read 현상 발생.

· REPEATABLE-READ

- 트랜잭션이 시작되기 전에 커밋된 내용에 대해서만 데이터를 조회한다. 그렇기에 트랜잭션의 범위 내에서 조회한 데이터 내용이 항상 동일함을 보장.

즉, 자신의 트랜잭션 번호보다 낮은(즉, 먼저 일어난) 트랜잭션 번호에서 변경(커밋)된 데이터를 조회한다.

- 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대해 수정이 불가하다.

- 문제점 : Phantom Read 현상이 발생함

- 예시

1) '트랜잭선1' 시작 2) '트랜잭션1'에서 ID가 1인 회원의 이름을 A->B로 UPDATE 3) '트랜잭션2' 시작 4) '트랜잭션2'에서 ID가 1인 회원의 이름을 조회 : A로 조회 5) '트랜잭션1'에서 ID 2인, 이름이 C인 회원 정보 삽입 5) '트랜잭션1' Commit 처리 6) '트랜잭션2'에서 ID가 1보다 큰 회원의 이름을 조회 : A, C로 조회 7) '트랜잭션2' 종료 ​ -> '트랜잭션2'에서 회원 이름이 처음에는 A, 두번째는 A로 조회되 Non-Repeatable Read 현상은 사라지지만 범위 데이터로 조회, 즉 ID가 1보다 큰 회원 정보를 조회하게 되면 4)번 단계에서는 없었던 C회원 정보가 발생하는 Phantom Read 현상이 발생.

· SERIALIZABLE

- 읽기 작업에도 잠금으로 설정되기 때문에 다른 트랜잭션에서는 조회, 수정이 불가능하다.

- 위의 특성으로 인해 동시처리 능력이 떨어지고, 성능저하가 발생한다.