3. 병렬 조인
2011.06.28 13:55
3. 병렬 조인
메커니즘 핵심 원리
- 병렬 프로세스들이 서로 독립적으로 조인을 수행 할 수 있도록 데이터 분배
- 분배 작업 완료 후 프로세스 간 서로 방해 받지않고(= 통신 불필요) 각자 할당받은 범위 내에서 조인 완료
방식
1. 파티션 방식 : Partition-Pair 끼리 조인 수행 (파티션 상태에 따라 다음과 같음)
1-1. 둘 다 같은 기준으로 파티셔닝(equi-partitioning)된 경우
1-2. 둘 중 하나만 파티셔닝된 경우(둘 다 파티셔닝되었더라도 파티션 기준이 서로 다른 경우는 여기에 해당)
1-3. 둘 다 파티셔닝되지 않은 경우
2. Broadcast 방식 : 한쪽 테이블을 Broadcast 하고 나서 조인 수행 ☞ 파티셔닝 불필요
(1) 둘 다 같은 기준으로 파티셔닝된 경우 - Full Partition Wise 조인
(그림 7-7)
- 조인컬럼인 deptno 기준으로
10 과 30이 하나의 파티션(→Partition Pair 1)
20 과 40이 또 다른 파티션(→Partition Pair 2) 나누어 저장
- 값의 분산 형태로 분석 시 리스트 파티션과 해시 파티션 둘 중 하나로 가정
☞ Range 파티션이면 10~20, 30~40 형태
< 전제조건 > : 병렬도 = 2, 프로세스 3개 (P000, P001 → QC)
- 상호배타적 Partition-Pair 형성으로 각 서버 프로세스가 하나씩 독립적으로 조인 수행 (Infra-operation parallelism)
☞ 만약 Partition-Pair가 10개면, 두 개 서버 프로세스가 각각 5개식 순차적 처리
- 실행계획
- 다른 병렬 조인은 두 개의 서버집합이 필요한 반면, 여기서는 하나의 서버 집합만 필요(뒤에서 자세히 다룸)
- Full Partition Wise 조인은 파티션 기반 Granule이므로 서버 프로세스 개수는 파티션 개수 이하로 제한
- 파티션 방식(Method)은 어떤 것이든 상관없음. Range, 리스트, 해시 상관없이 두 테이블 조인 컬럼에 대해 같은 방식, 같은 기준으로 파티셔닝 돼 있다면 서로 방해받지 않고 Partition-Pair 끼리 독립적 병렬 조인 가능
- 조인 방식도 어떤 것이든 선택 가능. NL 조인, 소트 머지 조인, 해시 조인 등
(2) 둘 중 하나만 파티셔닝된 경우 - Partial Partition Wise 조인
- 정의 : 다른 한쪽 테이블을 같은 기준으로 동적으로 파티셔닝하고 나서 각 Partition-Pair를 독립적으로 병렬 조인하는 것
- 특징
- 둘 다 파티셔닝이되었지만 파티션 기준이 서로 다른 경우에도 이 방식으로 조인 가능
- 데이터를 동적으로 파티셔닝하기 위해 데이터 재분배가 선행되어야 함
- Inter-operation parallelism을 위해 두 개의 서버 집합 필요
(그림 7-8)
< 전제조건 > : 병렬도 = 2, 프로세스 5개 (P000, P001, P002, P003 → QC)
- 1단계 : 첫 번째 서버 집합(P000, P001)이 dept 테이블을 읽어 두번 째 서버 집합(P002, P003)에 데이터 재분배
- 2단계 : Full Partition Wise 조인과 동일한 처리 (P002, P003 → QC)

- 실행계획
해시조인 아래쪽 두 테이블 중 어느 한쪽에 "PARTITION (KEY)" 또는 "PART (KEY)" 라고 표시되어 있으면, Partition Wise 조인
(3) 둘 다 파티셔닝되지 않은 경우 - 동적 파티셔닝
- 조인 컬럼에 대해 어느 한쪽도 파티셔닝되지 않은 상황이면 아래 두개의 방식 중 하나를 사용
- 양쪽 테이블을 동적으로 파티셔닝하고서 Full Partition Wise 조인
- 한쪽 테이블을 Broadcast 한 뒤에 조인
(그림 7-9)
- 1 단계 : 첫 번째 서버집합(P000, P001)이 dept 테이블을 읽어 두 번째 서버집합(P002, P003)에 전송
- 2 단계 : 첫 번째 서버집합(P000, P001)이 emp 테이블을 읽어 두 번째 서버집합(P002, P003)에 전송
(참고)
- 첫 번째 서버 집합 역할 : 데이터 분배
- 두 번째 서버 집합 역할 : 받은 데이터 파티셔닝
- 가능한 메모리 내에서 파티셔닝 하겠지만 공간 부족 시, Temp 테이블 스페이스 활용
- 2단계 완료 시점 : Partition Pair 구성
- 3 단계 : 양쪽 테이블 모두의 파티셔닝을 담당한 두 번째 서버 집합(P002, P003)이 각 Partition-Pair 에 대해 독립적 병렬 조인
(그림 7-10) : (그림 7-7) 과 동일
- 실행계획
해시 조인 아래쪽에 있는 두 테이블 모두 PQ Distrib 컬럼에 "HASH" 표시를 보고 동적 파티셔닝 확인 가능
- 특징
- 조인을 본격저으로 수행하기 전 사전 정지 작업 단계에서 메모리 자원과 Temp 테이블스페이스 공간을 많이 사용
- 양쪽 모두 파티셔닝해야 하기 때문에 기본적으로 양쪽 테이블 모두에 대한 전체 범위처리가 불가피
- 조인 컬럼의 데이터 분포가 균일하지 않을 시, 프로세스 간 일량 차이 때문에 병렬처리 효과 크게 반감될 수 있음
- 병렬 조인 처리 시, 동적 파티셔닝 방식이 유용한 경우
- 어느 한쪽도 조인 컬럼 기준으로 파티셔닝되지 않은 상황
- 두 테이블 모두 대용량 테이블
- 조인 컬럼의 데이터 분포 균일
(4) 둘 다 파티셔닝되지 않은 경우 - Broadcast 방식
- 조인 컬럼에 대해 어느 한쪽도 파티셔닝되지 않은 상황에서 사용되는 방식으로
- 두 테이블 중 작은 쪽을 반대편 서버 집합의 "모든" 프로세스에 Broadcast 한 후에 조인 수행
<전제조건> - 병렬도 = 2
(그림 7-11)
- 1단계 : 첫 번째 서버 집합에 속한 프로세스들이 각자 읽은 dept 테이블 레코드를 두 번째 서버 집합에 속한 모든 병렬 프로세스에게 전송
- 2단계 : 두 번째 서버 집합에 속한 프로세스들이 각자 맡은 범위의 emp 테이블을 읽으면서 병렬로 조인 수행. 1단계 완료 시, 두 번째 서버집합에 속한 프로세스 모두 dept 테이블의 완전한 집합을 갖게되어 프로세스 간 상호간섭없이 독립적 조인 수행 가능

