데이터베이스 락
DB의 트랜잭션 처리의 순차성을 보장하기 위해 데이터 변경을 일시적으로 중지하는 것.
일반적으로 일관성과 무결성을 유지하기 위해 DB에서 사용하는 공통적인 방법이다.
락은 데이터베이스 뿐만 아니라 어플리케이션에서도 걸 수 있는데, 어플리케이션단에서 거는 락은 대체로 Optimistic DB에서 거는 것은 대체로 Pessemistic락이다.
Optimistic
낙관적 (충돌시 락) : 실제 데이터베이스에 락을 걸지 않기 때문에 데드락 적음, 충돌이 빈번하지 않으면 성능이 좋다. (보통 버저닝을 가장 많이 사용한다.)
충돌을 인지하는 시점이 커밋 시점이므로, 충돌이 발생해서 롤백해야 한다고 했을 때, 그 전에 수행했던 모든 동작이 롤백되어야 하므로 충돌시 오버헤드가 크다.
Versioning
- 직접 만들기 쉬움 (JPA
@Version을 사용하면 사용가능) - 데이터를 버전으로 관리해서 데이터베이스 충돌 관리 한다.
TimeStamping - 시간 정보를 사용해서 데이터 베이스 충돌 관리 한다.
Checksumming - 데이터의 해시값을 사용하여 충돌을 방지한다.
Pessemistic
비관적 (충돌 예상시 락) : 실제 데이터베이스에 락을 건다.
대체로 DB에서 설정
충돌이 발생하는 시점을 바로 인지 하므로, 충돌이 발생했을 때, 낙관적 락보다 오버헤드가 덜하다 / 데이터 무결성을 지키기 용이하다.
락을 건다는 것 자체가 데이터 베이스 리소스를 사용하는 것이므로 충돌이 없으면 오버헤드 발생
Pessemistic 락에 대한 설명(InnoDB)
공통적으로
X락(exclusive)
- 동시에 같은 컬럼을 write할 때
- x락이 걸려있으면 다른 트랜잭션은 x, s 락 걸 수 없음
- 가장 높은 강도의 락
S락(shared)
- 여러 락 걸기 가능(read lock)
- share mode 명시하면 락
- 가장 낮은 강도의 락
외에도 update lock, intent lock이 있다.
InnoDB는 어떤 락 방식을 사용할까?
레코드락
- 인덱스를 잠군다.
- 인덱스가 없으면 custered index를 잠군다
gap lock
- index가 없는 부분에 대한 lock
데드락이 생기는 경우
- 서로 참조하는 테이블이 x락을 걸 경우
→ deadlock detection (작은 트랜잭션을 롤백 시킴)
→ lock wait timeout (일정시간 지나면 감지)
etc
- next key lock
- table lock
- …
락에대해 고민할 때 고려사항
-
충돌이 빈번한지
-
읽기 / 쓰기 연산의 비율
-> 일반적인 웹 어플리케이션은 읽기가 대부분이므로 웹 어플리케이션은 낙관적 lock을 사용한다.
그럼 DB에서 처리하는 락은 어떤 것들이 있을까?
perssimistic lock은 데이터베이스, 엔진마다 상이하기 때문에 사용하는 제품 또는 버전에 따라 공부하고 사용해야한다.
