Isolation level
트랜잭션에서 일관성 없는 데이터를 허용하도록 하는 수준
Isolation level의 필요성
-
데이터베이스는 ACID 특징과 같이 트랜잭션이 독립적인 수행을 하도록 한다.
-
따라서 Locking을 통해, 트랜잭션이 DB를 다루는 동안 다른 트랜잭션이 관여하지 못하도록 막는 것이 필요하다.
-
즉, 트랜잭션 수준 읽기 일관성(Transaction-Level Read Consistency)을 지키기 위해서이다.
(다시 말해 동시성 제어 문제 해결 위해)🔥 무조건 Locking으로 동시에 수행되는 수많은 트랜잭션들을 순서대로 처리하는 방식으로 구현하게 되면 데이터베이스의 성능은 떨어지게 될 것이다.
🌊 그렇다고 해서, 성능을 높이기 위해 Locking의 범위를 줄인다면, 잘못된 값이 처리될 문제가 발생하게 된다.
따라서 최대한 효율적인 Locking 방법이 필요함!
🏳🌈 Isolation level 종류
트랜잭션 격리 수준이란?
트랜잭션들끼리 얼마나 고립되어있는지(잠금 수준)을 나타내는 것으로, 특정 트랜잭션이 다른 트랜잭션에 의해 변경된 데이터를 볼 수 있도록 허용할지 말지를 결정하는 것이다.
격리 수준은 크게 4가지로 나뉜다
- READ UNCOMMITTED (트렌젝션 레벨 0)
- READ COMMITTED (트렌젝션 레벨 1)
- REPEATABLE READ (트렌젝션 레벨 2)
- SERIALIZABLE (트렌젝션 레벨 3)
아래로 내려갈수록
트랜잭션 간의 고립도가 높아지고 성능이 떨어지는게일반적이다.
⭐ Read Uncommitted (레벨 0)
특징
트랜잭션에 처리중이거나, 아직 Commit되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용함
사용자1이 A라는 데이터를 B라는 데이터로 변경하는 동안
사용자2는 아직 완료되지 않은(Uncommitted) 트랜잭션이지만
데이터B를 읽을 수 있다- 데이터베이스의 일관성을 유지하는 것이 불가능함
Dirty Read,Non-Repeatable Read,Phantom Read현상이 발생한다.
문제점
데이터 정합성 문제가 많으므로 RDBMS 표준에서는 격리 수준으로 인정하지 않는다.
예시>
- 트랜잭션A는 테이블의 데이터를 수정중인 상태이고 아직 COMMIT 전이다.
- 트랜잭션B는 트랜잭션A가 수정중인 데이터를 조회한다. (이를 Dirty Read라고 한다.)
- 트랜잭션A는 문제가 발생해 ROLLBACK한다.
- 하지만 트랜잭션B는 COMMIT되지 않은 데이터를 가지고 로직을 수행한다. (문제 발생)
⭐ Read Committed (레벨 1)
특징
Commit이 완료된 트랜잭션의 변경사항만 다른 트랜잭션만 조회 가능
트랜잭션이 수행되는 동안 다른 트랜잭션이 접근할 수 없어 대기하게 됨
대부분의 SQL 서버가 Default로 사용하는 Isolation Level임
실제 테이블 값을 가져오는 것이 아니라 Undo 영역의 백업된 레코드에서 값을 가져온다.
- Undo 영역은 데이터의 변경이 있을 경우 이전의 데이터를 보관하는 곳
사용자1이 A라는 데이터를 B라는 데이터로 변경하는 동안
사용자2는 해당 데이터에 접근이 불가능함Dirty Read가 발생하지 않는다.(트랜잭션이 Commit 되어 확정된 데이터만 읽는 것을 허용)Non-Repeatable Read,Phantom Read현상은 여전히 발생한다.- DB2, SQL Server, Sybase의 경우
읽기, 공유 Lock을 이용하여 구현한다. - Oracle은 Lock을 사용하지 않고 쿼리시작 시점의
Undo 데이터를 제공한다.
문제점
NON-REPEATABLE READ 부정합 문제가 발생할 수 있다.
👉 READ COMMITTED 격리 수준에서 실행되는 SQL 문장의 결과가 무엇인지 정확히 예측하고 있어야 한다.
⭐ Repeatable Read (레벨 2)
특징
트랜잭션이 범위 내에서 조회한 데이터 내용이 항상 동일함을 보장함
다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 불가능
MySQL에서 Default로 사용하는 Isolation Level
-
트랜잭션이 시작되기 전에 COMMIT된 내용에 대해서만 조회할 수 있는 격리수준이다.
-
MySQL에서는 트랜잭션마다 트랜잭션 ID를 부여하여 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경하는 것만 읽게 된다.
-
변경되기 전 레코드는 Undo 공간에 백업해두고 실제 레코드 값을 변경한다.
-
Read Commited와 다른 점은 한 트랜잭션이 조회한 데이터는 트랜잭션이 종료될 때까지 다른 트랜잭션이 변경하거나 삭제하는 것을 막으므로, 한번 조회한 데이터는 반복적으로 조회해도 같은 값을 반환한다.
문제점
- Dirty Read와 같은 현상은 발생하지 않지만 Phantom Read현상은 여전히 발생한다.
- 하나의 트랜잭션 실행시간이 길어질수록 Undo에 백업된 레코드가 많아져서 멀티 버전을 관리해야한다는 단점이 있다.
- 하지만 영향을 미칠 정도로 트랜잭션이 오래 지속되는 경우가 없어서 Read Committed와 Repeatable Read의 성능차이는 거의 없다고 한다.
- Update 부정합, Phontam Read가 발생할 수 있다.
⭐ Serializable (레벨 3)
특징
-
한 트랜잭션에서 사용하는 데이터를 다른 트랜잭션에서 접근 불가
-
트랜잭션이 커밋될때까지 모든 데이터에 잠금이 설정되어 다른 트랜잭션에서 해당 데이터를 변경할 수 없다.
-
완벽한 읽기 일관성 모드를 제공함
-
다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 UPDATE, INSERT, DELETE 불가능
-
가장 단순한 격리 수준이지만 가장 엄격한 격리 수준으로 Phantom Read가 발생하지 않는다.
-
모든 부정합 문제 해결
문제점
동시 처리 능력이 다른 격리 수준보다 떨어지고 성능 저하가 발생하여 데이터베이스에서 거의 사용되지 않는다.
🚀선택 시 고려사항
Isolation Level에 대한 조정은, 동시성과 데이터 무결성에 연관되어 있음
동시성을 증가시키면 데이터 무결성에 문제가 발생하고, 데이터 무결성을 유지하면 동시성이 떨어지게 됨
레벨을 높게 조정할 수록 발생하는 비용이 증가함
낮은 단계 Isolation Level을 활용할 때 발생하는 현상들
👎🏻 Dirty Read
-
커밋되지 않은 수정중인 데이터를 다른 트랜잭션에서 읽을 수 있도록 허용할 때 발생하는 현상
-
어떤 트랜잭션에서 아직 실행이 끝나지 않은 다른 트랜잭션에 의한 변경사항을 보게되는 경우
-
변경 후 아직 Commit 되지 않은 값을 읽고, Rollback 후의 값을 다시 읽어 최종 결과 값이 상이한 현상이다
-
Oracle은 다중 버전 읽기 일관성 모델을 채택하여 lock을 사용하지 않고 Dirty Read를 피해 일관성 있는 데이터 읽기가 가능하게 하였다.
-
발생 Level:
Read Uncommitted
👎 Non-Repeatable Read
- 한 트랜잭션에서 같은 쿼리를 두 번 수행할 때 그 사이에 다른 트랜잭션 값을 수정 또는 삭제하면서 두 쿼리의 결과가 상이하게 나타나는 일관성이 깨진 현상
(다시말해 하나의 트랜잭션 내에서 동일한 SELECT를 수행했을 경우 항상 같은 결과를 반환해야하는 REPEATABLE READ 정합성에 어긋나는 것이다.)
금전적 처리와 연결된 서비스에서 문제가 발생할 수 있다.
- 트랜잭션B에서 1번 상품의 총 투자액을 조회 👉 100만원이 조회됨
- 트랜잭션A에서 1번 상품의 총 투자액을 120만원으로 바꾸고 COMMIT
- 트랜잭션B에서 1번 상품의 총 투작액을 다시 조회 👉 120만원이 조회됨 (NON-REPEATABLE READ )
- 발생 Level:
Read Committed, Read Uncommitted
👎 Phantom Read
-
Non Reapeatable Read의 한 종류로 조건이 걸렸든 안 걸렸든 Select문을 쓸 때 나타날 수 있는 현상
-
한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽었을 때, 첫번째 쿼리에서 없던 유령(Phantom) 레코드가 두 번째 쿼리에서 나타나는 현상
-
트랜잭션 도중 새로운 레코드 삽입을 허용하기 때문에 나타나는 현상임
-
INSERT에 대해서만 발생하는 문제다. (SELECT, DELETE에 대해서는 발생하지 않는다)
👉 이를 방지하기 위해서는 쓰기 잠금 (write lock)을 걸어야 한다
START TRANSACTION; -- transaction id : 1
SELECT * FROM Member; -- 0건 조회
START TRANSACTION; -- transaction id : 2
INSERT INTO MEMBER VALUES(1,'hjoon',28); -- INSERT 하면 문제발생
COMMIT;
SELECT * FROM Member; -- 여전히 0건 조회
UPDATE Member SET name = 'zion.t' WHERE id = 1; -- 1 row(s) affected
SELECT * FROM Member; -- 1건 조회 (Phantom READ 문제발생)
COMMIT;
- 2번 트랜잭션
member 테이블에 id=1인 데이터를 INSERT 한 뒤 COMMIT 하였다.
REPEATABLE READ 격리수준에서는 1번 트랜잭션이 일관된 데이터를 보는 것을 보장해주기 위해서
변경되기 전 내용인 name=hjoon 을 UNDO 세그먼트에 남겨둬야 한다.- 1번 트랜잭션
첫 번째 쿼리에서 member를 조회했을 때
- DELETE에 대해서는 문제가 발생하지 않는다.
START TRANSACTION; -- transaction id : 1
SELECT * FROM Member; -- 1건 조회
START TRANSACTION; -- transaction id : 2
DELETE FROM Member WHERE id = 1;
COMMIT;
SELECT * FROM Member; -- 여전히 1건 조회
UPDATE Member SET name = 'zion.t' WHERE id = 1; -- 0 row(s) affected
SELECT * FROM Member; -- 여전히 1건 조회 (문제 없음)
COMMIT;- 발생 Level:
Repeatable Read,Read Committed,Read Uncommitted
