[Database] DB Transaction

Yanison·2023년 2월 14일
0

DataBase

목록 보기
2/2

트랜잭션

트랜잭션은 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 작업의 단위를 말한다.
데이터베이스에 접근하는 방법은 쿼리이므로, 즉 여러 개의 쿼리들을 하나로 묶는 단위를 말한다.

이에 대한 특징은 원자성,일관성,독립성,지속성이 있으며 이를 한꺼번에 ACID 특징이라고 한다.

  • 원자성(atomicity)
  • 일관성(consistency)
  • 독립성(isolation)
  • 지속성(durability)

원자성(Atomicity)

원자성은 트랙젝션과 관련된 일이 모두 수행되었거나 되지 않았거나를 보장하는 특징입니다. 예를 들어 트랜젝션을 커밋했는데, 문제가 발생하여 롤백 하는 경우 그 이후에 모두 수행되지 않음을 보장하는 것을 말합니다.

"all or nothing"

예를 들어 1000만 원을 가진 홍철이가 0원을 가진 규영이에게 500만원을 이체한다고 가정해봅시다.
그렇다면 결과적으로 홍철이 500만원 규영이 500만원을 가지게 되는데 해당 결과는 다음과 같은 operation 단위들로 이루어진 과정을 거침니다.

1.홍철의 잔고를 조회
2.홍철의 잔고에서 500만원을 출금
3.규영의 잔고에 500만원을 입금

여기서 1~3의 operation 중 데이터베이스 사용자는 이 세 가지 과정을 볼 수도 참여할 수도 없습니다. 다만 이 과정이 모두 끝난 이후 상황인 홍철 500만 원, 규영 500만 만원인 상황만 보는것이죠.

만약 이 작업을 도중 취소한다 했을때 홍철은 다시 1000만원, 규영이는 0원을 가져야 합니다. 위의 operation 중 어느 일부도 적용되지 않고 없었던 일이 되는 것이죠. 그래서 all or nothing 입니다.

또한, 트랜잭션 단위로 여러 로직들을 외부에 묶을 때 외부 API를 호출하는 것이 있으면 안됩니다. 만약 있다면 롤백이 일어났을 때 어떻게 해야 할 것인지에 대한 해결 방법이 있어야 하고 트랜잭션 전파를 신경써서 관리해야 합니다.

커밋과 롤백

커밋(commit)은 여러 쿼리가 성공적으로 처리되었거나 확정하는 명령어 입니다. 트랜잭션 단위로 수행하면서 변경된 내용이 모두 영구적으로 저장되는 것을 말합니다. "커밋이 수행되었다."를 "하나의 트랜잭션이 성공적으로 수행 되었다" 라고도 말합니다.

위의 그림처럼 update,insert,delete 쿼리가 하나의 트랜잭션 단위로 수행되고 이후에 데이터베이스에 영구 저장됩니다.


하지만 에러나 여러 이슈 때문에 트랜잭션 전으로 되돌려야 한다면 어떻게 해야 할까요? 이 때 사용하는 것이 롤백입니다. 롤백이란 트랜잭션으로 하나의 묶음 과정을 일어나기 전으로 돌리는 일(취소)를 말합니다.

롤백이란 트랜잭션으로 처리한 하나의 묶음과정을 이러나기 전으로 돌리는 일(취소)을 말합니다. 이러한 커밋과 롤백 덕에 데이터의 무결성이 보장이 됩니다. 또한, 데이터 변경 전에 변경 사항을 쉽게 확인할 수 있고 해당 작업을 그룹화할 수 있습니다.

트랜잭션 전파

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

예를들어 Develog 블로그 글을 쓰는 기능을 구현한다고 하였을때 글쓰기 기능에 다음과 같은 기능이 있다 가정해보자.

  • 글 임시 저장기능
  • 로깅 기능

이 글쓰기 기능에 트랜잭션 처리가 되어 있다면 로깅 기능에서 예외가 터질때 롤백이 시작되는데 임시 저장된 글 까지 롤백이 되버린다면 임시저장 글의 의미가 없어지게 된다. 이처럼 여러 트랜잭션을 하나의 메소드의 호출에 묶여있는걸 트랜잭션 전파라 한다.

스프링에서는 하나의 메소드, 혹은 하나의 클래스에 @Transactional 이라는 어노테이션을 통해 여러 쿼리 관련 코드들을 하나의 트랜잭션으로 처리한다.

