You will be fine

<Database> 트랜잭션의 Isolation Level 과 동시성 제어

by BFine
반응형

가. 동시에 많은 요청이 들어온다면?

 a. 트랜잭션

  -  대부분의 시스템들이 멀티스레드 형태로 동시처리를 하고있다.  또한 현재는 다양한 기기들이 존재하는 만큼 많은 요청이 발생한다.

  -  이 많은 요청들은 어플리케이션으로 흘러들어가고 필요한 데이터들을 DB로부터 가져오고 업데이트하고 추가하는 작업을 한다.

  -  이 데이터에 대한 검색, 업데이트, 추가, 삭제 쿼리를 하나씩 DB에 반영하는 것이 아니고 하나의 묶음단위로 처리가 되는데 이를 DB 트랜잭션이라고 부른다.

 

 b. 동시성 제어

  -  웹어플리케이션에서 한번에 한명씩 처리하는 것이 아니라 수용할 수 있는만큼 동시에 처리를 한다. 그와 동시에 많은 트랜잭션이 발생한다.

  -  어느 시스템이나 데이터의 정확성이 가장 중요하다. 만약에 A라는 제품을 샀는데 갑자기 B 제품의 가격이 나오거나 한다면 큰 문제가 된다.

  -  이를 방지하기위해 테이블이나 행단위 등에 Lock 걸어서 요청들에 대해 배제하여 데이터를 보호한다.

      => "이정도면 충분한게 아닌가?" 라는 생각이 들지만 아쉽게도 여기서 끝나는게 아니라 트랜잭션에 대한 동시성 제어도 필요하다.

 

 

나.  Isolation  

 a. ACID 중 I

  - Atomic(원자성)        : 하나의 트랜잭션의 내용은 모두 반영되거나 전부 반영이 되지않아야 한다.

  - Concurrency(일관성) : 트랜잭션이 실행전이나 이후에나 영향이 없는 데이터에 대해서는 항상 일관된 상태를 유지해야한다.

  - Duration(지속성)      : 실행이 완료된 트랜잭션은 영구적으로 반영되어야 한다.

  - 아마 한번쯤은 달달 외워보았을 트랜잭션의 4가지 요소인 ACID의 핵심인 I(Isolation)에 대해서 확인해보자. 

 

 b. Isolation 

  -  고립성이라고 불리우는 이 특성은 수행중인 트랜잭션에 다른 트랜잭션이 영향을 주면 안되며 독립적 작동해야 한다.

  -  "흠 그러면 한번에 하나씩 수행하면 되겠네!" 라고 할수도 있지만 많은 트랜잭션이 발생하는 서비스에는 성능저하라는 큰 문제가 발생한다. 

  -  이를 해결 하기위해 Isolation Level이 존재한다.

 

 c. lsolation Level

  -  Isolation level은 4가지로 구분되어된다. 각각의 내용과 문제점을 알아보자.

 

    1. Uncommitted Read

       -  말 그대로 Commit이 이루어지지 않은 데이터를 읽을 수 있다. 

       -  이상현상 : 읽어왔는데 해당 트랜잭션에 문제가 있어서 롤백이 되었다.. 이렇게 없는 값을 읽는 것을 Dirty Read라고 한다.

 

    2. Committed Read

       -  이 친구도 마찬가지로 말그대로 Commit한 데이터만 읽어온다. "여기까지만 하면 문제없는거 아닌가?" 라는 생각이 들지만 아쉽게도 아니다.

       -  이상현상 : 하나의 트랜잭션에 여러번 반복 읽기 작업이 있는 경우 그 사이에 다른 트랜잭션이 와서 Update 하는 경우 데이터가

            처음 읽었을때와 달라진다. 이를 Non-Repetable Read라고 한다.

       -  보통 RDB의 Default 레벨으로 설정되어있다.

 

    3. Repeatable Read

       -  트랜잭션이 시작하기 전에 Commit된 변경 내용에 대해서만 읽어온다.

       -  어떻게 불러올 수 있을까? 일반적으로 트랜잭션에 ID를 부여하고 지금 실행하려는 트랜잭션의 ID보다 낮은 값에 대해서 읽어온다.

       -  이상현상 : 역시나 하나의 트랜잭션에 여러번 반복 읽기하는 경우 그 사이에 다른 트랜잭션이 와서 Insert or delete 를 하는 경우 데이터가

           처음 읽었을때와 개수 달라지는 경우가 있을 수 있다. 이를 Pantom Read라고 한다.

 

    4. Serializable

        -  하나의 트랜잭션에서 사용하는 데이터에 대해서 다른 트랜잭션이 CRUD 할 수 없는 완전 배제 형태이다.

          =>  위의 Repeatable Read에서 Insert & Delete 까지 할 수 없도록 하는것과 같다.    

        -  트랜잭션의 무결성을 보장하지만 배제로 인한 성능저하가 발생하기 때문에 대용량 실시간 처리에는 적합하지 않다.   

 

  - 정리하면 레벨이 높아질수록 데이터의 정확성은 높아지지만 동시에 처리하기에는 어려워지므로 서비스에 맞는 level을 설정해야한다.

반응형

블로그의 정보

57개월 BackEnd

BFine

활동하기