Transaction 이란?

 

1️⃣Transaction 이란?

Transaction은 데이터베이스 내에서 수행되는 작업의 최소 단위로, 데이터 베이스의 무결성을 유지하며 데이터 베이스의 상태를 변경하는 기능을 수행합니다.
Transaction은 하나 이상의 query를 포함해야 하고, 데이터 정합성을 보장하기 위해서는 ACID 원칙을 만족해야 합니다.

 

ACID 원칙이란?

원자성, 일관성, 고립성, 지속성 4가지 규칙

1. 원자성 (Atomicity)

Transaction에 포함된 작업은 전부 수행되거나 전부 수행되지 않아야 합니다. (== All Or Nothing)

2. 일관성 (Consistency)

Transaction이 실행을 성공적으로 완료하면 실행 전과 후의 데이터 무결성이 유지되어야 합니다.

3. 고립성 (Isolation)

여러 Transaction이 동시에 실행될 때, 서로 간섭하지 않아야 합니다.
따라서 각 Transaction은 다른 Transaction의 연산 작업이 끼어들지 못하도록 보장하여 독립적으로 작업을 수행해야 하며, 동시에 수행되는 Transaction이 동일한 데이터를 가지고 충돌하지 않도록 제어해줘야 합니다. (동시성 제어)

4. 지속성 (Durability)

성공적으로 완료된 Transaction은 데이터 베이스에 그 결과가 영원히 반영되어야 합니다.
즉, Transaction이 완료되어 저장된 후에는 정전, 장애, 오류 등의 영향을 받지 않아야 합니다.

 

-- 예제
은행 계좌 이체를 하는 상황
A가 자신의 계좌에서 B에게 100만원을 송금한다.

-- 1. A의 계좌에서 100달러 차감
UPDATE accounts SET balance = balance - 100 WHERE user_id = 'A';

-- 2. B의 계좌에 100달러 추가
UPDATE accounts SET balance = balance + 100 WHERE user_id = 'B';

-- 3. 트랜잭션 커밋
COMMIT;

1. 원자성

3단계가 모두 성공하거나 하나라도 실패하면 전부 롤백되어야 한다. (All Or Nothing.)

=> A의 돈이 빠져나갔는데 중간에 문제가 생겨서 B의 계좌에 입금되지 않는 상황이 발생하면 안된다.
따라서 TRANSACTION을 사용하여 전체 작업을 하나의 단위로 처리해야 한다.

 

2. 일관성

트랜잭션 수행 전과 후에 데이터베이스는 항상 무결성 규칙을 유지해야 한다.

=> A의 계좌에서 100만원이 빠져나갔다면, B의 계좌에는 반드시 100만원이 추가되어야 한다.
=> 따라서 트랜잭션이 완전한 상태일 때만 DB에 반영되어야 한다.

 

3. 격리성

각 트랜잭션은 서로 간섭하지 않아야 한다.

=> A가 B에게 100만원을 송금하는 동안에 다른 트랜잭션이 A의 잔액을 조회한다면, 송금이 완료되기 전까지는 변경된 잔액이 조회되면 안된다.
=> 트랜잭션 격리 수준 설정을 통해 해결할 수 있다.
(격리 수준이 낮을수록 다른 트랜잭션이 커밋 전 데이터를 읽을 수 있고, 그 때는 Dirty Read 가 발생한다.)

 

4. 지속성

트랜잭션이 성공적으로 반영된 후에는, DB에 그 값이 그대로 유지되어야 한다.

=> A가 B에게 100만원을 송금한 후, 서버가 다운되어도 송금 내역은 손실되지 않아야 한다.
=> DB는 커밋이 완료되면 즉시 디스크에 저장해야 하며(WAL), 장애 발생 시에는 로그를 기반으로 데이터를 복구해야 한다.

 

---

 

ACID 원칙을 보장하기 위해 데이터베이스는 동시성 제어, 트랜잭션 격리 수준, MVCC 등을 활용한다.

2️⃣동시성 제어 (Concurrency Control)

동시성 제어란 트랜젝션이 동시에 수행될 때 일관성을 해치지 않도록 트랜젝션의 데이터 접근을 제어하는 DBMS의 기능입니다.

동시성 제어 기법 중 대표적인 것이 비관적 락과 낙관적 락입니다. 이 외에도 MVCC와 타임스탬프 기법 등이 존재합니다.

 

 

1. 비관적 락 (Pessimistic Lock)

비관적 락이란 다른 트랜잭션이 데이터를 수정할 가능성이 크다고 가정하고, 데이터에 대한 접근을 제한합니다.
주로 데이터를 조회하거나 수정하기 전에 락을 걸어 다른 트랜잭션이 접근하지 못하도록 합니다.

• 예시 : 은행 계좌 이체, 좌석 예약 시스템 등

 

-- 장점

• 충돌을 방지하여 데이터 정합성이 보장됩니다.

 

-- 단점

• 락이 걸린 동안 다른 트랜잭션이 대기하므로 성능이 저하될 수 있습니다.

 

 

2. 낙관적 락 (Optimistic Lock)

