-
동시성 제어 (Concurrency Control)
❓동시성 제어
❗DBMS가 다수의 사용자 사이에서 동시에 작용하는 다중 트랜잭션의 상호간섭 작용에서 DB를 보호하는 것.
- 동시성을 허용하면 일관성이 낮아진다.
비관적 동시성 제어
사용자들이 같은 데이터를 동시에 수정할 것이라고 가정
SELECT 시점에 Lock을 걸어 트랜잭션이 완료될 때 까지 유지한다.
⇒ 시스템 동시성을 심각하게 떨어뜨린다
→ wait 또는 no wait 옵션 사용
낙관적 동시성 제어
사용자들이 같은 데이터를 동시에 수정하지 않을 것이라고 가정
데이터 조회(SELECT)시 Lock을 걸지 않는다.
⇒ 수정 시점에 다른 사용자에 의해 값이 변경됐는지 검사가 필요하다.
목표
동시에 실행되는 트랜잭션 수를 최대화하면서
- 입력, 수정, 삭제, 검색 시 데이터의 무결성을 유지
일반적인 Locking 메커니즘은 읽기 작업에 공유 Lock을 사용한다.
⇒ 구현이 간단하지만, 문제점이 있다.
Lock
Lock이란 데이터베이스의 일관성과 무결성을 유지하기 위해 트랜잭션의 순차적 진행을 보장할 수 있는 직렬화 장치 개념
Shared Lock (공유 lock)
- 데이터를 읽을 때 사용
- 공유 lock은 트랜잭션이나 쿼리 수행이 완료될 때까지 유지되는 것이 아닌 다음 레코드가 읽히면 해제된다.
- (격리 수준이 Read Committed 일 경우)
- 다른 공유 Lock 과는 호환 👌, 하지만 배타적 lock 과는 호환되지 않는다 ❌
- 호환 ❓ ⇒ 한 리소스에 두 개이상의 lock을 동시에 설정할 수 있다.
- 즉, 여러 트랜잭션에서 동시에 하나의 데이터를 읽을 수 있다.
- 하지만, 변경중인 리소스를 동시에 읽을 순 없다.
- 격리 수준을 변경하지 않고 트랜잭션 내에서 공유 lock이 유지되도록 하려면 테이블 힘트로 holdlock을 지정하면 된다.
Exclusive Lock (배타 lock)
- 데이터를 업데이트 할 때 사용
- 트랜잭션이 완료될 때 까지 사용
- 다른 lock들과 호환되지 않는다.
- 즉, 한 리소스에 하나의 배타적 lock만 설정 가능하다.
- 배타적 lock은 여러 트랜잭션이 한 리소스에 엑세스할 수 없게 된다. (읽기도 ❌)
- 오직 하나의 트랜잭션만 해당 리소스를 점유
- 배타적 lock이 증가할 수록, 해당 리소스에 엑세스하기 위한 트랜잭션들이 증가
- ⇒ 성능 저하
일반적인 Locking 메커니즘의 문제점
읽기 작업과 쓰기 작업이 서로 방해를 일으켜 동시성 문제가 발생한다.
데이터 일관성에 문제가 생기는 경우가 있어서 Lock을 더 오래 유지하거나 테이블 레벨의 Lock을 사용해야 하고, 동시성 저하가 발생한다.
트랜잭션 격리성 수준을 상향 조정하면 일관성이 높아지지만, Lock이 더 오래 유지되어 동시성 저하 및 교착상태가 발생할 가능성이 증가한다.
⇒ MVCC 탄생
MVCC
MVCC (Multi-Version Concurrency Control)
- 다중 버전 동시성 제어
MVCC는 동시 접근을 허용하는 데이터베이스에서 동시성을 제어하기 위해 사용하는 방법 중 하나
MVCC 모델에서 데이터에 접근하는 사용자는 접근하는 시점의 데이터베이스의 스냅샷(snapshot)을 읽는다.
- 이 snapshot 데이터에 대한 변경이 완료될 때까지 만들어진 변경사항은 다른 데이터베이스 사용자가 볼 수없다.
- 변경이 완료 - 트랜잭션이 commit
- 사용자가 데이터를 업데이트하면 이전의 데이터를 덮어 씌우는 것이 아니라 새로운 버전의 데이터를 UNDO 영역에 생성한다.
- 대신 이전 버전의 데이터와 비교해서 변경된 내용을 기록
⇒ 하나의 데이터에 대해 여러 버전의 데이터가 존재하게 된다.
- 사용자는 마지막 버전의 데이터를 읽게 된다.
목적
- Lock을 사용하지 않는 일관된 읽기를 제공
- Lock을 사용하지 않음으로써 성능을 향상 시키기 위함.
Lock을 사용하지 않는 이유
- 베타적 락으로 인해 다른 트랜잭션이 해당 데이터를 read 하기 위해 기다리는 상황이 발생하고, 이런 트랜잭션들이 증가하면 성능저하로 이어진다.
특징
- 일반적인 RDBMS보다 매우 빠르게 작동
- 사용하지 않는 데이터가 계속 쌓여가게 되므로 데이터를 정리하는 시스템이 필요
- 데이터 버전이 충돌하면 애플리케이션 영역에서 이러한 문제를 해결해야 한다.
❓왜 빠르게 작동
❗Lock을 필요로 하지 않기 때문에
데이터를 읽기 시작할 때, 다른 사람이 그 데이터를 삭제하거나 수정하더라도 영향받지 않고 사용 가능
- 사용하지 않는 데이터가 계속 쌓임 → 데이터 정리하는 시스템 필요
MVCC 모델은 하나의 데이터에 여러 버전의 데이터를 허용하기 때문에 데이터 버전이 충돌할 수 있다
⇒ 애플리케이션 영역에서 문제 해야 한다.
참고 자료
https://javannspring.tistory.com/218
'🌱 spring' 카테고리의 다른 글
JPA - N + 1 문제 (0) 2022.10.11 영속성 컨텍스트 (0) 2022.10.11 JPA와 Hibernate, Spring data JPA (0) 2022.10.10 Spock 로 테스트 해보기 (0) 2022.10.06 QueryDSL (1) 2022.10.05