Intro
이번에 다룰 개념인 Serializability 와 Recoverable 는 만약 트랜잭션을 동시에 실행할 경우, 이상 현상이 일어나지 않도록 하는 중요한 특성이다. 트랜잭션을 말할때 꼭 알아야 하는 내용이므로 한번 정리해보자!
Serializability
DBMS는 여러 사용자의 요청을 동시에 수행하는 것이 필수적이다. 하지만 동시에 일어나는 경우 트랜잭션간의 간섭을 없애고 데이터 정합성을 일관성있게 제공해야만한다. 이를 Isolation 을 보장한다고 흔히 표현하는데, 이를 다른말로 하면 Serializability가 보장된다고 표현할 수 있다. Serializability는 한국말로 직역하면 직렬화를 의미하는데, 말 그대로 동시에 온 트랜잭션 요청을 순차적인 직렬화를 시켜 트랜잭션간의 간섭을 없애고 데이터간의 정합성을 맞추는 것을 의미한다.
🙋 아니 그래서 그걸 어케 하냐고요
🤖 삐빅..이제부터 알아BOZA
Schedule
Schedule은 다수의 트랜잭션이 동시에 실행될 때 그 트랜잭션들에 속한 operation들의 실행 순서를 의미한다. 예를 들어 T1,T2,T3가 동시에 실행된다면(여기서 동시는 정말 동시를 의미한다.), 내부의 operation이 겹쳐서 실행될 때 어떻게 실행되냐에 따라 실행결과가 다르게 나타날 수 있기때문에 DBMS는 Schedule을 serial schedule , non-serial schedule 로 구분한다.
non-serial schedule
Interleave 실행기법을 통해 트랜잭션 내부 연산이 번갈아가면서 병렬로 실행되는 스케줄 기법을 의미한다.
🙋 아니 인터리브가 뭡니까?
🤖 서로 다른 memory bank에 번갈아 가며 가용성을 높이는 메모리 기법입니당.
🙋 아니...좀 쉽게 설명해봐 이 깡통아
🤖 ... 10명이 화장실 1개를 쓰면 어떡함? 1명 들어가면 화장실 못쓰지? 그니까 화장실을 늘려서 번갈아가게 들어가면 1개의 화장실을 써도 다음 사람이 다른 화장실 들어가면 되니까 가용성이 높아지자너
👍
이 방법은 병렬적으로 처리하기 때문에 동시성이 높아지는 장점이 있다. 즉 다른 트랜잭션이 I/O 작업 등 시간이 소요되는 작업을 하는동안 다른 작업을 수행할 수 있다. 하지만, 단점은 Serializability 를 보장하지 않기 때문에 순서가 바뀜으로서 의도치않은 결과값이 나올 수 있다.
serial schedule
여러 트랜잭션이 들어와도 각 트랜잭션별로 구분해서 겹치지않도록 하고, 한 트랜잭션이 모두 실행되면 다른 트랜잭션을 실행하는 기법이다.
🤖 화장실이 하나란 뜻 ㅎ..
이 기법의 장점은 명확하다. 순서를 완벽하게 보장할 수있다는 점이다. 반면에 단점도 명확하다. 바로 성능이다. 예를들어 operation이 디스크 I/O가 필요하다면, 끝날 때까지 다른 트랜잭션을 실행할 수 없기 때문에 모든 트랜잭션들이 CPU보다 훨 느린 I/O가 끝날때 까지 기다려야한다.. (그래서 현실적으로 잘 안씀.)
🤬 아니 둘다 치명적인 약점이 있는데, 그러면 뭘 쓰라는거에요?!
🤖 그래서 나온게 있죵.
⭐️ Serializability scedule
위의 두가지 방법은 서로 매우 치명적인 trade-off가 있다. 그래서 이를 해결하기 위한 기법으로, 성능 개선을 위해 non-serial schedule를 사용하면서도 serial schedule 과 동일한 결과가 나올 수 있도록한다. 이를 conflict serializable 이라고도 하고 serial schedule 과 conflict equivalent 하다고 표현한다.
🙋 conflict 가 뭔데 이놈아
🤖 후.. 자세히 설명해줌.
Conflict
두개의 operation이 충돌하는 것을 의미한다. 여기서 충돌은 아래 세가지 조건을 충족하면 충돌이라고 한다.
1. operation이 서로 다른 트랜잭션에 속하는 경우
2. operation이 같은 데이터에 작업하는 경우
3. 둘 중 하나의 operation이 쓰기 작업하는 경우
🙋 전혀 이해를 못하겠는데요?
🤖 예를 들어보자.. 아래와 같은 경우를 의미해
1. R1(A), W2(B) = read는 A에 대한 작업, write는 B에 대한 작업
2. R1(A), W2(A) = read는 A에 대한 작업, write는 A에 대한 작업
3. W1(A), W2(A) = write는 A에 대한 작업, write는 A에 대한 작업
🙋 아니 그런데 이게 뭐가 문제냐니까??
🤖 두 개의 트랜잭션이 동시에 처리될때 이 경우는 실행 순서가 바뀌면 서로 실행결과가 바뀌니까..
👍
Conflict equivalent
이 의미는 아래의 두 조건을 충족할 경우를 의미한다.
- 같은 트랜잭션들의 operation 들로 구성된 schedule
- 양쪽 트랜잭션 내의 conflicting operation의 실행순서가 동일
🙋 알지?뭔말할지?
🤖 ... 예를 들어보자 아래의 두 스캐줄이 있을 경우
S1: R1(A), W1(A), R2(A), W2(A), R1(B), W1(B), R2(B), W2(B)
S2: R1(A), W1(A), R1(B), W2(B), R2(A), W1(A), R2(B), W2(B)
S1의 경우, conflict 가 일어날 데이터 순서는 아래와 같다.
- R1(A) -> W2(A)
- W1(A) -> R2(A)
- W1(A) -> W2(A)
- R1(B) -> W2(B)
- W1(B) -> R2(B)
- W1(B) -> W2(B)
R2(A), R1(B)의 순서만 바뀌었고, conflict operation의 순서는 그대로기 때문에 Conflict equivalent 이라 표현한다.
🙋 ... 예시가 더 어려운데요?? 한줄 요약해줘
🤖 ... conflict 가 일어날 거 같은 실행은 순서 고정해둔단거여...
Recoverability
Recoverability 는 트랜잭션이 실패했을 때의 회복 가능성을 의미한다. 트랜잭션은 하드웨어 이슈, 시스템 충돌, 소프트웨어 이슈등 다양한 이유로 중간에 실패할 수 있는데, 이때도 트랜잭션은 atomicity가 보장 돼야 하기 때문에 트랜잭션이 실패하면 트랜잭션 이전 상태로 복원될 수 있어야한다. 흔히 Rollback이라고 표현하는데,
Recoverability은 한마디로 Rollback 에 이상현상 없는가? 를 의미한다. DBMS는 스케줄이 recoverable 하도록 보장해야하며 recoverable한 스케줄이 무엇인지 알아보자
irrecoverable schedule
irrecoverable schedule 이란 롤백해도 이전 상태로 회복 불가능한 스케줄을 의미한다. 이러한 스케줄은 DBMS에서 허용하면 안되기 때문에 어떤 경우에 스케줄이 irrecoverable 한지 보자
Dirty read는 위와 같이 T1의 트랜잭션이 작업이 다 끝나지 않았지만, T2에서 트랜잭션에서 작업 내용을 보는 경우를 의미한다. 위의 예시를 보면, T1이 중간에 실패해 롤백을 하게 되면 T2는 유효하지 않은 데이터를 읽고 고친 후 commit 까지 진행한 상태라 Dirty Data를 가진 상태로 롤백하지 못하는 경우를 irrecoverable schedule라고 표현한다.
🙋 그러면 dirty read 만 안하면 되는건가요?
🤖 그러면 트랜잭션 하나만 하는거랑 다를바 없음..
recoverable schedule
recoverable schedule 이란 트랜잭션은 자신이 읽고있는 데이터를 변경하고 있는 다른 트랜잭션들이 모두 커밋, 롤백 되기 전까지 커밋하지 않는 스케줄을 의미한다.
예를 들어 T1이 T2가 변경하고 쓴 값을 읽는다면 T2가 커밋된 후에나 T1이 커밋되는 경우를 의미한다. 만약 T1 -> T2 -> T3 -> T4 의 데이터를 사용하고 있다면, T4가 커밋 혹은 롤백 되기 전까지 이전 트랜잭션들이 기다리는 것을 의미한다.
🙋 아니 근데 커밋되는거야 뭐 그렇다고 쳐도 rollback 하면 너무 비용이 큰데..?
🤖 아주 좋은 지적. 그걸 cascading rollback이라고 하고 이를 방지하기 위해 cascadeless schedule 이라고 한다.
cascadeless schedule
cascadeless schedule은 데이터를 W 한 트랜잭션이 커밋 혹은 롤백된 뒤에만 데이터를 읽을 수 있는 스케줄을 의미한다.
strict scedule
하지만 cascadeless schedule 은 read를 하지 않는 스케줄이고 write까지 막지는 않는다. 만약
W1(A) -> W2(A) -> W2 Commit -> W1 rollback
같은 순서라면, W1이 롤백하면서 W1이 발생하기 전의 데이터로 복구 되면서 W2가 커밋한 데이터가 사라지는 경우가 발생할 수 있다. 하지만 위 스케줄은 read자체가 없기 때문에 cascadeless 하다고 볼 수 있다.
여기에 추가적으로 보강해 읽지도 않을 뿐, 쓰지도 못하게 하는 경우를 strict scedule 라고 한다.
