Transaction

Transactions

Transaction

트랜잭션 = a unit of program execution that accesses and possibly updates various data items

 

트랜잭션의 두 가지 메인 이슈:

• failures (hardware failures, system crashes)
• concurrent execution of multiple transactions

 

 

Transaction properties (ACID)

: 데이터 무결성을 확보하기 위해 보장해야 하는 트랜잭션의 네 가지 속성

 

1. Atomicity

"All or none". 트랜잭션의 연산 결과는 모두 완전히 데이터베이스에 반영되거나, 아예 반영되지 않는다.

트랜잭션 전체 실행이 완료되지 못하면 트랜잭션 실행 전 상태로 복구해야 한다.

recovery mechanism에 의해 지켜지는 속성.

 

 

2. Consistency

트랜잭션의 실행은 데이터베이스의 일관성을 지켜야 한다.

트랜잭션이 실행되는 동안, 데이터베이스는 일시적으로 inconsistent 상태가 될 수 있지만 트랜잭션이 정상적으로 완료된 후 데이터베이스는 consistent 상태여야 한다. 

 

explicit constraints: primary keys, foreign keys, ...

implicit constraints: sum of balances of all accounts, ...

 

 

3. Isolation

각 트랜잭션은 현재 실행 중인 (완료되지 않은) 다른 트랜잭션과 별개로 실행된다. 아직 완료되지 않은 트랜잭션의 중간 결과들은 다른 트랜잭션에서는 접근할 수 없게 한다. 

트랜잭션이 serially 실행된다면 isolation은 반드시 지켜지게 된다.

concurrency control mechanism에 의해 지켜지는 속성.

 

 

4. Durability

성공적으로 완료된 트랜잭션의 결과값은 반드시 데이터베이스에 반영되어야 한다. 

recovery mechanism에 의해 지켜지는 속성.

 

 

 

Schedules

Concurrent execution

serial execution: 한 트랜잭션이 모두 완료된 후 다른 트랜잭션을 실행하는 방식. 데이터베이스의 일관성을 보장함.

concurrent execution: 한 트랜잭션을 실행하다가 할당된 시간이 끝나면 그 트랜잭션 완료되지 않은 상태로 다른 트랜잭션을 할당된 시간만큼 실행하는 방식

 

concurrent execution은 프로세서와 디스크 utilization을 높이고 트랜잭션 평균 반응 시간을 줄여 트랜잭션 처리량의 측면에서 더 좋은 성능으로 이어진다는 장점이 있지만, serial execution에서와 달리 추가적으로 데이터 일관성을 보장할 방법이 필요함. 

 

 

Schedule

schedule: a sequence of instructions that specify the chronological order in which instructions of concurrent transactions are executed

 

성공적으로 실행 마무리한 트랜잭션의 마지막 statement: commit instruction

성공적으로 마무리하지 못한 트랜잭션의 마지막 statement: abort instruction

 

 

Serializable schedule

serializable

어떤 스케줄의 실행 결과가 serial하게 실행한 결과와 똑같은 경우, 그 스케줄을 serializable schedule이라고 함. 

 

conflict

어떤 데이터 아이템에 대해, 서로 다른 transaction들의 instruction들이 각각...

(1) read - read 인 경우: not conflict

(2) read - write 인 경우: conflict

(3) write - read 인 경우: conflict

(4) write - write 인 경우: conflict

 

 

conflict equivalent schedule

어떤 스케줄에서 not conflict한 instruction들의 순서를 서로 맞바꾼 결과 스케줄

example:

1. write2(A) ↔ read1(B) : 다른 data item에 접근하므로 non conflicting
2. read2(A) ↔ read1(B) : "
3. write2(A) ↔ write1(B) : "
4. read2(A) ↔ write1(B) : "

 

conflict serializable schedule

어떤 스케줄의 conflict equivalent schedule이 serial하다면, 그 스케줄은 conflict serializable schedule

example:

 

 

Recoverable schedule

동시에 실행된 서로 다른 트랜잭션들이 있을 때, 한 트랜잭션의 failure가 미치는 영향에 관한 이슈

transaction T2가 T1이 업데이트한 데이터 아이템을 읽어 작업했다면, T2는 T1이 commit하기 전까지 commit하지 않고 기다려야 recoverable schedule

 

 

Isolation levels

dirty read

commit되지 않은 트랜잭션의 업데이트 결과를 읽어 작업하는 것.

만약 업데이트를 진행한 트랜잭션의 failure 발생하는 경우, 이 트랜잭션도 같이 롤백해야 함.

 

non-repeatable read

데이터 아이템을 읽어올 때마다 값이 바뀔 수도 있는 것.

이 트랜잭션에서 데이터 아이템을 읽은 후 다른 트랜잭션에서 그 데이터를 업데이트해서 다시 이 트랜잭션에서 그 데이터 아이템을 읽으면 이전과 값이 달라져 있게 됨.

 

phantoms

어떤 데이터들을 읽어올 때(select) 이후 다른 트랜잭션에서 새 데이터를 삽입하거나 삭제하면 이 트랜잭션에서 다시 그 데이터들을 읽어왔을 때 이전에 있던 데이터가 사라지거나 없던 데이터가 새로 생겨있을 수 있는 것.

 

levels of consistency

데이터를 활용하는 어플리케이션들의 성격과 목적에 따라, 완벽한 consistency가 보장되지 않아도 괜찮을 수 있음. 이러한 특성에 따라 목적에 맞는 consistency 보장 정도를 선택하게 됨.

예를 들어, banking 어플리케이션의 경우 엄격한 consistency가 필요하지만, 단순히 검색만 하는 경우 그렇게까지 보장하지는 않아도 괜찮다.

각 consistency level은 앞서 설명한 dirty read, non-repeatable read, phantoms problem들이 발생 가능한지 여부에 따라 구분됨.

1. read uncommitted: dirty read, non-repeatable read, phantom 모두 가능한 isolation level
2. read committed: committed된 transaction의 수행 결과만 읽음! dirty read 발생하지 않고, non-repeatable read와 phantom 가능한 isolation level
3. repeatable read: phantom problem만 가능한 isolation level
4. serializable: 세 문제 모두 발생하지 않는 isolation level

 

 

---

본 포스트 내용은 고려대학교 컴퓨터학과 "데이터베이스" 강의 내용 일부를 개인 공부 목적으로 정리한 것입니다.