@Service
@Transactional(readOnly=true) // 클래스 전체가 하나의 트랜잭션 단위로 묶여있음. 
public class MemberService"{
	private final MemberRepository memberRepository;
    
    private MemberService(MemberRepository memberRepository){
    	this.memberRepository = memberRepository;
    }
}

일관성(Consistency)

트랜잭션에서 일관성은 '허용된 방식'으로만 데이터를 변경해야 하는 것을 의미합니다. 데이터 베이스에 기록된 모든 데이터는 여러 가지 조건, 규칙에 따라 유효함을 가져야 합니다. 예를들어 홍철이는 1000만 원 이 있고 범석이가 0원이 있다고 칩시다. 범석이가 필자한테 500만 원을 입금할 수 있을까요? 불가능 합니다.(마이나스 통장은 제외)


격리성(Isolation)

격리성은 트랜잭션 수행 시 서로 끼어들지 못하는 것을 말합니다. 복수의 병렬 트랜잭션은 서로 격리되어 마치 순차적으로 실행되는 것처럼 작동되어야 하고, 데이터베이스는 여러 사용자가 같은 데이터에 접근할 수 있어야 합니다. 그냥 순차적으로 하면 쉽게 되겠지만 그렇게 하면 성능이 나쁘겠죠?

격리성은 여러 개의 격리 수준으로 나뉘어 격리성을 보장합니다.

격리 수준은 다음과 같습니다. 격리 수준이 높은순 입니다.

  • READ_UNCOMITTED
  • READ_COMMITTED
  • REPEATABLE_READ
  • SERIALIZABLE

위로 갈 수록 동시성이 강해지지만 격리성이 약해지고, 아래로 갈 수록 동시성이 약해지지만 격리성은 강해집니다. 예를들어 SERIALIZABLE은 격리성이 강한데 반해, 동시성은 약합니다. 또한, 각 단계마다 나타는 현상이 있습니다.

격리 수준에 따라 발생하는 현상

REPEATABLE_READ는 팬텀리드, 반복 가능하지 않는 조회, 더티 리드가 발생할 수도 있습니다.
READ_COMMITTED 팬텀리드, 반복 가능하지 않는 조회가 발생
READ_UNCOMITTED 팬텀리드, 반복 가능하지 않는 조회, 더티 리드가 발생할 수도 있습니다.

팬텀리드(phantom read)

예를 들어 사용자 A가 회원 테이블에서 age가 12 이상인 회원들을 조회하는 쿼리를 보낸다고 해봅시다. 이 결과로 세 개의 테이블이 조회한다고 해보죠. 그다음 사용자 B가 age가 15인 회원 레코드를 삽입합니다.

위 그림처럼 한 트랜젝션 흐름에서 동일한 쿼리를 보냈을때 조회 결과가 다른 경우를 팬텀 리드라 합니다.


반복 가능하지 않는 조회

반복 가능하지 않는 조회(non-repeatable read)는 한 트랜잭션 내의 같은 행에 두 번 이상 조회가 발생했는데, 그 값이 다른 경우를 가리킵니다. 예를 들어 age가 100인 회원 테이터가 있는데, 그 이후 회원의 나이를 1로 변경해서 커밋 했다고 하면 사용자는 100이 아닌 1을 읽게 됩니다.

팬텀리드와 차이점은??
한 트랜잭션에서 두번 이상의 조회가 발생 되었다고 했을때 팬텀 리드는 조회한 행의 값이 달라질 수도 있는것이고 반복 가능하지 않는 조회는 조회한 행의 값이 같더라도 조회한 행의 값이 달라질 수 있다는 차이가 있습니다.


더티 리드

반복 가능하지 않는 조회와 유사하며 한 트랜잭션이 실행 중일 때 다른 트랜잭션에 의해 수정되었지만 아직 '커밋되지 않은' 행의 데이터를 읽을 수 있을 때 발생합니다. 예를 들어 사용자 A가 큰 돌의 보석 개수
100을 1로 변경한 내용이 '커밋되지 않은' 상태라도 그 이후 사용자 B가 조회한 결과가 1로 나오는 경우를 말합니다.


격리수준

SERIALIZABLE

SERIALIZABLE은 말 그대로 트랜잭션을 순차적으로 진행시키는 것을 말합니다. 여러 트랜잭션이 동시에 같은 행에 접근할 수 없습니다. 이 수준은 매우 엄격한 수준으로 해당 행에 대해 격리시키고, 이후 트랜잭션이 이 행에 대해 일어난다면 기다려야 합니다. 그렇기 때문에 교착 상태가 일어날 확률도 많고 가장 성능이 떨어지는 격리수준 입니다.

