serializability(직렬화)
동시에 실행되는 트랜잭션 요청을 순차적인 직렬화로 만들어 트랜잭션 간 간섭을 없애고, 데이터간의 정합성을 맞추는 것
schedule 이란
여러 트랜잭션들이 동시에 실행될 때 각 트랜잭션에 속한 operation들의 실행 순서
ex) 트랜잭션 1: A가 B에게 20만원을 이체, 트랜잭션 2: B는 본인 계좌에 30만원 입금
- schedul 1) 트랜잭션 1 수행 후, 트랜잭션 2 수행
- r1(A) → w1(A) → r1(B) → w1(B) → commit 1 → r2(B) → w2(B) → commit 2
- schedul 2) 트랜잭션 2 수행 후, 트랜잭션 1 수행
- r2(B) → w2(B) → commit 2 → r1(A) → w1(A) → r1(B) → w1(B) → commit 1
- schedul 3) 트랜잭션 동시 수행
- r1(A) → w1(A) → r2(B) → w2(B) → commit 2 → r1(B) → w1(B) → commit 1
- schedul 4) 트랜잭션 동시 수행
- r1(A) → w1(A) → r1(B) → r2(B) → w2(B) → commit 2 → w1(B) → commit 1
- 등등 여러 스케줄 존재함! 각 트랜잭션 내의 operation 순서는 바뀌지 X
Serial schedule(직렬 스케줄)
여러 트랜잭션들이 순차적으로 실행되는 스케줄
- 위에서 schedule1과 schedule2가 serial schedule임
- 한 번에 하나의 트랜잭션만 실행되기 때문에 성능이 좋지 않지만, 이상한 결과가 나올 확률이 적음
Non-serial schedule(병렬적 스케줄)
여러 트랜잭션들이 겹쳐서 실행되는 스케줄
- 위에서 schedule3과 schedule4가 non-serial schedule임
- 트랜잭션들이 겹쳐서 실행되므로 동시성이 높아져 같은 시간 동안 더 많은 트랜잭션들을 처리할 수 있어 성능이 좋지만, 이상한 결과가 나올 확률이 높다.
❗️동시성을 제공하면서 이상한 결과를 초래하지 않는 트랜잭션 수행을 위해 나온 것이 바로 "Serialzability schedule"이다.
Serialzability schedule
serial 스케줄과 conflict equivalent한 스케줄
- 동시성 제어는 어떤 스케줄도 serializable하게 만든다. → isolation과 밀접한 관계가 있다.
conflict: 두 operation이 충돌하는 상황을 의미하며, 아래 3가지 조건을 충족하면 conflict 이다.
1. 서로 다른 트랜잭션 소속
2. 같은 데이터에 접근
3. 최소 하나는 쓰기(write) 작업이어야 함
r1(A) → w1(A) → r2(B) → w2(B) → commit 2 → r1(B) → w1(B) → commit 1
r2(B)와 w1(B), w2(B)와 r1(B), w2(B)와 w1(B)는 conflict이다.- conflict는 순서가 바뀌면 결과가 바뀐다.
만약, w2(B) → r1(B) 순서를 r1(B) → w2(B)로 바꾸면 결과가 달라진다.
conflict equivalent: 두 개의 스케줄이 아래 2가지 조건을 충족하면 conflict equivalent 이다.
1. 두 스케줄은 같은 트랜잭션들을 가져야 한다.
2. 모든 conflicting operations의 순서가 양쪽 스케줄 모두 동일하다.
schedule 2) r2(B) → w2(B) → commit 2 → r1(A) → w1(A) → r1(B) → w1(B) → commit 1
schedule 2) r1(A) → w1(A) → r2(B) → w2(B) → commit 2 → r1(B) → w1(B) → commit 1
1. 두 스케줄 모두 같은 트랜잭션들을 가진다.
2. r2(B)와 w1(B), w2(B)와 r1(B), w2(B)와 w1(B)인 conflicting operations 순서가 양쪽 스케줄에서 모두 동일하다.
따라서, 두 스케줄은 conflict equivalent하다.conflict serializable: serial 스케줄과 conflict equivalent한 스케줄
Recoverability(회복성)
트랜잭션이 실패했을 때(Rollback)의 회복 가능성
- 즉, 롤백이 발생했을 때 이전 상태로 회복 가능하도록 하는 특성
unrecoverable schedule
롤백을 해도 이전 상태로 회복 불가능한 스케줄 → DBMS는 이러한 스케줄을 허용하면 X
- 스케줄 내에서 commit된 트랜잭션이 rollback된 트랜잭션이 write한 데이터를 읽은 상황에서 발생!
ex) 트랜잭션 1: A(100만원)가 B(200만원)에게 20만원을 이체, 트랜잭션 2: B(200만원)는 본인 계좌에 30만원 입금
schedule) r1(A) → w1(A) → r2(B) → w2(B) → r1(B) → w1(B) → commit 1 → abort 2(rollback)
B입장에서 잔고는 200만원이 되지만, A입장에서는 20만원이 사라지는 데이터 불일치 발생 → unrecoverable schedulerecoverable schedule
스케줄 내에서 그 어떤 트랜잭션도 자신이 읽은 데이터를 write한 트랜잭션이 먼저 commit/rollback 전까지는 commit 하지 않는 경우
schedule) r1(A) → w1(A) → r2(B) → w2(B) → r1(B) → w1(B) → commit/abort 2 → commit/abort 1
1번 트랜잭션이 2번 트랜잭션에 의존하는 상황에서 2번 트랜잭션이 commit/abort 후에 1번 트랜잭션을 commit/abort하면 회복 가능해짐
→ 즉, 의존하고 있는 트랜잭션의 수행이 완전히 종료된 후에 본인 트랜잭션 수행 종료cascading rollback
여러 트랜잭션의 rollback이 연쇄적으로 일어나는 현상
- rollback이 연쇄적으로 발생하면 처리하는 비용이 많이 든다.
schedule) r1(A) → w1(A) → r2(B) → w2(B) → r1(B) → w1(B) → abort 2(rollback) → abort 1(rollback)
1번 트랜잭션이 2번 트랜잭션에 의존하는 상황에서 2번 트랜잭션이 abort 후에 1번 트랜잭션도 abort → cascading rollback 발생cascadeless schedule
스케줄 내에서 어떤 트랜잭션도 commit되지 않은 트랜잭션들이 write한 데이터는 읽지 않는 경우
schedule) r1(A) → w1(A) → r2(B) → w2(B) → commit 2 → r1(B) → w1(B) → commit 1
1번 트랜잭션이 2번 트랜잭션에 의존하는 상황에서 2번 트랜잭션이 완료된 후 트랜잭션 1이 데이터 읽음- write한 트랜잭션이 rollback을 해도 기존 데이터를 유지하기 때문에 다른 트랜잭션의 read는 아무런 영향을 받지 않음
cascadeless schedule의 문제점
- 스케줄 내 어떤 트랜잭션도 commit되지 않은 트랜잭션들이 write한 데이터는 "읽지 않는다"에서 읽는 것만 고려해주고, 쓰는 것은 고려 X
ex) 기존 3만원인 가격인 상품을 두 사람이 동시에 낮추려고 할 때
트랜잭션 1: 1만원으로 수정, 트랜잭션 2: 2만원으로 수정
schedule) w1(product=1만원) → w2(product=2만원) → commit 2 → abort 1(rollback)
트랜잭션1이 롤백되면서 트랜잭션2가 수행한 결과가 사라짐strict schedule
스케줄 내에서 어떤 트랜잭션도 commit되지 않은 트랜잭션들이 write한 데이터는 쓰지도 읽지도 않는 경우
- cascadeless schedule의 문제 해결
schedule) w1(product=1만원) → commit/abort → w2(product=2만원) → commit 2- 롤백할 때 회복하기가 쉬움
