[DB] Transaction

트랜잭션 (transaction) 이란 다양한 data items 를 접근하고 갱신할 수 있는 프로그램 실행 단위이다. 

 

Transaction Properties

데이터 무결성을 지키기 위해, database system 은 ACID 특성 보장해야 한다.

• Atomicity  (원자성) : 한 트랜잭션의 모든 연산들은 db 에 모두 반영되거나 모두 반영되지 않아야 한다. 
• Consistency (일관성) : isolation 내의 트랜잭션의 실행은 db 의 일관성을 유지한다. 여기서 일관성은 트랜잭션 전, 후에 데이터 모델의 모든 제약조건 (기본키, 외래키, 도메인, 도메인 제약조건 등) 을 만족하는 것을 통해 보장한다. 
• Isolation (격리성, 고립성) : 여러 트랜잭션이 동시에 발생하더라도, 각각의 트랜잭션은 동시에 실행되는 다른 트랜잭션을 인지하지 못한다. 중간 트랜잭션 결과들은 동시에 실행되는 다른 트랜잭션들에게 숨겨져있다. 즉, 트랜잭션끼리는 서로 간섭할 수 없다.
• Durability (지속) : 트랜잭션이 성공적으로 완료되었다면, system failures 가 있어도 db 에 생긴 변화는 영속된다. 

 

Transaction State

트랜잭션이 성공적으로 실행을 완료하지 못한다면, 트랜잭션이 aborted 되었다고 한다. atomicity property 를 보장하기 위해, aborted transaciton 은 db 에 영향을 미치면 안되므로 aborted transaction 이 만든 변화를 무효로 만든다. aborted transation 으로 인해 db 가 트랜잭션 시작 이전으로 돌아가는 것을 트랜잭션이 roll back 되었다고 한다. 트랜잭션에 의한 db 수정은 log 에 기록된다.

트랜잭션이 성공적으로 완료되면 트랜잭션이 commit 되었다고 한다. 업데이트를 수행한 committed transaction 은 db 를 새로운 일관된 상태로 만들며, system failure 가 있더라도 그 상태를 유지한다. 

 

트랜잭션은 다음 상태 중 하나를 가진다. 

• Active : 시작 상태. 트랜잭션은 실행되는 동안 이 상태를 유지한다. 
• Partially committed : 마지막 연산이 실행된 후
• Failed : 정상적인 실행이 더 이상 진행되지않는 것을 확인한 후
• Aborted : 트랜잭션이 롤백되고 db 가 트랜잭션 시작 이전의 상태로 돌아간 
• Commited : 성공적인 완료 후

트랜잭션은 committed state 에 들어가야 commit 되고, aborted state 에 들어가야 aborted 된다. 트랜잭션이 committed 되거나 aborted 되면 트랜잭션이 terminated 되었다고 한다. 

transaction 이 commit 되기 전에는 output 들이 main memory 에 일시적으로 저장되므로 partially commited 상태에도 아직 aborted 될 수 있다. 마지막 information 이 쓰여진 후에, transaction 은 committed state 가 된다. 

transaction 이 failed status 에 들어가면, system 은 두 가지 선택을 할 수 있다.

• restart transaciton : 트랜잭션의 internal logic 을 통해 생성되지 않는 hardware 나 software error 에 의해 트랜잭션이 aborted 될 때 사용된다.
• kill transaction : 주로 사용됨

 

Transaction Isolation

Transaction-processing systems 는 보통 multiple transaction 을 동시에 실행할 수 있는다. 트랜잭션의 동시 실행에 일관성(consistency) 을 유지하는 것은 추가적인 작업이 필요하다. 그럼에도 동시성을 허용하는 데에는 두 가지 장점이 있다.

• 향상된 throughput 과 resource utilization : CPU 와 disk 는 병렬처리가 가능하여 multiple transactions 를 병렬적으로 처리할 수 있다. 
• 감소된 waiting time : 트랜잭션이 serially 하게 실행되면, transaction 들은 앞의 transaciton 이 끝나기를 기다려 예측 불가한 delay 가 생길 수 있다. 반면, concurrent execution 은 예측불가 한 delay 를 출여주고 average response time 또한 감소시킨다.

database system 은 db 의 일관성을 파괴하는 것을 막기 위해, concurrency-control schems 라고 불리는 메커니즘을 사용하여 concurrent transations 사이의 interaction 을 통제해 isolation 을 만든다. 이 부분은 Concurrency control 에서 다시 다룬다. 

 

Schedule 

schedule 은 시스템 내에서 concurrent transactions 의 명령들이 시간 순으로 실행되는 것을 나타낸다. set of transactions 을 위한 schedule 은 모두 그 transaction 의 명령어로 이루어져야 하고, 반드시 각 transactions 에서 명령어들이 나오 순서를 지켜야 한다. schedule 은 transaction 이 commited state 로 들어갔음을 나타내는 commit operation 을 포함한다.

 

