Transaction

스터디 CS 주제로 Transaction에 대해 조사를 하였습니다.
우테코 테코톡을 참고하였으며, 더 알고 싶은 부분들은 블로그 글을 참고하였습니다.

특히 트랜잭션 격리 수준에 대해 공부할수록 많이 헷갈리는 것 같다.
다음에 기회가 있다면 실습을 통해 습득하도록 하자.

1. 트랜잭션이란?

• 여러 쿼리를 논리적으로 하나의 작업으로 묶어주는 것
• 업무 실행 단위 / 논리 명령 단위

예시) 거래가 일어날 때의 과정

• 구매자 계좌에서 10000원 출금
• 판매자 계좌에 10000원 입금

거래가 일어날 때 실행되는 쿼리

• UPDATE문 : 구매자 계좌에서 10000원 빼기
• UPDATE문 : 판매자 계좌에서 10000원 더하기

• 이떄! 출금 성공 후 서버다운 이라든지 다양한 이유로 오류가 발생 가능

• 구매자의 계좌에서는 돈이 빠져나갔는데, 판매자의 계좌에서는 돈이 들어오지 않는 이런 상황을 방지하기 위해서 나온것이 바로 트랜잭션 입니다.

• 즉 트랜잭션이라는 논리적인 하나의 작업 단위로 묶어서 쿼리들이 한꺼번에 모두 실행되거나 아예 아무 쿼리도 실행되지 않게 해주는 것입니다.

• 트랜잭션은 사용자 혹은 시스템상의 실수가 있더라도 데이터베이스가 데이터를 안정적으로 보장할 수 있도록 합니다.

하나의 트랜잭션은 커밋 혹은 롤백된다.

• 커밋이란 일종의 확인 도장으로 트랜잭션으로 묶인 모든 쿼리가 성공되어 트랜잭션 쿼리 결과를 실제 디비에 반영하는 것이고

• 롤백이란 쿼리 실행 결과를 취소하고 디비를 트랜잭션 이전 상태로 되돌리는 것입니다.

2. 트랜잭션의 성질

• 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질

ACID

Atomicity(원자성)

• 트랜잭션은 DB에 모두 반영되거나, 전혀 반영되지 않아야 한다.
  (완료되지 않은 트랜잭션의 중간 상태를 DB에 반영해서는 안된다.)
• 중간 단계까지 실행되고 실패하는 일이 없도록 보장
• 원자성이 보장되면 구매자의 계좌에서 돈이 빠져나갔는데 판매자의 계좌에 돈이 들어오지 않는 일은 없다.

Consistency(일관성)

• 트랜잭션 작업처리 결과는 항상 일관성 있어야 한다.
• 데이터베이스는 항상 일관된 상태로 유지되어야 한다.
• 마이너스 통장을 허락하지 않는다는 DB의 조건이 있다면 이 조건이 위배될 때 트랜잭션은 바로 종료된다.

Isolation(독립성)

• 둘 이상의 트랜잭션이 동시 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다.(각각의 트랜잭션은 서로 간섭 없이 독립적으로 이루어져야 한다.)
• 구매자의 계좌에서 돈이 빠져나가고 판매자의 계좌에 돈이 아직 들어가지 않은 DB상황을 다른 트랜잭션이 조회하면 안된다.

Durability(지속성)

• 트랜잭션이 성공적으로 완료되었으면 결과는 영구히 반영되어야 한다.
• 한번 송금이 성공하면 은행 시스템에 문제가 생기더라도 송금이 성공한 상태로 복구할 수 있어야 한다.

성능의 문제

• ACID 성질은 트랜잭션이 이론적으로 보장해야 하는 성질이고 실제로는 성능을 위해 손실보장이 완화 되기도 한다.

• 예를 들어 독립성을 완벽하게 보장하려고 하면 동일 데이터에 100개의 연결이 접근 했을 시, 이 100개 연결을 순차적으로 해결해야 합니다.
  동시성이 매우 떨어지는 문제가 발생하게 된다.

트랜잭션 격리 수준

• 동시성을 얻기 위한 한 가지 방법으로 트랜잭션의 격리레벨 설정이 있다.
• 트랜잭션 격리 레벨은 동시에 디비에 접근할 때 그 접근을 어떻게 제어할지에 대한 설정

• 밑으로 갈수록 격리 수준이 높아지지만 성능이 떨어짐, 데이터의 정합성과 성능이 반비례

READ UNCOMMITED (Level 0)

• 한 트랜잭션이 아직 커밋되지 않은 상태임에도 불구하고 변경된 값을 다른 트랜잭션에서 읽을 수 있다.

• 예를 들어 사용자 A가 트랜젝션 내에서 데이터를 수정하고 있는데 사용자 B가 그 데이터를 조회할 수 있다.

