Transaction 특징
ACID
-
Atomic
예를들어, 은행에서 계좌 송금을 하는데 내 계좌에서 10000원이 빠져 나가고 상대방이 내 돈을 받지 못한다면 안되기 때문에 계좌 송금부터 입금까지 하나의 transaction으로 본다. 만약, 내 계좌에서 출금은 성공하고 상대계좌에 입금이 실패한다면 rollback을 통해서 내 계좌에서 출금했던 것을 다시 원 상태로 돌려 놓는다. -
consistency
모든 DB테이블의 자료들은 정해진 규칙에 의해 관리가 되어야 하고, commit이 일어나는 시점에서는 모든 자료들이 일관성이 있어야 한다.
예를들어, 계좌는 무조건 0원 이상이어야하고,계좌에 10000원이 있다면 10000원 이하만 보낼 수있다. 10000원이 있는 계좌에서 송금했을때 내 계좌에 잔고가 마이너스가 될수 없다. 상대 계좌도 마찬가지로 정해진 규칙에 따라 일관성이 있어야 한다. -
Isolation
성능과 trade off의 관계라고 볼 수 있다.
DB의 고립이 가장 잘 된 상태라면 서버에서 많은 요청을 받을 수 없고
DB의 고립성이 떨어진다면 아무나 들어와서 쓸 수 있기 때문에 성능은 좋아지지만 데이터의 정확성이 떨어질 수 있다.
Isolation level 종류
- READ UNCOMMITED
- READ COMMITED
- REPEATABLE READ
- SERIALIZABLE
READ UNCOMMITED
각 트랜잭션에서의 변경내용이 commit이나 rollback이 되지 않았음에도 불구, 다른 트랜잭션에서 값을 읽을 수 있다.
문제가 생길 수 있기 때문에 대체로 사용하지 않는다.
문제 : DIRTY READ -> 트랜잭션이 완료되지 않았음에도 다른 트랙잭션에서 볼 수 있게 되는 현상
READ COMMITED
대부분 RDB에서 많이 사용하고 있는 격리 수준이다.
DIRTY READ같은 현상 발생하지 않는다.
실제 테이블 값을 가져오지 않고 백업되어 있는 Undo 영역의 값을 가져온다. (전에 commit 되어 있는 값)
REPEATABLE READ
MYSQL에서는 트랜잭션 마다 트랜잭션 ID를 부여하여 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경한 것만 읽게 된다.
undo 공간에 백업해두고 실제 레코드 값만 변경한다.
undo에 백업된 레코드가 많아지면 MySQL 서버의 처리 성능이 떨어질 수 있다.
이러한 변경방식은 mvcc(Multi Version Concurrency Control)라고 부른다.
REPEATABLE READ의 문제점
PANTHOM READ
다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다 안보였다가 하는 현상
이를 방지하기 위해서는 쓰기 잠금 걸어야함.
SERIALIZABLE
가장 단순한 격리 수준이지만 가장 엄격한 격리수준
성능 측면에서는 동시 처리가능성이 가장 낮다
PHANTOM READ가 발생하지 않지만 DB에서 거의 사용되지 않는다.
- Durability
모든 commit된 이력은 남겨진다.
DB에서 오류가 발생할 수 있기 때문에, 바로 disk에 반영하는게 아니라, 로그에 남겼다가 disk에 저장한다. 때문에 오류가 발생되어 계속 로그에 들어와도 disk에 반영되지 않아서 피해가 생기지 않는다.
