데이터베이스 Transaction 트랜잭션

Transaction(TXN)은 

한개 이상의 Operation들의 Sequence이다 (Read or Write)

 

왜 이런 Transaction의 정의가 필요하나?

실제 현실에서는
어떤 일은 일어나거나 안일어난다 그 중간은 없다

 

내가 화나서 친구를 한대 때리고싶다 치자

화나서 참으면 내가 안때린거다

1대를 때리거나 안떄리거나이지, 0.5대를 때릴 수는 없다

0.5배의 힘으로 때리는건.... 그것도 1대다 ㅋㅋㅋㅋ

반응형

 

그래서 프로그램에서는 여러 statement들을 묶어서 Transaction으로 만들 수 있다

 

START TRANSACTION;
	UPDATE Bank SET amount = amount - 100
		WHERE name = 'bob';
	UPDATE Bank SET amount = amount +100
		WHERE name = 'JOE';
COMMIT;

 

Transactiom은 다음 두 목표를 이루기 위해 사용되는데

 

Recovery & Durability

- 외부 요인들 때문에 DBMS가 다운 되거나 하는 상황들에 data를 consistent하게 유지해야한다

 

Concurrency

- TXN들을 parallelize하면서 우리들의 의도와 다른 일이 일어나는 것을 방지한다

728x90

 

Recovery & Durability

---

신뢰도가 높은 DBMS를 위해서는 필수적인 요소인다

- Crash (외부 요인들)

- 유저에 의한 Abort들

 

Key Idea 는

모든 Transaction을 전부 기록하거나, 아니면 다 버리거나하는거다

그래서 "rollback"을 가능하기 위해 log를 유지해야한다

 

Concurrent Executions of User Programs

---

성능 높은 DBMS를 위해서는 필수적인 요소이다

 

Key Idea는 DBMS에 접속하는 여러 유저들을 동시에 다룰 수 있어야한다

-> 각각의 TXNs는 고립된 상태로 수행되어야한다

 

Ex)

 

위 두 Client들이 동시에 실행된다면

문제들이 일어날 수도 있다

 

이상적으로는 두 Client들 중 한명이 먼저 실행되고

그 결과 값을 가지고 다른 Client를 실행해야한다

 

그러나

한 Client가 실행되고 있는 도중에

다른 Client를 실행하면

제대로 된 Update가 안될 수도 있다

 

그래서 위처럼

하나의 Transaction으로 다뤄주면 그런일이 없도록 할 수 있다

 

Transaction의 성질: ACID

---

Atomic

---

all  or nothing

 

왜냐하면 앞서 실제 현실에선 사람을 0.5대를 때릴 수는 없다

 

그래서 TXN의 두가지 결과는:

Commit: Transaction의 모든 change들이 반영된 

Abort: 아무 change가 안일어남

 

Consistent

---

모든 테이블은 유저마다 설정된 Constraint들을 만족해야한다

 

프로그래머나 시스템 선에서 이루어질 수 있다

 

Isolated

---

한 Transaction을 다른 Transaction과 별개로 서로 영향을 전혀 끼치지 않으며 실행된다

 

-> Concurrent!

 

Durable

---

TXN의 결과가  계속 유지되어야한다

 

->Disk에 기록

 

Transaction Inconsistencies

---

Dirty Read (Write-Read conflict)

---

inoconsistent한 값을 Read하는 Inconsistency

 

Ex)

W1(A) → R2(A) → W1(A)

A which is was not finished by T1 should not be read

 

Non-Repeatable Read (Read-Write conflict)

---

한 데이터에 대한 다른 값들을 Read하는 Inconsistency

 

Ex)

R1(A) → W2(A) → R1(A)

re-reading resulting in a different value

 

Lost Update (Write-Write conflict)

---

Write했던 값을 잃어버리는 경우

 

Ex)

W1(A) → W2(A) → R1(A)

Update of T1 was lost 😟

 

Phantom Read

---

존재하지 않는 record값을 read하는 것

 

Ex)

R1(R) → ins/del(R) → R2(R)

 

Isolation 단계들

---

 

Read uncommitted

---

• allows uncomitted data to be read
• the lowest isolation level

Read committed

---

• Read only committed value (usually default)
• → no dirty reads
• still many transaction inconsistencies exist

Repeatable read

---

• read only committed data
• further, another transaction cannot update the data between two reads of a data
• → no non-repeatable read, lost updates
• but phantom reads can still occur

Serializable

---

• Readeers don’t block writers and writers don’t block readers
• the strictest transaction isolation
• Very Expensinve