[기술면접 대비] Database 2 - Transaction, 격리레벨, 동시성

Transaction 개념과 ACID 원칙

👉 Transaction 이란?

DB에서 Query문에 의해 발생하는 일정 작업의 최소 단위

 

👉 Transaction 4원칙

트랜잭션의 4원칙으로 원자성, 일관성, 독립성, 영구성을 의미

• 원자성 : 트랜잭션 연산의 단위는 다 반영되거나, 다 안되거나
• 일관성 : 트랜잭션을 반복적으로 실행하더라도 그 결과 일정한 것
• 독립성(isolation) : 여러개의 트랜잭션간 분리되어서 실행 되는 것
• 영구성 : 한번 트랜잭션이 완료되면, 그 결과가 유지되는 것

 

👉 Transaction의 ACID 원칙 깨진 사례

ACID 깨진 경험이 있었냐, 1개의 함수에서 2개의 Table을 각각 수정하는 경우, 1번째 경우만 성공하고 2번째에서 오류 나는 경우에서 Transaction 

 

Transaction 연산

👉 Transaction의 Commit, Rollback 연산 이란?

• Commit 연산 : 입력한 자료나 수정한 자료에 대해, 전혀 문제가 없다고 판단되고, 하나의 트랜잭션이 성공적으로 종료 및 최종적으로 데이터베이스에 반영하는 연산
• Rollback 연산 : 하나의 트랜잭션이 비정상적으로 종료되어 일관성을 잃었을 때 실행한 연산들의 결과가 취소되고, 해당 트랜잭션 수행 이전의 상태로 돌아가는 연산, Rollback을 하는 경우엔 해당 트랜잭션을 재시작하거나 폐기함

 

👉 Transaction의 Commit 연산 전 후 비교

COMMIT 이전

• 다른 사용자가 SELECT 조회 가능
• 변경중인 행은 LOCK 설정이 되어, 다른 사용자가 변경 불가
• 메모리 버퍼에만 올라와 있기 때문에 데이터의 변경 이전 상태로 복구 가능

 

COMMIT 이후

• 다른 사용자가 해당 행을 맘대로 조작,조회 가능
• 데이터에 대한 변경 사항이 영구 반영

 

👉 Transaction의 REDO, UNDO 연산 이란?

장비에 장애나 비정상 종료가 발생시 REDO / UNDO를 사용해 데이터를 복구하고, 커밋하지 않은 데이터 롤백 수행

 

REDO

• 복구 역할, DB에서 수행한 모든 기록은 REDO에 저장
• 사용자가 했던 작업을 그대로 함 (실패한걸 다시 시도)
  ex) 시스템 장애 발생 (UNDO + TRANSACTION 날라감) => REDO 데이터를 이용해 마지막 Check Point 부터 장애까지의 DB BUFFER CACHE 복구 => REDO에 의해서 UNDO가 복구 => UNDO로 차례대로 Rollback 실행하며 커밋하지 않은 데이터 되돌림

 

UNDO 역할

• 작업 롤백(복구), 읽기 일관성을 수행
• 복구, 롤백 : 사용자가 했던 작업을 반대로 진행하며 복구 (원상태로 돌림)
  
• 복구, 롤백 : INSERT, UPDATE, DELETE의 변경되기 전 데이터를 보관하는 곳
  ex) 데이터 저장 중 세션이 COMMIT 없이 비정상 종료됨 => UNDO를 통한 복구 실행 (ROLLBACK) (set no = no + 1 => set no = no - 1)
  
  
• 일관성 : 트랜잭션의 격리 수준 유지을 위한 동시성 제공

 

UNDO의 데이터 기억 방법

• INSERT : insert 행의 Id 기록, UPDATE : 바뀌기 이전 값 기록, DELETE : 삭제한 모든 데이터 기록
  
