참고 자료
여러가지 트랜잭션 실행 케이스
트랜잭션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인지 판단하기는 어렵기 때문이다.
'DataBase > MySQL' 카테고리의 다른 글
[MySQL] 트랜잭션 격리 레벨 (6) | 2024.11.14 |
---|---|
[MySQL] concurrency control 기초2 (recoverability) (1) | 2024.11.13 |
[MySQL] 트랜잭션과 ACID (0) | 2024.11.13 |
[MySQL] 트리거 trigger (3) | 2024.11.12 |
[MySQL] 스토어드 프로시저 stored procedure (4) | 2024.11.12 |