📒 목차

• 📌 Transaction이란?
• 📌 Transaction의 속성 (ACID)
• 📌 Isolation-level
• 📌 Isolation-level에 따른 문제점

📌 Transaction이란?

Transaction은 처리되는 작업의 단위이다.

데이터베이스에서 Transaction 처리는 로직상 매우 중요한 기능이다. 따라서, 서로 다른 트랜잭션들을 처리하는 도중 하나의 단위 트랜잭션에서 에러가 발생한다면 이전에 성공했던 트랜잭션들을 다시 rollback 시켜 데이터의 Consistency가 깨지지 않도록 해주는 것이다.

모두 성공했을 경우에는 commit을 통해 확정 지어주게 된다.

데이터베이스에서 Transaction flow를 보게 되면 아래와 같다.

1. 서로 다른 Transaction을 부분적으로 처리한다.

2. 모든 Transaction이 정상적으로 완료되면 Commit 한다.

3. 만약 Transaction중 하나라도 비정상적으로 처리되면 rollback을 수행한다.

📌 Transaction의 속성 (ACID)

ACID 는 Transaction을 정의하는 4가지 속성을 가리키는 약어이다.

A(Atomicity) : 원자성

• 안전성 보장을 위해 가져야 할 성질 중의 하나로 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력이다.
• 모두 성공할 것 아니면 모두 실패하게 만드는 것(DB의 오염을 막기 위함).

C(Consistency) : 일관성

• 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것이다.
• 똑같은 쿼리를 조회할 때마다 동일한 결과값이 나타나야하는 것이다.
• 수정과 삭제로 인해 결과값이 달라지는 것은 당연하다.

I(Isolation) : 격리성

• 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것이다.
• A 사람의 요청을 처리하는 동안 B사람의 요청은 잠시 기다리는 것이다.

D(Durability) : 지속성

• 성공적으로 수행된 트랜잭션에 대한 로그가 남아야하는 성질로 런타임 오류나 시스템 오류가 발생하더라도, 해당 기록은 영구적이어야 하는 것이다.
• 성공하여 commit이 되었으면 서버를 다시 켜도 그 데이터는 그대로 유지가 되어야 되는 것이다.

📌 Isolation-level

Isolation-level 이란 Transaction의 격리 수준이라고 한다.

즉, 동시에 여러 트랜잭션이 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있도록 허용할지 말지를 결정하는 것이다.

Isolation은 총 4단계로 이루어져 있다.

아래 단계로 내려갈수록 안전해지는 반면 성능이 느려지는 단점이 있다.

1. READ UNCOMMITTED
2. READ COMMITTED
3. REPEATABLE READ
4. SERIALIZABLE

📌 Isolation-level에 따른 문제점

✅ 1단계 : READ UNCOMMITTED

각 트랜잭션에서의 변경 내용이 COMMIT이나 ROLLBACK 여부에 상관 없이 다른 트랜잭션에서 값을 읽을 수 있다.

즉, commit 되지 않는 데이터들을 조회할 수 있으나, 정합성에 문제가 많은 격리 수준이기 때문에 사용하지 않는 것을 권장된다.

아래 그림과 같이 Commit이 되지 않는 상태지만 Update된 값을 다른 트랜잭션에서 읽을 수 있다.

✅ 2단계 : READ COMMITTED

RDB(관계형 데이터베이스)에서 대부분 기본적으로 사용되고 있는 격리 수준이다.

Dirty Read와 같은 현상은 발생하지 않는다.

실제 테이블 값을 가져오는 것이 아니라 Undo 영역에 백업된 레코드에서 값을 가져온다.

• 트랜잭션-1이 Commit 한 이후 아직 끝나지 않는 트랜잭션-2가 다시 테이블 값을 읽으면 값이 변경됨을 알 수 있다.

• 하나의 트랜잭션내에서 똑같은 SELECT 쿼리를 실행했을 때는 항상 같은 결과를 가져와야 하는 REPEATABLE READ의 정합성에 어긋나게 된다.

• 이러한 문제는 주로 입금, 출금 처리가 진행되는 금전적인 처리에서 주로 발생하며 이런한 현상은 데이터의 정합성은 깨지고, 버그는 찾기 어려워진다.

✅ 3단계 : REPEATABLE READ

RDB(관계형 데이터베이스)에서 대부분 기본적으로 사용되고 있는 격리 수준이다.

MySQL에서는 트랜잭션마다 트랜잭션 ID를 부여하여 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경한 것만 읽게 된다.

Undo 공간에 백업해두고 실제 레코드 값을 변경한다.

• 백업된 데이터는 불필요하다고 판단하는 시점에 주기적으로 삭제한다.
• Undo에 백업된 레코드가 많아지면 MySQL 서버의 처리 성능이 떨어질 수 있다.

이러한 변경방식은 MVCC(Multi Version Concurrency Control)라고 부다.

- PHANTOM READ

REPEATABLE READ에 종종 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안 보였다가 하는 현상이 발생합니다. 이런 문제를 PHANTOM READ라고 한다.

PHANTOM READ 는 MySQL에서 자동으로 제거해 주기에 저희가 추가적으로 적용할 부분은 없다.

다음과 같은 PHANTOM READ 가 발생하지 않기 위해서 SERIALIZABLE 를 사용한다.

성능 측면에서는 동시 처리성능이 가장 낮으며 가장 단순한 격리 수준이지만 가장 엄격하다.

데이터베이스에서는 거의 사용되지 않는다.

✅ 4단계 : SERIALIZABLE

SERIALIZABLE에 대해 알아보기 위해 예시를 통해 알아보도록 하자!!

철수 3,000원, 훈이 2,000원, 영희 5,000원이 존재한다.

철수와 훈이가 가진 돈을 영희에게 모두 준다고 가정해 보자.

그럼 우리가 생각하기로는 영희의 돈은 10,000원이 되고 끝나는 게 당연하다.

하지만 컴퓨터의 입장에서는 순서대로 일을 진행하기에, 영희의 돈이 10,000원이 되지 않을 수도 있다.

철수가 영희에게 3,000원을 주는 동시에 훈이 또한 영희에게 2,000원을 주게 된다면 컴퓨터는 어떻게 받아들일까?

동시에 주는 상황을 컴퓨터 입장에서 생각해 보자.

1. 영희의 돈(5,000원)을 조회한다.
2. 철수가 주는 3,000원을 영희의 돈으로 update 시킨다.
3. 영희의 돈(5,000원)을 조회한다.
4. update가 완료되었다.
5. 훈이가 주는 2,000원을 영희의 돈으로 update 시킨다.
6. update가 완료되었다.
7. 최종적으로 영희가 가진 돈은 7,000원이 된다.

즉, 위와 같은 상황은 철수가 준 돈을 update 완료 하기 전에 훈이가 돈을 넘겨줌으로써, 데이터의 오염이 일어나게 된 것이다.

그렇기 때문에 철수가 돈을 주고 update가 완료될 때 까지는 영희 데이터에 훈이는 접근할 수 없도록 lock을 걸어 주어야 한다.

---

📌 참조

https://codebootcamp.co.kr/