transaction 들이 순차적으로 실행되는 schedule 을 serial 하고 한다. serial schedule 에서는 한 트랜잭션이 끝나고 다른 트랜잭션이 시작된다. transaction 들이 serial 하게 실행되면 동일한 결과값을 보장한다. 즉, db 가 consistent state 를 유지하도록 한다. database system 이 transaction 을 동시에 실행시키고 싶다면 schedule 은 serial 하지 않게 되어, concurrent execution 을 하게 되면 동일한 결과값을 보장할 수 없다. 즉, db 가 inconsistent state 를 유지하게 된다.

이러한 현상을 막기위해, database system 의 concurrency-control 은 어떠한 schedule 이 실행되더라도 db 가 consistent state 를 유지하도록 한다. schedule 이 serial 하다면 이를 serializable schedule 이라고 한다.

 

Serializability

 

 

Transaction Isolation Level

database system 에서, isolation 은 다른 유저와 systems 에게 transaction integrity 가 어떻게 보일지 결정한다. 낮은 isolation 은 많은 유저들이 같은 data 에 동시에 접근 할 때의 성능을 올려주지만, concurrency effects (dirty reads 나 lost updates) 의 수를 늘린다. 반면, 높은 isolation 은 concurrency effects 의 종류를 감소시키지만 더 많은 system resources 를 요구하고 한 transaction 이 다른 transaction 에 의해 block 당하는 경우를 증가시킨다. 

transaction isolation level 의 종류는 다음과 같다. 

• Serializable : serializable execution 을 보장한다. 
• Repeatable read : commited data 만 read 할 수 있고 한 transaction 이 data item 을 두 번 read 하는 사이에, 다른 transaction 이 data item 을 update 할 수 없다.
• Read committed : committed data 만 read 할 수 있지만 repeatable reads 는 필요하지 않다. 즉, 한 transaction 이 data item 을 두 번 read 하는 사이에, 다른 transaction 이 data item 을 update 하고 commit 했을 수 있다.
• Read uncommitted : uncommited data 를 read 할 수 있다. 

모든 isolations levles 는 dirty writes 를 허용하지 않는다. dirty writes 란 아직 commit 되거나 abort 되지 않은 다른 transaction 에 의해 이미 write 된 data item 을 write 하는 것이다. 

 

isolation level 에 따라 다음과 같은 문제가 발생할 수 있다.

• Dirty read : 아직 commit 되지 않은 update 중인 data 를 다른 transaction 읽을 수 있다. Read uncommitted 에서 발생할 수 있다.
• Non-repeatable read : 한 트랜잭션이 같은 data item 에 대해 select query 를 여러 번 실행할 때, 다른 트랜잭션이 해당 data item 을 update 후 commit 하여 select 마다 같은 data item 에 대해 다른 값을 가져올 수 있다. 즉, 반복해서 같은 데이터를 읽을 수 없게 되는 현상이다. Read committed 에서 발생할 수 있다.
• Phantom read : 한 트랜잭션이 같은 select query 를 여러 번 실행할 때, 다른 트랜잭션이 변경 작업을 수행해 select 가 다른 결과값을 가져올 수 있다.  Repeatable read 에서 발생할 수 있다.

 

SQL 에서는 transaction 이 암묵적으로 시작되고, commit work 나 rollback work 에 의해 종료된다. commit work 는 현재 transaction 을 이전 SQL statements 를 commit 하는 작업이고, rollback work 는 현재 transaction 이 abort 될 때 SQL statements 를 되돌리는 작업이다. isolation level 은 database level 에서 설정할 수 있고 transaction 시작 마다 바꿀 수 있다.

 

Implementation of Isolation Levels 

Isolation level 은 다음과 같은 concurrency control policy 를 사용하여 구현한다.

Locking

전체 db 를 locking 하는 대신, transaction 은 접근하는 data items 에 대해 lock 을 건다. transaciton 은 serializability 를 보장할 만큼 길게,  성능을 과도하게 손상시키지 않을 만큼 짧게 lock 을 유지해야 한다. serializability 를 보장하기 위해 two-phase locking protocol 이라는 technique 를 보편적으로 사용한다. shared lock 과 exclusive lock 을 사용하여 보다 개선된 locking 이 가능하다. two-phase locking 와 함께 두 종류의 lock 을 사용하여 serializability 를 보장하면서 data 의 concurrent reading 을 할 수 있다.

 

Timestamps

data item 마다 system 은 read timestamp 와 write timestamp 를 기록한다. timestamp 는 conflict 가 발생할 때, transactions 가 각각의 data item 을 transacitons 의 timestamps 순서대로 접근하도록 보장하는데 사용된다.

 

Multiple Versions and Snapshot Isolation

data item 의 하나 이상의 버젼을 유지함으로써, transaction 이 uncommited transaction 이나 serialization order 로 나중에 오 transaction 에 의해 쓰여진 새로운 version 이 아닌 data item 의 old version 을 읽을 수 있다. multiversion concurrency control techniques 는 다양하게 있고, 그 중 널리 쓰이는 것은 snapshot isolation 이다.

 

 

참조
Database-System-Concepts-7th-Edition
https://victorydntmd.tistory.com/129
https://en.wikipedia.org/wiki/Isolation_(database_systems)
https://nesoy.github.io/articles/2019-05/Database-Transaction-isolation