• ex) UPDATE user SET name='선민' WHERE user_id = 1 
  트랜잭션을 커밋전 실제 데이터 파일 내용을 선민으로 변경 / 언두 영역에 이전 값 abc 백업
  Commit시 현재 상태 그대로 적용 / 롤백시 백업된 데이터를 다시 데이터 파일로 복구

 

참고 링크

[MySQL] InnoDB 언두(Undo) 로그와 MVCC란 무엇일까?

 

Transaction 격리레벨

👉 Transaction의 Isolation Level 이란?

Isolation Level : 여러 트랜잭션이 동시에 DB에 접근할 때 접근을 어떻게 제어할지에 대한 설정으로 일관성이 없는 데이터를 어느 정도 허용 하는지에 대한 level

 

👉 Transaction의 Isolation Level 이 필요한 이유

트랜잭션간 ACID 원칙을 지키면서 효율적인 Lock을 걸기 위해 (만약 Lock을 너무 과도하게 걸면 성능 저하가 있을 수 있으므로, 최대한 효율적으로 하기 위함)

 

👉 Transaction Isolation Level 4가지

출처:https://github.com/WeareSoft/tech-interview/raw/master/contents/images/isolation-level.png

 

1. Read Uncommitted (가장 낮음, 변경 언제든지 노출)

• 트랜잭션에 처리(변경)중인(아직 커밋되지 않은) 데이터도 다른 트랜잭션이 읽기 허용
• 거대한 양의 데이터를 어림잡아 집계할 때 사용 적합

 

1.1 Read Uncommitted 예시

• 어떤 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안에도, 다른 사용자가 아직 완료되지 않은(Uncommitted 혹은 Dirty) 트랜잭션이지만 변경된 데이터(B) 읽기 가능.

 

2. Read Committed (Transaction 진행 중 UNDO 영역에 조회 접근 가능)

• 트랜잭션에 커밋 된 데이터 변경 내용을 다른 트랜잭션이 읽고 변경하는 것 허용
• 트랜잭션에서 변경 내용 커밋전에는 다른 트랜잭션에서 변경은 불가능.
• UNDO 영역의 백업된 레코드 데이터에 접근하고, 조회 할 수 있으나 변경 할 수 없음, 생성은 가능
• 조회를 허락하다 보니, 다시 조회하여 읽을 때 다른 내용이 발견될 수 있음 (Non-Repeatable Read)
• 생성을 허락하다 보니, 다시 접근하여 읽을 때 내용이 달라질 수 있음

 

2.1 Read Committed 예시

• ex) 사용자가 A 데이터 값을 B로 변경 중 다른 사용자 접근 불가 (읽기는 가능)
• ex) 사용자1이 Transaction 진행 중 데이터 A 조회 (값 : 1) , Commit 후 사용자2가 데이터 A 값 2로 변경 성공, 사용자1이 다시 접근하면 (값 2가 되어 있어) Non-Repeatable Read 발생 함

 

3. Repeatable Read (Transaction 진행 중 UNDO 영역에 조회 접근 가능 + 좀 더 따라감, Insert는 따라가지 못함)

• 트랜잭션에 커밋 된 데이터 변경 내용을 다른 트랜잭션이 읽고 변경하는 것 허용
• 트랜잭션에서 변경 내용 커밋전에는 다른 트랜잭션에서 변경은 불가능.
• UNDO 영역의 백업된 레코드 데이터에 접근하고, 조회 할 수 있으나 변경 할 수 없음, 생성은 가능
• 조회를 허락하지만, 더 세부적으로 접근하기 때문에, 재조회하여 읽을 때도 내용 동일 (Non-Repeatable Read X)
• 생성을 허락하다 보니, 다시 접근하여 읽을 때 내용이 달라질 수 있음

 

3.1 Repeatable Read 예시