낙관적 락이란 다른 트랜잭션이 데이터를 수정할 가능성이 적다고 가정하고, 데이터 수정 시 충돌 여부를 검사하는 방식입니다.
주로 데이터 조회 후 변경 사항을 저장할 때, 버전이나 타임스탬프를 비교하여 변경 충돌 여부를 확인합니다.

• 예시: 게시판 글 수정, 쇼핑몰 재고 관리

 

-- 장점

• 동시성이 높은 환경에서 성능이 좋습니다.

 

-- 단점

• 충돌이 발생하면 트랜잭션을 다시 수행해야 하므로 오버헤드가 발생할 수 있습니다.

 

 

3. MVCC (Multi-Version Concurrency Control, 다중 버전 동시성 제어)

MVCC란 데이터베이스에서 동시성을 높이고 락 없이 읽기 작업을 수행할 수 있도록 설계된 기법입니다.

비관적 락과 낙관적 락과 달리,
트랜잭션마다 서로 다른 데이터의 버전을 관리하여 동시성을 확보하는 방식입니다.

MVCC는 락 없이 동시성을 최대한 확보하고 싶은 경우에 좋은 선택입니다.

 

-- 동작 방식

1) 읽기 작업

• 각 트랜잭션이 데이터를 읽을 때, 해당 트랜잭션이 시작된 시점의 데이터 버전을 조회합니다.

2) 쓰기 작업

• 데이터를 수정할 경우, 기존 데이터를 직접 변경하지 않고, 새로운 버전의 데이터를 생성합니다.
• 다른 트랜잭션에서는 새로운 버전이 아닌, 자신의 트랜잭션이 시작될 당시의 데이터를 읽습니다.

3) 삭제 작업

• 데이터 삭제 시 즉시 삭제하지 않고, 논리적인 삭제 상태로 유지합니다.
• 이후 불필요한 버전이 정리됩니다. (Garbage Collection)

 

-- 장점

• 읽기 작업 시 락이 필요없기 때문에 높은 동시성을 지원합니다.
• 읽기와 쓰기가 충돌하지 않아 비관적 락보다 성능이 우수합니다.
• 읽기 작업 중 대기 시간이 없어 빠른 데이터 조회가 가능합니다.

 

-- 단점

• 버전 관리로 인한 스토리지 사용량이 증가하고, 불필요한 데이터 정리가 주기적으로 필요합니다.
• 그로 인한 정리 비용이 발생합니다.

 

---

3️⃣Transaction 격리 수준

트랜젝션 격리 수준이란 데이터베이스에서 동시에 실행되는 여러 트랜젝션 간의 독립성을 보장하는 정도입니다.

즉, 여러 트랜젝션이 동시에 수행될 때, 특정 트랜젝션이 다른 트랜젝션에서 변경 또는 조회하는 데이터를 읽을 수 있게 허용할지 여부를 결정하는 단계입니다.

격리 수준이 높은 순서대로 SERIALIZABLE, REPEATABLE READ, READ COMMITTED, READ UNCOMMITED가 존재합니다. 격리 수준이 높을수록 성능은 저하되지만 데이터 무결성이 보장되고, 격리 수준이 낮을수록 성능은 좋아지지만 데이터 일관성이 낮아집니다.

 

[ 격리 수준 ]

1. SERIALIZABLE

가장 높은 수준의 격리로, 트랜젝션을 순차적으로 실행합니다. 다른 사용자는 트랜잭션 영역에 해당하는 데이터에 대해 수정 및 입력이 불가능합니다. 따라서 모든 이상 현상을 방지하며, 가장 높은 데이터 일관성을 보장합니다. 하지만 동시성이 낮아져 성능 저하가 발생할 수 있습니다.

 

2. REPEATABLE READ

트랜잭션이 범위 내에서 조회한 데이터 내용이 항상 동일함을 보장합니다. 다른 사용자는 트랜잭션 영역에 해당하는 데이터에 대해 수정이 불가능합니다. 아래 레벨에 비해 데이터 일관성이 높습니다.
하지만 새로운 데이터가 삽입되면 Phantom Read 가 발생할 수 있습니다.

 

3. READ COMMITTED

트랜잭션이 커밋된 변경사항만 다른 트랜잭션이 읽을 수 있습니다. Dirty Read를 방지할 수 있지만 나머지 문제가 발생할 수 있습니다. 많은 DBMS(Oracle, SQL Server, PostgreSQL)의 기본 격리 수준입니다.

 

4. READ UNCOMMITTED

트랜잭션이 commit되지 않은 변경사항을 다른 트랜잭션이 읽을 수 있습니다. 가장 낮은 수준의 격리로 성능이 뛰어나지만 데이터 무결성이 보장되지 않아 신뢰성이 낮습니다.
Dirty Read, Non-Repeatable Read, Phantom Read가 발생할 수 있습니다.

 

 

[ 격리 수준의 트레이드 오프 (성능 vs 일관성) ]

