해당 게시글은 내용 정리 목적으로 작성되었습니다. 틀린 내용이 있다면 언제든지 말씀해 주세요
목차
1. 트랜잭션 격리성 수준 4가지
2. 트랜잭션 격리성의 동시성 문제
3. 트랜잭션 격리성의 설정 및 조회
4. 결론
트랜잭션 격리성은 여러 트랜잭션이 동시에 실행될 때 데이터의 일관성을 어떻게 유지할지를 결정하는 기준으로, 다양한 격리성 수준이 정의되어 있다.
트랜잭션 격리성 수준이 어떤 것이 존재하고, 이로 인해 해결되는 동시성 문제가 무엇인지 알아보자
1. 트랜잭션 격리성 수준 4가지
READ UNCOMMITTED (커밋 전 읽기)
- 트랜잭션 작업이 커밋되지 않아도 데이터를 읽을 수 있다.
- 트랜잭션 간의 락을 사용하지 않아서 성능이 가장 좋다.
- 다만 더러운 읽기 (Dirty Read), 반복 불가능한 읽기 (Non-Repeatable Read), 팬텀 읽기 (Phantom Read)와 같은 동시성 문제가 발생할 수 있다.
READ COMMITTED (읽기 완료)
- 트랜잭션이 커밋된 데이터만 읽을 수 있다. 즉, 다른 트랜잭션이 커밋한 변경 사항만 읽을 수 있다.
- Dirty Read는 방지 되지만 Non-Repeatable Read와 Phantom Read가 여전히 발생한다
REPEATABLE READ (반복 읽기 가능, 일관적인 읽기 가능)
- 트랜잭션이 시작된 시점의 데이터 상태를 유지하며, 트랜잭션이 끝날 때까지 동일한 데이터를 반복해서 읽을 수 있다.
- 즉, 트랜잭션이 실행되는 동안 읽은 데이터는 트랜잭션의 종료까지 일관되게 유지된다
- 대부분의 DB가 REPEATABLE READ 트랜잭션 격리성 수준을 기본으로 가져간다
- 기본적으로 공유 락을 걸어서 데이터의 변경을 방지해 일관적인 읽기가 가능하도록 하지만 Mysql에 경우 MVCC를 활용해서 일관적 읽기가 가능하도록 한다.
MVCC (Multi-Version Concurrency Control)는 트랜잭션이 데이터를 읽을 때, 데이터의 버전 관리와 스냅샷을 활용하여 읽기 일관성을 제공한다.
데이터베이스는 트랜잭션이 시작될 때의 데이터 상태를 유지하며, 이로 인해 반복 읽기 문제를 해결한다
SERIALIZABLE (직렬화 가능)
- 가장 높은 격리성 수준으로, 모든 트랜잭션이 순차적으로 실행되는 것처럼 동작한다.
- 즉, 트랜잭션들이 서로 간섭하지 않도록 보장한다
2. 트랜잭션 격리성의 동시성 문제
Dirty Read (더러운 읽기)
- 커밋전 읽기 라고도 하며 말 그대로 특정 트랜잭션에서 수정한 자원을 커밋하지 않아도 다른 트랜잭션에서 조회가 가능한 것을 의미한다.
Non-Repeatable Read (반복 불가능한 읽기)
- 반복 불가능한 읽기는 일관적이지 않은 읽기라고도 말할 수 있다.
- 트랜잭션이 동일한 데이터를 여러 번 읽을 때 다른 트랜잭션에 의해서 데이터가 변경되어 일관적이지 않은 데이터 조회가 발생하는 현상이다.
Phantom Read (팬텀 읽기)
- 트랜잭션이 쿼리를 실행할 때, 다른 트랜잭션이 새로운 데이터를 삽입하거나 삭제하여 결과가 달라지는 현상이다.
3. 트랜잭션 격리성 조회 및 설정
# 현재 세션의 트랜잭션 격리성 수준 조회
# MySQL
SELECT @@session.tx_isolation AS 'Isolation Level';
SELECT @@session.transaction_isolation AS 'Isolation Level';
# PostgreSQL
SHOW transaction_isolation;
# Oracle
SELECT s.SESSION_ID, s.ISOLATION_LEVEL
FROM V$SESSION s
WHERE s.SESSION_ID = SYS_CONTEXT('USERENV', 'SESSIONID');
# 글로벌 트랜잭션 격리성 설정
SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE READ;
4. 결론
트랜잭션 격리성은 트랜잭션 간의 데이터 충돌을 방지하고 데이터베이스의 일관성과 무결성을 유지하는 중요한 개념이다. 격리성 수준을 적절히 설정함으로써 성능과 데이터 무결성 간의 균형을 맞출 수 있다.
되도록이면 기본 트랜잭션 격리성을 변경하지 않는게 좋다. 다만 각 격리성에 따라서 발생할 수 있는 문제점을 잘 숙지하면 좋을 것 같다
'IT > 백엔드 필수 교양' 카테고리의 다른 글
[Java] 스프링에서 자주 사용하는 디자인 패턴 - 전략 패턴 (0) | 2024.08.05 |
---|---|
[DB] foreign key와 공유 락에 관하여 (0) | 2024.08.01 |
[JAVA] 비동기 요청으로 인한 동시성 테스트 하기 (0) | 2024.07.31 |
[k6] k6를 활용해서 Spring Boot API 부하 테스트 하기 (0) | 2024.07.30 |
[DB] Lock이란? (0) | 2024.07.29 |