REPEATABLE_READ

REPEATABLE_READ는 하나의 트랜잭션이 수정한 행을 다른 트랜잭션이 수정할 수 없도록 막아주지만 새로운 행을 추가하는 것은 막지 않습니다. 따라서 이후에 추가된 행이 발견될 수도 있습니다.

나타날 수 있는 현상

  • 팬텀리드

READ_COMMITTED

READ_COMMITTED는 가장 많이 사용되는 격리수준이며 MySQL 8.0, PostgreSQL,SQL Server, 오라클에서 기본값으로 설정되어 있습니다. READ_UNCOMMITTED와는 달리 트랜잭션이 커밋하지 않은 정보는 읽을 수 없습니다. 즉, 커밋 완료된 데이터에 대해서만 조회를 허용합니다.

하지만 어떤 트랜잭션이 접근한 행을 다른 트랜잭션이 수정할 수 있습니다. 예를 들어 트랜잭션 A가 수정한 행을 트랜잭션 B가 수정할 수도 있습니다. 이 때문에 트랜잭션 A가 같은 행을 다시 읽을 때 다른 내용이 발견될 수 있습니다.

나타날 수 있는 현상

  • 팬텀리드
  • 반복 가능하지 않는 조회

READ_UNCOMMITTED

READ_UNCOMMITTED는 가장 낮은 격리 수준으로, 하나의 트랜잭션이 커밋되기 이전에 다른 트랜잭션에 노출되는 문제가 있으나 가장 빠릅니다. 이는 데이터 무결성을 위해 되도록이면 사용되지 않는 것이 이상적이나, 몇몇 행이 제대로 조회되지 않더라도 괜찮은 거대한 양의 데이터를 '어림잡아' 사용하는 데는 사용하면 좋습니다.

지속성(Durability)

지속성(durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 하는 것을 의미합니다.
이는 데이터베이스에 시스템 장애가 발생해도 원래 상태로 복구하는 회복 기능이 있어야 함을 뜻하며, 데이터베이스는 이를 위해 체크섬, 저널링, 롤백 등의 기능을 제공합니다.

  • 체크섬
    중복 검사의 한 형태로, 오류 정정을 통해 송신된 자료의 무결성을 보호하는 단순한 방법
  • 저널링
    파일 시스템 또는 데이터배이스 시스템에 변경 사항을 반영(commit)하기 전에 로깅하는 것, 트랜잭션 등 변경 사항에 대한 로그를 남기는 것

무결성

무결성이란 데이터의 정확성, 일관성, 유효성을 유지하는 것을 말하며, 무결성이 유지되어야 데이터베이스에 저장된 데이터 값과 그 값에 해당하는 현실 세계의 실제 값이 일치 하는지에 대한 신뢰가 생깁니다. 무결성의 종류는 다음과 같습니다.

  • 개체 무결성 :: 기본키로 선택된 필드는 빈 값을 허용하지 않습니다.
  • 참조 무결성 :: 서로 참조 관계에 있는 두 테이블의 데이터는 항상 일관된 값을 유지해야 합니다.
  • 고유 무결성 :: 특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우 그 속성값은 모두 고유한 값을 가집니다.
  • NULL 무결성 :: 특정 속성 값에 NULL이 올 수 없다는 조건이 주어진 경우 그 속성 값을 NULL이 될 수 없다는 제약 조건입니다.

요약
트랜잭션은 하나의 논리적 기능을 수행하기 위한 작업의 단위이며 각 트랜잭션의 단위는 원자성,일관성,격리성,지속성이 보장이 되어야 무결성이 유지되어야 합니다. 무결성이 유지된다는 의미는 데이터베이스에 저장된 값과 그 값에 해당하는 현실 세계의 실제 값이 일하는지에 대한 신뢰가 생기는 것 입니다. 예를들어 유저는 은행에 돈을 저축하면 유저의 입장에서는 단 한번의 요청(request)로 통장 잔고에 유저의 돈이 저축이 되는 것을 확인 할 수 있지만 은행의 저축 시스템은 여러가지 논리적 작업들이 모인 기능이므로 해당 시스템 내부의 트랜잭션으로 묶인 모든 논리적 작업들이 상기 ACID 특성들이 보장이 되어야 무결성이 보장된, 즉 신뢰성 있는 저축 시스템이 될 수 있다는 것 입니다.

내용 참고 :: 면접을 위한 CS 전공지식 노트, 주홍철 저
profile
Yanison's devlog

0개의 댓글