• 커밋되지 않은 데이터를 조회하는걸 Dirty Read라고 말한다. 사용자 B가 데이터를 사용하는 도중에 사용자A가 데이터를 롤백시켜 버리면 데이터 정합성이 깨질 수 있다.

READ COMMITED (Level 1)

• 커밋이 완료된 트랜잭션의 변경사항만 다른 트랜잭션에서 조회 가능

• 트랜잭션이 이루어지는 동안 다른 사용자는 해당 데이터에 접근이 불가능

• 상대방이 커밋한 데이터만 조회할 수 있다. 따라서 Dirty Read는 발생하지 않는다. 하지만 NON-REPEATABLE READ가 발생할 수 있다.

• 예를 들어 사용자A가 커밋한 데이터를 사용자B가 트랜젝션 내에서 조회하고 있는데 이후에 사용자 A가 데이터를 수정 후 다시 커밋한다면 사용자B는 같은 트랜젝션 내에서 다른 데이터를 조회하게 되는 것이다.

• NON-REPEATABLE READ : 같은 트랜잭션 내에서 select문을 두번 조회했는데, 두 값이 다른값이 나오는 데이터 불일치 문제

REPEATABLE READ (Level 2)

• 트랜잭션 범위 내에서 조회한 내용이 항상 동일함을 보장

• 한 트랜잭션이 조회한 데이터는 트랜잭션이 종료할 때까지 다른 트랜잭션이 변경하거나 삭제하는것을 막음으로 한번 조회한 데이터는 반복적으로 조회해도 같은 값을 반환한다.

• 한번 조회한 데이터는 트랜젝션 내에서 다시 조회해도 같은 데이터가 나오는게 보장된다. 하지만 PHANTOM READ가 발생할 수 있다.

• 예를 들어 사용자A가 트랜젝션 내에서 20살 이하의 회원 리스트를 조회했을때, 중간에 사용자B가 회원을 20살 이하 회원을 한명 추가한다면, 다시 리스트를 조회했을때 나오는 결과가 달라질 수 있다. 이처럼 결과 집합이 달라지는 것을 PHANTOM READ라고 한다.

PHANTOM READ

• PHANTOM READ와 NON-REPEATABLE READ의 차이점에 대해

• 차이점은 데이터가 변경되지는 않았지만 이전보다 쿼리에 만족하는 데이터 값이 늘어난다는 점이 차이가 있습니다. (행값의 변화가 있느냐,행의 총 수의 변화가 있느냐의 차이)

• 다른 인터넷 문서에서 소개하고 있는 유령 읽기 현상은 항상 다른 세션에서 insert 를 했다거나, delete 를 했다거나 해서
  자신의 세션에서 조회한 자료 세트 범위가 다른 세션에 의해서 변경 될 경우
  그것이 자신의 자료 세트가 자기가 조작하지 않았음에도 불구하고 유령처럼 바뀌는 것이다고 소개하고 있다.

• 가장 쉬운 표현으로 내가 딱히 새로 만들거나 지운 것도 아닌데, 없던 놈이 보이고, 있던 놈이 사라지는 것이다.

SERIALABLE (Level 3)

• 한 트랜잭션에서 사용하는 데이터를 다른 트랜잭션에서 접근 불가
• 트랜잭션의 ACID성질이 엄격하게 지켜지나 성능은 가장 떨어진다.
• 단순 SELECT만으로도 트랜잭션이 커밋될 때까지 모든 데이터에 잠금이 설정되어 다른 트랜잭션에서 해당 데이터를 변경할 수 없게 된다.

각 격리 레벨에서 발생할 수 있는 문제점

참고

• 모든 데이터베이스는 자체적으로 트랜잭션을 지원한다.
• 데이터베이스는 기본적으로 트랜잭션을 관리하기 위한 설정을 갖고 있다.

• 데이터베이스에서는 명령을 끝마칠 때까지 수행 내역을 로그에 저장한다.
• 데이터베이스에 반영된 내용을 재반영하기 위한 Redo Log와
• 수행을 실패해 이전의 상태로 되돌리는 Undo Log를 이용해 트랜잭션을 지원을 한다.

참고
https://www.youtube.com/watch?v=e9PC0sroCzc
https://www.youtube.com/watch?v=aX9c7z9l_u8
https://postgresql.kr/blog/pg_phantom_read.html
https://devjem.tistory.com/27#READ%--UNCOMMITED
http://wiki.gurubee.net/pages/viewpage.action?pageId=21200923
https://itpenote.tistory.com/616
https://bae9086.tistory.com/109
https://itpenote.tistory.com/616?category=898785
https://doooyeon.github.io/2018/09/29/transaction-isolation-level.html