기존 Lcok-based
read | write | |
read | O | X |
write | X | X |
기존 컨커런시 컨트롤러는 위와 같이 리드만 동작하기 때문에 read And write 일경우 대기하고 기다리게 된다. 때문에 동시에 처리 하게 될때 퍼포먼스 적으로 떨어지게 된다. 이를 해결하기 위해 MVCC 가 등장하게 된다.
MVCC
같은 데이터에 대해서
read | write | |
read | O | O |
write | O | X |
양쪽 트랜잭션에서 write 되는 경우에는 block 이 되지만 이외의 트랜잭션에서는 동작한다. 이를 토대로 동시에 처리하게 되는 퍼포먼스가 올라가게 되는 것이다.
1.
트랜잭션 1은 유저의 권한을 읽는다.
2.
트랜잭션 2는 유저의 권한을 최고권한으로 변경한다.
a.
트랜잭션이 동작될 때 해당하는 값으로 변경되기 전에 write lock의 권한을 부여받는다.
b.
권한을 부여 받으면 변경하려는 커밋직전의 값(최고권한)을 따로 저장해둔다.
3.
트랜잭션 2가 write를 했지만 아직 커밋을 하지는 않는 상태에서 트랜잭션 1번이 해당하는 유저의 데이터를 읽게되면 어떤 값을 읽을까?
a.
최종커밋된 데이터를 읽게된다—> 일반권한으로 읽게 되는 것이다.
즉 MVCC 는 커밋된 데이터만 읽는다는 것이다.
4.
이제 트랜잭션 2번이 커밋을 하게되었다.
a.
자체적으로 저장해두 었던 값 최고권한 값을 데이터베이스에 반영이 된다.
b.
2-a 에서 부여받은 wirt lock의 값을 unlock으로 회수가 된다.
i.
여기서 왜 unlock으로 DB가 자체적으로 권한을 회수하는지 의문을 품을 수 있다. 이것은 트랜잭션이 작동될때 문제가 발생하면 롤백을 시켜주기 위해 해당하는 기능이 동작하는 것. 때문에 recoverability를 위해 commit 할때 wirt lock을 unlock을 해준다.
5.
여기서 트랜잭션 1번이 해당하는 유저의 값을 읽는다면?
a.
여기서는 트랜잭션의 isolation level의 값에 따라 다르게 읽게된다.
i.
isolation level이 read committed 라면 read하는 시간을 기준으로 그전에 commit된 데이터를 읽는다. ⇒ 즉) 최고권한 데이터를 읽게 된다는 것이다.
ii.
isolation level이 repeatable read 라면 트랜잭션 시작 시간 기준으로 그전에 commit된 데이터를 읽는다. ⇒ 즉) 기본권한 데이터를 읽게 된다.
iii.
isolation level이 read uncomitted 라면 mvcc는 committed된 데이터를 읽기 때문에 이 level에서는 보통 MVCC가 적용되지 않는다.
MVCC
•
데이터를 읽을 때 특정 시점 기준으로 가장 최근에 commit된 데이터를 읽는다. ⇒ Consistent read
•
데이터 변화(write) 이력을 관리한다. ⇒ 추가적인 저장 공간을 더 사용하는게 단점, 하지만 동시성 사용적인 즉면에서 장점이 있다. 때문에 오늘날의 데이터베이스는 MVCC를 사용해서 만든다.
•
read와 write는 서로를 block하지 않는다.