트랜잭션과 무결성
트랜잭션과 무결성
'트랜잭션'은 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 '작업의 단위'를 말한다. 그리고 DB에 접근하는 방법은 '쿼리'이다. 즉, 여러 개의 쿼리들을 하나로 묶는 단위를 말한다. 이에 대한 특징은 원자성, 일관성, 독립성, 지속성이 있고, 이를 'ACID 특징'이라고 한다.
원자성
ALL or NOTHING
'원자성(atomicity)'은 트랜잭션과 관련된 일이 모두 수행되었거나 되지 않았거나를 보장하는 특징이다. 만약 트랜잭션을 커밋했는데, 문제가 발생해 롤백하는 경우, 그 이후에 모두 수행되지 않음을 보장하는 것이다.
만약 1억을 가진 휘빈이가 0원을 가진 현호에게 5000만원을 이체한다고 해보자. 그러면 결과는 휘빈이 5000만원, 현호 5000만원일 것이다. 그리고 이 결과는 아래와 같은 operation단위로 이루어진다.
- 휘빈이의 잔고를 조회한다.
- 휘빈이 잔고에서 5000만원을 뺀다.
- 현호에게 5000만원을 넣는다.
위 1~3의 operation 중, 데이터베이스 사용자는 위 3가지의 과정을 볼 수도, 참여할 수도 없다. 그저 과정이 모두 끝난 결과인 휘빈이 5000만원, 현호 5000만원인 상황만 보게된다.
그리고 만약 이 작업을 '취소'한다고 한다면, 휘빈이는 다시 1억, 현호는 0원을 가져야한다. 일부 operation만 적용된 휘빈이 5000만원, 현호 0원 등의 상황은 되지 않는다는 것이다. 따라서 위에 적은 ALL or NOTHING 인것이다.
또한, 트랜잭션 단위로 여러 로직들을 묶을 때는 외부 API를 호출하는 것이 있으면 안된다. 만약 있다면 롤백이 일어났을 때 어떻게 할 것인지에 대한 해결방법이 있어야 하고, 트랜잭션 전파를 신경 써 관리해야 한다.
커밋과 롤백
'커밋(commmit)'은, 여러 쿼리가 성공적으로 처리되었다고 확정하는 명령어이다. 트랜잭션 단위로 수행되며, 변경된 내용이 모두 영구적으로 저장되는 것을 말한다. 따라서 "커밋이 수행되었다" 라는 말은, "하나의 트랜잭션이 성공적으로 수행되었다"라고 말할 수도 있다.
즉 예로들면, update, insert, delete의 쿼리가 하나의 트랜잭션 단위로 수행되고 이후에 데이터베이스에 영구 저장되는 것이다.
하지만 에러나 어떤 이슈 때문에 트랜잭션 전으로 돌려야 한다면 어떻해야 할까? 이 때는 '롤백'을 사용한다. '롤백'이란, 트랜잭션으로 처리한 하나의 묶음 과정을 일어나기 전으로 돌리는 일을 뜻한다.
이러한 '커밋'과 '롤백' 덕에 데이터의 무결성이 보장된다. 또한, 데이터 변경 전에 변경 사항을 쉽게 확인할 수 있고, 해당 작업을 그룹화할 수 있는 것이다.
트랜잭션 전파
트랜잭션을 수행할 때, 커넥션 단위로 수행하기 때문에 커넥션 객체를 넘겨서 수행해야 한다. 하지만 매번 넘겨주기 어렵고 귀찮은 작업이다. 따라서 이를 넘겨서 수행하지 않고, 여러 트랜잭션 관련 메서드의 호출을 하나의 트랜잭션에 묶이도록 하는 것을 '트랜잭션 전파'라고 한다.
아래의 코드를 참고해볼 수 있다.
@Service
@Transactional(readOnly = true)
public class VelogService{
private final VelogRepository velogrepository;
public VelogService(VelogRepository velogrespository){
this.velogRepository = velogRepository;
}
}위처럼 Spring에서는 @Transactional 애너테이션을 통해 여러 쿼리 관련 코드들을 하나의 트랜잭션으로 처리할 수 있다.
일관성
'일관성(consistency)'은, '허용된 방식'으로만 데이터를 변경해야 하는 것을 뜻한다. 데이터베이스에 기록된 모든 데이터는 여러 조건, 규칙에 따라 유효함을 가져야 한다. 만약 1억을 가진 휘빈이와 0원을 가진 현호가 있는데, 0원을 가진 현호가 휘빈이에게 입금을 할 수 있을까? 없을 것이다.
격리성
'격리성(isolation)'은, 트랜잭션 수행 시 서로 끼어들지 못하는 것을 말한다. 복수의 병렬 트랜잭션은 서로 격리되지만 마치 순차적으로 실행되는 것처럼 작동되어야 한다. 또한 데이터베이스는 여러 사용자가 '같은 데이터'에 접근할 수 있어야 한다.
그저 순차적으로 하면 쉬울 수 있겠지만, 성능은 나쁠 것이다. 따라서 '격리성'은 여러 개의 격리 수준으로 나뉘어 격리성을 보장한다.
아래 그림을 참고!!
격리 수준은 SERIALIZABLE, REPEATABLE_READ, READ_COMMITTED, READ_UNCOMMITTED가 있고, 볼 수 있는 것처럼, 위로 갈수록 동시성이 강해지지만 격리성은 약해지고, 아래로 갈수록은 반대의 모습을 보인다.
또한, 각 단계마다 나타나는 현상이 있다.
REPEATABLE_READ는 팬텀 리드, READ_COMMITTED는 팬텀 리드, 반복 가능하지 않은 조회, READ_UNCOMMITTED는 팬텀 리드, 반복 가능하지 않은 조회, 더티 리드가 발생할 수도 있다.
격리 수준에 따라 발생하는 현상
* 팬텀 리드
'팬텀 리드(phantom read)'는, 한 트랜잭션 내에서 동일한 쿼리를 보냈을 때, 해당 조회 결과가 다른 경우를 말한다.
만약, 유저A가 캐릭터 테이블에서 level이 6 이상인 캐릭터들을 조회하는 쿼리를 보냈다고 했을 때, 이 결과로 3개의 테이블이 조회한다고 해보자. 그다음 유저B가 level이 9인 캐릭터 레코드를 삽입한다. 그러면 그다음 3개가 아닌, 4개의 테이블이 조회되는 것이다.
* 반복 가능하지 않은 조회
'반복 가능하지 않은 조회(non-repeatable read)'는, 한 트랜잭션 내의 같은 행에 2번 이상 조회가 발생했는데, 그 값이 다른 경우를 뜻한다. 만약, 유저A가 아이템 개수가 100개라는 값을 가진 데이터였는데, 이후 유저B가 그 값을 1로 변경해서 커밋했다면, 유저A는 100이 아닌 1을 읽게 된다.
팬텀 리드와 다른 점은, 반복 가능하지 않은 조회는, 행 값이 달라질 수도 있는데, 팬텀 리드는 다른 행이 선택될 수도 있다는 것을 의미한다.
* 더티 리드
'더티 리드(dirty read)'는, 반복 가능하지 않은 조회와 비슷하며 한 트랜잭션이 실행 중일 때 다른 트랜잭션에 의해 수정되었지만, 아직 '커밋되지 않은'행의 데이터를 읽을 수 있을 때 발생한다. 만약, 유저A가 아이템 개수를 100개에서 1로 변경한 내용이 '커밋되지 않은' 상태라도, 그 이후 유저B가 조회한 결과가 1로 나오는 경우를 뜻한다.
격리 수준
* SERIALIZABLE
SERAILIZABLE은, 트랜잭션을 순차적으로 진행시키는 것을 뜻한다. 여러 트랜잭션이 동시에 같은 행에 접근할 수 없다. 매우 엄격한 수준으로 해당 행에 대해 격리시키고, 이후 트랜잭션이 이 행에 대해 일어난다면 기다려야 한다. 따라서 교착 상태가 일어날 확률이 많고 가장 성능이 떨어지는 격리 수준이다.
* REPEATABLE_READ
REPEATABLE_READ는, 하나의 트랜잭션이 수정한 행을 다른 트랜잭션이 수정할 수 없게 막아주지만, 새로운 행을 추가하는 것은 막지 않는다. 따라서 이후에 추가된 행이 발견될 수도 있다.
- READ_COMMITTED
READ_COMMITTED는, 가장 많이 사용되는 격리 수준이다. PostgreSQL, SQL Server, 오라클 등에서 기본값을 설정되어 있는 정도이다. READ_UNCOMMITTED와는 달리, 다른 트랜잭션이 커밋하지 않은 정보는 읽을 수 없다. 즉, 커밋 돤료된 데이터에 대해서만 조회 가능하다.
하지만, 어떤 트랜잭션이 접근한 행을 다른 트랜잭션이 수정 가능하다. 예를 들면, 트랜잭션A가 수정한 행을 트랜잭션B가 수정할 수 있다. 그리고 이 때문에 트랜잭션A가 같은 행을 다시 읽을 때, 다른 내용이 발견될 수 있다.
- READ_UNCOMMITTED
READ_UNCOMMITTED는 가장 낮은 격리 수준이다. 하나의 트랜잭션이 커밋되기 이전에 다른 트랜잭션에 노출되는 문제가 있긴 하지만, 가장 빠르다. 데이터 무결성을 위해 되도록 사용하지 않는 것이 좋지만, 몇몇 행이 제대로 조회되지 않더라도 괜찮은 거대한 양의 데이터를 '대충' 집계하는 데 사용하는 것은 좋다.
지속성
'지속성(durability)'은, 성공적으로 수행된 트랜잭션은 영원히 반영되어야 하는 것을 뜻한다. 이는 데이터베이스에 시스템 장애가 발생해도 원래 상태로 복구하는 회복 기능이 있어야 한다는 것을 말하고, 데이터베이스는 이를 위해 체크섬, 저널링, 롤백 등의 기능을 제공한다.
※ 체크섬
: 중복 검사의 한 형태, 오류 정정을 통해 송신된 자료의 무결성을 보호하는 단순한 방법
※ 저널링
: 파일 시스템 or 데이터베이스 시스템에 변경 사항을 반영(commit)하기 전에 로깅 하는 것을 말한다. 트랜잭션 등 변경 사항에 대한 로그를 남기는 것이다.
무결성
무결성
'무결성'은, 데이터의 정확성, 일관성, 유효성을 유지하는 것을 말한다. 무결성이 유지되어야 DB에 저장된 데이터 값과 그 값에 해당하는 실제 값이 일하는지에 대한 신뢰가 생긴다.
무결성의 종류는 아래와 같다.
* 개체 무결성
: 기본키로 선택된 필드는 빈 값을 허용하지 않는다.
* 참조 무결성
: 서로 참조 관계에 있는 두 테이블의 데이터는 항상 일관된 값을 유지해야 한다.
* 고유 무결성
: 특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우, 그 속성 값은 모두 고유한 값을 가진다.
* NULL 무결성
: 특정 속성 값에 NULL이 올 수 없다는 조건이 주어진 경우, 그 속성 값은 NULL이 될 수 없다는 제약 조건.
