트랜잭션: 두 판 사이의 차이

기술노트
(CS 용어 정리 - 트랜잭션 추가)
 
(Gemini 벌크 업로더로 자동 업로드)
 
(같은 사용자의 중간 판 3개는 보이지 않습니다)
1번째 줄: 1번째 줄:
== 트랜잭션 ==
<div style="font-family: 'Malgun Gothic';">
---
= 트랜잭션 (Transaction) =
> 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 작업의 단위
[[기술면접 CS 지식|← 목록으로 돌아가기]]
> 여러 개의 쿼리들을 하나로 묶는 단위


'''ACID 특징'''
'''트랜잭션은 데이터베이스의 상태를 변화시키기 위해 수행하는 논리적인 작업의 단위입니다.'''
트랜잭션에 대한 특징으로 원자성, 일관성, 독립성, 지속성이 있다.


=== 1. 원자성(atomicity) ===
하나의 트랜잭션은 한 개 이상의 SQL 쿼리(INSERT, DELETE, UPDATE 등)를 포함할 수 있습니다. 예를 들어, '계좌 이체'라는 하나의 논리적 작업을 위해 'A 계좌 잔액 차감'과 'B 계좌 잔액 증가'라는 두 개의 쿼리가 실행되어야 합니다. 데이터베이스는 이 두 쿼리를 하나의 트랜잭션, 즉 쪼갤 수 없는 작업 단위로 묶어 데이터의 무결성과 일관성을 보장합니다.
> "all or nothing"
> 트랜잭션과 관련된 일이 모두 수행되었거나 되지 않았거나를 보장하는 특징


예를 들어 트랜잭션을 커밋했는데, 문제가 발생하여 롤백하는 경우 그 이후에 모두 수행되지 않음을 보장하는 것
----


트랜잭션 단위로 여러 로직들을 묶을 때 외부 API를 호출하는 것이 있으면 안 된다. 만약 있다면 롤백이 일어났을 때 어떻게 해야 할 것인지에 대한 해결 방법이 있어야 하고 트랜잭션 전파를 신경 써서 관리해야 한다.
== 트랜잭션이 필요한 이유 ==
만약 트랜잭션이라는 개념이 없다면, 'A 계좌 잔액 차감'에는 성공했지만, 그 직후 시스템 장애로 'B 계좌 잔액 증가'에는 실패하는 상황이 발생할 수 있습니다. 이 경우 A의 돈은 사라졌지만 B에게는 전달되지 않아 데이터의 정합성이 깨지는 심각한 문제가 발생합니다. 트랜잭션은 이와 같은 문제를 방지하고 데이터베이스를 항상 신뢰할 수 있는 상태로 유지하기 위해 반드시 필요합니다.


==== 커밋과 롤백 ====
----
'''커밋(commit)''' : 여러 쿼리가 성공적으로 처리되었다고 확정하는 명령어
* 트랜잭션 단위로 수행
* 변경된 내용이 모두 영구적으로 저장된다.
* "커밋이 수행되었다." == "하나의 트랜잭션이 성공적으로 수행되었다."
* update, insert, delete의 쿼리가 하나의 트랜잭션 단위로 수행되고, 이후에 DB에 영구 저장된다.


'''롤백''' : 트랜잭션으로 처리한 하나의 묶음 과정을 일어나기 전으로 돌리는 일(취소)
== 트랜잭션의 핵심 속성: ACID ==
* 에러나 여러 이슈 때문에 트랜잭션 전으로 돌려야 할 때 사용
신뢰할 수 있는 트랜잭션은 반드시 4가지 핵심 속성을 만족해야 하며, 이를 **ACID**라고 부릅니다.


커밋과 롤백 덕에 '''데이터의 무결성'''이 보장된다. 또한 데이터 변경 전에 변경 사항을 쉽게 확인할 수 있고 해당 작업을 그룹화할 수 있다.
*  **원자성 (Atomicity):** 트랜잭션의 모든 작업이 전부 성공하거나, 전부 실패해야 합니다.
*  **일관성 (Consistency):** 트랜잭션 실행 후에도 데이터베이스는 항상 일관된 상태를 유지해야 합니다.
*  **고립성 (Isolation):** 하나의 트랜잭션은 다른 트랜잭션의 영향을 받지 않고 독립적으로 실행되어야 합니다.
*  **지속성 (Durability):** 성공한 트랜잭션의 결과는 영구적으로 저장되어야 합니다.


각 속성에 대한 자세한 설명은 아래 링크를 참고하세요.
*  **[[ACID|→ ACID 원칙 자세히 알아보기]]**


