(제 25회) 데이터베이스 / (53)~(54) 해설

53. 릴레이션 R과 S의 속성 A를 통한 이원 조인 (two-way join)의 구현 방법 중에서 릴레이션 R과 S가 조인 속성 A에 대해 오름차순으로 정렬되어 있을 경우에만 적용 가능한 방법은?

 

 

① 중첩 루프 ② 인덱스 검사

③ 해시 검사 ④ 정렬 합병

 

■ 해설

• 두 개의 테이블에서 각각 join 대상을 먼저 읽은 후 정렬하여 merge 하는 방식

1. Outer Table 의 인덱스를 통해 테이블 찾기

2. Outer Table 을 Join 컬럼 기준으로 정렬

3. Inner Table 도 인덱스를 기준으로 테이블 찾기

4. Inner Tavle 을 Join 컬럼 기준으로 정렬

5. 두 Table 을 Join (PGA 영역에서 진행)

Sort Merge Join 란

소트머지 조인은 데이터 정렬을 활용하여 정렬된 두 테이블의 행을 효율적으로 결합하는 조인 알고리즘입니다. Join Key 를 기준으로 두 테이블을 모두 정렬해야 하는 다소 큰 데이터 세트를 조인할 때 특히 효과적입니다. 두 개의 테이블에서 각각 Join 대상을 먼저 읽은 후 정렬하여 merge 하는 방식입니다.

 

Nested Loop Join 이란

번역하면 중첩 루프 조인이라고 하는데요. 줄여서 NL 조인이라고도 합니다. 중첩 루프(nested loop) 라는 말을 해석해 보면 '루프' 라는 용어는 반복을 의미하고 '중첩' 이라는 것은 여러 개가 겹치는 것을 의미합니다. 즉, 반복문 여러 개가 겹쳐 있는 구조를 중첩 루프라고 합니다. Nested Loop 조인은 한 테이블(outer table) 의 각 행을 반복하고 지정된 조건에 따라 다른 테이블(Inner Table) 의 행과 일치시키는 방식으로 처리됩니다.

 

Hash Join 이란

해시 Join 은 두 테이블 간의 조인 작업을 효율적으로 실행하기 위해 Hash map 을 사용하는 알고리즘 입니다. 이 방법은 기존 Nested Loop, Sort Merge 조인에서 부족할 수 있는 대규모 데이터 세트를 처리할 때 특히 유용합ㄴ다. 그러면 어떻게 작동할까요?

 

구분	Nested Join	Sort Merge Join	Hash Join
성능	첫번째 조건의 선형테이블이 얼마나 조건을 줄여주는가에 좌우	조인하고자 하는 테이블들의 처리결과가 유사해야 병합을 위해 대기하는 시작이 절약됨	Hash Area 사이즈 조정으로 수행속도 향상
인텍스 전략	후행 테이블에서 연결고리에 인덱스가 없는 경우 심각한 성능저하가 발생할 수 있으므로 인덱스 생성 필요	조인을 위한 인덱스 전략 고려 불필요	조인을 위한 인덱스 전략 고려 불필요
고려사항	선행(Driving) 테이블 선정 연결고리문제 고려(인덱스 존재여부) 테이블간 Join 순서	정렬을 위한 Sort Area 공간 고려 필요	두 테이블의 크기 차이가 현저한 경우에 적합 반드시 작은 테이블을 선행 테이블로 선정하여 Build input 을 수행
활용전략	OLTP 성 온라인 업무	DW, 배치업무 등의 대량 데이터 처리 업무	대량의 엑세스 시 배치처리, Full Table scan 하면서 조인해야 할 때, 비용은 많이 들지만 수행속도를 보장해야 하는 작업(Parallel Query 사용)

 

정답 : ④

 

 

54. 낙관적 로킹(optimistic locking)과 비관적 로킹 (pessimistic locking)에 대한 설명 중 옳지 않은 것은?

 

① 일반적으로 인터넷은 비정형적이고 체계화되지 않은 곳이므로 사용자들이 트랜잭션 수행 중에 작업을 중단하는 등의 예상치 못한 행동을 하여 비관적 로킹을 사용하는 것이 더 효율적이다.

② 만약 트랜잭션이 복잡하거나 클라이언트의 속도가 느린 경우 낙관적 로킹을 사용하면 극적으로 생산성을 향상시킬 수 있다.

③ 낙관적 로킹의 장점은 작업이 종료된 후에만 로크를 획득하기 때문에 비관적 로킹보다 로크를 가지고 있는 시간이 훨씬 짧다는 것이다.

④ 응용의 특성상 특정한 행에 많은 작업을 해야하는 트랜잭션의 경우에는 비관적 로킹을 사용 하는 것이 더 효율적이다.

 

■ 해설

 

구준	낙관적 락(Optimistic Lock)	비관적 락(Pessinistic Lock)
선택기준	충돌 발생 확률이 낮은 상황에서 주로 사용됩니다. 이 방식은 데이터가 대부분의 시간 동안 변경되지 않을 것이라는 낙관적 가정 하에 작동합니다.	충돌이 자주 발생할 것으로 예상되는 상황. 예를 들어, 동시에 여러 트랜잭션이 같은 데이터를 변경할 가능성이 높은 경우에 사용됩니다.
충돌대응	데이터를 업데이트하는 시점에서만 충돌을 확인합니다. 만약 충돌이 발견되면, 일반적으로 트랜잭션을 재시도하거나 오류를 반환합니다.	데이터에 접근하기 전에 먼저 락을 걸어 다른 트랜잭션의 접근을 차단합니다. 이로써 충돌을 예방합니다.

 

