PostgreSQL / PPAS 트랜잭션 Isolation Level

(출처 : https://www.postgresql.org/docs/9.5/transaction-iso.html - 공식 영문 DOC)

(출처 : https://postgresql.kr/docs/11/transaction-iso.html - 공식 번역 DOC)

 

• 이 페이지에서는 PostgreSQL / PPAS 트랜잭션 Isolation Level 의 개념 및 종류를 다룬다.
  
  
• Isolation 은 데이터베이스의 기본 원리인 ACID 의 I 를 뜻한다.
  (Atomic : 원자성 , Consistency : 일관성, Isolation : 격리성, 독립성 , Durability : 지속성)
  
  
• 즉, 데이터베이스를 사용하는 사용자 혹은 세션간의 트랜잭션 처리에 대해서 다른 사용자(세션)의 영향을 받지 않도록 보장한다.
  또한 이는 DB Lock 과 밀접하게 연관되어서 트랜잭션간의 Lock (혹은 격리) 수준에도 영향을 준다.
  (격리성과 lock 수준의 정도는 비례관계다.)
  
  
• PostgreSQL / PPAS 는 트랜잭션 간에 총 4개의 Isolation Level 을 설정 할 수 있고 각 Level 은 아래의 특성을 따른다.
  
  
• PostgreSQL / PPAS 와 MySQL / MariaDB 의 Isolation Level 은 동일하나 약간씩의 차이가 있다.
  (MySQL / MariaDB 참조 : MySQL / MariaDB 트랜잭션 Isolation Level)
  
  
  • READ UNCOMMITTED
    
    
    • select for update, update, delete 구문 실행 후, commit, rollback 에 관계 없이 수행 전의 데이터를 읽어 들인다.
      이로 인해 데이터 간의 일관성을 보장하기 위한 lock 이 발생하지 않는다.
      
      
    • 기존 RDBMS 에서는 위의 방식으로 인해 일관성이 보장되지 않는 데이터를 읽어 들이는 Dirty Read 가 발생할 수 있으나
      PostgreSQL / PPAS 는 이를 허용하지 않는다.
      
      
    • DB 내에서 SET 으로 옵션을 설정 할 수 있으나 PostgreSQL / PPAS 에서 작동 메커니즘은 READ COMMITTED 와 거의 동일하다.
      그래서 공식 DOC 에서도 실제 Isolation 유형은 READ UNCOMMITTED / READ COMMITTED 를 묶어서 아래의 2개와 함께 총 3개로 구분한다.
  • READ COMMITTED
    
    
    • ORACLE, PostgreSQL 의 default Isolation Level 이다.
      
      
    • Read uncommitted 와는 다르게 select for update, update, delete 구문 실행 후, commit 된 데이터를 읽어 들인다.
      
      
    • PostgreSQL / PPAS 에서는 데이터 변경이 발생 시, commit 되지 않은 데이터 변경 내역 마다 새로운 페이지를 만들어서 (ORACLE 에서 데이터블록) 변경이력을 관리하는
      MVCC 개념을 사용하기 때문에 commit 되지 않는 내용들에 대해서는 기존에 있는 갱신 이전 버전의 페이지를 확인한다.
      
      
    • 위의 방식으로 인해 비슷한 시간대에 동일 쿼리를 수행했는데 처음 수행했을때 보여지는 데이터 row 와 다른 트랜잭션에서 commit 이후에 보여지는 row 간에 정합성 차이 혹은 조회 일관성 이상등이 발생 할 수 있다.
      이로 인하여 이상이 발생하는 row 를 phantom row 라고 하며 (read 이상은 phantom read 라고 한다), 이를 방지하기 위해서 gap lock 이라는 개념이 존재하는데 해당 격리 단계 에서는 사용하지 않는다.
      
      
  • REPEATABLE READ
    
    
    • MySQL / MariaDB (InnoDB 기준) 의 default Isolation Level 이다.
      
      
    • 동일 세션내의 트랙잭션에서도 데이터 조회 변동 시점간의 gap 을 관리하기 위하여 snapshot 이라는 개념을 사용하며,
      이를 통하여 다른 세션으로 인하여 데이터가 변동되도 각 시점간의 snapshot 을 이용하여 일관된 데이터를 조회 및 변동 할 수 있다.
      
      
    • 위의 방식으로 인하여 gap lock 을 사용하므로 이 lock 이 발생 할 수 있으며
      select for update, update, delete 구문 실행 후, commit, rollback 및 다양한 상황에서 조건에 따라 record lock 도 발생 가능하다.
      
      
    • 조건에 따라 index range scan lock 도 발생하기 때문에 다른 세션으로 부터 들어오는 create select, insert select 방식의 조건 데이터 조회 후 기입 방식도 lock 이 걸릴수 있다.
      (기입 시, 조건 데이터 조회에 따른 index scan 을 발생 시킬수도 있기 때문)
      
      
  • SERIALIZABLE (직렬화)
    
    
    • 격리성이 제일 높은 단계다.
      
      
    • 작동구조는 REPEATABLE READ 와 유사하지만 아래에 설명될 일련의 트랜잭션 기입 및 조회가 동시에 이뤄질 시
      발생 할 수 있는 Serialization Anomaly 를 방지하기 위하여 동시적으로 데이터 변동으로 인한 상이성이 보이면 아래의 에러를 발생시킨다.
      
      ERROR: could not serialize access due to concurrent update
      
      
• 공식 DOC 에서는 아래표와 같이 각 Isolation Level 에 따른 데이터 기입, 조회 정합 이상 여부를 아래와 같이 정리하였다. 4개의 이상여부는 아래와 같이 설명되어 있다.
  
  
  • Dirty Read : 커밋되지 않은 데이터가 조회되는 현상
    
    
  • Nonrepeatable Read : 기존에 조회되었던 데이터 형상이 다른 트랜잭션으로 인해 변경되어서 변경된 데이터가 조회되는 현상
    
    
  • Phantom Read : 조건에 따라 수행된 쿼리를 다시 실행 시, 그 시간동안 일부데이터가 다른트랜잭션에 의해 변경 되어서 처음 수행되었던 쿼리의 결과와 상이한 현상 (ex : 첫번째 수행시에 보이지 않았던 레코드가 두번째에서 보이는 현상)
    
    
  • Serialization Anomaly : 일련의 트랜잭션 단위를 수행한 결과가 순서대로 수행했을 시 확인되는 트랜잭션들의 결과와 상이한 현상.

Isolation Level	Dirty Read	Nonrepeatable Read	Phantom Read	Serialization Anomaly
Read uncommitted	Allowed, but not in PG	Possible	Possible	Possible
Read committed	Not possible	Possible	Possible	Possible
Repeatable read	Not possible	Not possible	Allowed, but not in PG	Possible
Serializable	Not possible	Not possible	Not possible	Not possible

 

• MySQL / MariaDB 처럼 세션 단위로 조절 할 수 있으나 SET 으로 수행 시, 경고가 발생하면서 수행이 되지 않기에 BEGIN 을 사용 하여야 한다.
  또한, 이를 조절 할 때 기존에 수행되고 있는 데이터 변경관련 쿼리들이 있다면 변경 할 수 없다.
  
  

 

• PostgreSQL / PPAS 만의 feature 로 Repeatable Read Level 일 시, snapshot 으로 mvcc 를 관리하는 원리에 따라 특정 트랜잭션에 대한 snapshot 배정 및 해당 버전에서의 트랜잭션 상태 수정이 가능하다. 단 이를 사용하려면 기존에 트랜잭션이 수행되면서 이에 따른 snapshot 및 version 을 받은 상태여야 한다.