DevStarSJ.github.io 으로 이사했습니다.: 대용량 데이터베이스 솔루션 1권 #04 병렬처리

병렬처리 (Parallel operation)

- 병렬 조회 (Parallel Query Execution)

- 병렬 데이터 로딩 (Parallel Data Loading)

- 병렬 인덱스 생성 (Parallel Index Creation)

- 병렬 복구 (Parallel Recovery)

* 병렬처리로 하는 이유는 ?

저렴한 가격으로 성능향상이 가능하다. CPU만 늘리면 된다. 어렵지 않다.

요즘같은 Multi-core, Multi-CPU 시절에 하나의 Core만을 이용해서 처리하면 아무리 많은 일을 시켜도 나머지 Core들은 놀고있다.

실행구조

위의 그림을 예로 들면 해당 SQL문이 실행되었을 때 어떻게 병렬로 처리할까 ?

1. Data를 CPU들이 나누어서 읽게 된다.

2. CPU들이 읽은 Data를 가지고 각자 처리를 해서 조건에 맞는 Data만을 찾아 낸다.

3. Group By 가 있으므로 Sorting을 해야하니 CPU들을 나눠서 Sorting을 실시한다.

4. 결과물을 취합하여 사용자에게 보고한다.

Static Paraellel 과 Dynamic Parallel

* Dynamic Parallel (동적분할)

- 모든 CPU에 부하가 균등하게 분배 (라고는 하지만 그러기가 상당히 어려움. 대부분 먼저 끝난 것들은 SLEEP 상태)

- Data File별 독립적인 관리 불가능 (Data Table이 손상되면 전체 Data가 손상됨)

- 불규칙한 분포를 가진 처리범위 작업시 상대적으로 유리

* Static Parallel (정적분할)

- Data 자체를 처음부터 각각의 CPU에 나눠서저장하고 처리

- 독립적인 INDEX 재생성 가능 : GLOBAL INDEX , LOCAL INDEX

- 파일별 독립적인 ONLINE, OFFLINE : Data 손상시 해당 File만 복구

- 다량의 Data 관리에 유리

개념적으로는 Dynamic Parallel이 더 좋아 보이지만, 실제로 사용해보면 Static Parallel이 훨씬 더 빠르고 관리도 편하다.

병렬처리 사용방법 (Oracle의 경우)

1. 생성시 정의

CREATE TABLE line_item (

item_no number(7),

item_name varhar(20), ...

)

PARALLEL 20;

CREATE INDEX item_index on line_item (item) PARALLEL 20;

Table 생성시 병렬로 지정해 놓는것은 별로 좋은 방법이 아니다. SQL문으로 Hint 기능을 이용하는 것이 더 현명하다. Table 자체를 병렬로 생성하면 아주 안좋은 미꾸라지 같은 SQL문을 잘못 실행했을 때 시스템 전체 속도에도 영향을 주기 때문이다. 그리고 병렬처리로 효과를 볼려면 최소 CPU가 3개이상은 되어야 한다. PARALLEL 20 이라고 해 놓았다고 해서 CPU 가 20개 이하인 곳에서는 실행이 안되는 것은 아니다. 다만 DBMS가 계속해서 20개까지 병렬처리 하기위해서 노력은 한다.

2. 이미 작성된 Object에 대하여 병렬로 수정

ALTER TABLE line_item PARALLEL 20;

ALTER INDEX item_index REBUILD PARALLEL 20;

Table 및 Index를 Block에 저장하는데 있어서 중요한 개념이 2가지 있다. PCTFREE 와 PCTUSED 이 2가지에 대해서 알아보고 넘어가자. VARCHAR로 선언한 값 'A' 를 'ABC'로 수정하였을 경우 기존에 저장된 공간보다 새로 고친 값이 커져서 해당 Block에는 저장을 못할 수도 있다. 이럴 경우 다른 Block에 저장을 한다면 해당 ROW를 읽을 때 2 Block 이상을 같이 읽어야 할 것이다. 즉 I/O 양이 늘어나서 성능은 느려지게 된다.

Table의 경우는 PCTFREE 와 PCTUSED의 설정값이 있다.

PCTFREE 10 으로 설정하면 Block에 Data를 넣을 때 10%는 빈공간으로 두어서 UPDATE 등에 사용될 임시 저장공간으로 남겨놓는 것이다. 그리고 Table 내의 Data를 지우거나 Update로 PCTFREE 공간으로 옮겨지더라도 기존의 빈 공간은 사용하지 않는다. PCTUSED 60 이라고 설정하면 사용중인 공간이 60% 이하로 떨어지면 새로운 Data 등록이 가능하게 Free List로 등록을 하라는 명령이다.

하지만 View의 경우는 PCTFREE만 있고 PCTUSED가 없다.

그래서 계속해서 DELETE, UPDATE 가 자주 일어나는 Table의 INDEX인 경우 Table의 Data가 2GB 인데 Index가 5GB인 경우도 발생할 수 있다. 과거에는 이럴 경우 INDEX를 삭제 후 다시 생성하였다. INDEX 생성 과정은 Table을 Full-Scan 하여 Key를 Sorting 하는 과정으로 이루어져서 엄청난 시간이 걸린다. 그리고 Index 생성 중에는 DB를 정상적으로 이용하기 힘들다. 그래서 INDEX REBUILD 기능이 생겼다. INDEX REBUILD 는 DDL Lock이 발생하지 않아서 근무 중에도 사용이 가능하다. 해당 작업으로 Balance-Tree를 균형있게 만들어주며 필요없는 공간도 줄여준다.

3. 해당 SQL만 병렬로 처리 : Hint 기능 사용

SELECT /*+ PARALLEL(line_item,20) */ item_name, ... FROM line_item

병렬처리 적용범위

- TABLE ACCESS (FULL-SCAN)

- MERGE JOIN

- NESTED LOOPS

- SORT (GROUP BY, JOIN, ORDER BY, UNIQUE)

- AGGREGATE (GROUP BY) : MIN, MAX, COUNT ....

- CREATE TABLE AS SELECT ... FROM ...

- UNION, UNION ALL

- ALTER INDEX ... REBUILD ...

- DML : INSERT , DELETE, UPDATE