데이터베이스 - 동시성 제어

동시성 제어(Concurrency Control)

---

이전에 살펴본 트랜잭션의 개념 중 ACID 속성에서 Isolation(독립성)을 다시 생각해 보자.

독립성은 트랜잭션을 병렬적으로 처리하면서 다른 트랜잭션에 영향을 미치지 않아야 한다. 하지만 병렬적으로 실행하면 항상 문제가 되는 것이 있는데 바로 공유하고 있는 자원에 대해서 동시에 접근하게 되는 문제이다.

또한, 하나의 데이터베이스에서 하나의 작업만 수행할 수 있기 때문에 병렬적으로 처리되는 트랜잭션들을 순차적으로 수행할 필요가 생기게 되고 이러한 것을 제공하기 위해 나온 개념이 스케줄링이다.

스케줄링을 통한 동시성 제어는 DBMS 분야에서 중요한 구성 요소이다. 시스템에서 병렬로 실행되는 여러 트랜잭션 간의 일관성, 무결성 및 독립성을 유지하는 데 도움이 되기 때문이다.

스케줄링에서 여러 트랜잭션이 동시에 실행되는 경우 각 트랜잭션에 속한 작업들의 실행 순서를 Schedule이라고 한다.

DBMS에는 여러 Schedule 유형이 있는데 하나씩 살펴보자.

 

DBMS Schedule 유형

 

 

DBMS Schedule 유형

---

첫 번째로 Schedule을 연속적(Serial)인지 아니면 병렬적(Non Serial)인지를 나눌 수 있다.

 

Serial Schedules

한 트랜잭션이 다른 트랜잭션을 시작하기 전에 완전히 실행되는 경우 해당 Schedules을 Serial Schedules이라고 한다.

Serial Schedules에서 모든 트랜잭션은 차례로 실행된다. 즉, 현재 실행 중인 트랜잭션이 실행을 마칠 때까지 다른 트랜잭션 실행을 시작하지 않는다.

 

예제로 살펴보면 트랜잭션 T1과 T2가 있다고 가정했을 때 먼저 실행된 T1이 commit 할 때까지 T2는 실행되지 않는다.

이러한 Serial Schedules을 non-Interleaved 실행이라고 하는데 Interleave는 겹치다, 끼워넣다라는 의미로 하나의 트랜잭션 내에서 다른 트랜잭션이 실행할 수 있는지를 뜻한다.

 

Non-Serial Schedules

여러 트랜잭션이 동시에 실행되는 것으로 다른 트랜잭션은 이전 트랜잭션이 완료되지 않고 진행된다.

DBMS는 트랜잭션 처리 효율을 높이기 위해서 Non-Serial Schedules을 채택한다.

예제를 보면 T1의 작업이 아직 완료되지 않은 상황에서 T2가 실행되는 것을 알 수 있다.

Non-Serial Schedules에서 모든 트랜잭션 작업은 서로 섞이거나 혼합된다. Serial Schedules과는 다르게 Interleave 실행이 가능하다.

 

Non Serial-Schedules 유형

---

Non Serial-Scehdules 유형에는 Serializability에 따라서 Serializable 한 지, Non-Serializable 한 지 나뉜다.

 

• Serializability

먼저 Serializability에 대해서 알아보면 Serial 하지 않은 Schedules이 얼마나 Serializable 한 지를 판단하는 것이다.

조금은 이해하기 어려울 수 있는데 최대한 병렬적인 실행의 이점을 가지면서 얼마나 Serial 하게 수행할 수 있는지를 보는 것이다.

앞서 DBMS는 트랜잭션 처리 효율을 높이기 위해서 병렬적으로 처리할 수 있는 스케줄을 채택한다고 했는데 병렬적으로 처리되는 Schedules 중에서도 DB의 일관성을 해치지 않는 Schedules을 선택하기 위해서 DBMS는 Serializable 한 Schedules을 선택한다.

 

Serializable Schedule 유형

---

• Conflict Serializable

Conflict Serializable은 Conflict 하지 않는 작업을 교환하여 Serial Schedule로 변환하는 것을 의미하는데 Conflict란 다음의 3가지 조건을 모두 충족하는 경우를 말한다.

1. 둘 다 별도의 트랜잭션에 속한다.
2. 동일한 데이터 항목을 가지고 있다.
3. 작업 중 최소한 하나의 쓰기 작업이 포함되어 있다.

예제를 통해 살펴보면 위의 Schedule을 Serial Schedule로 변환한다고 가정해 보자.

Serial Schedule로 변환하기 위해서는 Conflict가 발생하지 않는 작업을 바꿔가면서 Serial 하게 변환하면 된다.

위의 그림과 같이 T1의 R(A)와 T2의 R(A)는 Conflict가 발생하지 않기 때문에 작업을 바꾼다.

마찬가지로 T1의 R(A)와 T2의 R(B)도 Conflict가 발생하지 않기 때문에 작업을 바꾼다.

 

마지막으로 T1의 R(A)와 T2의 W(B) 작업을 바꾸게 되는데 이때 읽기 작업과 쓰기 작업이기 때문에 Conflict가 발생할 것 같지만 서로 다른 데이터를 가지기 때문에 Conflict가 발생하지 않고 바꿀 수 있다.

최종적으로 충돌이 발생하지 않는 작업으로 바꾼 Schedule을 보면 Serial Schedule과 동일하게 된다.

