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

📙 1. 격리 수준이란

  트랜잭션의 격리 수준(Isolation Level)이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것을 말한다.

  격리 수준은 크게 'READ UNCOMMITTED', 'READ COMMITTED', 'REPEATABLE READ', 'SERIALIZABLE'의 4가지로 나뉜다. 뒤로 갈수록 각 트랜잭션 간의 데이터 격리(고립) 정도가 높아지며, 동시 처리 성능도 떨어지는 것이 일반적이다.
  'DIRTY READ'라고도 하는 'READ UNCOMMITTED"는 일반적인 데이터베이스에서는 거의 사용하지 않고, 'SERIALIZABLE' 또한 동시성이 중요한 데이터베이스에서는 거의 사용되지 않는다.

  오라클 같은 DBMS에서는 주로 'READ COMMITTED' 수준을 많이 사용하며, MySQL에서는 'REPEATABLE READ'를 주로 사용한다.

 

 

📙 2. 부정합의 문제

  데이터베이서의 격리 수준을 이야기하면 항상 함께 언급되는 세 가지 부정합의 문제점이 있다. 세 가지 부정합의 문제는 격리 수준에 따라 발생할 수도 있고 발생하지 않을 수도 있다.

	DIRTY READ	NON-REPEATABLE READ	PHANTOM READ
READ UNCOMMITTED	O	O	O
READ COMMITTED	X	O	O
REPEATABLE READ	X	X	O (InnoDB는 없음)
SERIALIZABLE	X	X	X

• DIRTY READ
  한 트랜잭션이 실행 중일 때 다른 트랜잭션에 의해 수정되었지만 아직 '커밋되지 않은' 행의 데이터를 읽을 수 있을 때 발생한다.
• NON-REPEATABLE READ
  한 트랜잭션 내의 같은 행에 두 번 이상 조회가 발생했는데, 그 값이 다른 경우를 말한다.
• PHANTOM READ
  트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안 보였다가 하는 현상을 말한다.

  4개의 격리 수준과 격리 수준의 레벨에 따라 발생할 수 있는 부정합의 문제점을 자세히 알아보도록 하자.

 

 

📙 3. READ UNCOMMITTED

  READ UNCOMMITTED는 가장 낮은 격리 수준으로, 각 트랜잭션에서의 변경 내용이 COMMIT이나 ROLLBACK의 여부에 상관없이 다른 트랜잭션에 보이게 된다.

  그림에서 확인할 수 있듯이 아직 커밋되지 않은 'emp_no=500000, first_name=Lara'인 사원을 사용자 B가 조회할 수 있다. 문제는 사용자 A가 처리 도중 알 수 없는 문제가 발생해 INSERT 된 내용을 롤백한다고 하더라도 여전히 사용자 B는 'Lara'가 정상적인 사 원리라고 생각하고 계속 처리할 것이라는 점이다.

  이처럼 어떤 트랜잭션에서 처리한 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있는 현상을 DIRTY READ(더티 리드)라고 한다.

  정합성(어떤 데이터들이 값이 서로 일치하는 상태)에 문제가 많은 격리 수준이므로, MySQL을 사용한다면 최소한 READ COMMITTED 이상의 격리 수준을 사용할 것을 권장한다.

	DRITY READ	NON-REPEATABLE READ	PHANTOM READ
READ UNCOMMITTED	O	O	O

 

📙 4. READ COMMITTED

  READ COMMITTED는 오라클 DBMS에서 기본으로 사용되는 격리 수준이며, 온라인 서비스에서 가장 많이 선택되는 격리 수준이다. 해당 격리 수준에서는 커밋이 완료된 데이터에 대해서만 조회를 허용한다.

  'emp_no=500000, first_name=Lara'의 데이터가 'emp_no=500000, first_name=Toto'로 변경이 되었다. 하지만, 아직 커밋이 되지 않았기 때문에 사용자 B는 employees 테이블이 아니라 언두 영역에 백업된 레코드에서 값을 가져오게 된다.

 

  READ COMMITTED 격리 수준에서 NON-REPEATABLE READ라는 부정합의 문제가 발생한다.

  사용자 B가 처음에 'Toto'를 검색하였을 때는 일치하는 결과가 없었다. 하지만, 사용자 A가 'Lara'라는 사원을 'Toto'로 변경하고 커밋까지 한 후, 다시 사용자 B가 'Toto'를 검색하면 이번에는 결과 1건이 조회된다.

  이는 별다른 문제가 없어 보이지만, 사실 사용자 B가 하나의 트랜잭션 내에서 똑같은 SELECT 쿼리를 실행했을 때는 항상 같은 결과를 가져와야 한다는 'REPEATABLE READ' 정합성에 어긋나는 것이다.

	DRITY RED	NON-REPEATABLE READ	PHANTOM READ
