schedule
: 여러 transaction들이 동시에 실행될 때 각 transaction에 속한 operation들의 실행 순서
각 transaction 내의 operation들의 순서는 바뀌지 않는다.
데이터를 읽고 쓰는 구문 하나하나를 operation이라 함.
operation을 간략하게 어떤 구문이고(read,write,commit..) 어떤 트랜젝션이고(1번 트랜잭션, 2번 트랜잭션, 2번의 commit...) 무슨 데이터(K사용자의 데이터, H사용자의 데이터)를 활용하는지 표현하여 순서로 나타낸 것이 schedule
-
Serial schedule
: transaction들이 겹치지 않고 한 번에 하나씩 실행되는 schedule.
한 번에 하나의 트랜잭션만 실행되기 때문에 여러 트랜잭션을 처리하는 좋은 성능을 낼 수 없고 현실적으로 사용할 수 없는 방식.
ex) 트랜잭션 1번에 대한 operation들이 실행된 후, 트랜잭션 2번에 대한 operation들이 실행되는 것.
-
Nonserial schedule
: transaction들이 겹쳐서 실행되는 schedule.
동시성이 높아져서 같은 시간동안 더 많은 트랜잭션들을 처리할 수 있다.
단점: transaction들이 어떤 형태로 겹쳐서 실행되는지에 따라 이상한 결과가 나올 수 있음.
ex) 시리얼 스케줄과 반대로 1번 트랜잭션이 실행됐다가 2번 트랜잭선이 실행되고 다시 1번 트랜잭션이 실행되는 순서.
Nonserial schedule에서의 단점을 해결하려면?
conflict serializable한 nonserial schedule을 허용하는 방법.
-
conflict(=충돌)
: 두 개의 operation에 대해서 사용하는 것.
conflict operation은 순서가 바뀌면 결과도 바뀜.
두 개의 oeration이 3가지 조건을 모두 만족해야함.
1. 서로 다른 transaction 소속
2. 같은 데이터에 접근
3. 최소 하나는 write operation -
conflict equivalent(=동등한)
: 2가지 조건 만족해야함.
1. 다른 스케줄은 같은 트랜잭션들을 가진다.
2. 어떤 conflicting operation의 순서도 양쪽 스케줄 모두 동일하다.
스케줄 2번을 보면 serial schedule임. serial schedule과 conflict equivalent일 때 conflict serializable이라 함.
따라서 nonserial 스케줄인 3번은 conflict serializable하다. 그래서 nonserial 스케줄임에도 불구하고 정상적인 결과를 도출해낼 수 있음.
그럼 RDBMS에서 어떻게 구현할까?
여러 트랜잭션이 실행될 때마다 해당 스케줄이 conflict serializable인지 확인하면 될 것 같지만 실제로는 못함.
왜?
요청이 많아지면 동시에 실행될 수 있는 트랜잭션 수가 많아지기 때문에 그 트랜잭션의 스케줄이 각각 conflict serializable한지 확인하기엔 비용이 엄청남.
따라서 여러 transaction을 동시에 실행해도 schedule이 conflict serializable하도록 보장하는 프로토콜을 적용함.
즉, 실행하고 나서 확인하는 순서가 아닌 아예 conflict serializable한 스케줄만 실행될 수 있도록 하는 것!
