*[데이터베이스] 트랜잭션

트랜잭션

트랜잭션이란? 

데이터베이스의 상태를 변화(SQL 질의어 사용)시키기 위해 수행하는 작업 단위 
작업 단위는 SQL 명령문들로 이루어져 있으며 개발자가 정하는 기준에 따라 다름

 

예시) 회원 정보 수정 

1. 저장 버튼 클릭 : UPDATE문을 이용하여 사용자 정보 수정
2. 회원 정보 구성 : SELECT문을 이용하여 사용자 정보 최신 유지
3. 작업 단위 : UPDATE + SELECT   

트랜잭션 특징

1. 원자성 : DB에 모두 반영되거나, 아예 반영되지 않거나 
2. 일관성 : 작업 처리 결과는 늘 같아야함 
3. 독립성 : 트랜잭션의 연산에 다른 트랜잭션이 끼어들 수 없음 
4. 지속성 : 트랜잭션이 성공적으로 완료되었다면, 그 결과는 영구적이여야함 

Commit과 Rollback 

1. Commit : 하나의 트랜잭션이 완료되었으며, DB가 일관성있는 상태일 때 알려주기 위해 사용하는 연산 
2. Rollback : 하나의 트랜잭션이 비정상적으로 종료되어 원자성이 침해된 경우, 트랜잭션 시작전 상태로 rollback 가능 

트랜잭션 관리 

DBMS의 구조 

1. Query Processor(질의 처리기), Storage System(저장 시스템), Page Buffer 
2. 입출력 단위 : 고정 길이의 page 단위로 disk에 읽거나 씀 
3. 저장 공간 : 비휘발성 저장 장치 disk에 저장하고, 일부를 Main Memory에 저장 

Page Buffer Manager

1. DBMS의 저장 시스템에 속하는 모듈 중 하나로, Main Memory에 유지하는 페이지를 관리 
2. Buffer의 관리 정책에 따라 UNDO 복구, REDO 복구의 필요성이 결정됨 

UNDO 

1. Buffer 교체 알고리즘에 따라 Buffer의 교체는 Buffer의 상태에 따라 결정되므로(트랜잭션의 상태X) 트랜잭션간 변경된 page들이 디스크에 출력될 수 있음
2. 만약 트랜잭션이 정상적으로 종료되지 않았다면 디스크에 입력된 page를 원상 복구 시켜야함 (UNDO)

UNDO가 영향을 받는 버퍼 관리 정책 

1. 첫번째 정책은 수정된 페이지를 언제든지 디스크에 작성할 수 있는 정책이다. 대부분의 DBMS가 채택하는 Buffer 관리 정책이며, UNDO logging과 복구가 필요하다.
2. 두번째 정책은 트랜잭션 종료 시점까지는 버퍼에 유지하는 정책이다. UNDO는 필요없지만, 매우 큰 메모리 버퍼가 필요하다.

REDO 

1. 이미 commit한 트랜잭션의 수정을 디스크에 반영하는 복구 작업

REDO가 영향을 받는 버퍼 관리 정책

1. 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책, 트랜잭션이 커밋되었을 때 수정된 페이지들이 disk에 반영되므로 redo가 필요 없다.
2. 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책, 트랜잭션이 디스크상의 db에 반영되지 않을 수 있기에 redo 필요하며 대부분의 DBMS 정책이다.

트랜잭션 격리 수준

트랜잭션 격리 수준이란? 

트랜잭션 격리수준이란 동시에 여러 트랜잭션이 수행될 때, 트랜잭션끼리 얼마나 고립되어 있는지를 나타내는 것을 말한다. 
실제로 ACID 원칙은 종종 지켜지지 않는다, DB엔진은 동시성을 위해서 ACID 원칙을 희생하여 동시성을 얻을 수 있는 isolation level(격리 수준)을 제공한다.

InnoDB의 격리 수준 종류 

1. READ UNCOMMITED : 어떤 트랜잭션이 특정 테이블을 잡고 있더라도 다른 트랜잭션에서 조회가 가능하다. 
2. READ COMMITED : 어떤 트랜잭션의 작업이 완료된 후 COMMIT이 되어야만 다른 트랜잭션에서 조회가 가능하다.
3. REPETABLE READ : 반복해서 읽기 작업을 수행하더라도 읽어 들이는 값이 변화하지 않는 정도의 격리 수준을 보장한다.
4. SERIALIZABLE : 쓰기 작업 뿐만 아니라 읽기 작업에도 LOCK을 설정하는 격리 수준이다. 

READ UNCOMMITED

아직 커밋되지 않은 데이터도 읽어올 수 있는 격리 수준이다. 대신 이 격리 수준을 사용한다면 DIRTY READ가 발생할 수 있다. 

참고) DIRTY READ
롤백이 이루어져 실제로 커밋이 이루어지지 않은 데이터를 읽어 들이는 현상을 말한다.

READ COMMITED

커밋된 데이터만 보이는 수준의 isolation을 보장하는 격리 수준이다.  REPEATBLE READ가 Transaction이 첫 읽기 작업을 기준으로  Consistent Read를 수행하는 반면, READ COMMITED는 읽기 작업마다 DB snapshot을 다시 구성한다. 그렇기 때문에 읽기 작업마다 커밋된 데이터를 읽어올 수 있는 것이다. 대신 하나의 트랜잭션에서 읽기 작업을 수행했을 때 늘 같은 결과를 가져와야 하는 정합성에 어긋난다. (UNREPETABLE READ) 

REPETABLE READ 

반복해서 읽기 작업을 수행하더라도 값이 변화하지 않는 isolation을 보장하는 격리 수준이다. REPETABLE READ는 트랜잭션 작업에서 처음 읽기 작업을 수행할 때의 시간을 기록한 후 그 이후 모든 읽기 작업에서 그 시간대의 Consistent Read를 수행한다. 따라서 트랜잭션 작업 중에 접근하는 테이블에 새로운 커밋이 이루어졌더라도 첫 읽기 작업 때 구성된 snapshot을 읽어오기 떄문에 값의 변화가 없다. 대신 이 격리 수준을 사용한다면 PHANTOM READ가 발생할 수 있다.

참고) PHANTOM READ
Consistent Read가 변경된 데이터에 한해서만 Snapshot을 구성하는데, 만약 데이터가 추가되는 경우 다음 읽기 작업시에 생성하지도 않았던 행이 추가되는 현상을 팬텀 읽기라고 한다.

SERIALIZBLE

읽기 작업을 수행할 때도 락을 건 후에 수행하는 격리 수준인데, 데드락이 발생할 확률이 굉장히 높다. 

참고) Consistent Read
읽기 작업을 수행할 때 현재 DB의 값이 아닌 특정 시점의 DB snapshot을 읽어오는 것을 의미한다. 물론 이 snapshot은 커밋된 변화만이 적용된 이미지이며 Inno DB 엔진은 log를 통해 이를 지원한다.

 

Reference

https://d2.naver.com/helloworld/407507

https://real-dongsoo7.tistory.com/57

데이터베이스 트랜잭션(Transaction)에 대하여 알아보자!

https://github.com/gyoogle/tech-interview-for-developer

gyoogle/tech-interview-for-developer