동시성제어(트랜잭션)

 

 

- 다수의 트랜잭션이 경쟁시 발생할 수 있는 문제

  - Dirty Read : 아직 트랜잭션이 완료되지 않은 상황에서 데이터에 접근을 허용할 경우 발생할 수 있는 데이터 불일치

  - Non-Repeatable Read : 한 트랜잭션에서 같은 쿼리를 두번 실행했을 때 발생할 수 있는 데이터 불일치

  - Phantom Read : 한 트랜잭션에서 일정 범위의 레코드를 두번 이상 읽을 때 발생하는 데이터 불일치

 

- 트랜잭션 격리 수준 (isolation level)

  - DEFAULT : 기본 격리 수준 (DB isolation level 따름)

  - READ_UNCOMMITTED (level 0) : 커밋되지 않은 데이터에 대한 읽기 허용 (Dirty Read 발생 할 수 있음)

  - READ_COMMITTED (level 1) : 트랜잭션이 커밋된 확정 데이터만 읽기 허용  (Dirty Read 방지)

  - REPEATABLE_READ (level 2) : 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸리므로 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정이 불가 (Non-Repeatable Read 방지)

  - SERIALIZABLE (level 3) : 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸리므로 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정 및 입력이 불가 (Phantom Read 방지 (※ 격리 수준이 올라갈 수록 성능 저하의 우려가 있음)

 

 

---------------------------------

우리는 오라클을 사용하고 사용자가 많지 않기때문에 동시성 제어를 고려할 필요가없음

실시간으로 초당 수백 수천건의 트래픽이 들어오게되면 데이터의 동시성제어가 중요하게됨

※오라클과 타 디비가 다른점은 추후 설명하겠음(엄청난차이가있어서 금융권의 주요데이터는 비싸도 오라클을 사용할수밖에없음)

https://blog.daum.net/fasterbh/4571927

 

<ORACLE 제외한 타비기기준으로 설명>

기본적으로  DB는 트랜잭션 레벨 READ_COMMITTED 으로 설정함

트랜잭션이 끝난 데이터만 읽겠다는 소리임(데이터의 신뢰성이 중요하니까)

 

 

그런데 실시간으로 대량의 데이터가 들어오게되면 INSERT UPDATE가 빈번하게 일어남

이때 트랜잭션이 걸리면서 table lock이 걸림

트랜잭션이 지속적으로 발생하여 SELECT도 안됨

 

DB는 가용성과 신뢰성을 동시에 고민해야되는데

가용성에 문제가 생김(LOCK때문에 조회가 되지않으니까)

 

이럴 경우에는 트랜잭션이 진행중이라도 데이터를 읽을 수 있는 상태인 READ_UNCOMMITTED로 Isolation level을 변경할수밖에 없음

COMMIT되지 않은 내용도 읽겠다는 소리임 (조회가 안되면 안되니까)

 

이럴때 발생하는게 drity read임

rollback시킬수도 있는 데이터지만 위험성을 감소하더라도 가용성을 높이겠다는 소리임

 

 

이게 drity read