ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • MVCC
    🌱 spring 2022. 10. 5. 18:58

    동시성 제어 (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 하기 위해 기다리는 상황이 발생하고, 이런 트랜잭션들이 증가하면 성능저하로 이어진다.

    특징

    1. 일반적인 RDBMS보다 매우 빠르게 작동
    2. 사용하지 않는 데이터가 계속 쌓여가게 되므로 데이터를 정리하는 시스템이 필요
    3. 데이터 버전이 충돌하면 애플리케이션 영역에서 이러한 문제를 해결해야 한다.

    ❓왜 빠르게 작동

    ❗Lock을 필요로 하지 않기 때문에

    데이터를 읽기 시작할 때, 다른 사람이 그 데이터를 삭제하거나 수정하더라도 영향받지 않고 사용 가능

    • 사용하지 않는 데이터가 계속 쌓임 → 데이터 정리하는 시스템 필요

    MVCC 모델은 하나의 데이터에 여러 버전의 데이터를 허용하기 때문에 데이터 버전이 충돌할 수 있다

    ⇒ 애플리케이션 영역에서 문제 해야 한다.

    참고 자료

    https://javannspring.tistory.com/218

    https://mangkyu.tistory.com/53?category=761304

    https://velog.io/@znftm97/MySQL-MVCC란

    '🌱 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

    댓글

Designed by Tistory.