 Microsoft SQL Server 2000 Analysis Services 응용 프로그램의 원본으로 Teradata Database 사용
Joy Mundy Microsoft Corporation 2003년 6월 요약 이 문서에서는 SQL Server 2000 Analysis Services와 HOLAP(Hybrid OLAP), MOLAP(Multidimensional OLAP) 또는 ROLAP(Relational OLAP) 솔루션용 Teradata Database를 모두 이용하는 분석 응용 프로그램을 작성하는 방법에 대해 설명합니다. 이 문서는 두 데이터베이스 시스템 모두의 기능에 대해 기본적으로 이해하고 있는 시스템 통합자나 데이터베이스 개발자를 대상으로 합니다.
Microsoft Corporation과 NCR 부서인 Teradata는 서로의 고객이 분석 응용 프로그램을 구축할 때 두 회사 모두의 제품을 함께 사용할 수 있다는 점을 인식하고 있습니다. Analysis Services 분석 데이터베이스는 OLAP 큐브와 데이터 마이닝 모델(가능한 경우)을 포함하며 HOLAP, MOLAP 또는 ROLAP 방식으로 Teradata Database에 있는 데이터를 사용할 수 있습니다. 아래에서 자세히 설명한 대로 Analysis Services 기능 중 대부분은 Teradata Database를 사용하여 지원됩니다. 이 문서에서는 Teradata Database 원본이 존재하고 사용자 쿼리, 분석 및 데이터 대기 시간 요구 사항이 정의되었다고 가정합니다. 시작하기 전에 다음 사항에 익숙해지는 것이 좋습니다.
Microsoft와 Teradata에서 지원하는 Analysis Services 기능거의 모든 Analysis Services 기능이 Teradata Database를 사용하여 지원됩니다. Teradata Database를 사용하여 지원되는 기능 목록은 다음과 같습니다.
Microsoft SQL Server 온라인 설명서에서는 이러한 기능에 대한 소개 정보를 제공합니다. 특히 SQL Server 2000 버전에서 지원하는 기능 Microsoft와 Teradata에서 지원하지 않는 Analysis Services 기능Microsoft와 Teradata에서 지원하지 않는 Analysis Services 기능은 다음과 같습니다.
설치 및 구성프로덕션 환경에서는 Teradata Database와 다른 서버에 Analysis Services를 설치하는 것이 좋습니다. 분석 서버에 필요한 소프트웨어는 다음과 같습니다.
Analysis Services 구성많은 Analysis Services 설정이 제품 설치 즉시 변경됩니다.
연결 테스트연결을 테스트하려면 먼저 개발 컴퓨터에 Analysis Services가 제대로 설치되어 있는지 확인합니다. 분석 관리자를 실행하고 Foodmart 2000 데이터베이스에 대한 정의를 찾은 다음 차원이나 큐브를 다시 처리합니다. Analysis Services를 사용한 경험이 없으면 분석 관리자의 "시작" 화면에서 제공하는 자습서를 통해 학습하는 것이 좋습니다. 그런 다음 Teradata Database에 대한 연결을 확인하고 분석 관리자에서 Teradata Database를 가리키는 새 데이터 원본을 만듭니다. 데이터 원본 만들기 마법사의 첫 번째 화면에서 다음 그림과 같이 OLE DB Provider for Teradata를 선택하십시오. 다음 그림에는 데이터 원본 만들기 마법사의 공급자 화면이 나와 있습니다.
데이터 링크 속성 대화 상자의 연결 탭에서 Teradata Database에 연결하는 데 필요한 정보를 입력하십시오. 이 예에는 Teradata1이라는 서버에 대한 연결이 나와 있습니다. 특정 IP 주소에 연결할 수도 있습니다. 이 경우 암호 저장 허용 확인란을 선택해야 합니다. 다음 그림에는 데이터 원본 만들기 마법사의 연결 화면이 나와 있습니다.
연결 테스트 단추를 사용하여 Teradata Database에 대한 연결을 테스트합니다. Data Link Properties 대화 상자의 모두 탭에서 확장 속성을 편집하여 OLE DB Provider for Teradata의 여러 매개 변수를 설정할 수 있습니다. 가장 많이 설정되는 매개 변수는 다음과 같습니다.
추가 구성 옵션 및 문제 해결 기법은 OLE DB Provider for Teradata Installation and Users Guide 분석 관리자의 차원 마법사와 큐브 마법사를 사용할 때는 차원이나 큐브의 원본으로 사용되는 데이터베이스를 선택합니다. 연결이 제대로 작동하고 있는지 확인하려면 작은 차원을 만들어 처리하십시오. 익숙한 Teradata Database에서 매우 작은 테이블을 원본 테이블로 사용하십시오. 차원을 만들어 처리할 수 있으면 데이터 원본이 정확하게 정의된 것입니다.
위에서 설명한 일부 지원되지 않는 기능을 제외하면 Teradata Database를 원본으로 사용하는 OLAP 큐브의 논리 디자인과 다른 모든 데이터베이스를 원본으로 사용하는 큐브의 논리 디자인은 동일합니다. 최선의 Analysis Services 데이터베이스 디자인 및 작성 방법에 대한 대부분의 기존 정보는 데이터가 SQL Server 관계형 데이터베이스를 원본으로 사용한다는 가정 하에 작성되었습니다. Teradata Database를 원본으로 사용하는 데이터의 경우 다음 사항을 제외하고는 이러한 권장 사항을 대부분 따라야 합니다.
Analysis Services 큐브 및 차원Analysis Services 데이터베이스에는 차원과 큐브가 포함되어 있습니다. 차원은 관계형 차원 테이블과 유사하고 일반적으로 관계형 차원 테이블에서 채워집니다. 큐브는 관계형 팩트 테이블과 유사하고 관계형 팩트 테이블에서 채워집니다. 차원 중 대부분은 여러 큐브 간에 공유됩니다. 큐브는 리프 수준 팩트와 집계 팩트의 두 가지 팩트 데이터로 구성됩니다. 리프 수준 팩트는 큐브에서 가장 세부적인 팩트 데이터입니다. 큐브의 입자가 큐브 원본으로 사용되는 팩트 테이블의 입자와 같은 경우가 있습니다. 즉, 큐브에는 관계형 원본 테이블만큼 많은 리프 수준 행이 포함되어 있습니다. 큐브의 입자가 원본 팩트 테이블의 입자보다 많은 경우도 있습니다. 이 경우 최하위 수준의 큐브는 실제로 원본 팩트 테이블의 집계입니다. 유용한 집계를 만드는 것이 큐브 쿼리 성능을 개선하는 중요한 방법 중 하나지만 집계는 선택 사항입니다. Analysis Services에서 만든 큐브 팩트 데이터와 집계 데이터는 하나 이상의 파티션에 저장됩니다. 큐브에 여러 파티션이 있는 경우 해당 큐브는 일반적으로 쿼리에서 분리에 자주 사용되는 차원을 따라 분할됩니다. 시간은 가장 많이 사용되는 분할 차원입니다. Analysis Services 성능 가이드
분할된 큐브를 사용하는 것이 좋습니다. 이 기능에는 Enterprise Edition의 SQL Server 2000이 필요합니다. Analysis Services 처리Analysis Services 데이터베이스를 전체적으로 처리해야 할 경우의 첫 번째 단계는 차원을 처리하는 것입니다. 거의 모든 경우 차원 데이터가 관계형 데이터베이스에서 Analysis Services 엔진으로 끌려오고 유효성이 검사되며 분석 서버에 Analysis Services 차원 형식으로 기록됩니다. 예외적인 경우인 관계형 차원 저장소에 대해서는 이 백서 뒷부분에서 간략히 설명합니다. 다음 단계는 데이터베이스에서 모든 큐브를 전체적으로 처리하는 것입니다. 이 단계를 "각 큐브의 각 파티션 처리"라고 합니다. 큐브 파티션 처리 자체는 리프 팩트 처리와 집계 처리의 두 가지 단계로 구성됩니다. 전체 처리는 상대적으로 드뭅니다. 기록 데이터의 초기 로드 후에 발생하는 정기(일반적으로 매일, 매주 또는 매달) 처리는 증분 처리입니다. 증분 처리는 전체 처리와 같은 단계로 구성되지만 관계형 저장소에 추가된 팩트 데이터와 차원 구성원만 처리합니다. 부록 A에는 Analysis Services 처리의 자세한 설명에 대한 많은 참조 정보가 있습니다. Analysis Services 쿼리Analysis Services 쿼리는 Microsoft Excel 피벗 테이블과 같은 클라이언트 도구에서 만듭니다. MDX(MultiDimensional Expression) 언어로 된 이 쿼리는 PTS라는 중간 계층 구성 요소나 클라이언트에 전달됩니다. PTS는 데이터 캐시를 포함하고 가능한 경우 해당 캐시에서 쿼리를 확인합니다. PTS 캐시에 요청된 데이터가 포함되어 있지 않으면 분석 서버의 요청이 만들어집니다. 또한 분석 서버에는 모든 사용자 간에 공유되는 캐시가 있습니다. 서버 캐시에서 쿼리를 확인할 수 없으면 서버가 영구 저장소로부터 데이터를 요청합니다. 서버는 쿼리를 확인하는 데 사용할 수 있는 가장 높은 수준의 집계에서 데이터를 반입하고 해당 결과로 생성된 셀 집합을 요청된 수준으로 집계한 다음 계산된 구성원과 같은 계산을 모두 계산합니다. 계산된 구성원은 MDX로 정의되고 "MeasureA minus MeasureB"와 같이 매우 단순할 수 있지만 광범위한 리프 데이터 집합을 암시적으로 요청하는 매우 복잡한 MDX 표현식일 수도 있습니다. 큐브를 디자인하고 쿼리 성능을 평가할 때는 상당한 양의 리프 데이터가 "최상위 고객 10명의 평균 매출"과 같이 겉보기에 단순한 계산된 구성원을 평가하는 데 필요할 수 있다는 점을 기억해야 합니다. 이 예에서 최상위 고객의 동적 평가는 비용이 많이 드는 작업일 수 있습니다. 이 평가는 리프 데이터가 관계형 데이터베이스에 ROLAP 또는 HOLAP 저장소 모드로 저장되더라도 항상 분석 서버에서 발생합니다. Analysis Services 저장소 모드Analysis Services는 다음 세 가지 모드의 큐브 파티션 데이터 저장소를 지원합니다.
저장소 모드에 관계없이 큐브는 성능을 제외한 모든 측면에서 동일하게 작동합니다. 쿼리 시간에 대부분의 계산이 Analysis Services 데이터베이스 엔진에서 발생합니다. ROLAP 또는 HOLAP을 사용하는 파티션에서 쿼리를 확인하는 데 관계형 데이터가 필요하면 상대적으로 단순한 쿼리가 Analysis Services 엔진에서 Teradata Database로 전송됩니다. 큐브 파티션을 처리하는 동안을 제외하고는 MOLAP 큐브가 Teradata Database에 액세스하지 않습니다. 관계형 디자인 시 유용한 정보Analysis Services 큐브 작성에 대한 기존 설명서와 최선의 방법에서는 대부분 관계형 원본을 차원형으로 구조화할 것을 권장합니다. 차원형으로 구조화된 관계형 모델에는 다음 두 가지 테이블 구조가 있습니다.
메모리 요구 사항많은 리소스, 특히 Analysis Services 성능 가이드 차원 구성원과 구성원 속성이 메모리에 저장할 수 있는 것보다 많으면 다음 세 가지 옵션 중 하나를 선택할 수 있습니다.
매우 큰 차원을 제거하는 데는 위험성이 따르지만 이 방법이 최선일 때가 종종 있습니다. 비즈니스 사용자는 분석 과정에서 개별 고객의 이름을 볼 필요가 거의 없습니다. 비즈니스 사용자에게는 더 많은 집계 차원을 정의하고 드릴스루 또는 작업을 통해 세부 데이터를 보는 기능을 제공하는 것이 더 낫습니다. 관계형 스키마 요구 사항Analysis Services 데이터베이스의 기반이 되는 데이터 모델은 단순한 차원형 구조, 즉 별모양 스키마, 눈송이 스키마 또는 단일 평면 테이블을 따라야 합니다. 이러한 모델을 혼합할 수 있습니다. 예를 들어 동일한 Analysis Services 데이터베이스 내에 일반 별모양 차원 테이블, 완전히 정규화된 "눈송이" 테이블, 팩트 테이블의 데이터에서 분리된 차원을 각각 원본으로 사용하는 테이블이 있는 경우가 있을 수 있습니다. Analysis Services에서는 팩트 테이블과 차원 테이블 간에 정수 대리 키가 필요하지 않지만 가능하면 사용하는 것이 좋습니다. 큰 데이터 집합, 특히 큰 차원의 경우에는 가능한 한 가장 작은 데이터 형식을 키에 사용하십시오. 차원이 처리될 때는 Analysis Services가 차원 수준 간의 참조 무결성을 확인하여 모든 자식 차원 구성원이 유효한 부모를 가지도록 합니다. 마찬가지로 큐브가 처리될 때도 Analysis Services가 팩트와 모든 차원 간의 참조 무결성을 확인합니다. 모든 차원에 해당 구성원이 없으면 큐브 내에서 어떠한 팩트도 허용되지 않습니다. 큐브 원본으로 뷰 사용일반적으로 Analysis Services 데이터베이스의 원본으로 테이블을 직접 사용하지 않고 관계형 뷰를 사용하는 것이 최선의 방법입니다. 이 간접 수준은 관계형 데이터베이스와 Analysis 데이터베이스 간의 절연 계층을 제공합니다. 가장 간단한 경우로 뷰를 "select * from PhysicalTable"로 정의하십시오. 차원 구조에 아직 관계형 원본 데이터가 없으면 관계형 구조를 단순화하는 뷰를 정의하여 논리적 차원형 데이터베이스를 구현할 수 있습니다. 일반적인 예는 Order/Detail 테이블 구조를 단일 Fact_OrdersLineItems 뷰로 비정규화하는 것입니다. 분석 사용자의 비즈니스 요구 사항을 개발하는 프로세스를 단계별로 거치고 논리적 차원형 모델을 디자인하는 것이 좋습니다. 이 논리적 차원형 모델은 작성한 Analysis Services 차원과 큐브에 매우 밀접하게 매핑됩니다. Teradata Database에서 차원형 구조를 물리적으로 인스턴스화하기 위해 정규화된 데이터 웨어하우스를 다시 지정할지 여부는 다음 사항에 따라 결정됩니다.
차원 키 크기 최소화Analysis Services 데이터베이스가 큰 경우에는 작은 데이터 형식의 차원 ID를 사용하는 것이 좋습니다. 모든 차원이 메모리에 꼭 맞아야 한다는 점을 유념하십시오. 작은 키를 사용하면 차원 크기가 최소화되어 메모리 요구 사항이 줄어들고 성능이 개선됩니다. MOLAP 큐브의 경우 차원 ID가 리프 팩트 다차원 구조의 키로 사용됩니다. 작은 키를 사용하면 ROLAP 또는 MOLAP 팩트 구조의 디스크 저장소 요구 사항이 최소화되고 성능이 개선됩니다. 일반적으로 차원형 웨어하우스의 경우에는 정수 대리 키를 차원에 사용하는 것이 최선의 방법입니다. 차원형 데이터 웨어하우스를 채우고 유지 관리하는 작업은 주로 차원 구성원이 "변경"된 시기 평가, 새 차원 구성원과 대리 키 만들기, 만든 대리 키를 팩트 테이블로 전파 등으로 이루어집니다. Teradata 데이터 웨어하우스가 차원형 데이터 웨어하우스가 아니어서 대리 키를 사용할 수 없는 경우가 자주 있습니다. 대리 키를 사용할 수 있으면 Analysis Services 차원에 대한 정의에서 해당 대리 키를 차원 ID로 지정하십시오. MOLAP 저장소의 스키마 최적화Analysis Services에 관한 많은 최선의 방법과 백서에서 "스키마 최적화"의 중요성에 대해 설명하고 있습니다. 이 과정은 시스템에서 큐브 처리용으로 단순화된 관계형 쿼리와 ROLAP 쿼리를 생성하도록 큐브를 정의합니다. 대부분의 시스템에서는 이 단계를 통해 MOLAP 처리 성능이 상당히 개선됩니다. Teradata Database에서 작성된 큐브의 경우 Teradata의 Join 또는 Aggregate Join 인덱스를 사용하면 이 단계의 중요성이 낮아질 수 있습니다. 하지만 관계형 쿼리에서 여러 차원 테이블을 삭제하는 비용이 0인 경우가 자주 있으며 MOLAP 저장소를 사용하는 큐브의 경우 이 단계를 거치는 것이 좋습니다. 자세한 내용은 온라인 설명서의 큐브 스키마 최적화 Teradata의 Aggregate Join 인덱스가 구축된 경우 이렇게 스키마를 최적화하면 안됩니다. Teradata Database 쿼리 최적화 프로그램은 최적화되지 않은 기본 큐브 정의를 통해 쿼리 구문을 생성하도록 기본 설정되어 있습니다. 부모-자식 차원 및 ROLAP 저장소Analysis Services에서는 알려진 고정 개수의 명명된 수준이 있는 표준 차원과 덜 구조화된 부모-자식 차원을 지원합니다. 파티션이 관계형 데이터베이스에 하나라도 저장되어 있는 경우에는 부모-자신 차원을 사용하지 않는 것이 좋습니다. Teradata Database 인덱싱원본 Teradata Database와 같은 단위 수준에서 작성되는 Analysis Services 큐브도 있고 원본 Teradata Database보다 높은 단위 수준에서 작성되는 Analysis Services 큐브도 있습니다. 예를 들어 관계형 데이터에는 해당 날짜의 타임스탬프가 찍힌 트랜잭션이 포함되지만 큐브에는 시간 차원이 포함되지 않는 경우가 발생할 수 있습니다. 이 경우 큐브와 같은 단위 수준에서 Aggregate Join 인덱스를 작성하면 ROLAP 저장소에 대한 사용자 쿼리 성능이 상당히 개선됩니다. 큐브에서 ROLAP 저장소를 사용하는 경우 하나 이상의 Aggregate Join 인덱스를 추가하면 성능이 상당히 개선될 수 있습니다. 작성할 Aggregate Join 인덱스에 대한 최선의 권장 사항은 사용자 쿼리의 분석에서 나옵니다. 이 작업은 Database Query Logging 기능(Teradata Database V2R5 버전 이상)이나 Access Logging 기능(Teradata Database V2R5 버전 미만)을 통해 수행할 수 있습니다. 관계형 스키마에 Aggregate Join 인덱스를 추가하면 전체 유지 관리 전략이 잠재적으로 영향을 받습니다. Aggregate Join 인덱스를 사용하면 데이터 관리 인프라의 비용이 늘어날 가능성이 있습니다. 사용자 쿼리 성능을 최적화하려면 Aggregate Join 인덱스가 있는 ROLAP을 선택하거나 MOLAP 저장소 모드를 선택해야 합니다. HOLAP 저장소 모드는 지원되기는 하지만 MOLAP에 비해 거의 선택되지 않습니다. Teradata Database 최적화 프로그램의 작업이 제대로 수행되도록 하려면 초기 로드 후 모든 테이블에 대한 통계를 수집하는 것이 좋습니다. 또한 이후 변경 사항으로 인해 테이블 데이터 인구 통계가 상당히 수정될 경우에는 통계를 정기적으로 다시 수집하는 것이 좋습니다. 가상 큐브Analysis Services OLAP 데이터베이스는 대개 여러 개의 실제 큐브로 구성되며 이러한 실제 큐브는 종종 하나 이상의 가상 큐브로 결합됩니다. Analysis Services 데이터베이스를 쿼리하는 사용자가 볼 때는 가상 큐브의 모양과 작동 방식이 실제 큐브와 다르지 않습니다. 가상 큐브는 숙련된 디자이너가 다음과 같은 작업에 사용하는 매우 강력한 분석 디자인 구조입니다
적은 대기 시간 OLAP을 위한 디자인하나 이상의 큐브 파티션을 관계형으로 저장하면 적은 대기 시간 또는 "실시간" OLAP이 활성화됩니다. 대기 시간이 적은 OLAP 응용 프로그램은 트랜잭션이 발생하자마자 비즈니스 사용자가 분석 데이터를 사용할 수 있음을 의미합니다. Analysis Services 응용 프로그램의 대기 시간을 줄이려면 업스트림 프로세스가 적은 대기 시간으로 Teradata 데이터 웨어하우스를 채워야 합니다. 적은 대기 시간의 대체 디자인큐브에 하나 이상의 ROLAP 파티션이 포함되어 있으면 대기 시간이 매우 적어집니다. 많은 고객이 대부분의 큐브를 MOLAP 파티션에 저장하며 적은 대기 시간 데이터를 유지하기 위해 집계가 0으로 설정된 단일 ROLAP 파티션을 가집니다. 예를 들어 ROLAP 파티션에 "오늘" 또는 "금주"의 데이터가 있을 수 있습니다. 이 구성에서는 매일 밤 또는 매주 실행되는 프로세스가 ROLAP 파티션을 MOLAP 파티션으로 변환할 수 있습니다. 원할 경우 모든 큐브의 파티션을 ROLAP 파티션으로 저장할 수 있습니다. 차원 변경 사항을 관리하기 위한 옵션과 그에 따른 문제가 더 많이 있습니다. 가장 많이 사용되는 구성에서는 차원이 다차원 저장소에 저장됩니다. 대기 시간이 적으면 기존 차원 구성원(예: 기존 고객)의 새 트랜잭션을 분석에 사용할 수 있습니다. 정기적으로, 즉 매일 밤이나 그보다 더 자주 차원 증분 처리를 수행하면 새 차원 구성원을 분석에 사용할 수 있습니다. 차원 변경 사항에 대한 적은 대기 시간 액세스가 필요한 고객은 관계형 차원 저장소를 사용해야 하고 관계형 차원 저장소를 사용하려면 모든 큐브 파티션의 관계형 저장소가 필요합니다. 동적 차원의 경우에만 관계형 차원 저장소를 사용하고 정적 차원의 경우에는 일반 다차원 저장소를 사용하는 것이 좋습니다. 다른 기술 자료에서는 적은 대기 시간을 위해 많이 사용하는 기법, 즉 자동화된 일정에 따라 5-15분 등의 간격으로 점차 큐브를 처리하는 기법에 대해 설명합니다. 캐시 플러시Analysis Services는 로컬 캐시와 서버 캐시를 사용하여 쿼리를 확인한다는 점을 유념하십시오. 적은 대기 시간 응용 프로그램에서는 캐시로 인해 쿼리 결과가 일관성을 잃을 수 있습니다. 두 개의 쿼리가 집계 수준과 세부 수준에서 각각 동시에 실행된다는 전제 하에 집계 쿼리는 로컬 캐시나 서버 캐시에서 응답되지만 세부 쿼리는 RDBMS에서 확인되어야 한다고 가정해 봅시다. 이 경우 새 트랜잭션은 세부 쿼리를 통해 선택되고 세부 데이터의 집계는 캐시에서 확인된 집계 쿼리와 일치하지 않을 수 있습니다. 캐싱을 해제하는 방법이 없으므로 캐시를 자주 플러시해야 합니다. 앞부분의 "Analysis Services에서 지원하지 않는 기능" 절에서 설명한 대로 Teradata Database의 경우에는 자동화된 실시간 OLAP 기능이 지원되지 않습니다. 이 기능은 SQL Server 2000 관계형 데이터베이스에서 작성된 큐브에만 적용되고 관계형 서버와 분석 서버 간의 통신을 사용하여 캐시를 플러시합니다. 캐시는 어렵지 않게 플러시할 수 있습니다. Analysis Services 성능 가이드의 부록 C에서 설명한 대로 VBscript CacheFlusher.vbs를 사용할 수 있습니다. CacheFlusher.vbs는 분석 서버에서 실행해야 합니다. 서버 캐시를 플러시하면 클라이언트쪽 캐시에 해당 캐시를 비우라는 메시지가 자동으로 전송됩니다. 분석 서버에서 CacheFlusher.vbs를 N초마다 실행하는 일정을 잡을 수 있습니다. 그렇지 않고 Teradata 데이터 웨어하우스를 모니터링하다가 행이 삽입되거나 업데이트될 때 VBscript를 트리거하는 응용 프로그램을 작성할 수도 있습니다. 적은 대기 시간 환경에서는 캐시의 효과가 없어지기 때문에 쿼리 성능이 항상 저하됩니다. MOLAP 처리 성능 개선Analysis Services 성능 가이드에서는 MOLAP 큐브 처리 성능을 개선하는 방법에 대해 많은 권장 사항을 제공합니다. 일반적으로 Teradata Database에서 작성된 큐브의 경우에는 이러한 권장 사항을 모두 따라야 합니다. Teradata MOLAP 구현의 가장 중요한 차이는 병렬 처리의 중요성과 권장하는 병렬도입니다. 이 백서 앞부분에서 설명한 대로 MOLAP 파티션 처리의 병목은 Teradata Database와 Analysis Services 간의 통신에서 발생할 가능성이 가장 높습니다. 이 통신 채널이 제약을 받을 때는 다른 Analysis Services 기술 문서에서 일반적으로 권장하는 것보다 많은 파티션을 병렬로 처리하는 것이 이치에 맞습니다. 항상 자신의 고유한 환경에서 병렬 처리를 테스트하여 가장 좋은 성능을 찾아야 합니다. Analysis Services 팩트 및 집계 처리가 게이팅 계수인 경우가 일반적인데, 대부분의 기술 문서에서는 파티션마다 두 개의 CPU를 전용으로 지정할 것을 권장합니다. 대역폭이 제약을 받는 경우에는 CPU마다 하나 이상의 파티션을 처리하여 보다 많은 파티션을 병렬로 처리할 수 있으므로 성능이 개선됩니다. 네 개의 700MHz 프로세서를 탑재한 서버가 설치된 단순 실험 환경에서 각각 160,000개의 행(총 1.6M의 행)과 30개의 MOLAP 집계가 있고 두 개의 노드로 이루어진 Teradata Database를 원본으로 사용하는 10개의 파티션에 대한 병렬 처리 성능이 테스트되었습니다. 이 경우 이 분석 서버에서 네 개의 파티션을 병렬로 처리하는 때의 성능이 가장 좋았습니다. 즉, 직렬로 처리할 때보다 성능이 세 배나 좋았습니다. 시스템에서 얻은 가장 빠른 처리 속도는 300,000개 행/분(읽기, 리프 팩트 쓰기 및 집계 계산/쓰기 포함)이었습니다. 시스템은 통신 채널의 제약을 받았습니다. MOLAP 처리 성능은 가끔씩 큐브 전체를 새로 고칠 때의 가장 큰 관심사입니다. 300,000개 행/분(읽기, 리프 팩트 쓰기 및 집계 계산/쓰기 포함)의 병렬 처리 속도는 많은 BI(비즈니스 인텔리전스) 응용 프로그램에서 받아들일 수 있는 일 단위 또는 주 단위 증분 처리 속도입니다. 파티션을 처리하는 동안 큐브의 사전 업데이트 이미지를 쿼리에 사용할 수 있습니다. MOLAP 저장소는 가장 안정된 쿼리 성능을 제공합니다. Teradata Database에서 작성된 Analysis Services MOLAP 큐브는 파티션을 병렬로 처리합니다. 자세한 내용은 Analysis Services 성능 가이드 디자인 고려 사항 요약Teradata Database 위에 Analysis Services 데이터베이스를 구현할 때의 가장 큰 기술 문제는 데이터를 저장할 방법과 위치입니다. 아래에 가장 유용한 세 가지 옵션이 요약되어 있습니다. ROLAP, Analysis Services 집계 없음, Aggregate Join 인덱스 사용: 이 구성은 대부분의 사용자 쿼리에 대해 탁월한 쿼리 성능을 제공하며 적은 대기 시간 응용 프로그램에 가장 적합합니다. 테이블에 Aggregate Join 인덱스가 있으면 데이터 로딩 시나리오를 주의 깊게 디자인해야 합니다. ROLAP, Analysis Services 집계 없음, Aggregate Join 인덱스 없음: 이 구성은 대부분의 사용자 쿼리에 대해 양호한 쿼리 성능을 제공하며 매우 적은 대기 시간 응용 프로그램에 가장 적합합니다. MOLAP: MOLAP 구성은 사용자 쿼리에 대해 가장 일관된 고성능 저장소 모드를 제공합니다. 하지만 통신 대역폭이 제약을 받는 상황에서는 MOLAP 큐브를 처리하는 데 필요한 시간을 받아들이기가 곤란할 수 있습니다. 특히 큐브가 생산된 후 해당 큐브 전체를 다시 처리해야 할 경우에 그렇습니다. MOLAP 저장소는 1) 큐브 증분 처리 시간이 시스템 요구 사항을 충족할 때와 2) 리소스 분할 시나리오가 수용되어야 할 때 사용하는 것이 좋습니다. 통신 대역폭이 제약을 받는 시스템에서 큐브 구조를 무효화하는 차원 변경 사항이 발생하면 많은 시간을 들여서 MOLAP 파티션을 다시 처리해야 합니다. 같은 차원 변경 사항이 발생해도 ROLAP 파티션이 다시 처리되지만, Teradata Database의 해당 파티션이 집계를 0으로 설정한 채로 구현되기 때문에 처리가 빠르게 발생합니다. 다시 처리를 트리거하는 차원 변경 사항의 종류에 대한 자세한 내용은 Analysis Services 성능 가이드 Teradata Database에는 세부 데이터를, Analysis Services 다차원 구조에는 집계를 보관하는 HOLAP 구성은 MOLAP에 대해 거의 권장되지 않습니다.
Analysis Services와 Teradata Database는 세계적 수준의 분석 환경을 만드는 데 있어서 매우 상호 보완적이며 매우 유연하게 솔루션을 구현하는 방법을 제공하여 사용자 요구 사항에 대해 잘 이해하고 있는 구현자가 가장 적절한 방법으로 최고의 솔루션을 작성할 수 있도록 합니다.
Microsoft SQL Server 2000 온라인 설명서 Microsoft SQL Server 2000 Resource Kit http://www.info.ncr.com
최종 수정일 : 2003년 11월 13일 | | |||||||||||||||||||||||||||||||||||||||
소개
항목에서는 이러한 기능 중 여러 버전의 SQL Server 2000에서 지원하는 기능을 지정합니다. 이 중 많은 기능은 SQL Server 2000 Enterprise Edition과 Developer Edition에서만 사용할 수 있습니다. 특히 사용자 정의 파티션은 Standard Edition에서 사용할 수 없습니다. 분할은 이 백서 뒷부분에 설명한 대로 Teradata Database를 사용하여 대규모 Analysis Services 데이터베이스를 성공적으로 작성하고 구축하는 데 필요한 핵심 요소입니다. Enterprise Edition을 사용하는 것이 좋습니다.
