Transaction이란?
개념
데이터베이스의 상태를 변화시키기위해 수행하는 작업의 단위를 뜻한다.
상태를 변화시킨다? 질의어를 통해 데이터베이스에 접근하는 행위를 말한다.
중요한 것은 작업의 단위는 질의어의 한문장이 아니라는 것이다.
예를 들어,
사용자가 게시판에 글을 올리려고 한다. 글을 작성하고, 업로드버튼을 누른 뒤 다시 글을 돌아왔을때
게시판에 자신의 글이 포함되어있는 것을 볼 수 있을 것이다.
이러한 상황을 데이터베이스 작업으로 옮기면, 사용자가 업로드 버튼을 눌렀을때 Insert문을 통해
사용자가 입력한 정보를 데이터베이스에 삽입한다. 그러고나서 게시판을 구성할 글을 다시 select문을 통해 최신정보를 가져온다.
즉, 작업의 단위는 insert문과 select문 둘다 를 합친것이다. 이러한 작업단위를 하나의 트랜잭션이라 한다.
관리자나 개발자가 하나의 트랜잭션 설계를 잘하는 것이 데이터를 다루는 것에 많은 이점이 있다.
특징
ACID : 데이터베이스의 트랜잭션이 안전하 수행되기 위해 지켜져야 할 것들.
원자성(Atomicity)
- 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력이다.
- 즉, 트랜잭션이 데이터베이스에 모두 반영되던가, 모두 반영되지 않아야 한다는 것이다.
- 예를 들어, 자금 이체는 성공할 수도 실패할 수도 있지만 보내는 쪽에서 돈을 빼 오는 작업만 성공하고 받는 쪽에 돈을 넣는 작업을 실패해서는 안된다.
- 원자성은 이와 같이 중간 단계까지 실행되고 실패하는 일이 없도록 하는 것이다.
일관성(Consistency)
- 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미한다.
- 트랜잭션이 진행되는 동안에 데이터베이스가 변경 되더라도 업데이트된 데이터베이스로 트랜잭션이 진행되는것이 아니라, 처음에 트랜잭션을 진행 하기 위해 참조한 데이터베이스로 진행된다. 이렇게 함으로써 각 사용자는 일관성 있는 데이터를 볼 수 있는 것이다.
- 무결성 제약이 모든 계좌는 잔고가 있어야 한다면 이를 위반하는 트랜잭션은 중단된다.
독립성(Isolation)
- 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미한다.
- 이것은 트랜잭션 밖에 있는 어떤 연산도 중간 단계의 데이터를 볼 수 없음을 의미한다.
- 하나의 특정 트랜잭션이 완료될때까지, 다른 트랜잭션이 특정 트랜잭션의 결과를 참조할 수 없다.
- 은행 관리자는 이체 작업을 하는 도중에 쿼리를 실행하더라도 특정 계좌간 이체하는 양 쪽을 볼 수 없다.
- 공식적으로 독립성은 트랜잭션 실행내역은 연속적이어야 함을 의미한다.
지속성(Durability)
- 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미한다.
- 시스템 문제, DB 일관성 체크 등을 하더라도 유지되어야 함을 의미한다.
- 전형적으로 모든 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴 수 있다.
- 트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있다.
Commit, Rollback
Commit이란
하나의 트랜잭션이 성공적으로 끝났고, 데이터베이스가 일관성있는 상태에 있을 때, 하나의 트랜잭션이 끝났다라는 것을 알려주기위해 사용하는 연산이다. 이 연산을 사용하면 수행했던 트랜잭션이 로그에 저장되며, 후에 Rollback 연산을 수행했었던 트랜잭션단위로 하는것을 도와준다.
Rollback이란
하나의 트랜잭션 처리가 비정상적으로 종료되어 트랜잭션의 원자성이 깨진경우, 트랜잭션을 처음부터 다시 시작하거나, 트랜잭션의 부분적으로만 연산된 결과를 다시 취소시킨다.
후에 사용자가 트랜잭션 처리된 단위대로 Rollback을 진행할 수도 있다.
ACID속성을 구현하는 건 간단한 문제가 아니다. 트랜잭션 처리는 인덱스 업데이트를 비롯한 수많은 변화가 필요하다.
연산 순서는 실패의 원인이 되기도 한다. 예를 들면 공간부족이나 CPU 자원 점유문제가 있다.
ACID는 DB의 모든 연산이 한번에 실행되는 것을 권장한다. 사실상 이것은 정렬하기 어려운 문제이다. 널리 사용하는 두 가지 방법이 있는데 로깅방식과 새도우 패이징이다. 두경우 모두 업데이트 되는 데이터(구현방식에 따라 읽혀지는 데이터)에 락(lock)을 거는 것이 필요하다. 로깅방식에서 원자성은 DB에 데이터를 업데이트 하기 전에 로그에 모든 변경사항을 기록하는 것으로 보장된다. 이것은 충돌 현상이 발생하더라도 DB 무결성을 보장해준다. 새도 패이징 방식은 변경이 DB의 복사본에 저장된다. 그리고 새로운 복사본은 트랜잭션이 commit 되면 활성화 된다. 복사본은 변경 전 데이터 부분만을 의미한다.
최근까지 DB들은 대부분 ACID를 보장하기 위해 락(lock)에 의존했다. 이것은 데이터 처리전에 언제나 락이 필요함을 의미한다. 많은 수의 락을 관리하게 되면 동시작업 수행이 어렵고 성능저하를 초래하게 된다. A유저가 특정 테이블을 읽고 있다면 B유저는 A의 트랜잭션이 끝나기를 기다려야 한다.
락의 대안으로 수정되는 모든 데이터를 별도 복사본으로 관리하는 MVCC(다중 버전 동시성 제어)가 있다. 방금 전 언급한 A,B 유저의 예를 들면 A가 트랜잭션을 시작할 때 가지고 있던 복사본을 B에 제공하여 동시에 수행이 가능하다. 이 방식은 사용자들이 데이터 처리하는 데 있어 많은 유연성을 제공한다.
네트워크 환경에서 ACID특성을 보장하는 것은 어렵다. 연결이 끊길 수도 있고 두 사용자가 동시에 DB의 동일한 부분을 접근할 수도 있다
트랜잭션의 commit 여부를 각 사용자로부터 확인하기 위해 2단계 commit이 분산 트랜잭션에 적용된다. 트랜잭션이 병렬 수행되는 경우 많은 주의가 필요하다. 2단계 락은 완전한 독립성을 보장하기 위해 사용된다.
참고
https://mommoo.tistory.com/62 [개발자로 홀로 서기]