[SQL] Transaction

Data Integrity(무결성) 

- 은행, 항공사, 온라인 티켓 예매 시스템 등 기밀 데이터를 다루는 산업에서 중요한 개념 

- 위 산업들은 모두 transaction을 사용 

 

Transaction 

- 여러 개의 SQL 구문을 그룹화 -> 모든 변경사항을 데이터베이스에 적용(all or nothing; 그 중 하나라도 에러가 있으면 적용X)

   ex) 은행 송금 업무: 출금계좌와 입금계좌의 데이터 업데이트가 동시에 이루어져야 한다 

- 데이터의 consistency(일관성)를 유지 

- 오류 발생 시 Rollback을 통해 데이터를 원래 상태로 되돌릴 수 있음 

- 4가지 특성(ACID)을 만족해야 

    Atomicity(원자성): all or nothing 

    Consistency(일관성): transaction 실행 전 후 일관성 유지. valid state -> valid state 

    Isolation(격리성): 여러 transaction이 동시에 실행될 때, 각각이 독립적으로 실행되어야.

                                 하나의 transaction 내부에서 만든 변경사항은 commit 을 해야 다른 transaction에 반영됨 

                                  save point: transaction 내 특정 지점을 저장 

                                  https://www.postgresql.org/docs/current/transaction-iso.html

    Durability(지속성): transaction이 성공적으로 완료되면 그 변경사항이 영구적으로 저장되어야. data forever 

-- <SAVEPOINT 예제>

BEGIN TRANSACTION;

-- A 계좌에서 100원 출금
UPDATE accounts SET balance = balance - 100 WHERE account_id = 'A';

-- 첫 번째 저장점 설정
SAVEPOINT sp1;

-- B 계좌에 100원 입금
UPDATE accounts SET balance = balance + 100 WHERE account_id = 'B';

-- 두 번째 저장점 설정
SAVEPOINT sp2;

-- C 계좌에 200원 입금 (에러 발생 가정)
UPDATE accounts SET balance = balance + 200 WHERE account_id = 'INVALID_ACCOUNT';

-- 오류 발생 시 sp2까지 롤백
ROLLBACK TO SAVEPOINT sp2;

-- 나머지 정상적인 부분을 커밋
COMMIT;

 

---

Isolation Level(격리 수준)에 따라 발생하는 Read Issue

1) Dirty Read: commit되지 않은 데이터를 읽어버림 

2) Non-Repeatable Read: 한 트랜잭션 내에서 같은 데이터를 조회할 때마다 값이 변경. 주로 업데이트할 때 발생 

3) Phantom Read: 같은 조건으로 조회했을 때, 실행 시점마다 레코드 개수가 달라짐(새로운 행이 추가되거나 삭제)

---

Serialization Anomaly (직렬화 이상현상)

- 트랜잭션을 병렬로 실행할 때, 서로 다른 실행 순서에 따라 데이터 결과가 달라지는 문제

- 기본적으로 Repeatable Read와 같음 

- Serialization Failure: 여러 transaction이 동시에 실행되어, 직렬(순차적)로 실행했을 때는 있을 수 없는 결과가 나타남

                                     (제대로 격리X -> 직렬화 가능한 순서를 찾지 못해 transaction이 실패)