격리 수준	Dirty Read	Non-Repeatable Read	Phantom Read	성능
READ UNCOMMITTED	❌ 발생	❌ 발생	❌ 발생	가장 빠름
READ COMMITTED	✅ 방지	❌ 발생	❌ 발생	빠름
REPEATABLE READ	✅ 방지	✅ 방지	❌ 발생 (MySQL에서는 방지)	느림
SERIALIZABLE	✅ 방지	✅ 방지	✅ 방지	가장 느림

 

---

4️⃣Transaction 이상현상

ACID 원칙이 보장되지 않았을 때 나타날 수 있는 이상현상들이 존재합니다.

Dirty Read, Non-Repeatable Read, Phantom Read, Lost Update

 

1. Dirty Read 

• 커밋되지 않은 데이터를 읽는 문제입니다.

 

-- 예시

• 트랜잭션 A가 데이터를 변경하고 있을 때, B가 그 데이터를 읽습니다.
  하지만 나중에 트랜잭션 A가 롤백되면 트랜잭션 B는 유효하지 않은 데이터를 사용하게 됩니다.

-- 트랜잭션 A: 사용자 잔액을 변경하는 중 (아직 커밋하지 않음)
BEGIN;
UPDATE accounts SET balance = 100 WHERE user_id = 'A';

-- 트랜잭션 B: 트랜잭션 A가 커밋하기 전에 데이터를 조회함 (Dirty Read 발생)
SELECT balance FROM accounts WHERE user_id = 'A';  -- 🚨 100이 조회됨 (문제 발생)

-- 트랜잭션 A 롤백
ROLLBACK;

 

-- 원인

• READ UNCOMMITTED 격리 수준에서는 커밋되지 않은 데이터를 읽을 수 있습니다.

 

 

2. Non-repeatable Read

• 같은 데이터를 두 번 조회했을 때, 다른 결과가 나오는 문제입니다.

 

-- 예시

• 트랜잭션 A가 데이터를 읽고, 트랜잭션 B가 그 데이터를 변경하고 커밋한 후, 트랜잭션 A가 다시 읽으면 다른 값을 얻게됩니다.

-- 트랜잭션 A: 처음에 잔액을 조회함
BEGIN;
SELECT balance FROM accounts WHERE user_id = 'A';  -- 결과: 500

-- 트랜잭션 B: 같은 계좌의 잔액을 변경하고 커밋
BEGIN;
UPDATE accounts SET balance = 300 WHERE user_id = 'A';
COMMIT;

-- 트랜잭션 A: 같은 데이터를 다시 조회
SELECT balance FROM accounts WHERE user_id = 'A';  -- 🚨 결과: 300 (변경됨!)

 

-- 원인

• READ COMMITED 격리 수준에서는 트랜잭션이 조회할 때마다 커밋된 최신 데이터를 읽기 때문에 발생합니다.

 

 

3. Phantom Read

• 같은 조건으로 데이터를 두 번 조회했을 때 결과 집합이 달라지는 문제입니다.

 

-- 예시

• 트랜잭션 A가 특정 조건으로 데이터를 조회하고, 트랜잭션 B가 해당 조건을 만족하는 새 데이터를 삽입/삭제한 후, 트랜잭션 A가 다시 같은 조건으로 조회하면 결과 집합이 달라집니다.

-- 트랜잭션 A: 현재 CS 학과 학생 수를 조회함
BEGIN;
SELECT COUNT(*) FROM students WHERE department = 'CS';  -- 결과: 10

-- 트랜잭션 B: CS 학과에 새로운 학생을 추가하고 커밋
BEGIN;
INSERT INTO students (id, name, department) VALUES (11, 'John Doe', 'CS');
COMMIT;

-- 트랜잭션 A: 다시 같은 조건으로 조회함
SELECT COUNT(*) FROM students WHERE department = 'CS';  -- 🚨 결과: 11 (학생 추가됨!)

 

-- 원인

• REPEATABLE READ 격리 수준까지는 기존 행의 변경만 방지(Non-Repeatable Read 해결)하고,
• 새로운 행 추가는 방지하지 않습니다.

 

❓ Non-Repeatable Read 와 Phantom Read 차이점

문제 유형	원인	발생 조건
Phantom Read	조회 조건을 만족하는 행이 추가 또는 삭제됨	INSERT, DELETE
Non-Repeatable Read	동일한 행(row)의 값이 변경됨	UPDATE, DELETE

 

 

4. Lost Update (갱신 손실)

•  여러 개의 트랜젝션이 한 개의 데이터를 동시에 갱신(update)할 때 하나의 트랜잭션의 갱신이 무효화되는 것입니다.

 

-- 예시

-- 트랜잭션 A
SELECT balance FROM accounts WHERE id = 1;  -- 현재 잔액: 100
UPDATE accounts SET balance = 90 WHERE id = 1;

-- 트랜잭션 B (A가 끝나기 전에 실행)
SELECT balance FROM accounts WHERE id = 1;  -- 현재 잔액: 100
UPDATE accounts SET balance = 80 WHERE id = 1;

-- 트랜잭션 B가 커밋 후, 트랜잭션 A가 커밋하면 잔액이 90이 아니라 80이 됨 (A의 변경 사항이 사라짐)