[MySQL] concurrency control 기초1 (schedule, serializability)

참고 자료 

유투브 쉬운코드 동시성 제어

여러가지 트랜잭션 실행 케이스 

트랜잭션1 K가 H에게 20만원 입금  

트랜잭션2 H가 자신 계좌에 30만원 입금 

 

해당 2개의 트랜잭션은 여러 형태의 실행이 가능할 수 있다. 

 

CASE1

 

CASE2

 

CASE3

 

CASE4 (Lost Update)

operation 

실행된 각 쿼리를 의미한다. 

 

각 CASE를 operation 간소화 

r1(K) 의미: READ / 트랜잭션1 / K 계좌 

c1 의미: 트랜잭션1 commit

 

Schedule 개념 

여러 트랜잭션들이 동시에 실행될 때 각 트랜잭션에 속한 operation들의 실행 순서

각 트랜잭션 내의 operations들의 순서는 바뀌지 않는다.

 

Serial Schedule 개념 

CASE1, CASE2 같이 동시에 실행된 트랜잭션들이 겹치지 않고 하나씩 실행되는 schedule을 Serial Schedule 이라고 한다. 

 

Nonserial Schedule 개념 

CASE3, CASE4 같이 동시에 실행된 트랜잭션들이 겹쳐서 실행되는 schedule을 Nonserial Schedule 이라고 한다. 

 

Serial Schedule 특징

Serial Schedule은 각 트랜잭션이 순차적으로 진행되니 데이터 정합성 문제는 없다. 

하지만 read/write 같은 스토리지 엔진을 통한 I/O 작업 또한 cpu는 놀게된다. 

그러니 현실적으로 사용할 수 없는 방식이다. 

 

Nonserial Schedule 특징

read/write 같은 작업을 할 때 다른 트랜잭션 작업을 cpu가 진행할 수 있다. 

동시성이 높아져서 같은 시간 동안 더 많은 트랜잭션들을 처리할 수 있다.

하지만 트랜잭션들이 어떤 형태로 겹쳐서 실행되는지에 따라 이상한 결과가 나올 수 있다.

→ CASE4 

Nonserial Schedule 안전하게 사용하고 싶다

고민거리 

nonserial schedule로 실행해도 이상한 결과가 나오지 않을 수 있는 방법을 연구하기 시작 

 

아이디어

serial schedule과 동일한 nonserial schedule을 실행하면 된다. 

그렇다면 'schedule이 동일하다' 의미의 정의가 필요하다

 

Conflict of two operations

다음 세 가지 조건을 모두 만족하면 conflict

1. 서로 다른 트랜잭션 소속 

2. 같은 데이터에 접근 

3. 최소 하나는 write operation 

 

CASE3의 conflict

 

w2(H) → r1(H): write / read conflict

r2(H) → w1(H): read / write conflict

w2(H) → w1(H): write / write conflict

 

conflict operation의 순서가 바뀌면 결과 또한 달라진다.

ex) w2(H)와 r1(H)가 바뀌면 Lost Update 현상 발생

 

Conflict equivalent for two schedules

다음 조건을 모두 만족하면 conflict equivalent

1. 두 schedule은 같은 트랜잭션을 가진다. 

2. 어떤 conflicting operations의 순서도 양쪽 schedule 모두 동일하다

 

Conflict equivalent example

두 케이스의 conflict 순서가 동일 

w2(H) → r1(H): write / read conflict

r2(H) → w1(H): read / write conflict

w2(H) → w1(H): write / write conflict

 

그런데 CASE2는 serial schedule 이다. 

즉 CASE3는 nonserial schedule 이지만 CASE2와 conflict equivalent 하다 

그래서 CASE3는 conflict serializable 하다 

즉 정상적인 결과가 나온다 

 

반면 CASE4는 어떤 serial schedule 과도 conflict equivalent 하지 않아서 정상적인 결과가 나오지 않는다.  

 

정리 

nonserial schedule을 사용을 안전하게 사용하고 싶으면 conflict serializable한 nonserial schedule을 허용하자 

 

하지만 실제 RDBMS에서는 이 방식을 사용하지 않는다.

예제에서는 단 2개의 트랜잭션을 통해 확인하지만 실제 운용에서는 수많은 트랜잭션이 발생하는데 

해당 schedule이 conflict serializable인지 판단하기는 어렵기 때문이다.