안녕하세요. DB2 및 XpertMon 사용자 여러분!
㈜ 아이티엑스퍼트그룹 DB 사업부입니다.

이번 주에는 WS II 의 기본 개념과 쿼리를 처리하는 방식과 WS II 에 있어 성능 향상을 위한
설정 팁에 이어 WS II V8.2의 신기능에 대해 살펴보도록 하겠습니다.

---

WS II V8.2의 신기능

WS II V8.2에 새로이 추가된 내용은 다음과 같습니다.

• Fenced Wrapper
  WS II V8.1 에서 모든 wrapper는 DB2 엔진과 동일한 프로세스에서 돌아갔습니다.
  효율은 가장 높았지만, 위험성도 그만큼 높았습니다. WS II V8.2 에서는 wrapper가
  db2fmp 프로세스 안에서 따로 떨어져 돌아갈 수 있게 되었습니다. 이러한 Fenced
  Wrapper는 생성시 옵션을 선택하거나, ALTER WRAPPER 문을 통해서 설정 할 수
  있습니다.
  Wrapper를 독립적으로 유지하는 것은 엔진과 로컬데이터를 보호할 수 있고,
  문제 분석을 용이하게 하며, Wrapper 개발 등에 유용합니다.
  그리고 db2fmp 프로세스는 스레드화 되어 여러 db2agent 프로세스가 Wrapper를
  공유하게 됩니다.
  Wrapper를 공유하게 되면, 메모리 사용이 줄어들게 됩니다.
  
  
• Nickname 데이터의 병렬 처리
  MPP 환경에서 Nickname 데이터와 파티션된 데이터간에 join이 일어나게 된다면
  coordinator 파티션에서 연속적인 방법으로만 가능했습니다.
  하지만 WS II V8.2 에서는 Nickname 데이터가 모든 파티션에 분산되어,
  로컬 데이터와의 Join이 병렬로 수행될 수 있습니다.
  이러한 병렬 처리는 Fenced Wrapper를 필요로 합니다.
  
  이러한 병렬 처리는 어떠한 경우에 유용할까요?
  
  로컬 데이터와 Nickname데이터가 Join되거나 Union 될 때 유용합니다.
  로컬에 대용량의 데이터가 여러 노드에 분산되어 있을 경우, 대용량의 데이터를
  coordinator 파티션으로 옮기지 않게끔 하기 위해 Nickname 데이터를 로컬 파티션에
  분산시켜서 병렬 처리를 하게 하는 것입니다.
  
  이러한 병렬처리는 Nickname 데이터를 로컬테이블이나 중간 join 결과가 있는
  파티션에 전체혹은 일부를 분산하여 전송하거나, 파티셔닝 키가 아닌 칼럼에 대한
  join을 만족시키기 위해 Nickname데이터와 로컬 데이터 모두를 분산시키는 방법이
  있습니다.
  이런 분산처리는 기본적으로 로컬 데이터의 양이 방대한 경우 매우 효과적입니다.
  
  그렇다면, 옵티마이저는 항상 파티션된 테이블과 Nickname 간의 Join 및 Union 에
  대해 병렬 처리를 선택할까요?
  답은 ‘아니오’ 입니다.
  다음과 같은 경우에 있어서는 Coordinator 파티션에서 연속적인 방법으로
  수행하는 것이 가장 좋은 방법입니다.
  
  • 쿼리에 사용되는 Nickname 이 많을 경우
  • 쿼리에 사용되는 로컬 데이터의 양이 그리 많지 않을 경우
  
  이런 경우, 로컬 데이터를 Coordinator 파티션으로 옮기는 것이 더 빠르므로,
  굳이 많은 Nickname 데이터를 분산시킬 필요가 없기 때문입니다.
  
  Fenced Wrapper를 사용하게 되면, 병렬 처리를 가능하게 하지만, 병렬 처리를
  강제하지는 않습니다.
  병렬처리에 대한 여부는 옵티마이저가 결정하게 됩니다.
  
  Nickname 과 로컬 파티션 데이터가 관계된 병렬 처리는 로컬 데이터가 수십만 건
  이상일 경우 가장 큰 이득을 볼 수 있습니다. 만약 사용되는 로컬 데이터가 작다면,
  Coordinator 에서의 연속처리 방법이 최상의 방법이며, Fenced Wrapper의 오버헤드
  역시 만만치 않게 됩니다. 병렬처리 최대의 효과는 로컬데이터를 Coordinator 로
  옮기지 않는다는데 있습니다. 따라서 여러 로컬 테이블이 join에 사용된다면 그 효과는
  매우 커집니다. MPP 환경에서 Federated 쿼리를 사용할 경우 Fenced Wrapper를
  항상 사용하시기를 권합니다.
  
  또한 Nickname 간의 join, UNION 에 있어서도 Nickname 데이터를 분산처리 할 수
  있습니다. 다만 이 경우에는 분산처리를 통한 이익이 분산에 드는 cost 보다 큰
  경우에만 의미가 있습니다.
  
  그럼, SMP에서는 어떨까요? intra_partition_parallelism 을 사용하면, 로컬 데이터에
  관련된 쿼리가 여러 프로세스에 의해 처리됩니다. 하지만 원격 데이터에 대해서는
  V8.1 까지는 병렬처리가 불가능했습니다.
  WS II V8.2부터는 로컬 데이터 부분에 대해서는 병렬처리가 가능해졌습니다.
  Nickname 과의 join은 연속적인 방법으로 Coordinator 프로세스가 처리하게 됩니다.
  
  
  SMP에서 intra_partition_parallelism을 사용하기 위해서는,
  INTRA_PARALLEL을 ’YES’로 , DEGREE를 1보다 큰 값으로 설정하시면 됩니다.
  
