트랜잭션
트랜잭션이란 데이터베이스의 상태를 변경시키기 위해 수행하는 작업 단위이다. 상태 변경이라고 함은 SELECT, UPDATE, INSERT, DELETE 와 같은 행동을 뜻한다. 이 트랜잭션은 모두 한꺼번에 수행되어야 할 일련의 연산들을 의미한다.
한꺼번에 수행되어야 하기 때문에 작업의 완전성을 보장해주고, 작업의 일부만 적용되는 현상이 발생하지 않도록 만들어준다.
모두 처리하거나, 처리하지 못한 경우에는 이전 상태로 복구한다.
하나의 트랜잭션은 Commit(작업 완료)되거나 Rollback(취소)된다.
트랜잭션의 특성(ACID)
트랜잭션은 원자성, 일관성, 독립성, 지속성의 4가지 특징이 존재한다.
-
원자성(Atomicity)
원자성은 트랜잭션이 DB에 모두 반영되거나 전혀 반영되지 않거나를 뜻한다. All or Nothing을 생각하면 된다. -
일관성(Consistency)
일관성은 트랜잭션 작업 처리의 결과가 항상 일관되어야 함을 뜻한다. 즉, 데이터 타입이 반환 후와 전이 항상 동일해야 한다. -
독립성(Isolation)
독립성은 하나의 트랜잭션은 다른 트랜잭션에 끼어들 수 없고 마찬가지로 독립적임을 의미한다. 즉, 각각의 트랜잭션은 독립적이라 서로 간섭이 불가능하다. -
지속성(Durability)
지속성은 트랜잭션이 성공적으로 완료되면 영구적으로 결과에 반영되어야 함을 뜻한다. 보통 commit이 된다면 지속성은 만족할 수 있다.
트랜잭션의 Commit, Rollback
Commit
하나의 트랜잭션이 성공적으로 끝나서 데이터베이스가 일관성있는 상태에 있음을 의미한다.
Rollback
트랜잭션의 원자성이 깨질 때, 즉 하나의 트랜잭션 처리가 비정상적으로 종료되었을 때의 상태를 뜻한다. Rollback이 이뤄진다면 트랜잭션을 다시 실행하거나 부분적으로 변경된 결과를 취소할 수 있다.
트랜잭션의 상태
1. 활동 (Active) : 트랜잭션이 실행중인 상태
2. 실패 (Failed) : 트랜잭션 실행에 오류가 발생하여 중단된 상태
3. 철회 (Aborted) : 트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태
4. 부분 완료 (Partially Committed) : 트랜잭션의 마지막 연산까지 실행하고 Commit 연산이 실행되기 직전의 상태
5. 완료 (Commited) : 트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태
트랜잭션 동작 단위
개발자가 DB 접근 툴 등의 클라이언트를 사용해서 DB 서버에 접근하는데 이때, 클라이언트는 데이터베이스 서버에 연결을 요청하고 커넥션을 맺는다.
데이터베이스 서버는 내부에 세션을 만들어 세션을 통해 커넥션을 통한 여러 요청을 실행하게 된다.
따라서 트랜잭션 기능 또한 새션 내에서 동작하게 되기에, 하나의 세션에서 트랜잭션 진행 중에 다른 커넥션 또는 세션을 통해 해당 데이터에 접근하면 세션 시작 이전의 데이터만 볼 수 있다.
트랜잭션 격리 수준
SERIALIZABLE
가장 엄격한 격리 수준으로, 이름 그대로 트랜잭션을 순차적으로 진행시킨다. 여러 트랜잭션이 동일한 레코드에 동시 접근할 수 없으므로 어떠한 데이터 부정합 문제도 발생하지 않는다. 하지만 트랜잭션이 순차적으로 처리되어야 하므로 동시 처리 성능이 매우 떨어진다는 단점이 있다. 가장 안전하지만 가장 성능이 떨어지므로, 극단적으로 안전한 작업이 필요한 경우가 아니라면 사용해서는 안된다.
REPEATABLE READ
MVCC를 이용하는데, 일반적으로 RDBMS는 변경 전의 레코드를 언두 공간에 백업해두는데 그런 경우에는 변경 전/후 데이터가 모두 존재하므로 동일한 레코드에 대해 여러 버전의 데이터가 존재고 이를 MVCC라고 부른다. 이를 통해 트랜잭션이 롤백된 경우에 데이터를 복원할 수 있을 뿐 아니라 서로 다른 트랜잭션 간에 접근할 수 있는 데이터를 세밀하게 제어할 수 있다.
- Phantom Read
한 트랜잭션 내에서 동일한 결과를 보장하지만, 새로운 레코드가 추가되는 경우에 부정합이 생길 수 있다. 새로운 레코드의 추가까지는 막지 않기 때문인데 따라서 SELECT로 조회시에 트랜잭션이 끝나기 전에 다른 트랜잭션에 의해 추가된 레코드가 발견될 수 있다. 이를 Phantom Read(유령 읽기)라고 한다.
READ COMMITED
커밋된 데이터만 조회할 수 있는데 이 수준은 위에서 발생하는 Phantom Read에 Non-Repeatable Read(반복 읽기 불가능) 문제까지 발생한다.
- Non-Repeatable Read
반복 읽기를 수행하면 다른 트랜잭션의 커밋 여부에 따라 조회 결과가 달라질 수 있음을 의미하며 이러한 데이터 부정합 분제를 Non-Repeatable Read라고 한다.
READ UNCOMMITED
커밋하지 않은 데이터조차도 접근할 수 있는 격리수준으로, 다른 트랜잭션의 작업이 커밋 또는 롤백되지 않아도 즉시 보이게 된다.
- Dirty Read
어떤 트랜잭션의 작업이 완료되지 않았는데도, 다른 트랜잭션에서 볼 수 있는 부정합 문제를 Dirty Read라고 하며 이는 데이터가 조회되었다가 사라지는 현상을 초래하기에 시스템에 상당한 혼란을 주게 된다.
참고로 오라클에서는 Read Commited를 기본으로 사용하며, MySQL에서는 Repeatable Read를 기본으로 사용한다.
데이터베이스 쓰기 처리 방식
1. 테이블을 개별 호출 후 쓰기 처리
쓰기 원하는 데이터 테이블을 개별적으로 호출하고, 호출한 만큼 쓰기가 진행된다. 비용은 호출 및 쓰기의 대상이 되는 테이블의 개수와 쓰는 데이터의 용량에 비례하여 부과된다. 예를 들어 위 그림처럼 세번의 쓰기 처리를 진행할 경우 3회의 테이블 호출 비용과 처리한 데이터 총 용량에 해당하는 쓰기 비용이 나올 수 있음
비용 : 3회 테이블 호출 비용 + 처리한 데이터 총 용량만큼의 쓰기 비용
2. 테이블을 일괄 호출 후 트랜잭션 처리
쓰기 원하는 데이터 테이블들을 한 번에 호출하고 이에 대한 트랜잭션 처리를 통해 쓰기가 진행된다. 한 번에 다수의 테이블을 호출하는 만큼, 기본 처리 비용이 상대적으로 비싸지만, 단 1회의 호출로 필요한 모든 테이블을 불러올 수 있기에 절약할 수 있는 방안이 될 수 있다.
비용 : 1회 테이블 호출 비용 + 처리한 데이터 총 용량만큼의 쓰기 비용
결론
첫 번째 방식은 테이블 개수가 적은 간단한 데이터나 용량이 큰 데이터 처리에 유리하나, 두 번째 방식은 테이블의 개수가 많은 데이터 처리에 유리함.
무결성
무결성(Integrity)은 정보에 결점이 없도록 유지하는 성질로, 데이터베이스 내에 저장되는 데이터 값들이 항상 일관성을 갖고 데이터의 유효성, 정확성, 안정성을 유지할 수 있도록 하는 제약조건을 두는 데이터베이스의 특성
무결성의 종류
-
개체 무결성
기본 키 제약이라고도 하며, 테이블은 기본키를 지정하고 그에 따른 무결성 원칙을 지켜야하는 조건- 기본키에는 null이 올 수 없음
- 키본키는 테이블 내에 오직 하나의 값만 존재해야 함
-
참조 무결성
외래 키 제약이라고도 하며, 테이블 간의 참조 관계를 선언하는 제약조건- 외래키 값은 null이거나 참조 릴레이션의 기본키 값과 동일해야 함
- 외래키 속성은 참조할 수 없는 값을 지닐 수 없음
-
도메인 무결성
테이블에 존재하는 필드의 무결성을 보장하기 위한 것으로 필드의 타입, null값 허용 등에 대한 사항을 정의하고 올바른 데이터가 입력되었는지 확인하는 조건 -
null 무결성
테이블의 특정 속성 값이 null이 될 수 없게 하는 조건 -
고유 무결성
테이블의 특정 속서에 대해 각 레코드들이 갖는 값들이 서로 달라야 하는 조건 -
키 무결성
하나의 테이블에는 적어도 하나의 키가 존재해야 하는 조건 -
관계 무결성
테이블의 어느 한 레코드의 삽입 가능 여부 또는 한 테이블과 다른 테이블의 레코드들 사이의 관계에 대한 적절성 여부를 지정한 조건
무결성 제약조건의 장단점
-
장점
스키마 정의시 일관성 조건을 한 번만 명시하면 데이터베이스가 갱시노딜 때 DBMS가 자동적으로 일관성 조건을 검사하므로 응용 프로그램들은 일관성 조건을 검사할 필요가 없음. -
단점
프로그래밍 작업이 훨씬 복잡해지고, 무결성 제약조건을 반복해서 구현해야 하며 무결성 제약조건들 간에 서로 충돌이 발생할 수 있음.
참고
https://innovation123.tistory.com/61
https://blog.thebackend.io/transaction-write/
https://jiwondev.tistory.com/163
https://velog.io/@zionedoha/%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%AC%B4%EA%B2%B0%EC%84%B1%EC%9D%B4%EB%9E%80
https://mangkyu.tistory.com/299