이처럼 Schedule이 Serial Schedule과 Conflict equivalent 한 것을 Conflict Serializable이라고 한다.

 

• Conflict equivalent

Conflict가 발생하지 않는 작업을 교환해서 Schedule이 다른 Schedule로 변환할 수 있는 경우 두 Schedule은 Conflict equivalent 하다고 한다.

 

Non-Serializable 유형

---

• Recoverability

Recoverability는 실제 환경에서 여러 가지 이유로 트랜잭션이 실패하는 경우가 생길 때 이를 해결하기 위한 방법으로 DBMS는 트랜잭션들을 Recoverability(복구 가능)하도록 스케줄링한다.

DBMS는 해당 트랜잭션이 실행되기 전 시점으로 DB를 복구해야 되는데 여러 트랜잭션이 동시에 실행되는 경우 정상적으로 복구가 되지 않을 수 있다.

 

• Recoverable Schedule

트랜잭션이 다른 트랜잭션에 의해 업데이트된 값을 읽는 경우, 해당 트랜잭션은 값을 업데이트하는 다른 트랜잭션이 커밋된 후에만 커밋할 수 있다.

 

• Non-Recoverable

트랜잭션이 커밋되지 않은 트랜잭션에서 연산의 값을 읽고 해당 트랜잭션보다 먼저 커밋하면 Non-Recoverable이라고 한다.

예시를 살펴보면 먼저 T1에서 R(A)와 W(A) 작업을 진행하고, T2에서 R(A)와 W(A) 작업을 진행하였다.

그다음 T1에서 R(A)와 W(A) 작업을 진행하고 commit을 하였는데 T2에서 문제가 발생하여 롤백을 진행하였다.

롤백을 통해서 트랜잭션 이전 상태로 돌아가야 되지만 이미 T1에서 commit을 했기 때문에 Durability 속성으로 인하여 롤백을 할 수 없게 된다.

이러한 문제가 있기 때문에 DBMS에서는 Non-Recoverable Schedule은 허용하면 안 된다.

 

Recoverable Schedule 유형

---

Recoverable Schedule에는 3가지 유형이 있는데 하나씩 살펴보자.

 

• Cascading Rollback

한 트랜잭션의 실패로 인해 여러 다른 트랜잭션이 롤백 및 중단되도록 강제되는 경우를 의미한다.

예제를 살펴보면 T1에서 W(A)한 값을 T2에서 읽고, T2에서 W(A)한 값을 다시 T3에서 읽고 있다. 즉, T2는 T1에 종속되고, T3는 T2에 종속된다.

이러한 상황에서 만약 T1이 실패하게 되면 종속되어 있던 T2가 롤백되고, 따라서 T3도 같이 롤백된다.

이러한 Cascading Rollback은 상당한 자원 낭비로 이어질 수 있다.

 

• Cascadeless Schedule

트랜잭션이 마지막으로 작성된 트랜잭션이 커밋 및 중단될 때까지 데이터 항목을 읽을 수 없는 경우를 의미한다.

트랜잭션이 값에 대한 읽기 작업을 수행하려면 해당 값에 대한 쓰기 작업을 수행하는 트랜잭션이 커밋할 때까지 기다려야 한다.

예제를 살펴보면 T1에서 A의 값을 업데이트한 뒤 T2에서 R(A)를 하기 위해서는 먼저 T1의 작업이 commit 돼야 한다.

따라서 T1이 commit 되기 전까지 T2는 R(A) 작업을 하지 않고 기다리게 된다.

앞서 살펴본 Cascading Rollback과 비교하면 commit이 완료된 이후에 다른 트랜잭션에서 데이터를 읽기 때문에 문제가 발생하여 롤백을 하더라도 연쇄적인 롤백을 하지 않는다. 이를 통해서 Cascading Rollback의 자원 낭비 문제를 해결할 수 있다.

또한, A 데이터를 변경하는 트랜잭션 T1이 A 데이터에 접근하려는 T2 트랜잭션보다 먼저 commit 되어야 하므로 Recoverability를 만족할 수 있다.

하지만 Cascadeless Schedule에서 트랜잭션의 결과가 사라지는 문제가 발생할 수도 있다.

만약 T2에서 W(A) 작업을 하고 commit을 한 상황에서 T1에 문제가 발생하여 T1을 롤백한다고 가정해 보면 T1이 실행되기 이전의 상태로 돌아가기 때문에 T2의 작업들이 분실되는 문제가 발생한다.

이러한 문제를 해결하기 위해 제약 사항을 추가한 Strict Schedule이 있다.

 

• Strict Schedule

Schedule에서 마지막으로 쓴 트랜잭션이 커밋되거나 중단될 때까지 트랜잭션이 데이터 항목을 읽거나 쓸 수 없는 경우 이러한 스케줄을 의미한다.

예제를 살펴보면 T1의 W(A) 작업이 완료되어 commit 되기 전까지 T2에서는 A 데이터에 대해서 읽거나 쓰는 작업을 할 수 없게 된다.

이를 통해서 Cascadeless Schedule에 트랜잭션 작업이 분실되는 경우를 방지할 수 있고 롤백하기가 더 쉽다는 장점을 가지고 있다.

 

참고 자료

---

https://d2.naver.com/helloworld/407507

Schedule in DBMS - Scaler Topics

[DB] Scheduling

DBMS Schedules and the Types of Schedules