• Nickname에 대한 Informational Constraint
  WS II V8.2에서는 Nickname과 로컬 테이블에 있어서, Relational Integrity ,
  Check Constraint 등을 지정할 수 있습니다.
  하지만 이름에 있어서 ‘Informational’이 의미하는 바가 ‘정보성’ 이므로 제약조건이
  강제적으로 적용되지는 않습니다. 다만, 옵티마이저가 쿼리를 rewrite 하는데 도움을
  줍니다.
  문법은 테이블에 제약조건을 추가하는 것과 유사합니다.
  
• Federated Query 에 대한 스냅샷 모니터링
  스냅샷 모니터를 통해 원격에서 처리되는 쿼리 정보를 확인 할 수 있게 되었습니다.
  스냅샷 정보를 확인하는 방법은 다음과 같습니다.
  
  • UPDATE MONITOR SWITCHES USING STATEMENTS ON;
  • GET SNAPSHOT FOR DYNAMIC SQL ON
  
  스냅샷 결과에서는, 전체문장, timing, 반환된 건수 등이 출력됩니다.
  각각의 데이터소스에서 처리되는 원격 문장에 대해서도 각각의 timing 과 반환된 건수를 알 수 있습니다.
  이 스냅샷 정보를 이용해서 문제가 되는 SQL이 있다면, 그 문제가 로컬에 있는지,
  원격에 있는지 확인 할 수 있습니다.
  다만 스냅샷에 나오는 문장이 로컬인지 원격인지를 알려주는 내용이 없기 때문에
  사용자가 직접 확인을 해야 하는 어려움도 있습니다.
  

이상적인 적용방법

가장 일반적인 질문중의 하나는 WS II 인스턴스와 웨어하우스 데이터의 위치를 지정하는
방법에 관한 것입니다.
이런 경우 가능하다면, WS II 인스턴스 내에 웨어하우스 데이터베이스를 위치시키도록 하기바랍니다.
대량의 데이터 전송을 막을 수 있을 뿐더러, fenced wrapper를 사용한다면 병렬처리의 잇점도
살릴 수 있습니다.

여러 원격 데이터 소스에 접근하기 위한 게이트웨이로 WS II를 사용할 경우 주의할 사항이
있습니다.
이런 경우 한번에 한 종류의 데이터 소스에 접근하는 방식을 사용하는데다, WS II가 단순한
통로역할만을 하는 것이 아니기 때문에 처리 속도가 느려질 수 있다는 것을 유의해야 합니다.
따라서, 쿼리를 수행하기에 앞서 그 내용을 확인하고, EXPLAIN을 통해 pushdown 내용을
확인하는 과정이 필요합니다.
일반적으로 Nickname을 정의하고 쿼리를 수행하는 것이 편리하기 때문에 그렇게 하는 것을
원하지만, 쿼리가 어떻게 수행되는지 여부를 확인하지 않고 수행한다면 수많은 데이터가
WS II로 전송되어 처리속도가 매우 느려질 수 있으므로 반드시 EXPLAIN을 통해 쿼리의
실행계획을 확인하시기 바랍니다.

그리고, WS II 서버를 ETL 엔진으로 사용하지 마시기 바랍니다. 모든 변환을 SQL로 표현하는
것도 불가능할 뿐더러, 복잡한 변환 함수는 pushdown에 영향을 주기 때문입니다.

자주 사용되는 원격 데이터를 MQT를 사용해서 로컬에 저장하는 내용에 대해 앞서 설명했지만,
복제나 DEFERRED REFRESH 방식의 MQT를 사용해 로컬에 캐시해 둔다면 수행 속도가 매우
빨라질 수 있습니다.
만약 캐시나 복제가 힘든 상황이라면, 일부 데이터를 영구적으로 통합하는 것도 한 방법입니다.

결론

원격 데이터 소스에서 WS II로 대량의 데이터가 이동하는 경우, 수행시간이 매우 길어질 수
있습니다.
WS II는 단순한 게이트웨이로서는 훌륭히 동작하지만, 성능면에서는 다소 문제가 될 수
있습니다.
임시목적이 아닌 가상 웨어하우스를 구성하는 데 있어서 WS II를 사용할 경우, 특히 대용량
데이터에 접근하는 경우는 반드시 proof-of-concept을 수행하시기 바랍니다.
그리고 WS II를 통해 데이터에 접근할 경우 코스트와 실행 계획을 확인 한 후에 수행하시기
바랍니다.
마지막으로, 원격 데이터를 복제나 MQT등을 통해 로컬에 캐시하여 쿼리의 처리속도를 크게
향상시킬 수 있습니다.

---

XpertMon for DB2 UDB V2
DB 사업부
Tel : 02-2108-1458
Fax : 02-2108-1459
Mobile : 011-896-6545
E-mail : hjlee@iteg.co.kr
URL : http://iteg.co.kr