1️⃣ 트랜잭션
DB의 상태를 변화시키기 위해 수행하는 작업의 논리적 단위
- 트랜잭션은 상황에 따라 Commit 되거나 Rollback 됨
- Commit : 모든 부분작업이 정상적으로 완료되면 이 변경사항을 한꺼번에 DB에 반영함
- Rollback : 부분 작업이 실패하면 트랜잭션 실행 전으로 되돌림
💡 트랙잭션을 사용하는 이유 이해하기
- 상황 : ATM 계좌이채
- A은행에서 출근하여 B은행으로 송금하려함
- 송금 중 알수없는 오류로 A은행 계좌에서 돈은 빠져나갔지만, B은행 계좌에 입금되지 않았음
- 이와 같은 상황을 막기위해 거래가 성공적으로 모두 끝나야 이를 완전한 거래로 승인하고, 도중에 오류가 발생하면 이 거래를 처음부터 없던 거래로 완전히 되돌림
-> 이렇게 거래 안정성을 확보하는 방법이 트랜잭션!
2️⃣ 트랜잭션 상태
-
활동(Active)
트랜잭션이 실행 중에 있는 상태, 연산들이 정상적으로 실행 중인 상태 -
장애(Failed)
트랜잭션이 실행에 오류가 발생하여 중단된 상태 -
철회(Aborted)
트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태 -
부분 완료(Partially Committed)
트랜잭션이 마지막 연산까지 실행했지만, Commit 연산이 실행되기 직전의 상태 -
완료 (Committed)
트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태
3️⃣ ACID
4가지 특성 Atomicity, Consitency, Isolation, Durability 를 ACID라고 부름
원자성(Atomicity)
- 트랜잭션이 DB에 모두 반영되거나 혹은 전혀 반영되지 않아야 함(All or Nothing)
- 트랜잭션의 작업이 부분적으로 실행되거나 중단되지 않는 것을 보장함
- 오류가 나면 Rollback을 하는데 트랜잭션의 길이가 길면, 오류가 발생하지 않은 부분도 처음부터 다시 작업해야함 -> save point로 해결할 수 있음
Commit
- 여러 쿼리가 성공적으로 처리되었다고 확정하는 명령어
- 트랜잭션 단위로 수행되어 변경된 내용이 모두 영구적으로 저장되는 것
- 커밋이 수행됨 = 트랜잭션이 성공적으로 수행됨
Rollback
- 트랜잭션으로 처리한 하나의 묶음 과정을 일어나기 전으로 돌리는 명령어
- Commit 되지 않은 변경된 모든 내용을 취소하고 DB를 이전상태로 되돌림
Savepoint
- 오류가 발생하지 않음이 확실한 부분이 Rollback 되지않도록 하는 중간 저장지점
- (트랜잭션의) 전체가 아닌 특정 부분에서 트랜잭션을 취소 시킬 수 있음
- 취소하려는 지점을 savepoint로 명시한 뒤,
rollback to savepointname;실행하면 해당 savepoint 지점까지 처리한 작업이 rollback됨
COMMIT
작업1
작업2
SAVEPOINT A;
작업3
작업4
SAVEPOINT B;
작업5
작업6
ROLLBACK TO SAVEPOINT B; /* 작업5,6 취소 */
ROLLBACK TO SAVEPOINT A; /* 작업 3,4 (,5,6) 취소 */
ROLLBACK /* 작업 1,2(,3,4,5,6) 취소 */
일관성(Constency)
- 트랜잭션의 실행은 항상 기대되는 값을 정확하게 보여줘야 함
- 트랜잭션 수행 전/후로 데이터 모델의 제약조건(기본키, 외래키, 도메인 제약조건 등)을 만족해야 함
ex) SQL연산을 col1+col2+col3-col4의 로직으로 실행하는데 실행 때마다 예측된 결과가 항상 같지않고 다른 결과가 나오면 일관성이 깨진 것
- 트랜잭션에서 일관성 보장은 어떤 이벤트와 조건이 발생했을 때, 트리거를 통해 보장함(= 허용한 방식으로만 데이터를 변경)
트리거(Trigger)
- 특정 테이블에 INSERT, DELETE, UPDATE같은 DML문이 수행됐을 때, DB에서 자동으로 동작하도록 설정된 프로그램
- 사용자가 직접 호출하는 형태가 이니라, DB에서 자동으로 호출하는 것이 특징
- 한쪽 테이블에 정보 수정이 일어났을 경우, 다른 쪽 테이블에도 함께 정보가 수정될 수 있도록 자동으로 업데이트를 하는 명령 등을 구성
격리성(=고립성, Isolation)
- 트랜잭션 수행 시 다른 트랜잭션이 작업에 끼어들지 못하도록 보장하는 것
- 둘 이상의 트랜잭션이 동시에 병행(parallelism)실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션에 끼어들 수 없음 (= 서로 격리되어 마치 순차적으로 실행되는 것처럼 작동함)
- 격리성을 보장하기 위해 Lock & Unlock 기법을 사용함
- 데이터를 읽거나 쓰기 작업 중일 때는 해당 영역에 Lock을 걸어 다른 트랜잭션이 접근하지 못하게 함
- 먼저 들어온 트랜잭션 요청이 끝나면 Unlock하여 다른 트랜잭션이 처리 될 수 있도록 허용함
- 만약 Lock & Unlock을 잘못사용하는 경우, 어떠한 트랜잭션도 수행될 수 없는 데드락(Deadlock)상태에 빠질 수 있음
- 격리 수준에 따라 나눠서 보장함
격리 수준에 따라 발생하는 현상
- 팬텀리드(phntom read)
트랜잭션이 동일한 조회를 두 번 실행했을 때, 첫 번째 조회에는 없었던 행(데이터)이 두 번째 조회 결과에 나타나는 현상- 트랜잭션 A가 특정 조건을 만족하는 데이터를 조회함
- 그 사이에 트랜잭션 B가 새로운 데이터를 삽입해서 그 조건을 만족시키고 커밋함
- 트랜잭션 A가 동일한 조건으로 다시 데이터를 조회할 때, 처음에 없었던 데이터(팬텀 데이터)가 결과에 나타남
- 반복 가능하지 않은 조회(non-repeatable read)
한 트랜잭션이 같은 데이터를 두 번 읽을 때, 두 번째 읽기에서 이전과 다른 값을 읽게 되는 경우를 의미
이 경우 다른 트랜잭션이 그 사이에 데이터를 수정했기 때문에 발생함- 문제) 트랜잭션 A가 데이터를 처음 읽었을 때와 두 번째 읽었을 때 값이 다르면, 일관성 문제가 생길 수 있음
- 예시)
트랜잭션 A가 테이블에서 데이터를 읽음
-> 트랜잭션 B가 해당 데이터를 업데이트하고 커밋함
-> 트랜잭션 A가 다시 데이터를 읽을 때 값이 변경됨
- 더티 리드(dirty read)
한 트랜잭션이 아직 커밋되지 않은 다른 트랜잭션의 데이터를 읽는 경우를 의미
즉, A 트랜잭션이 데이터베이스의 값을 변경했지만, 커밋하지 않은 상태에서 B 트랜잭션이 그 변경된 값을 읽을 수 있는 경우- 문제) A 트랜잭션이 나중에 롤백하면, B 트랜잭션은 존재하지 않는 잘못된 데이터를 읽은 것이 됨
- 더티 리드는 커밋되지 않은 변경을 읽는 것이고, 반복 가능하지 않은 조회는 커밋된 데이터를 읽는 과정에서 일관성 문제가 생기는 것
- 예시)
트랜잭션 A가 테이블에서 데이터를 업데이트하고 아직 커밋하지 않은 상태
-> 트랜잭션 B가 트랜잭션 A가 업데이트한 데이터를 읽음
-> 트랜잭션 A가 롤백하면, 트랜잭션 B는 잘못된 데이터를 참조하게 됨
격리수준
- SERIALIZATION
트랜잭션을 순차적으로 진행하며, 여러 트랜잭션이 동시에 같은 행 접근 불가
교착상태가 일어날 확률이 높고 성능이 가장 떨어짐
- REPEATABLE_READ
하나의 트랜잭션이 수정한 행을 다른 트랜잭션이 수정할 수 없도록 막아주지만, 새로운 행을 추가하는 것은 막지 않음
- READ_COMMITTED
가장 많이 사용되는 격리수준
다른 트랜잭션이 커밋하지 않은 정보는 읽을 수 없음(= 완료된 데이터에 대해서만 조회 허용)
하지만 어떤 트랜잭션이 접근한 행을 다른 트랜잭션이 수정할 수 있음
- READ_UNCOMMITTED
가장 낮은 격리수준으로, 하나의 트랜잭션이 커밋되기 이전에 다른 트랜잭션이 노출 될 수 있음 (= 가장 빠름)
지속성 (=영속성, Durability)
- 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함
- commit을 실행했다면 해당 데이터는 DB에 영원히 반영되어야 함
- DB에 시스템 장애가 발생해도 원래 상태로 복구하는 회복 기능(ex. 체크썸, 저널링, 롤백 등)이 있어야 함을 의미
- 저널링 : 파일 시스템 또는 DB시스템에서 변경사항을 반영(commit)하기 위해 로깅하는 것, 트랜잭션 등 변경 사항에 대한 로그를 남기는 것
- 체크썸 : 중복 검사의 한 형태로, 나열된 데이터를 더하여 체크섬 숫자를 얻고, 정해진 비트 수의 모듈라로 정해진 비트 수로 재구성하는 것 (https://hojak99.tistory.com/246)
4️⃣ 무결성
- 데이터의 정확성, 일관성, 유효성을 유지하는 것
- 관점에 따라 키 무결성을 개체(엔터티) 무결성 안에 포함 시키기도 하며, 종류가 다양함
개체 무결성 (Entity Integrity)
- 기본키로 선택된 필드는 빈 값을 허용하지 않음
- 모든 테이블은 기본키가 반드시 존재해야하며, 각 기본키는 반드시 유일 값을 가지되 Null이 아니어야 함
키 무결성 (Key Integrity)
- 하나의 릴레이션에는 적어도 하나의 키가 존재해야 함
- 테이블의 모든 레코드는 서로 식별 가능해야 함
참조 무결성 (Referential Integrity)
- 서로 참조 관계에 있는 두 테이블에 있는 데이터는 항상 일관된 값을 유지해야 함
- 외래키는 Null값을 가지거나, 외래키가 참조하는 테이블의 기본키에 존재하는 값이어야 하며, 기본키가 참조되는 외래키가 존재할 경우 데이터는 삭제/변경할 수 없음
도메인 무결성 (Domain Integrity)
- 특정 속성 값이 그 속성이 정의된 도메인에 속한 값이어야 함
- 테이블에 존재하는 필드의 무결성을 보장하기 위한 것으로, 데이터 타입, Null 허용 여부 등을 정의하여 사용함
- 속성값은 원자성을 가지며, 해당 도메인에 정의된 값이어야 함
Null 무결성
- 특정 속성 값이 null이 올 수 없다는 조건이 주어진 경우. 그 속성 값은 Null이 될 수 없음
고유 무결성 (Unique Intergrity)
- 특정 속성에 대해 고유한 값을 가지도록 조건을 주어진 경우, 그 속성 값은 모두 고유한 값을 가짐
관계 무결성 (Relation intergrity)
- 릴레이션에 어느 한 튜플의 삽입 가능 여부 또는 한 릴레이션과 다른 릴레이션의 튜플 사이의 관계에 대한 적절성 유무를 지정한 규정
사용자 정의 무결성 (User Defined Integrity)
- 다른 무결성 범주에 속하지 않는 사용자 정의 제약조건을 만족해야 함
참고자료
https://dkswnkk.tistory.com/555
TOPCIT ESSENCE ver3 기술영역-데이터 이해와 활용
https://computer-science-student.tistory.com/196
[책] 면접을 위한 CS 전공지식 노트
https://theheydaze.tistory.com/582
https://dev-coco.tistory.com/158
https://kadamon.tistory.com/21
https://steady-coding.tistory.com/562
🐥👩💻💰