✏️ 트랜잭션과 ACID 원칙
🏁 트랜잭션과 ACID 원칙에 대해서 설명해주세요
트랜잭션
트랜잭션은 DBMS에서 논리적 기능을 수행하기 위한 작업의 단위를 의미합니다.
ACID 원칙
- ACID원칙은 트랜잭션이 DBMS에서 안전하게 수행되도록 보장하기 위한 성질을 의미하는 4가지 원칙의 약어입니다.
원자성(Atomicity): 트랜잭션에 포함된 작업은 전부 수행되거나 아니면 전부 수행되지 않아야 합니다. (all or nothing)일관성(Consistency): 트랜잭션을 수행하기 전이나 수행한 후나 데이터베이스는 항상 일관된 상태를 유지해야 합니다.독립성(Isolation): 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장해야 합니다.지속성(Durability): 수행을 성공적으로 완료한 트랜잭션은 변경한 데이터를 영구히 저장해야 합니다. 저장된 데이터 베이스는 저장 직후 혹은 어느 때나 사용자 또는 시스템에 발생할 수 있는 장애, 오류에 영향을 받지 않아야 합니다.
🤔 DBMS는 Durability를 어떻게 보장할까?
해당 트랜잭션에 대한 로그를 남겨놓는 방식으로 Durability를 보장할 수 있습니다.
Write-Ahead Logging (WAL): 대부분의 관계형 데이터베이스 관리 시스템(RDBMS)에서는 Write-Ahead Logging을 사용하여 내구성을 보장합니다. 이 방법에서는 트랜잭션이 커밋되기 전에 해당 변경 사항을 로그 파일에 먼저 기록한 후, 데이터 파일에 변경 사항을 적용합니다. 따라서 트랜잭션을 커밋하기 전에 로그에 기록되어 있는 모든 변경 사항은 시스템 장애 시에도 복구될 수 있습니다.
🚀 트랜잭션의 수행 과정
트랜잭션 수행을 완료하면 부분완료 또는 실패 상태 중 하나가 됩니다. DBMS는 부분완료 상태에서는 작업한 내용을 데이터베이스에 반영하고, 실패 상태에서는 작업한 내용을 취소합니다.
부분완료: 트랜잭션 수행은 완료됐지만 변경 내용이 데이터 베이스에 기록됐는지 확실하지 않은 상태입니다. 이 상태에서는 DBMS가 최종적으로 변경 내용을 데이터베이스에 기록해야 완료 상태(지속성)가 됩니다.실패: 트랜잭션을 중간에 중단하였거나 부분완료 상태에서 변경 내용을 데이터베이스에 저장하지 못한 상태를 말합니다. 실패 상태에서 DBMS는 트랜잭션이 수행한 작업을 모두 원상복구시킵니다.
🤫 트랜잭션은 어떤 경우에 사용할 수 있을까?
특정 테이블의 잘못된 값을 수정하는 경우
- 잘못된 값 확인: 먼저 잘못된 값을 확인
- 트랜잭션 시작: 트랜잭션을 시작(START TRANSACTION). 변경 작업을 묶어서 처리
- 값 수정: 잘못된 값을 올바른 값으로 수정
- 커밋: 변경 작업이 완료되었을 경우, 트랜잭션을 커밋하여 변경 사항을 영구적으로 반영
- 롤백(옵션): 만약 변경 작업 중에 문제가 발생하여 트랜잭션을 취소해야 할 경우, 롤백을 수행하여 원래의 상태로 되돌림.
DB에 새로운 데이터를 추가하는 경우
- 웹 서버에서 POST로 받은 요청이 유저의 장바구니에 상품을 담는다고 가정하였을 때 해당 유저의 장바구니 테이블에 상품의 PK 값을 추가하는 경우
- 특정 상품을 상품 테이블에서 조회 후 PK 값 확인
- 특정 유저를 유저 테이블에서 조회 후 PK 값 확인
- 트랜잭션 시작: 트랜잭션을 시작(START TRANSACTION). 변경 작업을 묶어서 처리
- 유저와 상품의 관계를 정의하는 장바구니 테이블에 각각의 PK 값을 Foreign Key로 사용하여 레코드 추가
- 커밋: 추가 작업이 완료되었을 경우, 트랜잭션을 커밋하여 변경 사항을 영구적으로 반영
- 롤백(옵션): 만약 추가 작업 중에 문제가 발생하여 트랜잭션을 취소해야 할 경우, 롤백을 수행하여 원래의 상태로 되돌림.
이외에도, 작업을 수행하기 위해 여러 쿼리를 실행해야 할 때, 각 쿼리의 성공 유무가 다른 쿼리의 결과에 critical한 영향을 미치는 경우(예를 들어, 계좌 입/출금 등의 경우)에 트랜잭션을 활용할 수 있습니다.
✚ 트랜잭선 수준 읽기 일관성과 트랜잭션 고립화 수준
트랜잭션이 시작된 시점부터 데이터를 일관성있게 데이터를 읽어들일 수 있도록 하는 것을 트랜잭션 수준 읽기 일관성이라고 합니다. 이 때, 트랜잭션 고립화 수준에 따라 일관성의 정도를 조절할 수 있습니다.
- 트랜잭션 고립화 수준
- 레벨 0 (Read Uncommitted)
- 트랜잭션에서 처리 중인, 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용합니다.- Dirty Read, Non-Repeatable Read, Phantom Read 현상이 발생합니다.
- 레벨 1 (Read Committed)
- 트랜잭션이 커밋되어 확정된 데이터만 읽는 것을 허용합니다. (Dirty Read 방지)
- Non-Repeatable Read, Phantom Read 현상은 여전히 발생
- 레벨 2 (Repeatable Read)
- 선행 트랜잭션이 읽고 있는 데이터는 해당 트랜잭션이 종료될 때까지 후행 트랜잭션이 갱신, 삭제하는 것을 허용하지 않습니다.
- Phantom Read 현상은 여전히 발생
- 레벨 3 (Serializable Read)
- 선행 트랜잭션이 읽고 있는 데이터는 해당 트랜잭션이 종료될 때까지 후행 트랜잭션이 갱신, 삭제, 삽입하는 것을 허용하지 않습니다.
- 완벽하게 읽기 일관성 모드를 제공합니다.
낮은 단계의 트랜잭션 고립화 수준을 사용할 때 발생하는 세 가지 현상
-
Dirty Read
Dirty Read는 다른 트랜잭션에 의해 수정됐지만 아직 커밋되지 않은 데이터를 읽는 것을 말합니다. 위 예시를 보면, Transaction_1이 정상처리되지 않고 Rollback될 수 있습니다. 이럴 경우 그 값을 이미 읽은 Transaction_2는 잘못된 값을 가지고 본인의 로직을 처리하는 상태에 놓이게 됩니다. -
Non-Repeatable Read
Non-Repeatable Read는 한 트랜잭션 내에서 같은 Key를 가진 Row를 두 번 읽었는데 그 사이에 값이 변경되거나 삭제되어 결과가 다르게 나타나는 현상을 말합니다. -
Phantom Read
Phantom Read는 한 트랜잭션 내에서 같은 쿼리를 두 번 수행했는데, 첫 번째 쿼리에서 없던 유령(Phantom) 레코드가 두 번째 쿼리에서 나타나는 현상을 말합니다.
🙏 본 개념의 정리에 대한 피드백과 질문은 환영입니다!
본 개념의 다른 정리 및 피드백, 인터뷰 주제의 순서는 테크 인터뷰 스터디 Repository에서 확인 가능합니다.
