DBMS 동시성 제어: 잠금 및 타임스탬프 기반 프로토콜
피오나 브라운
⚡ 스마트 요약
DBMS의 동시성 제어는 데이터 무결성을 손상시키지 않고 트랜잭션이 정확하게 실행되도록 관리합니다. 잠금 기반, 2단계, 타임스탬프 기반 및 유효성 검사 기반 프로토콜을 사용하여 업데이트 손실이나 더티 읽기와 같은 이상 현상을 방지하고 직렬화 가능한 결과를 보장합니다.
동시성 제어란 무엇입니까?
동시성 제어 데이터베이스 관리 시스템에서 동시 실행(système)은 여러 작업을 서로 충돌 없이 관리하는 절차입니다. 이를 통해 데이터베이스 트랜잭션이 동시에 정확하게 수행되어 해당 데이터베이스의 데이터 무결성을 손상시키지 않고 올바른 결과를 도출할 수 있습니다.
모든 사용자가 단순히 데이터를 읽기만 한다면 서로 간섭할 여지가 없으므로 동시 접속 처리는 매우 쉽습니다. 그러나 실제 데이터베이스는 읽기 및 쓰기 작업이 혼합되어 있기 때문에 동시 접속 처리는 어려운 과제가 됩니다.
DBMS 동시성 제어는 주로 다중 사용자 시스템에서 발생하는 이러한 충돌을 해결하는 데 사용됩니다. 따라서 동시성 제어는 두 개 이상의 트랜잭션이 동시에 실행되고 동일한 데이터에 접근해야 하는 데이터베이스의 적절한 작동을 위한 가장 중요한 요소 중 하나입니다. 이는 다음과 같은 요소들과 밀접하게 연관되어 작동합니다. 거래 관리이는 동시성 제어가 안전하게 인터리빙해야 하는 작업 단위를 정의합니다.
동시성 처리의 잠재적 문제점
다음은 적절한 DBMS 동시성 제어가 없을 경우 발생할 수 있는 몇 가지 문제점입니다.
- 손실된 업데이트 여러 트랜잭션이 동일한 행을 선택하고 선택된 값에 따라 해당 행을 업데이트할 때 발생합니다.
- 미확정 종속성 (더티 리드)는 두 번째 트랜잭션이 아직 커밋되지 않은 다른 트랜잭션에 의해 업데이트된 행을 선택할 때 발생합니다.
- 반복 불가능한 읽기 두 번째 트랜잭션이 동일한 행에 여러 번 접근하여 매번 다른 데이터를 읽을 때 발생합니다.
- 잘못된 요약 이 오류는 한 트랜잭션이 반복되는 데이터 항목의 모든 인스턴스 값에 대한 요약을 취하는 동안 다른 트랜잭션이 해당 인스턴스 중 일부를 업데이트할 때 발생합니다. 결과적으로 생성된 요약은 정확한 결과를 반영하지 않습니다.
동시성 방식을 사용하는 이유는 무엇일까요?
DBMS에서 동시성 제어 방식을 사용하는 이유:
- 상충하는 거래 간에 상호 배제를 통한 격리를 적용합니다.
- 읽기-쓰기 및 쓰기-쓰기 충돌 문제를 해결하기 위해.
- 실행 제약 조건을 지속적으로 적용하여 데이터베이스의 일관성을 유지합니다.
- 동시 실행 트랜잭션 간의 상호 작용을 제어하기 위해 동시성 제어 체계를 사용합니다.
- 직렬화 가능성을 보장하기 위해.
예시
두 사람이 같은 영화의 같은 상영 시간에 맞춰 전자 키오스크에서 영화표를 동시에 구매한다고 가정해 봅시다.
하지만 해당 상영관에는 좌석이 하나밖에 남지 않았습니다. 동시 접속 제어가 없다면 두 명의 영화 관람객 모두 티켓을 구매하게 될 가능성이 있습니다. 동시 접속 제어를 사용하면 이러한 상황이 발생하지 않습니다. 두 관람객 모두 영화 좌석 데이터베이스에 접근할 수는 있지만, 동시 접속 제어는 거래 과정을 먼저 완료한 구매자에게만 티켓을 제공합니다.
동시성 제어 프로토콜
각기 다른 동시성 제어 프로토콜은 허용하는 동시성 수와 그에 따른 오버헤드 사이에서 서로 다른 절충점을 제공합니다. DBMS에서 사용되는 주요 동시성 제어 기법은 다음과 같습니다.
- 잠금 기반 프로토콜
- 2단계 잠금 프로토콜
- 타임스탬프 기반 프로토콜
- 검증 기반 프로토콜
아래에서는 가장 널리 사용되는 잠금 기반 프로토콜부터 차례로 살펴보겠습니다.
잠금 기반 프로토콜
잠금 기반 프로토콜 DBMS에서 락 기반 프로토콜은 트랜잭션이 적절한 락을 획득하기 전까지 데이터 항목을 읽거나 쓸 수 없도록 하는 메커니즘입니다. 락 기반 프로토콜은 특정 데이터 항목을 단일 트랜잭션에 잠그거나 격리함으로써 동시성 문제를 해결하는 데 도움을 줍니다.
잠금은 데이터 항목과 연결된 데이터 변수로, 해당 항목에 대해 수행할 수 있는 작업을 나타냅니다. 잠금은 동시 트랜잭션이 데이터베이스 항목에 접근하는 방식을 동기화하는 데 도움을 줍니다. 모든 잠금 요청은 동시성 제어 관리자에게 전송되며, 트랜잭션은 잠금 요청이 승인된 후에만 진행됩니다.
바이너리 잠금: 데이터 항목에 대한 이진 잠금은 잠금 상태 또는 잠금 해제 상태일 수 있습니다.
공유/독점: 이 잠금 메커니즘은 사용 용도에 따라 잠금을 구분합니다. 쓰기 작업을 수행하기 위해 획득한 잠금을 배타적 잠금이라고 합니다.
1. 공유 잠금(S): 공유 잠금은 읽기 전용 잠금이라고도 합니다. 공유 잠금을 사용하면 데이터 항목을 여러 트랜잭션 간에 공유할 수 있습니다. 왜냐하면 어떤 트랜잭션도 해당 항목을 업데이트할 권한이 없기 때문입니다. 예를 들어, 두 트랜잭션이 한 사람의 계좌 잔액을 읽는 경우, 데이터베이스 공유 잠금을 설정하여 읽기 권한을 부여합니다. 다른 트랜잭션이 해당 잔액을 업데이트하려고 하면, 읽기 작업이 완료될 때까지 공유 잠금이 업데이트를 차단합니다.
2. 배타적 잠금(X): 배타적 잠금(X-lock)을 사용하면 데이터 항목에 대한 읽기 및 쓰기가 모두 가능합니다. 이 잠금은 배타적이며 동일한 데이터 항목에 대해 동시에 여러 개의 잠금이 걸릴 수 없습니다. X-lock은 `lock-x` 명령어를 사용하여 요청합니다. 예를 들어, 계좌 잔액을 업데이트해야 하는 거래의 경우 X-lock을 설정하여 해당 거래를 허용할 수 있으며, 이후 읽기 또는 쓰기를 시도하는 두 번째 거래는 차단됩니다.
3. 심플리스틱 잠금 프로토콜: 이를 통해 트랜잭션은 작업을 시작하기 전에 모든 객체에 대한 잠금을 획득할 수 있습니다. 트랜잭션은 쓰기 작업이 완료된 후 데이터 항목의 잠금을 해제할 수 있습니다.
4. 사전 청구 잠금: 이 프로토콜은 연산을 평가하고 실행을 시작하는 데 필요한 데이터 항목 목록을 생성합니다. 모든 잠금이 승인되면 트랜잭션이 실행되고, 모든 연산이 완료되면 잠금이 해제됩니다.
굶주림: 기아 상태는 트랜잭션이 락을 획득하기 위해 무기한 대기하는 상황을 말합니다. 이러한 현상의 원인으로는 락이 걸린 항목에 대한 대기 체계 관리가 미흡하거나, 리소스 누수가 발생하거나, 동일한 트랜잭션이 반복적으로 기아 상태의 희생양이 되는 경우 등이 있습니다.
이중 자물쇠: 교착 상태는 두 개 이상의 프로세스가 서로 자원을 해제하기를 기다리면서 순환 고리를 형성하는 상황을 말합니다.
2상 잠금(2PL) 프로토콜
The 2단계 잠금 프로토콜2PL이라고도 하는 이 방법은 트랜잭션 데이터에 잠금을 적용하여 직렬화 가능성을 보장하는 동시성 제어 방식입니다. 이를 통해 다른 트랜잭션이 동일한 데이터에 동시에 접근하는 것을 차단합니다.
2단계 잠금 프로토콜을 사용하면 각 트랜잭션이 두 단계에 걸쳐 잠금 또는 잠금 해제 요청을 할 수 있습니다.
- 성장 단계: 이 단계에서 거래는 잠금을 획득할 수는 있지만 잠금을 해제할 수는 없습니다.
- 수축 단계: 이 단계에서 거래는 잠금을 해제할 수는 있지만 새로운 잠금을 획득할 수는 없습니다.
2PL이 직렬화 가능성을 제공하는 것은 사실입니다. 하지만 교착 상태가 발생하지 않는다는 것을 보장하지는 않습니다. 위 다이어그램에서 로컬 및 글로벌 교착 상태 감지기는 교착 상태를 탐지하고 트랜잭션을 초기 상태로 되돌려 해결합니다.
엄격한 XNUMX단계 잠금 방식
Strict 2PL은 2PL과 거의 동일합니다. 유일한 차이점은 Strict-2PL은 락을 사용한 후 절대 해제하지 않는다는 것입니다. 커밋 시점까지 모든 락을 유지하고 프로세스가 완료되면 한꺼번에 해제합니다.
중앙 집중식 2PL
중앙 집중식 2PL에서는 단일 사이트가 잠금 관리 프로세스를 담당합니다. 전체 DBMS에 대해 하나의 잠금 관리자만 존재합니다.
기본 사본 2PL
기본 복사본 2PL 메커니즘에서는 여러 잠금 관리자가 서로 다른 사이트에 분산되어 있으며, 특정 잠금 관리자는 데이터 항목 집합에 대한 잠금을 관리하는 역할을 담당합니다. 기본 복사본이 업데이트되면 변경 사항이 슬레이브에 전파됩니다.
분산형 2PL
이 메커니즘에서는 잠금 관리자가 모든 사이트에 분산되어 각 사이트의 데이터에 대한 잠금을 관리하는 역할을 합니다. 데이터 복제가 없는 경우, 이는 기본 복사본 2PL과 동일합니다. 분산형 2PL의 통신 비용은 기본 복사본 2PL보다 상당히 높습니다.
타임스탬프 기반 프로토콜
The 타임스탬프 기반 프로토콜 DBMS에서 타임스탬프는 시스템 시간 또는 논리 카운터를 타임스탬프로 사용하여 동시 트랜잭션 실행을 순차적으로 처리하는 알고리즘입니다. 이를 통해 충돌하는 모든 읽기 및 쓰기 작업이 타임스탬프 순서대로 실행되도록 보장합니다.
이 방식에서는 항상 오래된 트랜잭션에 우선순위가 부여됩니다. 시스템 시간을 사용하여 트랜잭션의 타임스탬프를 결정하며, 가장 일반적으로 사용되는 동시성 프로토콜입니다. 락 기반 프로토콜은 충돌하는 트랜잭션의 실행 순서를 관리하는 반면, 타임스탬프 기반 프로토콜은 작업이 생성되는 즉시 충돌을 관리합니다.
예:
Suppose there are three transactions T1, T2, and T3. T1 has entered the system at time 0010 T2 has entered the system at 0020 T3 has entered the system at 0030 Priority will be given to transaction T1, then T2 and lastly T3.
장점:
- 스케줄은 2PL 프로토콜처럼 직렬화할 수 있습니다.
- 거래 대기 시간이 없으므로 교착 상태 발생 가능성이 사라집니다.
단점 : 동일한 트랜잭션이 재시작되고 지속적으로 중단될 경우 기아 현상이 발생할 수 있습니다.
검증 기반 프로토콜
The 검증 기반 프로토콜 DBMS에서 낙관적 동시성 제어 기법이라고도 하는 이 방법은 트랜잭션에서 동시성 충돌을 방지하는 방법입니다. 이 프로토콜에서는 트랜잭션 데이터 자체를 업데이트하는 대신 트랜잭션 데이터의 로컬 복사본을 업데이트하므로 실행 중 간섭이 줄어듭니다.
검증 기반 프로토콜은 세 단계로 수행됩니다.
- 읽기 단계
- 검증 단계
- 쓰기 단계
읽기 단계
읽기 단계에서는 트랜잭션을 통해 데이터 값을 읽을 수 있지만, 쓰기 작업이나 업데이트는 실제 데이터베이스가 아닌 로컬 데이터 복사본에만 적용됩니다.
검증 단계
검증 단계에서는 업데이트를 적용해도 직렬화 가능성이 유지되는지 확인하기 위해 데이터를 검사합니다.
쓰기 단계
쓰기 단계에서 유효성 검사가 성공하면 업데이트가 데이터베이스에 적용되고, 그렇지 않으면 업데이트는 폐기되고 트랜잭션이 롤백됩니다.
동시성 제어 프로토콜 비교
네 가지 프로토콜 계열은 트랜잭션이 실제로 충돌하는 빈도에 대해 서로 다른 예측을 합니다. 아래 표는 각 계열이 어떤 위치에 속하는지 요약한 것입니다.
| 프로토콜 | 접근 | 이중 자물쇠 | 언제가 최고야 |
|---|---|---|---|
| 잠금 기반 | 비관적, 접근 전에 잠금장치를 설치한다 | 가능한 | 갈등은 빈번하게 발생합니다. |
| 2상 잠금 | 비관적, 성장 및 축소 단계 | 가능한 | 직렬화 가능성이 필요합니다. |
| 타임스탬프 기반 | 타임스탬프 순으로 정렬 | 교착 상태 없음 | 주문은 중요합니다. 기다리는 것은 손해입니다. |
| 검증 기반 | 낙관적으로, 쓰기 전에 검증하세요 | 교착 상태 없음 | 갈등은 드물다 |
요약하자면, 락 기반 및 2PL 프로토콜은 충돌이 흔히 발생한다고 가정하고 사전에 방지하는 반면, 타임스탬프 및 유효성 검사 프로토콜은 충돌이 드물다고 가정하고 충돌이 발생했을 때만 해결합니다.
좋은 동시성 프로토콜의 특징
이상적인 동시성 제어 메커니즘은 다음과 같은 목표를 가지고 있습니다.
- 현장 및 통신 장애에 대한 복원력이 있어야 합니다.
- 최대 동시성을 달성하기 위해 트랜잭션의 병렬 실행을 허용합니다.
- 오버헤드를 최소화하려면 저장 메커니즘과 계산 방법이 적당해야 합니다.
- 이는 트랜잭션의 원자적 행위 구조에 대한 몇 가지 제약을 강제해야 합니다.
