ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 트랜잭션 격리 수준(Isolation level)
    데이터베이스 2023. 2. 26. 22:31

     

    트랜잭션의 격리 수준(Isolation level)이란 

    동시에 여러 트랜잭션이 처리될 때, 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있도록 허용할지 말지를 결정하는 것이다.

     

     

    트랜잭션의 격리 수준 은 다음과 같은 4가지가 있다.

     

    • READ UNCOMMITTED(커밋 전 읽기)
    • READ COMMITTED(커밋 후 읽기)
    • REPEATABLE READ(반복 읽기)
    • SERIALIZABLE(직렬화 가능)

     

    1. READ UNCOMMITTED

     각 트랜잭션에서의 변경 내용이 commit 이나 rollback 여부에 상관없이 다른 트랜잭션에서 보여지게 되는 수준으로써

    거의 쓰지 않는 격리 수준이라고 볼 수 있다.

     

    2. READ COMMITTED

     PostgreSQL 에서 기본으로 사용되고 있는 수준으로써,

    온라인 서비스에서 가장 많이 선택되는 격리 수준이다. 

     

     

    위 이미지만 보더라도 이 격리 수준이 어떻게 동작할 수 있는 내용인데,

    사용자 A 에서 트랜잭션을 먼저 시작하고, 사용자 B가 도중에 새로운 트랜잭션을 진행했을 때 사용자 B가 어떻게 조회되는지 알 수 있는 그림이다. 

     사용자 A가 emp_no = 50000인 사원의 first_name을 "JuBal" 에서 "Toto"로 수정을 진행하는데, 

    변경 되기 전에 UNDO 영역에 emp_no = 50000인 사원 first_name을 "JuBal" 값으로 백업을 시킨 후, 

    사용자 A가 commit 되기 전에 사용자 B가 emp_no = 50000 을 조회하게 되면

    변경한 "Toto" 값이 아닌 위에서 언급한 UNDO 영역에 있는 "JuBal" 값으로 조회하는 것을 볼 수 있다.

     

     이렇게 진행 함으로써, 더티 리드를 막을 수 있고, 같은 트랜잭션 안에서 내용을 유지한다는 것을 알 수 있다.

     

    UNDO 영역의 데이터는 크게 두가지 용도로 사용된다.

    1) 트랜잭션의 롤백 대비용

    2) 트랜잭션의 격리 수준을 유지하면서 높은 동시성 제공

     

    3. REPEATABLE READ

    데이터 조회 시 항상 동일한 데이터 응답을 보장하는 격리 수준

     

     

    사용자 B 가 먼저 emp_no = 50000인 사원을 조회해 보면 "JuBal"값으로 조회가 되는 것으로 확인하고,

    이후 사용자 A가 새로운 트랜잭션으로 "Toto"로 값을 변경 후, commit 을 하더라도

     

    사용자 B는 새로 변경한 트랜잭션보다 작은 트랜잭션에서 수행을 하면 처음과 같은 값인 "JuBal"값으로 조회가 되는 

    것을 알 수 있다. 

     이전에서 얘기한 READ COMMITTED 수준과 마찬가지로 UNDO 영역에 데이터 백업하는 것은 동일하지만 

    REPEATABLEREAD 는 MVCC 라고 하는

    여러 버전별로 제공하여 Lock을 사용하지 않는 일관된 읽기를 제공하는 것이라고 한다. 

    Lock을 사용하지 않는 사용 이유는 베타적 락으로 인해 다른 트랜잭션이 해당 데이터를 read하기 위해 기다리는 상황이 발생하고, 이런 트랜잭션들이 계속 된다면 성능 저하로 이어지기 때문이다.

    그런데, 문제는 트랜잭션을 시작한 후 오랜 시간동안 트랜잭션을 종료를 하지 않으면 UNDO영역이 무한정 커질 수 있고, 이렇게 백업된 레코드가 많아질수록 데이터베이스의 처리 성능이 떨어질 수 있다.

     

    4. SERIALIZABLE

    한 트랜잭션에서 읽고 쓰는 레코드를 다른 트랜잭션에서는 절대 접근할 수 없는 가장 엄격한 격리 수준

    매우 엄격한 수준으로 해당 행에 대해 격리시키고 이후 트랜잭션이 해당 행에 대해 발생한다면 기다려야 되는 방식이라

    동시성 이슈는 없지만 성능이 가장 떨어져 실무에서 쓰기 어렵다.

     

     

    * 출처: 데이터 중심 애플리케이션 설계

    * 출처: https://zzang9ha.tistory.com/381

    '데이터베이스' 카테고리의 다른 글

    sql 특수 상태 검색(조건 상태 검색)에 관한 글  (0) 2022.08.07
    170911_TIL  (0) 2017.09.12
    170904_TIL  (0) 2017.09.12
Designed by Tistory.