'''트랜잭션 전파'''
----
> 트랜잭션을 수행할 때 커넥션 단위로 수행하기 때문에 커넥션 객체를 넘겨서 수행해야 한다. 하지만 이를 매번 넘겨주기가 어렵고 번거롭다. 이를 넘겨서 수행하지 않고 여러 트랜잭션 관련 메서드의 호출을 하나의 트랜잭션에 묶이도록 하는 것을 말한다.


<syntaxhighlight>java
== 트랜잭션의 상태 변화 ==
트랜잭션은 실행 과정에서 다음과 같은 5가지 상태를 거칩니다.


@Service
; 1. 활동 (Active)
@Transactional(readOnly = true)
: 트랜잭션이 실행을 시작하여 현재 실행 중인 상태입니다. 연산들이 정상적으로 실행되고 있는 동안 이 상태를 유지합니다.
public class MemberService {
private final MemberRepository memberRepository;
public MemberService(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
}
</syntaxhighlight>
* `@Transactional` 애너테이션을 통해 여러 쿼리 관련들을 하나의 트랜잭션으로 처리 (Spring 프레임워크)


; 2. 부분 완료 (Partially Committed)
: 트랜잭션의 마지막 연산까지 모두 실행했지만, 아직 데이터베이스에 최종적으로 변경 내용을 반영하지는(COMMIT) 않은 상태입니다. 모든 연산이 성공했음을 확인하고 최종 커밋을 준비하는 단계입니다.


; 3. 완료 (Committed)
: 트랜잭션의 모든 연산이 성공적으로 완료되어, 변경 내용이 데이터베이스에 영구적으로 저장된 상태입니다. COMMIT 연산을 통해 이 상태가 됩니다.


=== 2. 일관성(cnsistency) ===
; 4. 실패 (Failed)
---
: 하드웨어 고장, 데이터 무결성 제약조건 위반 등 여러 이유로 트랜잭션의 실행이 중단된 상태입니다.
>'허용된 방식'으로만 데이터를 변경해야 하는 것


데이터베이스에 기록된 모든 데이터는 여러 가지 조건, 규칙에 따라 유효함을 가져야 한다. 예를 들어 홍철이는 1000만 원이 있고 범석이는 0원이 있다고 할 때, 범석이가 나에게 500만원을 입금하는 것은 불가능하다. 0원으로부터 500만원이 나오는 것은 불가능하다.
; 5. 철회 (Aborted)
: 트랜잭션이 실패하여 실행 이전의 상태로 모든 작업을 되돌린(ROLLBACK) 상태입니다. 트랜잭션이 비정상적으로 종료되었음을 의미합니다.


----


=== 3. 격리성(isolation) ===
== 트랜잭션 제어 언어 (TCL) ==
---
사용자는 SQL의 트랜잭션 제어 언어(TCL)를 통해 트랜잭션을 직접 제어할 수 있습니다.
> 트랜잭션 수행 시 서로 끼어들지 못하는 것


* 복수의 병렬 트랜잭션은 서로 격리되어 마치 순차적으로 실행되는 것처럼 작동되어야 한다.
*   `COMMIT`: 모든 작업을 최종적으로 데이터베이스에 반영합니다.
* 데이터베이스는 여러 사용자가 같은 데이터에 접근할 수 있어야 한다. 순차적으로 하면 쉽게 되겠지만 성능이 나빠진다.
*   `ROLLBACK`: 진행된 모든 작업을 취소하고 트랜잭션 이전 상태로 되돌립니다.
*  `SAVEPOINT`: 트랜잭션 내에 중간 저장 지점을 만들어, 특정 지점까지만 롤백할 수 있도록 합니다.


격리성은 여러 개의 격리 수준으로 나뉘어 격리성을 보장한다.
</div>
![[Pasted image 20230207110611.png]]
 
 
'''격리 수준'''
* SERIALIZABLE, REPEATABLE_READ, READ_COMMITTED, READ_UNCOMMITTED
* 위로 갈수록 동시성이 강해지고, 격리성은 약해진다.
* 아래로 갈수록 동시성은 약해지고, 격리성은 강해진다.
 
'''각 단계마다 나타나는 현상'''
REPEATABLE_READ - 팬텀 리드
READ_COMMITTED - 팬텀 리드, 반복 가능하지 않은 조회 발생
READ_UNCOMMITTED - 팬텀 리드, 반복 가능하지 않은 조회, 더티 리드 발생 가능
 
 
==== 격리 수준에 따라 발생하는 현상 ====
'''팬텀 리드(phantom read)'''
> 한 트랜잭션 내에서 동일한 쿼리를 보냈을 때 해당 조회 결과가 다른 경우
 
예를 들어 사용자 A가 회원 테이블에서 age가 12 이상인 회원들을 조회하는 쿼리를 보낸다고 했을 때, 이 결과로 세 개의 테이블이 조회된다고 한다. 그 다음 사용자 B가 age가 15인 회원 레코드를 삽입한다. 그러면 그다음 세 개가 아닌 네 개의 테이블이 조회되는 것이다.
 
 
'''반복 가능하지 않은 조회(non-repeatable read)'''
> 한 트랜잭션 내의 같은 행에 두 번 이상 조회가 발생했는데, 그 값이 다른 경우
 
예를 들어 사용자 A가 큰돌의 보석 개수가 100개라는 값을 가진 데이터였는데, 그 이후 사용자 B가 그 값을 1로 변경해서 커밋했다고 하면 사용자 A는 100이 아닌 1을 읽게 된다.
 
팬텀 리드와의 차이점 : 반복 가능하지 않은 조회는 행 값이 달라질 수도 있는데, 팬텀 리드는 다른 행이 선택될 수도 있다.
 
 
'''더티 리드(dirty read)'''
> 한 트랜잭션이 실행 중일 때 다른 트랜잭션에 의해 수정되었지만 아직 '커밋되지 않은' 행의 데이터를 읽을 수 있을 때 발생
 
예를 들어 사용자 A가 큰돌의 보석 개수 100을 1로 변경한 내용이 '커밋되지 않은' 상태라도 그 이후 사용자 B가 조회한 결과가 1로 나오는 경우를 말한다.
 
 
==== 격리 수준 ====
'''SERIALIZABLE'''
* 트랜잭션을 순차적으로 진행시키는 것
* 여러 트랜잭션이 동시에 같은 행에 접근할 수 없다.
* 매우 엄격한 수준으로 해당 행에 대해 격리시키고, 이후 트랜잭션이 이 행에 대해 일어난다면 기다려야 한다. 그렇기 때문에 교착 상태가 일어날 확률도 많고 가장 성능이 떨어지는 격리 수준
 
 
'''REPEATABLE_READ'''
* 하나의 트랜잭션이 수정한 행을 다른 트랜잭션이 수정할 수 없도록 막아주지만 새로운 행을 추가하는 것은 막지 않는다. 따라서 이후에 추가된 행이 발견될 수도 있다.
 
 
'''READ_COMMITTED'''
* 가장 많이 사용되는 격리 수준
* MySQL8.0, PostgreSQL, SQL Server, 오라클에서 기본값으로 설정되어 있다.
* READ_UNCOMMITTED와는 달리 다른 트랜잭션이 커밋하지 않은 정보는 읽을 수 없다. 즉, 커밋 완료된 데이터에 대해서만 조회를 허용한다.
* 하지만 어떤 트랜잭션이 접근한 행을 다른 트랜잭션이 수정할 수 있다.
- 예를 들어 트랜잭션 A가 수정한 행을 트랜잭션 B가 수정할 수도 있다. 이 때문에 트랜잭션 A가 같은 행을 다시 읽을 때 다른 내용이 발견될 수도 있다.
 
 
'''READ_UNCOMMITTED'''
* 가장 낮은 격리 수준
* 하나의 트랜잭션이 커밋되기 이전에 다른 트랜잭션에 노출되는 문제가 있지만 가장 빠르다.
* 이는 데이터 무결성을 위해 되도록이면 사용하지 않는 것이 이상적이나, 몇몇 행이 제대로 조회되지 않더라도 괜찮은 거대한 양의 데이터를 '어림잡아' 집계하는 데는 사용하면 좋다.
 
 
=== 4. 지속성(durabilitiy) ===
---
> 성공적으로 수행된 트랜잭션은 영원히 반영되어야 하는 것을 의미
 
* 데이터베이스에 시스템 장애가 발생해도 원래 상탵로 복구하는 회복 기능이 있어야 한다.
* 데이터베이스는 이를 위해 체크섬, 저널링, 롤백 등의 기능 제공
 
* 체크섬 : 중복 검사의 한 형태로, 오류 정정을 통해 송신된 자료의 무결성을 보호하는 단순한 방법
* 저널링 : 파일 시스템 또는 데이터베이스 시스템에 변경 사항을 반영(commit)하기 전에 로깅하는 것, 트랜잭션 등 변경 사항에 대한 로그를 남기는 것
 
 
 
 
== 무결성 ==
---
> 데이터의 정확성, 일관성, 유효성을 유지하는 것
> 무결성이 유지되어야 DB에 저장된 데이터 값과 그 값에 해당하는 실제 값이 일치하는지에 대한 신뢰가 생긴다.
 
==== 종류 ====
'''개체 무결성'''
* 기본키로 선택된 필드는 빈 값을 허용하지 않는다.
'''참조 무결성'''
* 서로 참조 관계에 있는 두 테이블의 데이터는 항상 일관된 값을 유지해야 한다.
'''고유 무결성'''
* 특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우 그 속성 값은 모두 고유한 값을 가진다.
'''NULL 무결성'''
* 특정 속성 값에 NULL이 올 수 없다는 조건이 주어진 경우 그 속성 값은 NULL이 될 수 없다는 제약 조건이다.

2025년 9월 11일 (목) 17:01 기준 최신판

트랜잭션 (Transaction)

← 목록으로 돌아가기

트랜잭션은 데이터베이스의 상태를 변화시키기 위해 수행하는 논리적인 작업의 단위입니다.

하나의 트랜잭션은 한 개 이상의 SQL 쿼리(INSERT, DELETE, UPDATE 등)를 포함할 수 있습니다. 예를 들어, '계좌 이체'라는 하나의 논리적 작업을 위해 'A 계좌 잔액 차감'과 'B 계좌 잔액 증가'라는 두 개의 쿼리가 실행되어야 합니다. 데이터베이스는 이 두 쿼리를 하나의 트랜잭션, 즉 쪼갤 수 없는 작업 단위로 묶어 데이터의 무결성과 일관성을 보장합니다.

트랜잭션이 필요한 이유

만약 트랜잭션이라는 개념이 없다면, 'A 계좌 잔액 차감'에는 성공했지만, 그 직후 시스템 장애로 'B 계좌 잔액 증가'에는 실패하는 상황이 발생할 수 있습니다. 이 경우 A의 돈은 사라졌지만 B에게는 전달되지 않아 데이터의 정합성이 깨지는 심각한 문제가 발생합니다. 트랜잭션은 이와 같은 문제를 방지하고 데이터베이스를 항상 신뢰할 수 있는 상태로 유지하기 위해 반드시 필요합니다.

트랜잭션의 핵심 속성: ACID

신뢰할 수 있는 트랜잭션은 반드시 4가지 핵심 속성을 만족해야 하며, 이를 **ACID**라고 부릅니다.

