[Database] 트랜잭션

📕 목차

1. Transaction 개념
2. Transaction State
3. Implementation of Atomicity and Durability
4. Concurrent Execution
5. Serializability
6. Recoverability

1. Transaction 개념

📌 Definition

사용자 관점: 논리적인 작업의 단위
시스템 관점: 동시성 제어와 회복 단위
BEGIN TRANSACTION과 END TRANSACTION에 의해 표현

📌 Attribute

Atomicity(원자성): All or Nothing
Consistency(일관성): 정확성
Isolation(고립성): 중간 과정의 외부 노출 금지
Durability(영구성): 한 번 저장된 데이터는 영구적이어야 한다.

🟡 Example

전부 실패하거나, 전부 성공하거나.

2. Transaction State

📌 Life Cycle

결과는 무조건 commit 혹은 rollback만 존재한다.

3. Implementation of Atomicity and Durability

📌 Shadow Copy Technique

나중에 다시 다룰 내용..

4. Concurrent Execution

📌 Concept

동시성을 허용하는 이유
- System Throughput 증가
- Transaction의 평균 Response Time 감소 (FIFO와 Round Robin 가성비 따져볼 것)
동시성 제어
- 동시에 실행되는 Transaction들의 실행결과 정확성 보장
- Locking, Timestamp Ordering, Multi-version CC, …
- CC Overhead << Concurrent Execution의 성능 향상

🤔 언제나 동시성 제어가 이득인가?

동시성은 CPU와 Disk 이용률을 증가시키는 반면, 동시성 제어를 위한 Overhead가 발생한다.
만약, FIFO가 더 좋은 성능을 보이는 환경이라면 필요없다.
적정한 수준에서, 적정한 알고리즘을 택하는 것이 최선이다.

📌 Serial Schedule

Transaction을 시간대 별로 나열
결과가 다를 수 있으나, 모두 같은 state를 갖기에 언제나 정확하다.

📌 Concurrent Schedule

순서가 달라지면, state도 달라질 수 있는 문제가 발생한다.

5. Serializability

📌 Concept

\(S_{c}\): Concurrent schedule, SS: Set of serial schedules
\(S_{c}\)의 실행 결과가 SS의 한 schedule의 실행 결과와 동일하다면 ⇒ Serializable Schedule
Serializability 종류
- Conflict Serializability
- View Serializability

📌 Conflict Serializability

Conflict Operation (순서 중요)

from\to	Read	Write
Read	not conflict	conflict
Write	conflict	conflict

Conflict Serializability
- Schedule S와 S`가 conflict equivalent (S`: nonconflict operation들을 swap하여 생성)
  ⇒ 하나라도 순서가 결정되면 된다.
- Concurrent schedule S가 conflict serializable
  ⇒ S와 conflict equivalent한 serial schedule 존재
  ⇒ Cycle이 생기면 conflict serializable하지 않다.

📌 Test for Conflict Serializability

Precedence Graph (V, E)
- V: Schedule에 나타나는 모든 Transaction들의 집합
- E: Set of \(T_{i}\) → \(T_{j}\)
  1. \(T_{i}\)가 write(Q)를 \(T_{j}\)의 read(Q) 전에 실행
  2. \(T_{i}\)가 read(Q)를 \(T_{j}\)의 write(Q) 전에 실행
  3. \(T_{i}\)가 write(Q)를 \(T_{j}\)의 write(Q) 전에 실행
Test
- Schedule S에 대한 precedence graph가 cycle이 없을 경우, S는 Conflict Serializable

📌 Conflict Serializability 한계

Schedule 8: 실행 결과 자체는 맞지만, Cycle이 생겨서 직렬화 불가능하다고 판단한다.
Schedule 9: Cycle이 생겨서 불가능하다.

6. Recoverability

📌 Recoverable & Cascadeless Schedule 생성 방법

💡 Commit되지 않은 데이터에 대한 판독 금지

Commit 하지 않은 걸 읽는 dirty read 금지

🟡 Example

다음 Transaction Schedule이 Serializability하지 않음을 보여라. (초기 A = 1,000)

T1	T2
	read(A)
read(A)
A = A + 10
write(A)
	A = A * 1.1
	write(A)

T1 → T2 순차 실행 결과: 1111
T2 → T1 순차 실행 결과: 1110

∴ 둘의 state가 다르므로 Serializability하지 않다.

📝 예제

주어진 트랜잭션과 스케줄에 대하여 충돌 직렬 가능한(conflict serializability) 스케줄을 모두 골라라

트랜잭션
- T1: r1(X); r1(Z); w1(X);
- T2: r2(Z); r2(Y); w2(Z); w2(Y);
- T3: r3(X); r3(Y); w3(Y);
스케줄
- S1: r1(x); r2(Z); r1(Z); r3(X); r3(Y); w1(X); w3(Y); r2(Y); w2(Z); w2(Y);
- S2: r1(X); r2(Z); r3(X); r1(Z); r2(Y); r3(Y); w1(X); w2(Z); w3(Y); w2(Y);
- S3: r1(X); r2(Z); r2(Y); w2(Z); r3(X); r3(Y); w3(Y); w2(Y); r1(Z); w1(X);

1️⃣ S1