[ACID #1] Transaction이란?

✔️ Transaction

트랜잭션이란 무엇일까요? 트랜잭션을 왜 사용할까요?

트랜잭션이란, 하나의 작업 단위로 처리되는 SQL 쿼리 모음입니다.

보통 원하는 작업을 전부 하나의 SQL 쿼리문으로 처리하기는 어렵습니다. 어떤 작업이냐에따라 다르겠지만 사실 불가능에 가깝죠.

이해를 돕기 위해 트랜잭션을 적용할만한 간단한 예시로 계좌이체 프로세스를 예를 들어보겠습니다.

계좌이체 프로세스를 간소화해서 실행해야하는 액션만 생각을 해본다면,

1. SELECT - 보내는 이의 계좌 잔고를 확인한다.
2. UPDATE - 보내는 이의 계좌 잔고에서 보낼 금액만큼 차감한다.
3. UPDATE - 받는 이의 계좌 잔고에 받은 만큼 금액을 증감한다.

트랜잭션은 이 세가지 작업을 하나의 작업으로 처리한다는 뜻입니다.

---

✔️ Transaction Lifespan

• BEGIN -> Transaction 시작
• COMMIT -> disk에 변경사항을 저장한다 (persist)
• ROLLBACK -> 모든 변경사항을 되돌린다

만약 트랜잭션에서 20,000개의 쿼리를 실행하다가 중간에 문제가 생겼다고 가정해봅시다.

 

문제가 생기기 전까지 실행됐던 쿼리들의 변경사항은 디스크에 써져 있었을까요?

 

만약 그랬다면 ROLLBACK 과정에서 디스크에 썼던 모든 변경사항을 전부 지워줘야합니다.

 

그렇다면 이런 과정속에서 최적화는 어떻게 진행해야할까요?

 

우리의 USE CASE에 따라 데이터베이스를 최적화할 수 있습니다.

 

우리가 잘 알고있는 MySQL, PostgreSQL, SQL Server, OracleDB 같은 DBMS들은 각각 특정 포인트에 포커스를 두고 최적화하게끔 만들어져 있습니다.

 

• ROLLBACK 단계에 포커스를 둔 최적화
• COMMIT 단계에 포커스를 둔 최적화

예를 들어 PostgreSQL 같은 경우, 트랜잭션 내 쿼리들이 실행될 때 디스크에 변경사항을 쓰기 때문에 최종적으로 COMMIT 할 때의 속도가 굉장히 빠릅니다. (그래서 I/O 작업이 많이 일어난다는 단점이 있기도 합니다.)

 

COMMIT 단계에서 CRASH가 나는 경우 사용하는 DBMS가 COMMIT이 빠른 경우라면 SQL Server처럼 COMMIT이 느린 경우보다 덜 위험할 수 있습니다.

 

트랜잭션 후 실제로 COMMIT이 되고 안되고는 굉장히 중요한 문제입니다.

---

✔️ Read-only Transactions

트랜잭션은 보통 데이터를 생성하고 변경할 때 사용합니다.

 

하지만 트랙잭션을 read-only 용도로 사용할 수도 있습니다.

 

데이터의 일관성을 유지하고 싶을때 트랜잭션을 사용하는 경우죠.

 

리포트를 생성하는데 트랜잭션을 시작한 시점 이후 계속 같은 시점의 스냅샷을 필요로 하는 경우를 예로 들을 수 있습니다.

 

읽어들이는 데이터는 트랜잭션을 시작한 시점을 기준으로 한 데이터여야 하는 상황인 것이죠.

 

동시에 실행되는 다른 트랜잭션으로 인해 데이터가 변경된다고 하더라도 트랜잭션을 시작한 시점의 데이터만을 읽고 싶을때 트랜잭션을 사용할 수 있습니다.

 

이게 바로 ACID 개념의 I 에 해당하는 Isolation의 개념입니다.

 

Isolation 개념은 이어져올 다른 포스팅에서 다룰 예정입니다.

---

✔️ Example

account_id	balance
1	$1000
2	$500

 

Account 1에서 Account 2로 $100를 송금하는 상황

BEGIN;

  SELECT balance FROM accounts WHERE id = 1;

  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;

결과

 

account_id	balance
1	$900
2	$600