① 일반적으로 인터넷은 비정형적이고 체계화되지 않은 곳이므로 사용자들이 트랜잭션 수행 중에 작업을 중단하는 등의 예상치 못한 행동을 하여 비관적 로킹을 사용하는 것이 더 효율적이다(X)

 

비정형적이고 체계화되지 않고 예상치 못한 행동을 한다는 얘기는 충돌이 발생할 것으로 예상하기 힘든 상황이다 라고 설명을 하고 있기 때문에 낙관적 로킹을 사용하는 것이 효율적입니다.

 

• DB 충돌 상황을 개선할 수 있는 방법

- 첫 번째, 테이블의 row 에 접근 시 Lock 을 걸고 다른 Lock 이 걸려 있지 않을 경우에만 수정을 가능하게 할 수

있음

- 두 번째, 수정할 때 내가 먼저 이 값을 수정했다고 명시하여 다른 사람이 동일한 조건으로 값을 수정할 수 없게

하는 것

 

• 비관적 락(Pessimistic Lock) 이론

- 비관적 락은 트랜잭션의 충돌이 발생한다고 가정하고 우선 락을 걸고 보는 방법

- 비관적 락이란 트랜잭션이 시작될 때 Share Lock 또는 Exclusive Lock 을 걸고 시작하는 방법

- DB 에서 제공하는 락 기능 사용

- Repeatable Read, Serializable 급의 격리 수준 제공

 

[장점]

- 충돌이 자주 발생하는 환경에서 롤백의 횟수를 줄일 수 있어 성능에 유리

- 데이터 무결성을 보장하는 수준이 높다

[단점]

- 동시성이 떨어져 성능 손해를 많이 본다

- 읽기가 많이 이루어지는 곳에는 적합하지 않다

- 데드락을 유발할 수 있다.

 

 

• 낙관적 락(Optimistic Lock) 이론

- 수정할 때 내가 이 값을 수정했다고 명시하여 다른 사람이 동일한 조건으로 값을 수정할 수 없게 하는 것

- 낙관적 락은 트랜잭션을 커밋하기 전까지는 트랜잭션의 충돌을 알 수 없다는 특징

- DB에서 제공하는 것이 아닌 어플리케이션 레벨에서 잡아주는 Lock

- 애시 당초 버전을 동시에 select query 에 사용하기 때문에 해당 row 가 update 된 경우 찾을 수 없음

- version 뿐만 아니라 hashcode 또는 timestampp 를 이용

 

[장점]

- 충돌이 안난다는 가정하에 요청이 수행되므로 처리 성능이 좋다.

[단점]

- 잦은 충돌이 일어나서 처리 비용이 많이 들 때는 적합하지 않다.

- 어플리케이션단에서 롤백 처리를 어떻게 할 지 구현해야 한다.

 

언제 어떤 경우에 각각 효과적일까?

위에서 낙관적 락과 비관적 락이 각각 어떤 개념이며 어떤 롤백 처리방식을 가지고 있는지 알아보았습니다. 그렇다면 어느 경우에는 낙관적 락을 사용하고 또 어떨 경우에 비관적 락을 사용하면 좋을까요?

 

낙관적 락은 데이터를 업데이트 하기 전의 조회(select) 하면서 Lock 을 거는 작업이 필요 없습니다. 따라서 성능적으로 비관적 락보다 더 좋습니다 그리고 낙관적 락은 트랜잭션을 필요로 하지 않습니다. 이 두가지가 비관적 락에 비해 가지는 낙관적 락의 최대 강점입니다.

 

트랜잭션을 필요로 하지 않기 때문에 아래와 같은 로직의 흐름을 가질 때도 충돌 감지를 할 수 있습니다. 만약 비관적 락이라면 1번에서 3번 사이의 트랜잭션을 유지할 수가 없습니다.

1. 클라이언트가 서버에 정보를 요청
2. 서버에서는 정보를 반환
3. 클라이언트에서 이 정보를 이용하여 수정 요청
4. 서버에서는 수정 적용(충돌 감지 가능)

또한 성능적으로 비관적 락보다 좋습니다. 때문에 충돌이 많이 일어나지 않을 것이라고 보여지는 곳에 사용하면 좋은 성능을 기대할 수 있습니다.

 

하지만 낙관적 락의 최대 단점은 롤백입니다. 만약 충돌이 났다고 한다면 이를 해결하려면 개발자가 수동으로 롤백처리를 한땀 한땀 해줘야 합니다. 비관적 락이라면 트랜잭션을 롤백 하면 끝나는 작업이지만 낙관적 락은 그렇지 않습니다. 수동으로 롤백처리는 구현하기도 까다롭지만 성능적으로 보더라도 update 를 한번 씩 더 해줘야 합니다. 따라서 결과적으로 비관적 락 보다 좋지 않을 수 있습니다. 이러한 단점 때문에 낙관적 락은 충돌이 많이 예상되거나 충돌이 발생했을 때 비용이 많이 들것이라고 판단되는 곳에서는 사용하지 않는 것이 좋을 것으로 보입니다.

 

정답 : ①

 

---

 

공감과 댓글은 아이티신비에게 큰 힘이 됩니다.

블로그 글이 유용하다면 블로그를 구독해주세요.♥