Transaction

• 단일한 논리적인 작업 단위
• 논리적인 이유로 여러 SQL문들을 하나의 작업으로 묶어서 나눠질 수 없게 만든 것.
• transaction의 SQL문 중 일부만 성공한다해서 DB에 반영되지 않음.
• 모든 SQL문이 성공해야 의미가 있는 작업.

* 예시 - A가 B에게 20만원을 이체하는 과정

START TRANSACTION

UPDATE account SET balance = balance - 200000 where id='A'
UPDATE account SET balance = balance + 200000 where id='B'

// 지금까지 작업한 내용을 DB에 영구적으로 저장하는 명령어 + 트랜잭션 종료
COMMIT;
// 지금까지 작업들을 모두 취소하고 transaction 이전 상태로 되돌리는 명령어 + 트랜잭션 종료
ROLLBACK;


select * from account;

COMMIT

• 작업이 완료된 SQL 쿼리문의 결과를 DB에 영구적으로 저장하고, 트랜잭션을 종료시키는 명령어.

ROLLBACK

• 작업이 완료된 SQL 쿼리문의 결과를 취소하고 이전의 상태로 되돌리는 명령어 + 트랜잭션 종료.

AUTOCOMMIT

• 각각의 SQL문을 자동으로 트랜잭션 처리 해주는 개념.
• SQL문이 성공적으로 실행되면 자동으로 commit.
• 실행 중에 문제가 있었다면 자동으로 rollback.
• MYSQL에서는 autocommit = enabled가 default.
• 다른 DBMS에서도 대부분 같은 기능을 제공.

  START TRANSACTION // 이 sql문을 실행과 동시에 autocommit은 off 된다
  COMMIT or ROLLBACK // 이 명령어를 실행시켜 트랜잭션이 종료되면 원래의 autocommit 상태로 원복

일반적인 트랜잭션 사용 패턴

1. 트랜잭션 시작(begin)
2. 데이터를 읽거나 쓰거나의 SQL문들을 포함해서 로직을 수행
3. 일련의 과정들이 문제없이 동작했다면 트랜잭션을 commit
4. 중간에 문제가 발생했다면 트랜잭션을 rollback

ACID

Atomicity(원자성)

• ALL or NOTHING (모두 성공해서 진행되거나, 아무일도 일어나지 않거나)
• 트랜잭션은 논리적으로 쪼개질 수 없는 작업 단위이기 때문에, 내부의 SQL문들이 모두 성공해야 한다.
• 중간에 SQL문이 실패하면 지금까지의 작업을 모두 취소하여 아무일도 없었던 것처럼 rollback 한다.

  commit 또는 rollback 실행 시 DB에 저장하거나, 이전상태로 되돌리는 작업은 DBMS가 담당.
  개발자는 언제 commit 또는 rollback 할지를 챙겨야 한다.

Consistency(일관성)

• 트랜잭션은 DB 상태를 consistent 상태에서 또 다른 consistent 상태로 바꿔줘야 한다.
• constraints, trigger 등을 통해 DB에 정의된 rules을 트랜잭션이 위반했다면 rollback 해야한다.
• 트랜잭션이 DB에 정의된 rule을 위반했는지 DBMS가 commit 전에 확인하고 알려준다.
• 그 외에 application 관점에서 transaction이 consistent하게 동작하는지는 개발자가 챙겨야 한다.

Isolation(고립성,격리성)

트랜잭션끼리 고립되어야 하는 이유

• J가 H에게 20만원을 보내기위해 J의 통장에서 20만원을 차감했다.(1번 트랜잭션 시작)
• H의 통장에 20만원을 입금하기위해 read를 한 상황.
• 그 순간 H가 ATM기기에서 자신의 통장에 30만원을 입금을 한다.(2번 트랜잭션 시작)
• 그래서 자신의 통장을 read를 한 후, 30만원을 입금시켜 write까지 하게 되었다. (2번 트랜잭션 완료)
• 2번 트랜잭션 완료 후, J가 보낸 20만원을 H의 통장에 write하여 입금을 완료한다.(1번 트랜잭션 완료)

결과적으로 1번 트랜잭션 중간에 2번 트랜잭션이 영향을 주게 되어, 30만원이 사라지는 결과를 초래하게 되었다.

• 여러 transaction들이 동시에 실행될 때도 혼자 실행되는 것처럼 동작하게 만들어야 한다.
• DBMS는 여러 종류의 isolation level을 제공한다. 이유는?
  1. isolation level이 높으면 높을수록 엄격하게 분리한다.
  하지만 엄격할수록 동시성이 떨어지기 때문에, DB 서버의 성능은 낮아진다.
  2. isolation level이 낮아지면 동시성 향상으로 성능은 높아진다.
  하지만 트랜잭션끼리 영향을 받을 확률이 증가하여 이상한 결과가 나타날 수 있다.
• 개발자는 isolation level 중에 어떤 level로 transaction을 동작시킬지 설정할 수 있다.
• concurrency control의 주된 목표가 isolation이다.

Durability(지속성, 영존성)

• commit된 트랜잭션은 DB에 영구적으로 저장한다.
  즉, DB system에 문제(power fail or DB crash)가 생겨도 commit된 트랜잭션은 DB에 남아 있는다.
• '영구적으로 저장한다' 라고 할 때는 일반적으로 '비휘발성 메모리(HDD, SSD, ..)에 저장함'을 의미
• 기본적으로 트랜잭션의 durability는 DBMS가 보장한다.

참고사항

1. transaction을 어떻게 정의해서 쓸지는 개발자가 정하는 것. 구현하려는 기능과 ACID 속성을 이해해야 transaction을 잘 정의할 수 있다.
2. transaction의 ACID와 관련해서 개발자가 챙겨야 하는 부분들이 있습니다. DBMS가 모든 것을 알아서 해주는 것은 아니다.

Reference
쉬운코드(yotube) - 데이터베이스 시리즈 (Transaction, ACID)