- 실행계획
양쪽 테이블 모두 파티션되지 않았을 시 1차적으로 Broadcast 방식 고려
∵ 양쪽 테이블을 동적으로 파티셔닝하는 방식에 비해 리소스 사용량이 매우 적음
그러나 Broadcast 되는 테이블이 아주 작을 때만 유용
중대형 이상일 때는 과도한 프로세스 간 통신으로 성능 저하
두번째 서버 집합이 메모리 내에서 감당하기 어려울 정도로 큰 테이블을 Broadcast 할 시, Temp 테이블 스페이스 사용으로 급격한 성능 저하 가능
※ 위와같은 부담이 없을 저도로 어느 한 쪽 테이블이 충분히 작을 때만 유용
- 특징
- Broadcast 는 작은 테이블이라는 전제이기 때문에 Serial 스캔으로 처리 할 때도 많음
☞ P→P 보다 S→P 형태가 일반적, 두 테이블 중 한쪽 테이블만 병렬 처리
- Broadcast 가 이루어지고 나서의 조인 방식은 어떤 것이든 선택 가능. NL 조인, 소트 머지 조인, 해시 조인 등
- Broadcast 되는 작은 쪽 테이블은 전체범위 처리가 불가피, 큰 테이블은 부분범위 처리 가능
병렬 조인 방식 요약
- 오라클 고도화 원리와 해법 2 (bysql.net 2011년 1차 스터디)
- 작성자: 위충환 (실천하자)
- 최초작성일: 2011년 06월 28일
- 본문서는 bysql.net 스터디 결과입니다 .본 문서를 인용하실때는 출처를 밝혀주세요. http://www.bysql.net
- 문서의 잘못된 점이나 질문사항은 본 문서에 댓글로 남겨주세요. ^^
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
40 | 2. 서브쿼리 Unnesting | darkbeom | 2011.05.15 | 19841 |
39 | 2. 소트를 발생시키는 오퍼레이션 | 휘휘 | 2011.06.12 | 3508 |
38 | 2. 파티션 Pruning | 실천하자 | 2011.06.21 | 26102 |
» |
3. 병렬 조인
![]() | 실천하자 | 2011.06.28 | 7220 |
36 |
3. 다양한 인덱스 스캔 방식
![]() | 멋진넘 | 2011.02.18 | 33881 |
35 |
3. 해시 조인
![]() | darkbeom | 2011.03.20 | 21602 |
34 | 3. 옵티마이저의 한계 | 멋진넘 | 2011.04.19 | 7902 |
33 | 3. 뷰 Merging | 실천하자 | 2011.05.15 | 23516 |
32 |
3. 데이터 모델 측면에서의 검토
![]() | 멋진넘 | 2011.06.13 | 5922 |
31 | 3. 인덱스 파티셔닝 | darkbeom | 2011.06.19 | 54156 |
30 |
4. 테이블 Random 액세스 부하
[1] ![]() | darkbeom | 2011.02.23 | 14754 |
29 | 4. 조인 순서의 중요성 | 운영자 | 2011.03.27 | 14374 |
28 | 4. 통계정보 Ⅰ | darkbeom | 2011.04.25 | 18214 |
27 | 4. 조건절 Pushing | 실천하자 | 2011.05.31 | 7114 |
26 |
4. 소트가 발생하지 않도록 SQL 작성
![]() | 멋진넘 | 2011.06.12 | 7940 |
25 | 5. 테이블 Random 액세스 최소화 튜닝 | suspace | 2011.02.24 | 7028 |
24 | 6. 스칼라 서브쿼리를 이용한 조인 [1] | 휘휘 | 2011.03.28 | 6686 |
23 | 5. Outer 조인 | 실천하자 | 2011.03.29 | 5084 |
22 | 5. 카디널리티 | suspace | 2011.04.26 | 5989 |
21 | 5. 조건절 이행 | 휘휘 | 2011.05.29 | 5509 |