• ex) 사용자가 A 데이터 값을 B로 변경 중 다른 사용자 접근 불가 (읽기는 가능)
• ex) 사용자1이 Transaction 진행 중 데이터 A 조회 (값 : 1) , Commit 후 사용자2가 데이터 A 값 2로 변경 실패, 사용자1이 다시 접근하면 (값 1 그대로 되어 있어) Non-Repeatable Read 발생 안함
• ex) 사용자1이 Transaction 진행 중 데이터 A조회, 사용자2가 A에 Insert를 진행. 다시 사용자1이 A 조회시 데이터가 새로 생김 => Phantom Read 현상 발생

 

4. Serializable

• 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 Shared Lock이 걸리는 Level
• 완벽한 읽기 일관성 모드(사고 안남)를 제공한다.
• 따라서, 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정, 입력, 생성이 불가능
• 무결성은 보장되지만 성능이 낮아짐

 

https://yubi5050.tistory.com/135

[DB] Transaction 격리 수준 종류 (Isolation Level)

 

👉 Dirty Read , Non-Repeatable Read, Phantom Read 설명 해보시오

Dirty Read

• 커밋되지 않은 수정 중인 데이터를 다른 트랜잭션에서 읽을 수 있도록 허용할 때 발생하는 현상
• ex) 데이터 조회중인데 데이터가 다른 트랜잭션에 의해 생기거나, 없어지거나 함

 

Non-Repeatable Read

• 한 트랜잭션에서 같은 쿼리를 두 번 수행시 그 사이에 다른 트랜잭션이 값을 수정하여, 두 쿼리의 결과가 다르게 나타나는 현상 (비 일관성)

 

Phantom Read

• 한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽을 때, 첫 번째 쿼리에서 없던 레코드가 두 번째 쿼리에서 나타나는 현상
• 이는 트랜잭션 도중 새로운 레코드가 삽입되는 것을 허용하기 때문

 

동시성, Lock, MVCC

👉 동시성 제어 (Concurrency Control) 이란?

다중 트랜잭션의 상호간섭 작용에서 Database를 보호하는 것 (Lock이나 Transaction 격리 수준 조절을 통해 해결)

동시에 실행되는 트랜잭션 수를 최대화하면서도 입력, 수정, 삭제, 검색 시 데이터 무결성이 유지되도록 하는 데

 

참고 문헌 : https://dataonair.or.kr/db-tech-reference/d-guide/sql/?mod=document&uid=363 

동시성 제어

 

👉 MVCC (Multi Version Concurrency Control) 란?

MVCC는 RDBMS에서 동시성을 높이기 위해 등장한 기술로 서로 다른 Session이 동일한 데이터에 접근시, 각 세션마다 스냅샵 이미지를 보장해주는 메커니즘.

하나의 레코드에 대해 2개의 버전이 유지되고, 필요와 특정 상황에 따라 데이터가 보여지는 구조
ex) RDBMS에서 쓰기(Write) 세션이 읽기(Read) 세션을 blocking하지 않고, 읽기 세션이 쓰기 세션을 blocking 하지 않음

 

👉 Lock 메커니즘의 문제점은?

동시성 제어 성능 저하 발생 (동시에 수행 될 수 있는 트랜잭션 제한적)

읽기 작업과 쓰기 작업이 동시에 실행 되다보니, 서로 방해를 일으켜서, 데이터 일관성에 문제가 생길 수 있음

위 문제를 해결 하기 위해선 Lock을 더 오래 유지하거나 기준을 높여야 되고 => 동시성 저하로 이어짐

 

👉 Lock 의 종류 (공유락 vs 베타락)

공유락 (Shared Lock, Read Lock)

• 트랜잭션이 조회를 할 때 사용되는 락
• 데이터 조회만 수행하기에 공유락에서는 동시 접근 가능

 

베타락 (Exclusive Lock, Write Lock)

• 트랜잭션이 데이터 변경시 사용되는 락
• 트랜잭션이 완료될 때까지 유지되며, 베타락 내에선 어떠한 접근도 허용 X