💡 Transaction과 비관적 락, 낙관적 락
DB를 조작하며 동시에 같은 데이터 row에 접근할 때, 서로 충돌하여 데이터의 무결성을 해치는 상황이 발생할 수 있다.
이를 방지하는 것이 transaction이고, transaction은 해당 데이터에 lock을 거는 방식으로 동작한다.
lock에는 두가지 방법이 있는데,
말그대로 자원 경쟁을 비관적으로 보는 것이 비관적 락. 낙관적으로 보는 것이 낙관적 락이다.
비관적 락(pessimistic lock)
문제가 발생할 것이라고 미리 생각하고 트랜잭션이 시작될 때 예방책의 Lock을 걸어주는 방식
비관적락 에는 Shared Lock, Exclusive Lock이 있다
- Shared Lock 공유락 : = Read Lock 트랜잭션이 읽기를 할때 사용하는 락.
데이터를 읽기만 하기 때문에 같은 공유락끼리는 동시에 접근을 허용한다.
write, 변경작업은 막는다 - Exclusive Lock 배타락 : = Write Lock 데이터를 변경할 때 사용하는 락.
트랜잭션이 종료될 때까지 유지된다.
배타락은 1번 1lock, read와 write 접근을 금지한다.
shared lock은 같은 shared lock이면 함께 db를 읽도록 허용하지만
shared lock과 exclusive lock은 서로 blocking된다
비관적 락 SQL문
- SELECT id, `name`
FROM theTable
WHERE id = 2;
- {새로운 값으로 연산하는 코드}
- BEGIN TRANSACTION;
- UPDATE anotherTable
SET col1 = @newCol1,
col2 = @newCol2
WHERE id = 2;
- UPDATE theTable
SET `name` = 'Karol2',
WHERE id = 2;
- {if AffectedRows == 1 }
- COMMIT TRANSACTION;
- {정상 처리}
- {else}
- ROLLBACK TRANSACTION;
- {DB 롤백 이후 처리}
- {endif}
BEGIN TRANSACTION 명령어로 transaction을 걸어주고, 명령이 실패하면 롤백하도록 명령어를 입력한다.
충돌이 일어날 경우 이처럼 DB단에서 TCL로 처리하게된다
낙관적 락(optimistic lock)
자원에 락을 걸지 않고, 동시성 문제가 발생하면 그때 처리한다.
db를 수정할 때 수정했다고 명시하여 다른 트랜잭션이 동일한 조건으로 값을 수정할 수 없게 한다.
- version, hashcode, timestamp 같은 별도의 컬럼을 추가한다.
해당 컬럼의 상태를 보고 충돌을 확인하는 방식으로 충돌 발생을 막는다. - 충돌이 발생하면 어플리케이션 단에서 처리하게된다.
update에 실패해도 자동으로 예외를 던지지 않고, 0개의 row를 update한다.
따라서 여러 작업이 묶인 트랜잭션이 실패하면 개발자가 직접 롤백처리를 해주어야한다.
낙관적 락 SQL문
- SELECT id, `name`, `version`
FROM theTable
WHERE iD = 2;
- {새로운 값으로 연산하는 코드}
- UPDATE theTable
SET val1 = @newVal1,
`version` = `version` + 1
WHERE iD = 2
AND version = @oldversion;
- {if AffectedRows == 1 }
- {정상 처리}
- {else}
- {롤백 처리}
- {endif}
transaction이 없다
충돌 발생으로 수정하지 못한 부분은 어플리케이션 단에서 개발자가 직접 롤백 처리 해야한다.
***JPA에서의 낙관적 락 :
@Version으로 사용,
낙관적 락 발생 시 ObjectOptimisticLockingFailureException 오류가 발생하며 개발자가 롤백처리하는 과정이 필요하다.
비관적 락과 낙관적 락은 언제 사용해야할까?
일반적으로 낙관적 락이 DB에 락을 걸지 않으므로 빠른 처리 속도를 보인다.
비관적 락은 데이터 자체에 락을 걸게 되므로 동시성이 떨어져 성능 저하를 보이고 데드락Deadlock 발생 위험도 있다.
반면에 충돌이 많이 발생하는 환경 혹은 충돌 발생 시 비용이 많이 들때는 비관적 락이 트랜잭션 롤백으로 쉽게 처리가 가능하다면
낙관적 락은 수동롤백이 필요해 처리가 까다롭고 (0개 row지만) DB를 update한 후 롤백을 처리하므로 성능도 떨어지게 된다.
참고 :
https://sabarada.tistory.com/175
https://velog.io/@bagt/Database-낙관적-락-비관적-락
트랜잭션과 격리성에 대해 더 알아보자 : https://sabarada.tistory.com/117
💡 DB에서의 Deadlock은 무엇이고 deadlock을 해결하려면 어떻게 해야 하나요?
Deadlock교착상태란 두 개 이상의 프로세스가 자원을 점유한 상태에서 서로 다른 프로세스가 점유하고 있는 자원을 요구하며, 서로의 작업을 끝나기만을 기다리며 둘 다 영원히 끝나지 않는 상황을 뜻합니다.
아래 네 가지 상황이 함께 일어날 경우에만 deadlock이 발생한다
- 상호 배제(Mutual Exclusion)
한 번에 한 개의 프로세스만이 공유자원을 사용할 수 있음 - 점유 대기(Hold and Wait)
프로세스가 할당된 자원을 가진 상태에서 다른 자원을 기다림 - 비선점(No Preemption)
프로세스가 작업을 마친 후 자원을 자발적으로 반환할 때까지 기다림
(이미 할당된 자원을 강제적으로 빼앗을 수 없음) - 순환 대기(Circular Wait)
프로세스의 자원 점유 및 점유된 자원의 요구 관계가 원형을 이루면서 대기하는 조건.
각 프로세스는 순환적으로 다음 프로세스가 요구하는 자원을 가지고 있음
deadlock 해결 방법
- 타임아웃 설정 및 재시도: 트랜잭션이 특정 시간 동안 락을 획득하지 못하면 데드락을 감지하고 해당 트랜잭션을 롤백하고 재시도하기
- 데드락 검출과 해제 알고리즘 사용: 데이터베이스 시스템은 데드락을 감지하고 해제할 수 있는 알고리즘을 제공한다. 주기적으로 데드락을 검사하고 필요한 경우 트랜잭션 중 하나를 롤백하여 데드락을 해제한다. 자동화
- 더 적은 범위의 락 사용: 데드락을 방지하기 위해 락의 범위를 최소화한다. 가능하면 트랜잭션 내에서 가장 필요한 리소스만 락을 획득하고, 다른 리소스에 대한 접근은 락을 피하는 방법을 사용할 수 있다.
- 트랜잭션 우선순위 설정: 각 트랜잭션에 우선순위를 부여하여 데드락 시 특정 트랜잭션을 롤백하는 대신 우선순위가 낮은 트랜잭션을 롤백할 수 있다. 이를 통해 중요한 작업을 우선 처리한다
https://charles098.tistory.com/99
https://velog.io/@yanghl98/운영체제OS-Deadlock데드락-정의-발생-조건-해결-방법
💡 Index가 왜 필요한가요?
DB에서의 인덱스는 DB테이블에 목차를 매기는 것으로 데이터의 주소값을 저장하며, 테이블에 대한 동작의 속도를 높여주는 자료구조이다.
테이블 내 1개 컬럼, 혹은 여러개 컬럼을 이용해 생성하며,
검색과 레코드 접근을 빠르게 처리할 수 있고, 순서가 있는 동작에 효율적으로 사용할 수 있다.
= index가 없다면 데이터 주소값을 특정할 힌트가 없으므로 테이블 전체를 탐색하게되며 검색 시간이 증가하게 된다.
DB Index에 적합한 자료 구조는 크게 Hash Table, B-Tree, B+Tree 등이 있다
- Hash Table : key-value 데이터 저장에 특화된 자료구조. key(특정 컬럼 값) = value(데이터 위치)
- B-Tree : B-Tree란 자식 노드가 2개 이상인 트리를 의미. Key의 왼쪽 자식은 항상 Key보다 작은 값을, 오른쪽 자식은 큰 값을 가집니다
- B+Tree : B+Tree는 B-Tree를 확장 및 개선한 자료 구조로서, 말단의 리프 노드에만 데이터의 위치(Value)를 관리
더 자세한 설명 https://tecoble.techcourse.co.kr/post/2021-09-18-db-index/
'CS > DB & SQL' 카테고리의 다른 글
[기술면접] DB | Nested Loop, Sort-Merge, Hash Join (0) | 2023.09.07 |
---|---|
[기술면접] DB 문답 | index 상세 (0) | 2023.09.05 |
[기술면접] DB 문답 | Transaction + SQL언어 (0) | 2023.09.01 |
[기술면접] DB문답 | SQL JOIN, RDB vs NoSQL (0) | 2023.08.29 |
[기술면접] DB | 모델링 N:M관계 (0) | 2023.08.28 |