대량의 데이터를 액세스하는 작업에서는 시스템 리소스를 많이 사용하는 대신 짧은 시간에 보장할 수 있어야 한다. 다음은 수행방법을 살펴보자
1. 두 테이블 중 적은 테이블을 선행 테이블로 결정한다.
2. 선행 테이블을 Hash Function을 이용하여 Hash Area에 Hash Table을 구성한다.(Build Input)
3. 만약 Hash Area만으로 생성 가능하다면 후행테이블은 크기에 상관없이 차례로 Hash Function을 이용하여 Hash Table과 조인(Probe Input)하면서 성공한 결과값을 운반단위로 이동한다.
4. 만약 Hash Area만으로 Hash Table 생성이 불충분 하다면 Hash Table Overflow가 발생하여 데이터를 나눠서 저장 할 Partition 수를 결정한다.(Fan -out)
5. 선행 테이블의 조인 컬럼과 Select List 컬럼을 메모리로 읽어 들여 첫번째 해쉬 함수를 이용하여 Partition을 Mapping하고, 두번째 해쉬 함수를 이용하여 해쉬 테이블 생성시 사용 할 해쉬 값을 생성한다.
6. 선행 테이블의 조인 컬럼의 유일 값만으로 Bit-Vector을 생성한다. -추후 Bit-Vector filtering에 사용하기 위함.
7. Partition에 데이터를 MOVE하고 채워진 Partition은 디스크로 내려간다.
8. 선행 테이블이 모두 읽혀지면 Partition 테이블을 완성하고, Partition 크기순으로 정렬한 후 작은 Partition N개를 메모리에 로드한다.
9. 후행 테이블을 읽으면서 조인컬럼으로 Bit-Vector와 Filtering에 성공하였다면, 첫번째 해쉬함수로 Partition을 결정하고, 두번째 해쉬 함수를 이용하여 메모리 상에 있는 선행테이블과 조인하고 성공하면 운반단위로 이동하고, 해당 Partition이 메모리에 존재하지 않는다면 해쉬 키값,조인컬럼, Select List를 디스크에 쓴다.
10. 후행 테이블이 모두 읽혀지면, Bit-Vector Filtering에 성공했지만, 조인에 성공하지 못해 미 처리된 선행 파티션과 후행 파티션을 메모리에 올려 차례로 반복수행 한다.
액세스해야 할 데이터가 많을 경우 Sort Merge Join은 Merge 단계에 들어 가기 위해 양쪽 테이블의 처리 범위가 SORT 되어야 하므로 SORT에 대한 부담이 크고, Nested Loop Join은 선행 테이블의 처리 범위가 넓을 경우 그 만큼 랜덤 액세스의 발생으로 수행속도를 보장할 수 없다.이해 반해 Hash Join은 다른 조인에 시스템 리소스를 가장 많이 사용하지만 Hash Function을 이용함으로써 Sort를 하지 않고, 각 테이블에 한번만 액세스하여 조인이 이루어 지므로 큰 테이블간이나, 큰 테이블과 적은 테이블의 조인에 효율적인 조인 방법이다. Hash Join의 특징 및 사용기준은 다음과 같다.
특징
1. 다른 테이블의 결과 값을 제공받지 않고, 자신에게 주어진 조건으로만 처리범위를 결정한다.(독립적).
2. 해쉬 함수를 이용 하게 되므로 부분범위 처리를 할 수 없으며 전체범위 처리를 하게 된다.(전체범위 처리)
3. 메모리 영역만으로 해쉬 테이블을 생성시 최적의 효과를 낼 수 있으므로 적은 테이블이 선행으로 온다.
4. 해쉬 함수를 이용하므로 결과값의 정렬을 보장 받을 수 없다.
사용기준
1. 대량의 데이터 액세스 시, 배치 처리, Full Table Scan 하면서 조인 해야 할 때 유리하다.
2. 비용은 많이 들지만 수행속도를 보장해야 하는 작업에 유용하다.(Parallel Query 사용)
3. 가능한 메모리 내에서 작업 가능하도록 init Parameter나 Session 정보를 변경하여 사용한다. (Hash_area_size, Hash_multiblock_io_count 등..)
수행속도는 시스템 리소스와 즉결된다. 사용자는 작업의 성격을 분명히 하고, 작업에 적합한 조인을 선택해야만 수행 속도를 보장할 수 있다. SQL작성 후 반드시 실행계획를 확인 하여 사용자가 원하는 액세스로 수행되는지를 확인하는 습관을 들어야 한다.
http://database.sarang.net/?inc=read&aid=541&criteria=dbms&subcrit=&id=&limit=20&keyword=&page=1
![\includegraphics[height=5cm]{operator/gfx/radixjoin}](http://homepages.cwi.nl/~marcin/thesis/img82.gif)
separate clusters according to the value of a hash function calculated over the join attribute. In the second, corresponding clusters are joined using any traditional join method - Figure 3.9. This solution proves effective when number of clusters is selected in such a way, that they are small enough to fit into cache memories. 
댓글 없음:
댓글 쓰기