transaction에 대한 격리 수준이 필요한 이유
사용자 1, 2가 동일한 계좌에 100원씩 동시에 송금하는 상황에서 트랜잭션 격리 수준이 존재하지 않는 경우
두명이 100원씩 총 200원을 입금했더라도 실제로 100원만 입금된 것으로 반영됨
여러 트랜잭션이 같은 데이터를 동시에 읽고 쓸 때 많은 동시성 문제 발생 가능한 것
트랜잭션의 격리 수준
트랜잭션을 여러 개 동시에 실행하더라도 트랜잭션을 순차적으로 실행했을 때와 동일한 결과를 내도록 보장함
이를 통해 데이터의 일관성을 유지함
transaction 격리 수준 - commit 후 읽기 (read committed)
*이 수준에서도 많은 동시성 문제를 db에서 막아줌
commit 후 read, write
- dirty read 가 없음 : db에서 읽을 때 커밋된 데이터만 읽음
- dirty write 가 없음 : db에 쓸 때 커밋된 데이터만 덮어씀
dirty read를 막아야하는 이유
dirty read를 방지한다는 것은 커밋되지 않은 데이터를 읽는 것을 방지하는 것을 의미한다
dirty read를 막지 않게 되면 두 트랜잭션이 함께 이루어질 경우
- 하나의 트랜잭션으로 반영될 값 A
- 다른 트랜잭션이 커밋되지 않은 이전 값 0을 읽음
- 실제로는 A라는 메시지가 안읽어진 상태고 안읽은 수는 1이 됨
dirty write을 막아야하는 이유
dirty write이란 commit 되지 않은 상태의 데이터를 덮어 쓸 수 있다는 것을 의미한다
dirty write을 허용할 시
- 트랜잭션 1이 구매자를 A로 설정
- 트랜잭션 2은 수신자를 B로 설정
- 트랜잭션 1이 수신자 A로 설정
- 트랜잭션 2가 구매자 B로 설정
- 구매자 B, 수신자 A
커밋되지 않은 값을 다른 트랜잭션이 덮어썼기 때문에 데이터에 대한 불일치 문제 발생
dirty write을 막아주면
- 트랜잭션 1의 구매자, 수신자 작성을 기다림
- 커밋 이후 트랜잭션 2의 구매자, 수신자 작성
commit 후 읽기로 해결되지 않는 동시성 문제
비반복 읽기로 인한 불일치 발생
커밋된 값들만 읽었으나 다시 읽으면 그 값들이 달라지는 경우 발생하는 문제
- 계좌 1 : 1000원
- 이후 계좌 2 : 1500원 → 계좌 1이 바뀐 것을 고려 x
- 구한 합계는 실제 2000원이 아닌 2500이 됨
이와 같은 예시는 몇 초 후 사용자 2가 새로고침을 통해 정상적인 결과를 반환받을 가능성이 높음
→ 지속적인 문제는 아니며 서비스에 따라 잠깐의 비정상 응답을 허용할 수 있음
→ 그러나 특정 상황에서는 이러한 일시적 비정상 응답을 허용할 수 없는 환경 또한 있음
- 데이터베이스 백업
-
데이터베이스 백업을 위해서는 전체 복사본을 만들어야하고 시간이 오래 걸릴 수 있음
-
백업 도중에도 데이터베이스에 write가 실행될 수 있음
이때 커밋 후 읽기(read committed)처럼 일부는 이전 버전의 데이터, 일부는 새로운 버전의 데이터를 백업 프로세스에게 반환 시
일관성이 깨진 데이터들이 저장되는 문제 발생 가능
-
- 시간이 오래 걸리는 쿼리
- 데이터베이스의 전체 데이터를 기반으로 통계 분석을 하거나 데이터가 로직상 올바른지 확인하는 무결성 검사 쿼리를 실행 시 시간이 오래 걸릴 수 있음
- 커밋 후 읽기 격리 수준(read committed)을 사용 시 일부는 이전 버전의 데이터를 보게 되며 비정상 적인 결과 반환 가능
⇒ 이와 같이 커밋 이후 값을 읽더라도 그 값들이 변경되어 데이터에 대한 불일치 문제가 발생하는 경우인
비반복 읽기 문제들은 반복 읽기 격리 수준을 사용하면 됨
