이 글은 쉬운코드 의 영상을 기반으로 작성된 글 입니다. 글로 이해가 잘 안되시면 위 링크로 들어가셔서 보시길 강추합니다!!
여러 트랜잭션들이 동시에 실행될 때 각 트랜잭션에 속한 operation들의 실행 순서를 schedule이라고 합니다. 여기서 operation은 하나의 쿼리문이라고 생각하면 됩니다.
그림의 두 상황의 트랜잭션이 동시에 실행됐다고 가정해봅시다. 두 트랜잭션에서 동시에 실행되면 어떤 순서로 실행될까요?
트랜잭션의 동작 순서를 조금 간략히 작성하기 위해 함축적으로 표현했습니다. 우선 schedule, operation 두 가지 개념이 나옵니다.
schedule: 여러 트랜잭션들이 동시에 실행될 때 각 트랜잭션에 속한operation들의 실행 순서operation: 하나의 실행(쿼리)
위 작성된 schedule 을 보면 트랜잭션들이 겹치지 않고 한 번에 하나씩 실행되고 있습니다. 이 땐 데이터가 유실될 일 없이 트랜잭션 단위로 실행되기 때문에 isolation 속성이 잘 지켜지는 것을 알 수 있습니다. 이런 경우를
Serial schedule 이라구 부릅니다. 모든 스케줄을 한번에 하나의 트랜잭션만 실행하면 데이터가 유실되는 문제는 막을 수 있지만 성능에 문제가 발생합니다. 무조건 한 번에 하나의 트랜잭션만 실행되기 때문에 좋은 성능을 낼 수 없고 하나의 서버가 다수의 클라이언트의 요청을 처리한다면 이 방법은 현실적으로 사용하기 어려운 방식입니다.
그렇다면 아래와 같은 상황은 어떨까요?
schedule1은 A가 B에게 송금하기 위해 B의 잔액을 조회하기 전 B가 자신의 돈을 읽는 과정이 반영되었습니다.
위 같이 트랜잭션 사이에 다른 트랜잭션의 operation 이 실행되는 것을 Nonserial schedule 이라고 부릅니다. 트랜잭션들이 겹쳐서 실행되기 때문에 동시성이 높아져서 같은 시간 동안 더 많은 트랜잭션들을 처리할 수 있습니다. 이 스케줄은 큰 단점이 있는데요. 바로 operation 의 순서에 따라 다른 결과가 나올 수 있습니다. 위 예시를 보면 schedule1 같은 경우는 Serial schedule 과 같은 결과인 B의 잔액이 20000원인 것을 볼 수 있고 반면에 schedule2 일 때에는 B의 잔액이 10000원인 것을 확인할 수 있습니다. 왜 그럴까요?
w1(B)가 커밋되기 전 r2(B)가 실행됐다.
schedule2에서 다른 결과가 나온 이유는 w1(B)보다 r2(B)가 먼저 실행됐기 때문입니다. w1(B)가 반영된 B의 잔액을 조회해야 하는데 반영되기 전 잔액을 조회하다보니 데이터가 유실되는 상황이 발생했습니다.
고민
앞서 보여드린 예시말고도 다양한 스케줄이 나올 수 있습니다. 여기서 알아야할 점은 두 상황 모두 개발자 입장에서 원치 않은 상황이라는 것 입니다. Serial schedule 은 정합성은 맞지만 성능이 떨어지고 Nonserial schedule 은 정합성이 떨어지지만 성능이 좋습니다. 정합성도 맞고 성능도 좋게 할 수 있는 방법은 없을까요?
Serial schedule과 동일한 Nonserial schedule을 실행한다.
여기서 동일하다는 개념에 대해 설명하겠습니다. 이를 위해선 Conflict of two operations라는 개념이 있습니다. 두 개의 operaion이 충돌하는 조건은 3가지 입니다.
- 두 개의 operation은 서로 다른 트랜잭션 소속
- 두 개의 operation이 같은 데이터에 접근
- 최소 하나는 write operation
앞의 w1(B)와 r2(B)는 위 3가지의 조건을 충족하기 때문에 충돌한다고 정의할 수 있습니다. 충돌한다는 것은 두 operation의 순서가 바뀌면 결과도 바뀐다는 뜻입니다.
schedule이 동일하다는 뜻은 위 충돌되는 operation 순서가 양쪽 schedule이 동일하다는 뜻입니다.
이 때 동일한 스케줄을 Conflict serializable 이라고 부르는데 이 스케줄들의 특징은 Serial schedule 과 결과가 동일하기 때문에 정합성이 맞는 schedule 입니다. 동시에 실행하지만, 정합성도 맞출 수 있는 우리가 원하는 스케줄입니다.
해결책
Conflict serializable 한 Nonserial schedule 을 허용하는 것 입니다.
그럼 이런 스케줄을 허용하기 위해 위의 예시처럼
schedule들을 비교해주고 확인해야 하나요?
아닙니다. 실제 비즈니스 로직은 위 예시처럼 간단하지 않고 꼭 2개가 아닌 다수의 트랜잭션을 동시에 실행하는 경우도 있습니다. 따라서 다수의 트랜잭션을 동시에 실행해도 항상 schedule 이 conflict seralizable 하도록 보장하는 프로토콜을 적용해주어야 합니다.
이 해결책 중 하나가 바로 isolation level 입니다.
참고 자료