READ COMMITTED	X	O	O

 

  '격리 수준과 부정합의 문제'가 정리되어 있는 표에서 알 수 있듯이 REPEATABLE READ에서는 NON-REPEATABLE READ 문제가 발생하지 않는다.

  REPEATABLE READ 격리 수준에서는 기본적으로 SELECT 쿼리 문장이 트랜잭션 범위 내에서만 작동하기 때문이다.

그래서 START TRANSACTION(또는 BEGIN) 명령으로 트랜잭션을 시작한 상태에서 온종일 동일한 쿼리를 반복해서 실행해 봐도 동일한 결과만 보게 된다.

 

 

📙 5. REPEATABLE READ

  REPEATABLE READ는 MySQL의 InnoDB 스토리지 엔진에서 기본으로 사용되는 격리 수준이다.

  REPEATABLE READ에서는 NON-REPEATABLE READ 부정합이 발생하지 않는다.

  InnoDB 스토리지 엔진은 트랜잭션이 ROLLBACK 될 가능성에 대비해 변경되기 전 레코드를 언두(Undo) 공간에 백업해 두고 실제 레코드 값을 변경한다. (MVCC방식)

  REPEATABLE READ는 MVCC(Multi Version Concurrency Control)를 위해 언두 영역에 백업된 이전 데이터를 이용해 동일 트랜잭션 내에서는 동일한 결과를 보여주기 때문에 NON-REPEATABLE READ 부정합이 발생하지 않는다.

 

  사실은 READ COMMITTED도 MVCC를 이용해 COMMIT 되기 전의 데이터를 보여준다. 하지만, READ COMMITTED와 REPEATABLE READ는 언두 영역에 백업된 레코드의 여러 버전 가운데 몇 번째 이전 버전까지 찾아 들어가느냐가 다르기 때문에, NON-REPEATABLE READ 문제의 발생여부가 다르게 된다.

  REPEATABLE READ 격리 수준에서 어떻게 언두 영역에 백업된 레코드에 접근하는지 살펴보자.

 

  모든 InnoDB의 트랜잭션은 고유한 트랜잭션 번호(순차적으로 증가하는 값, 테이블에서는 TRX-ID로 표기하겠다.)를 가지며, 언두 영역에 백업된 모든 레코드에는 변경을 발생시킨 트랜잭션의 번호가 포함되어 있다. 그리고 언두 영역의 백업된 데이터는 InnoDB 스토리지 엔진이 불필요하다고 판단하는 시점에 주기적으로 삭제한다.

  사용자 B가 'emp_no=500000'인 데이터를 조회할 때, 자신의 트랜잭션 번호(10번) 보다 작은 트랜잭션 번호에서 변경한 것만 보게 된다. 그래서 사용자 B는 변경된 'Toto'를 얻게 되는 것이 아니라 'Lara'를 얻게 되는 것이다.

  즉, NON-REPEATABLE READ 문제가 발생하지 않는다.

  하지만, REPEATABLE READ 격리 수준에서는 PHANTOM READ(또는 PHANTOM ROW) 부정합 문제가 발생할 수 있다.
  사용자 B가 실행하는 두 번의 SELECT ... FOR UPDATE 쿼리 결과는 서로 다르다. SELECT ... FOR UPDATE 쿼리는 SELECT 하는 레코드에 쓰기 잠금을 걸어야 하는데, 언두 레코드에는 잠금을 걸 수 없다. 그래서 SELECT ... FOR UPDATE나 SELECT ... LOCK IN SHARE MODE로 조회되는 레코드는 언두 영역의 변경 전 데이터를 가져오는 것이 아니라 현재 레코드의 값을 가져오게 되는 것이다.

	DRITY READ	NON-REPEATABLE READ	PHANTOM READ
REPEATABLE READ	X	X	X (InnoDB는 없음)

 

 

📙 6. SERIALIZABLE

  SERIALIZABLE은 가장 단순한 격리 수준이면서 동시에 가장 엄격한 격리 수준이다. 그만큼 동시 처리 성능도 다른 트랜잭션 격리 수준보다 떨어진다.

  트랜잭션의 격리 수준이 SERIALIZABLE로 설정되면 읽기 작업도 공유 잠금(읽기 잠금)을 획득해야만 하며, 동시에 다른 트랜잭션은 그러한 레코드를 변경하지 못하게 된다.

  즉, 한 트랜잭션에서 읽고 쓰는 레코드를 다른 트랜잭션에서는 절대 접근할 수 없는 것이다.

	DIRTY READ	NON-REPEATABLE READ	PHANTOM READ
SERIALIZABLE	X	X	X

 

해당 글은
백은빈, 이성욱 님의 'Real MySQL 8.0',
주홍철 님의 '면접을 위한 CS 전공지식 노트'
를 참고하였습니다.