  • **원자성 (Atomicity):** 트랜잭션의 모든 작업이 전부 성공하거나, 전부 실패해야 합니다.
  • **일관성 (Consistency):** 트랜잭션 실행 후에도 데이터베이스는 항상 일관된 상태를 유지해야 합니다.
  • **고립성 (Isolation):** 하나의 트랜잭션은 다른 트랜잭션의 영향을 받지 않고 독립적으로 실행되어야 합니다.
  • **지속성 (Durability):** 성공한 트랜잭션의 결과는 영구적으로 저장되어야 합니다.

각 속성에 대한 자세한 설명은 아래 링크를 참고하세요.

트랜잭션의 상태 변화

트랜잭션은 실행 과정에서 다음과 같은 5가지 상태를 거칩니다.

1. 활동 (Active)
트랜잭션이 실행을 시작하여 현재 실행 중인 상태입니다. 연산들이 정상적으로 실행되고 있는 동안 이 상태를 유지합니다.
2. 부분 완료 (Partially Committed)
트랜잭션의 마지막 연산까지 모두 실행했지만, 아직 데이터베이스에 최종적으로 변경 내용을 반영하지는(COMMIT) 않은 상태입니다. 모든 연산이 성공했음을 확인하고 최종 커밋을 준비하는 단계입니다.
3. 완료 (Committed)
트랜잭션의 모든 연산이 성공적으로 완료되어, 변경 내용이 데이터베이스에 영구적으로 저장된 상태입니다. COMMIT 연산을 통해 이 상태가 됩니다.
4. 실패 (Failed)
하드웨어 고장, 데이터 무결성 제약조건 위반 등 여러 이유로 트랜잭션의 실행이 중단된 상태입니다.
5. 철회 (Aborted)
트랜잭션이 실패하여 실행 이전의 상태로 모든 작업을 되돌린(ROLLBACK) 상태입니다. 트랜잭션이 비정상적으로 종료되었음을 의미합니다.

트랜잭션 제어 언어 (TCL)

사용자는 SQL의 트랜잭션 제어 언어(TCL)를 통해 트랜잭션을 직접 제어할 수 있습니다.

  • `COMMIT`: 모든 작업을 최종적으로 데이터베이스에 반영합니다.
  • `ROLLBACK`: 진행된 모든 작업을 취소하고 트랜잭션 이전 상태로 되돌립니다.
  • `SAVEPOINT`: 트랜잭션 내에 중간 저장 지점을 만들어, 특정 지점까지만 롤백할 수 있도록 합니다.
원본 주소 "https://technote.wiki/index.php?title=트랜잭션&oldid=1111"