Len Wyatt Microsoft Corporation 2002년 10월 요약: 이 문서는 Microsoft SQL Server Accelerator for BI (BI Accelerator)로 구축된 기업 인텔리전스 (BI) 시스템에서 수행된 다양한 성능 실험에 대해 설명하고 있습니다. 이 문서는 실험 결과를 기반으로 이와 유사한 시스템에 대한 권장사항을 제시합니다. 또한, 이 문서는 고객의 구현을 위한 성능 또는 시스템 사이징 실험 수행 방법도 제시합니다. 시스템의 구축을 위해 BI Accelerator가 사용되었는지 여부에 상관 없이 이 문서가 제공하는 여러 결과와 권장사항은 Microsoft 도구를 사용하는 다른 BI 시스템에도 적용될 수 있습니다.
| 개요 |  |  |
기업이 의사결정을 위해 운영 체제의 데이터를 사용하는 것이 기업 인텔리전스 (BI)입니다. 운영 체제는 그 산업 부문에 따라 명령 입력, 인벤터리 관리, 재무 계정 추적, 항공권 예약 등의 작업을 제공합니다. BI 시스템은 운영 체제로부터 데이터를 가져와 사용자가 이전에는 알지 못했던 사업, 고객, 작업 또는 제품에 대한 정보를 활용할 수 있도록 합니다. 일반적으로 기업의 운영 체제는 기업 인텔리전스를 적절하게 제공하지 않기 때문에, 우리는 “운영 체제에서 데이터를 가져온다”고 합니다. 보통 운영 체제의 데이터는 Extract, transform, Load (ETL) 기능을 사용함으로써 BI 작업을 위해 구성되고 최적화된 별도의 데이터베이스에 복사됩니다. 이러한 데이터베이스 형식을 데이터 저장소 또는 데이터 마트라고 부릅니다. 업계에서는 데이터 저장소와 데이터 마트를 구축하고 지원하는 것에 중점을 두고 개발해 왔습니다. 이들을 구축하는 팀은 풍부한 기술적인 경험뿐만 아니라 해박한 사업 기술도 확보하고 있어야만 합니다. 이러한 기술을 보유하고 있는 팀은 이러한 팀을 구축하고 수 많은 고객에게 배포하는 능력을 확보하고 있는 컨설팅 조직에서 쉽게 찾을 수 있지만, 대부분의 경우 BI 시스템의 설계, 구축 및 배포를 위해서는 많은 시간이 소요됩니다. Microsoft SQL Server Accelerator for Business Intelligence (BI Accelerator)는 이러한 숙련된 팀이 BI 어플리케이션을 훨씬 신속하게 구축할 수 있도록 하는 도구입니다. BI Accelerator는 사업적인 가치는 적지만 시스템의 올바른 작동을 위해서는 매우 중요한 세부적인 스키마 설계의 구축과 복잡한 ETL 작업을 자동화합니다. 지금까지 검증된 사항에서 알 수 있듯이 BI Accelerator는 필요한 기간을 세 달이나 네 달까지 단축할 수 있습니다. 이러한 시간 단축은 개발자가 BI 데이터 모델의 모든 요소를 한 장소에서 설계할 수 있도록 하는 Microsoft Excel 문서인 Analytics Builder Workbook과 데이터 모델을 구현하기 위해 필요한 데이터베이스와 ETL 작업을 구축하는 Analytics Builder 유틸리티로 인해 가능한 것입니다. 이 문서는 아래의 질문들을 다루고 있습니다. - BI Accelerator로 어플리케이션을 구축하는 경우, 어떠한 하드웨어 성능을 기대할 수 있습니까?
- 사이트는 어떠한 설정을 사용해야 하며, 최적의 성능을 얻기 위해 어떠한 지침을 준수해야 합니까?
- 사이트는 새로운 시스템을 계획할 때 어떠한 점을 고려해야 합니까?
BI Accelerator는 여러 다양한 디자인 구축에 사용될 수 있기 때문에, 사용 가능한 모든 시스템에 대한 특성을 제시할 수는 없습니다. 이것은 마치 “이 컴파일러로 구축한 프로그램은 얼마나 빠릅니까?”라고 질문하는 것과 같습니다. 분명히 이것은 컴파일되는 프로그램에 의해 영향을 받습니다. 비록 상황이 이렇다고 하더라도 BI 시스템의 가장 중요한 성능 요소에 대해 살펴보도록 하겠습니다. 어떤 의미에서, 이 문서는 BI Accelerator와 함께 제공되는 문서의 확장 문서라고 할 수 있습니다. 이 문서는 BI Accelerator가 출시될 당시에는 제공되지 않았던 성능 관련 권장사항과 측정 결과를 포함하고 있습니다. 마지막으로 이 문서를 한 단어로 설명하는 것은 불가능합니다. 이 문서는 모든 구성에 대한 설명을 제공하는 포괄적인 문서가 아니며, 배포를 위해 시스템을 정의할 수 있도록 하는 특정 구성 지침을 제공하지도 않습니다. 이 문서는 배포 계획, 구성 조종 및 위험 방지에 유용하게 사용되는 일반 정보를 제공하고자 합니다. 이 문서에서 제공되는 정보와 조언은 최종적인 것으로 받아들이지 말고 직설적으로 받아들여야 합니다. 이 문서를 최대로 활용하기 위해서는 BI의 개념과 BI Accelerator를 숙지하고 있어야 합니다. 만일 BI에 익숙하지 않다면, 기업 인텔리전스: 보다 신속한 의사 결정 (Microsoft, 2002)이 이 분야에 대한 훌륭한 개요를 제공할 것입니다. 보다 기술적인 정보는 Data Warehouse Lifecycle Toolkit (John Wiley & Sons, 1998)에서 얻을 수 있습니다. BI Accelerator에 대한 추가 내용은, http://www.microsoft.com/korea/solutions/bi/에서 개요를 읽고 반드시 BI Accelerator를 다운로드한 다음 참고 문서를 참조하십시오. BI Accelerator에서 제공되는 이 문서는 BI 어플리케이션의 설계, 배포 및 유지관리에 대한 섹션을 제공합니다.
| BI 시스템의 성능 측정 | | |
BI 시스템의 경우에는 다음 두 가지의 주요 측정 사항이 있습니다. 사용자 쿼리를 위해 준비된 데이터의 속도, 허용된 응답 시간 내에 쿼리를 동시 수행할 수 있는 사용자의 수. 업데이트 횟수BI는 데이터를 운영 체제에서 BI 시스템 (데이터 저장소, 데이터 마트 또는 의사 결정 지원 시스템)으로 반드시 이동시키도록 합니다. 이 데이터는 기업이 쿼리할 수 있는 별도의 사본을 확보할 수 있도록 하기 위해만 이동되는 것이 아니며, 데이터는 가용성과 성능상의 이유로 ETL 작업을 통해 별 모양 표시 또는 눈 모양 표시가 있는 스키마와 함께 데이터베이스에 복사됩니다. ETL 작업은 많은 양의 데이터를 처리할 수 있으며, 대부분의 경우 기업은 다른 작업에 최소한의 영향만을 미치기 위해 시스템이 사용되지 않는 시간에 이 작업들을 수행합니다. 이는 매일 (매주 등) 업데이트가 주어진 시간 내에 수행될 수 있는가? 라는 일반적인 운영상의 질문을 제시합니다. 이 질문에 대한 답변을 얻기 위해서는 시스템의 업데이트 횟수를 측정해야 합니다. 중요도에 있어서 팩트 테이블은 디멘션(dimension) 테이블보다 큰 비중을 차지하기 때문에, 이 문서에서는 매 시간 업데이트되는 팩트 테이블 열의 개수 별로 업데이트 횟수를 측정합니다. 활성 사용자 세션우리는 사용자가 쿼리를 실행할 수 있도록 하기 위해 BI 시스템을 구축했습니다. 쿼리 성능을 고려하는 방법으로는 여러 가지가 있습니다. TPC-C와 같은 OLTC 벤치마크는 많은 양의 단순 쿼리가 처리될 때의 횟수를 조사하여 초당 쿼리 수를 측정하였습니다. 하지만 이 벤치마크는 BI 시스템의 요구를 충족시키지는 못합니다. BI 쿼리는 보다 복잡하고, 보다 많은 데이터를 처리하며, 읽기전용입니다. 게다가, 수 천명의 사용자를 지원하는 배포가 증가한다고 할지라도 일반 BI 시스템은 OLTP 시스템보다 적은 수의 사용자 만을 지원합니다. 비록 BI 쿼리가 보다 크고 복잡하다고는 하지만, 사용자가 데이터를 보다 잘 탐색할 수 있도록 하려면 짧은 시간 (되도록이면 1초 이내) 내에 수행되어야만 합니다. 응답 시간은 로드되는 BI 시스템의 성능을 측정하는 작업에 있어서 매우 중요한 요소입니다. 많은 IT 기업이 사용자들과 서비스 수준 계약을 맺는데 여기엔 평균 응답 시간이 정해진 임계값 보다 작아야 된다고 명시되어 있습니다. 사용자는 쿼리를 제출한 후, 일단 결과를 판단한 다음, 다른 쿼리를 제출하는 경향이 있습니다. 쿼리 간의 시간 (“씽크 타임”)은 쿼리가 사용자 세션으로부터 도착하는 횟수를 제한합니다. 이는 사용자가 주요 쿼리 성능 메트릭과 같이 응답 시간 요구사항에 적합하도록 시스템이 지원할 수 있는 동시 활성 사용자 세션의 수를 설정할 수 있도록 합니다. 초당 쿼리와 같이 간단한 메트릭을 고려한다면, 동시 세션의 측정은 보다 유용하게 사용될 수 있습니다. 그러면, 어떤 “씽크 타임”을 사용해야 합니까? 일부 사용자는 수 초마다 쿼리를 제출하지만, 다른 사용자들은 다른 용무를 보기 위해 세션을 활용하지 않습니다. 이로써 평균 씽크 타임이 매우 길어지게 됩니다. 이 문서에서는 30초의 평균 씽크 타임을 사용하였습니다. 이 시간은 사용자의 시스템 사용이 많은 경우에는 길게 느껴질 수도 있지만, 대기 상태에 있는 세션을 고려해본다면 그리 길지 않은 시간입니다. 쿼리 성능의 측정은 작업 로드를 위해 선택된 실제 쿼리 수에 의해 큰 영향을 받습니다. 이 성능 실험 또는 다른 성능 실험에서 보고되는 쿼리의 수는 실제 배포에서 사용되는 수보다 많거나 적을 수 있습니다. 따라서 대규모 배포의 경우에는 사이트의 특성에 적합한 평가를 수행하는 것이 좋습니다. 이러한 테스트 수행 방법은 이 문서의 마지막 부분에서 다루고 있습니다.
| About BI Accelerator | | |
앞에서 언급한 바와 같이 이 문서는 BI Accelerator 참고 문서를 대신하기 위해 작성된 것이 아닙니다. 이는 이 문서에서 설명하고 있는 실험에 대한 이해를 돕는 일부 특징들을 강조하기 위한 것입니다. Analytics Builder 유틸리티가 실행되면, 다음과 같은 세 개의 데이터베이스가 만들어집니다. - Staging 데이터베이스는 운영 체제로부터 들어오는 데이터가 Subject Matter 데이터베이스에 들어가기 전에 잠시 대기하는 장소를 제공합니다. 사이트는 이 데이터베이스를 채우기 위해 반드시 ETL 모듈을 개발하거나 구입해야 합니다. 데이터가 Subject Matter 데이터베이스에 들어가면, Staging 데이터베이스에서 삭제됩니다. Staging 데이터베이스는 항상 Subject Matter 데이터베이스와 동일한 서버에 들어있게 됩니다.
- Subject Matter 데이터베이스는 데이터를 위한 장기 저장소입니다. Subject Matter 데이터베이스의 테이블과 열은 Analytics Builder Workbook에 정의된 바와 같이 구축됩니다. Subject Matter 데이터베이스는 스노우플레이크 스키마를 가지고 있는데 이는 각 디멘션의 모든 수준이 자체 수준 테이블을 가지고 있어서 관계형 무결성(relational integrity)을 실시하는데 도움이 됩니다. Subject Matter 데이터베이스의 디멘션 구성원은 할당된 대리 키이며 이는 운영 체제가 할당한 비즈니스 키(또는 코드)와는 다른 것입니다. 팩트 테이블의 모든 열은 디멘션 내에도 해당 키를 가지고 있으며, 이 역시 테이블의 제약 조건(의존성)에 의해 강제적으로 이루어집니다.
- Analysis 데이터베이스는 Analysis Services 큐브를 통해 빠른 사용자 쿼리를 지원하고 계산 작업과 Analytics Builder Workbook에 정의되어 있는 명명된 모음을 구현하도록 구성되었습니다. 이 데이터베이스의 정의는 수신되는 데이터 소스인 Subject Matter 데이터베이스와 밀접하게 연결되어 있습니다. Analysis 데이터베이스는 Subject Matter 데이터베이스와 동일한 서버에 위치할 수도 있으며, 위치하지 않을 수도 있습니다.
Analytics Builder 유틸리티도 여러 개의 Data transformation Services (DTS) 패키지를 생성하는데 이는 사용자 쿼리를 위해 데이터를 준비하는 ETL 작업을 관리합니다. 대부분의 패키지들은 두 개의 최고 수준 패키지인 Master Import와 Master Update에 의해 제어됩니다. - Master Import는 데이터를 플랫 파일로부터 Staging 데이터베이스로 가져오는 작업을 수행하는데 이는 엄청난 입력 작업입니다. 우리는 Staging 데이터베이스를 배치할 사용자 지정 패키지를 구축할 때, 대부분의 사이트가 Master Import를 예제로 사용할 것이라 예상하고 있습니다.
- Master Update는 데이터를 Staging 데이터베이스로부터 Subject Matter 데이터베이스와 Analysis Services 데이터베이스로 가져오는 패키지를 제어합니다. ETL 프로세스의 이 부분에는 오류 점검, 대리 키 지정, 기록 추적, 큐브 프로세싱 및 파티션 관리와 같은 작업이 포함됩니다. Master Update와 그 하위 패키지는 사용자 쿼리를 위해 데이터를 준비하는 여러 작업을 수행하기 때문에, 이 문서는 먼저 Master Update의 성능에 초점을 맞추고 있습니다.
BI Accelerator는 Microsoft의 BI Practices 팀이 일반적으로 추천하는 여러 가지 최상의 구현 방법을 제공합니다. 그래서, 특정 기능은 (긍정적이건 부정적이건)기본적으로 해당 성능과 함께 구축됩니다. 예를 들어, 관리를 돕기 위해 Analysis Services 큐브를 파티셔닝하고 동일한 방법으로 팩트 테이블을 파티셔닝 하는 것이 권장됩니다. 파티셔닝은 프로세싱과 쿼리 성능 모두에 도움이 됩니다. 과거의 파티셔닝은 관련 데이터베이스, Analysis Services 및 데이터의 흐름을 관리하는 DTS 패키지에 대해 주의해야 하는 구현이 힘든 작업이었습니다. Analytics Builder Workbook를 이용하여 큐브의 Partition by Months 속성을 trUE로 설정할 때 BI Accelerator는 일괄된 방법으로 이를 처리합니다. 시간 별로 파티셔닝하는 대규모의 사이트의 경우, 이것은 큰 이점이 됩니다. 반면, BI Accelerator는 비록 Analytics Services가 다른 디멘션의 파티셔닝 구현을 완벽하게 지원한다고 할지라도 현재 이것을 지원하지 않습니다. 성능에 영향을 주는 다른 디자인 구현은 다음과 같습니다. - 인덱스와 제약 조건은 데이터가 로드되기 전에 Subject Matter 데이터베이스 테이블에 배치됩니다.
- 인덱스는 팩트 테이블에서 유지 관리되지 않습니다. 사용자 쿼리가 관련 테이블이 아닌 큐브로 보내지고 Subject Matter 데이터베이스의 주 목적이 Analysis Services에 제공할 명확하고 일관된 데이터 세트를 유지 관리하는 것이기 때문에, 인덱스가 필요하지 않습니다. 그 결과, 팩트 테이블은 매우 빠르게 로드되어 공간이 대폭 절약됩니다.
- Master Update와 그 하위 패키지는 광범위한 데이터 확인 작업을 실시합니다. 이 설정을 비활성화할 수도 있지만, 일반적으로 사이트에서는 이를 활성화 하는 것이 좋습니다. 추가 정보는 이 문서의 뒷 부분에 나오는 “오류 검사 활성화” 섹션을 참조하십시오.
- Subject Matter 데이터베이스의 팩트 테이블은 월 별로 파티셔닝 할 수 있으며, 해당 큐브 파티션은 원칙적으로 병렬 처리가 가능합니다. Master Update는 이러한 수준의 병렬 처리를 구현하지 않습니다. 파티션 수준의 병렬 처리는 로컬 사이트의 사용자 정의로 설정할 수 있습니다.
- BI Accelerator는 얼마나 많은 양의 데이터가 디멘션과 팩트 테이블에 로드 되는지에 대한 정보는 가지고 있지 않습니다. 또한, 구성원의 수나 팩트 테이블의 개수를 알지 못한 상태에서 Analysis Services가 큐브에 대한 집계를 설계하도록 할 수는 없습니다. Partition Aggregation 유틸리티는 이 작업을 지원하기 위해 제공되며 이는 주로 데이터가 로드된 다음에 수행됩니다.
| 하드웨어와 소프트웨어 구성, 테스트 데이터 | | |
이 섹션은 하드웨어와 소프트웨어 구성 그리고 테스트가 실시될 때 사용되었던 예제 데이터에 대해 설명합니다. BI Accelerator목적이 신속한 사용자 지정 배포인 BI Accelerator는 두 개의 예제 스키마와 함께 제공됩니다. 하나는 Sales and Marketing Analytics (SMA)을 위한 것이며 다른 하나는 Retail Analytics (RA)를 위한 것입니다. 이 문서의 내용은 SMA 스키마를 기반으로 하지만, 아래의 내용과 같이 약간의 차이가 있습니다. - 추가 구성원 속성이 Customers 디멘션에 추가되었습니다. Unisys Corporation은 이 스키마를 위한 다양한 크기의 데이터세트를 구축할 때 사용하였던 데이터 생성기에 또 다른 속성을 추가하여 제공하였습니다. 이 미묘한 차이는 이 문서에서 설명하고 있는 실험에 아무런 영향도 주지 않습니다.
- 명명된 모음인 상위 5명의 고객들(Top 5 Customers)은 Sales 큐브에서 제거됐습니다. 그 이유는 이 문서의 뒷 부분에 나오는 “쿼리 성능 테스트” 섹션에서 설명됩니다.
- Enable Aggregations 속성은 모든 큐브 내에 있는 모든 수준의 Time 디멘션에 대해 Yes(예)로 설정되어 있습니다. BI Accelerator 버전1.0을 사용하는 사이트의 경우엔 Yes로 변경해주는 것이 좋습니다. 버전 1.1에는 이렇게 변경되어 있습니다.
SMA 스키마는 여러 개의 가상 디멘션의 기반이 되는 Time 디멘션과 다양한 멀티 레벨 디멘션(Sales Force, Product, Geography, Customer 및 Campaigns)을 가지고 있습니다. 게다가, 이 스키마에는 하나의 수준을 포함하고 있는 다음과 같은 다양한 플랫 디멘션이 들어있습니다. Sales Type, Order Type, Order Status, Forecast Scenario, Quota Version, Load Quality, Customer Status. 일곱 개의 물리 큐브와 여섯 개의 가상 큐브가 이 디멘션을 기반으로 구축됩니다. 이들 물리 큐브로는 Sales, Order, Backlog, Forecast, Quota, Mktg Campaign 및 Campaign Leads가 있으며, 가상 큐브로는 Forecast and Sales, Orders and Backlog, Orders and Sales, Sales Force Performance, Mktg Campaign Analyses, Sales vs Forecast 및 Quota가 있습니다. 모든 테스트에는 한 가지 모음의 디멘션 데이터가 사용되었습니다. 가장 큰 디멘션은 백만 명의 구성원을 갖고 있는 Customer 디멘션입니다. 테스트 데이터이 문서가 설명하고 있는 테스트를 수행하는데 필요한 Sales, Orders 및 Backlog 팩트 테이블에 사용되는 데이터를 구축하기 위해 Unisys 데이터 생성기가 사용되었습니다. 천만 열 데이터베이스, 일억 열 데이터베이스, 십억 열 데이터베이스 이들 세 개의 데이터세트가 사용되었습니다. 아래의 표는 이들 세 데이터베이스 각각의 팩트 테이블 별 열 개수를 보여주고 있습니다. | 테이블 이름 | 천만 열 데이터베이스 | 일억 열 데이터베이스 | 십억 열 데이터베이스 | | Fact_Backlog | 3,850,466 | 38,146,462 | 382,756,178 | | Fact_Orders | 3,265,839 | 32,369,806 | 324,823,696 | | Fact_Sales | 2,955,561 | 29,291,120 | 293,907,214 | | 총계 | 10,071,866 | 99,807,388 | 1,001,487,088 |
쿼리 시간을 위해서는 혼합된 쿼리가 사용되었습니다. 23개의 템플릿 쿼리로부터 오백 개의 사용자 세션이 만들어 졌습니다. 각각의 사용자 세션은 각 템플릿의 쿼리를 일부 변경하여 사용하였기 때문에 여러 사용자의 쿼리는 각기 다릅니다. 이것은 Analysis Services가 그 쿼리 결과 캐시의 모든 쿼리에 응답하는 것을 방지하기 위한 것입니다. 이 캐시는 일반 작업에 있어 큰 이점으로 작용되지만, 성능 데이터를 수집하는 경우에는 이 캐시를 사용하지 않는 방법을 모색해야 하며 이렇게 한다면, 매우 빠른 응답 시간을 얻을 수 있을 것입니다. 아래의 두 예제 쿼리는 동일한 템플릿에서 구축된 것이며, 각기 다른 사용자 세션에 표시됩니다. 각각의 쿼리는 Sales 큐브로부터 각기 다른 측정치를 선택하며, 모든 업계에 대한 측정값과 몇 개월 동안의 측정값을 보여줍니다. SELECT { [Time].[Standard].[Quarter].[Q1 - 2000] } ON COLUMNS ,
{ [Customer].[Direct].[Industry].members } ON ROWS
FROM [Sales]
WHERE ( [Measures].[Actual Discount %] )
SELECT { [Time].[Standard].[Quarter].[Last Year]} ON COLUMNS ,
{ [Customer].[Direct].[Industry].members } ON ROWS
FROM [Sales]
WHERE ( [Measures].[Actual Avg Gross Margin] )
비록 이 쿼리들이 유사해보일지라도, 이들은 각기 다른 분기(quarters)와 측정치를 참조합니다. 하나의 쿼리가 특정 명명된 분기(quarter)를 참조하는 동안, 두 번째 쿼리는 현재 분기와 동일한 작년의 분기의 산출을 참조하게 된다는 점을 기억하십시오. 23 개의 각 템플릿에는 서버가 이전 캐시 결과를 기반으로 하여 모든 쿼리에 대해 응답하는 것을 방지하는 변수(variations)가 포함되어 있습니다. 이 쿼리들은 폭넓은 디멘션 수준과 Multidimensional Expressions (MDX) 기능을 처리합니다. 이들은 사용자가 SMA 모델에 대해 질문할 수 있는 실제 쿼리를 반영하도록 되어 있습니다. 쿼리에 대한 추가 예제는, 부록 A를 참조하십시오. 하드웨어이러한 성능 연구에 사용되는 한쌍으로 설치된 4-way 컴퓨터이므로 한 대의 서버는 Subject Matter와 Staging 데이터베이스를 지원하고 DTS 패키지를 실행하며, 다른 한대의 서버는 Analysis 서버를 실행합니다. 이 구성을 선택한 두 가지 이유는 다음과 같습니다. - 첫 번째, 이 구성은 쿼리 지원 작업에서 대부분의 데이터 준비 작업을 분리하기 때문에 사용자 쿼리에 영향을 주지 않고도 Subject Matter 데이터베이스에서 새로운 데이터를 준비할 수 있습니다. 이 설정은 실제 배포 시나리오에 적합합니다.
- 두 번째, SQL Server 관련 엔진과 Analysis Services에 의해 사용되는 리소스를 보다 간편하게 측정할 수 있습니다.
RDBMS 서버는 네 개의 700 MHz CPU, 8 GB 메모리, StorageWorks 컨트롤러를 사용하는 880 GB의 RAID-5 디스크 공간을 가지고 있는 Compaq 5800이 사용되었습니다. Analysis 서버는 700 MHz CPU, 4 GB 메모리, StorageWorks 컨트롤러를 사용하는 406 GB의 RAID-5 디스크 공간을 가지고 있는 Compaq 5800이 사용되었습니다. 이 상태로도 유용한 시스템이지만, 프로세서의 속도는 우리가 이 시스템을 구축한 이후 더욱 더 발전을 거듭하였습니다. 오늘날, 시스템은 이 연구에 사용된 CPU 보다 두 배나 빠른 CPU 속도를 갖게 되었습니다. 게다가, 이들 네 클라이언트 컴퓨터는 쿼리를 Analysis 서버에 등록하기 위해 사용됩니다. 이 컴퓨터들도 각각 125 개의 클라이언트 세션을 실행하는 네 개의 CPU 컴퓨터입니다. 쿼리 성능 테스트를 위해 클라이언트 컴퓨터는 시스템의 병목현상을 야기시켜선 안됩니다. 소프트웨어컴퓨터의 소프트웨어 구성은 BI Accelerator 참고 문서의 요구사양에 적합하게 구성되었습니다. 간략히 말하자면, 컴퓨터는 Microsoft Windows 2000 Enterprise Edition, SQL Server 2000 Enterprise Edition with Service Pack 2 (SP2) 및 Excel 2002를 실행하고 있었습니다. SQL Server 데이터베이스는 RDBMS 서버에 설치되었으며, SQL 서버와 Analysis Services는 모두 Analysis 서버에 설치되었습니다. Analysis Services 저장소는 BI Accelerator 참고 문서에서 권장된 바와 같이 SQL Server로 통합되었습니다. RDBMS 설치에 있어서 데이터베이스 로그는 일반 권장사항대로 데이터베이스와는 다른 별도의 단일 디스크 드라이브에 위치하게 됩니다. 모든 기타 구성 설정과 옵션에는 고유한 기본값이 사용되었습니다. Analysis 서버에서 /3GB 스위치는 3 GB 주소 공간 (기본값은 2GB)으로의 프로세스 액세스를 허용할 수 있도록 운영 체제에 설정되었습니다. Analysis Services 메모리 보존 임계 값도 3 GB로 설정되었습니다. BI Accelerator 구성 참고 문서에 명시된 바와 같이 이 값은 사용자 인터페이스에 설정될 수 없으며 반드시 레지스트리를 통해 설정되어야 합니다. Analysis Services 프로세스 버퍼 크기는 프로세싱 성능을 위해 1 GB로 설정되었습니다. 이 버퍼 크기는 대부분의 사이트에서 필요로 하는 값보다 큽니다. 최적의 크기를 찾기 위한 실험은 실시되지 않았습니다. Analysis Services 설치 시 임시 파일 디렉터리를 별도의 단일 디스크 드라이브에 두었습니다. 이 임시 파일은 산출되는 집계가 할당된 프로세스 버퍼 공간과 맞지 않을 경우, 프로세싱 때 사용됩니다. 그리고 나서 집계는 임시 파일에 스풀링되고, 추가 열의 데이터와 통합되도록 다시 읽혀진 다음, 다른 임시 파일에 기록됩니다. 단일 드라이브는 읽기와 쓰기 작업이 모두 발생되어 검색에 너무 많은 시간을 소요하기 때문에 단일 드라이브 임시 디렉터리를 가지고 있는 이 구성이 정말 유용할 지는 알 수 없습니다. 이것은 프로세스 버퍼가 1 GB 까지 확장되도록 설정함으로써 임시 파일을 필요로 하지 않기 때문에 이 문서에서 설명하는 성능 작업과 아무런 관련이 없습니다. Analysis Services의 경우엔 이러한 임시 파일들을 사용하지 않아도 될 정도로 큰 프로세스 버퍼를 사용하는 것이 좋습니다. 특히, 적합하지 않은 집계 디자인이 사용되고 서버가 오버로드 되는 경우, 높은 수준의 쿼리 동시성을 지원하기 위해서는 Analysis Services를 위해 두 개의 스레드 카운트 설정을 변경해야 합니다. 이 값은 레지스트리 에디터를 사용해 설정되었으며, 사용자 인터페이스를 통해서는 사용할 수 없습니다. PoolProcessThreads는 600으로 설정되었으며, PoolWorkerThreads는 500으로 설정되었습니다. 이 테스트를 위해 사용되는 컴퓨터를 포함해 Microsoft 기업 네트워크 상의 모든 컴퓨터는 안티바이러스 유틸리티를 실행합니다. 이 소프트웨어가 실행 중인 상태에서는 실행을 중지할 수 없습니다. 안티바이러스 소프트웨어로 인해 성능 테스트를 실행하는 동안 일부 문제를 초래했습니다. 이 문제들은 결과에 영향을 끼치지 않는 것으로 보이지만, 데이터에 특정 변형을 초래할 수 있습니다.
| 데이터 준비 성능 테스트 | | |
이 섹션은 사용자가 쿼리를 위해 데이터를 준비할 때 수행해야 하는 작업에 대해 설명합니다. 이러한 작업에는 Master Import, Master Update의 실행과 일반적으로 Master Update에 의해 수행되는 Analysis Services의 프로세싱이 포함됩니다. 디멘션을 준비하는 것이 비록 Master Update가 실행하는 주요 작업이라고 할지라도 일반적으로 디멘션 테이블은 중요도에 따라 팩트 테이블보다 작습니다. 따라서 이 섹션은 팩트 테이블 프로세싱에 중점을 두고 있습니다. 이 섹션에서 보고되는 모든 속도는 별도로 언급되어 있지 않은 경우 팩트 테이블 열을 기반으로 합니다. Master Import는 주로 사이트가 사용자 지정 가져오기 프로세스를 설계하는 템플릿이기 때문에 이 문서는 Master Import의 성능을 설명하는데 많은 부분을 할애하지는 않습니다. 또 다른 한 가지 이유로는 이것이 Master Update와 비교하여 매우 신속하게 실행되며 병목현상을 야기시키지 않는다는 점입니다. 예를 들어 Master Import는 일억 열 데이터베이스에서 Master Update 보다 거의 네 배 정도 빠르게 실행되었습니다. 큐브 프로세싱은 Master Update에 의해 실행되는 작업에 포함되어 있지만, 큐브 프로세싱은 병목현상이 아닙니다. 큐브 프로세싱은 Master Update의 속도보다 두 배 이상 빠르게 실행됩니다. 따라서, Master Update에 의해 실행되는 RDBMS 작업은 매우 신중한 특성화 작업도 할 수 있습니다. 아래의 표는 가져오기, 업데이트 및 큐브 프로세싱 작업 시 시간별로 처리되는 열의 수를 보여주고 있습니다. | 작업 | 시간별로 처리되는 열의 수 | | Import 100 million rows | 95,364,238 | | Update 100 million rows | 22,932,858 | | Process cubes serially | 51,027,640 |
Master Update의 테이블 수준 병렬 계산 Master Update는 병렬 계산으로 디멘션 작업을 수행하고, 디멘션 작업이 완료되면 병렬 계산으로 팩트 테이블 작업을 수행합니다. 여기에서 사용되는 SMA 예제에서 Sales, Orders 및 Backlog 팩트 테이블은 대략 유사한 크기를 갖고 있습니다. 이들은 각 열의 29%, 32% 그리고 38%를 갖고 있습니다. Master Update가 팩트 테이블에서 작업하는 대부분의 시간 동안 이 테이블은 병렬로 처리됩니다. 하지만, 팩트 테이블이 크기에 있어서 충분히 안정되지 않은 경우에는 열에 지정된 하나의 팩트 테이블은 계산을 할 수 있습니까? 이것을 테스트하기 위해 일억 열 데이터베이스가 사용되며, Sales 팩트 테이블의 열 만을 갖고 있는 유사한 데이터베이스가 구축됩니다. 아래의 표는 두 시나리오에서의 Master Update 속도를 보여줍니다. 분명히 이 데이터의 처리에 있어서 병렬 계산은 큰 도움이 되었습니다. | 팩트 테이블의 개수 | 시간별로 처리되는 열의 수 | | 단일 팩트 테이블 | 10,587,084 | | 세 개의 팩트 테이블 | 20,156,775 |
그림 1은 세 개의 팩트 테이블을 병렬로 로드하여 실행하는 경우와 하나의 팩트 테이블을 병렬로 로드하여 실행하는 경우의 CPU 사용을 보여주고 있습니다. 단일 테이블 테스트 시, 작업로드는 단일 프로세서가 병목현상을 초래하지 않으며 처리할 수 있는 것보다 조금 더 컸다는 사실을 명심하십시오 (이것은 네 개의 CPU를 갖고 있는 서버이기 때문에 100% 활용한다는 것은 네 개의 CPU가 모두 사용되고 있다는 것을 의미합니다). 이것은 이 작업이 하나의 CPU만을 전적으로 사용하고 다른 CPU들은 그다지 도움이 되지 않는다는 것을 의미합니다. 여러 테이블이 병렬로 준비되는 경우 더 많은 수의 CPU가 사용됩니다.
브라우저가 인라인 프레임을 지원하지 않는다면, 여기를 클릭하여 별도의 페이지에서 볼 수 있습니다.
그림 1 Master Update가 팩트 테이블을 로드하는 경우의 프로세서 사용 파티셔닝파티셔닝은 Analysis Services를 위해 큰 성능상의 이점을 제공할 수 있으며, BI 데이터의 관리를 보다 쉽게 만듭니다. Partition by Month 속성에서 파티셔닝이 Analytics Builder Workbook의 큐브에 대해 trUE로 설정되어 있다면, 이 Analytics Builder 유틸리티는 파티셔닝을 구현하는 패키지를 구축하고, 각 월별 데이터를 위해 Subject Matter 데이터베이스에 별도의 팩트 테이블을 구축합니다. Master Update가 각 새로운 월별 데이터를 프로세스할 때 팩트 테이블은 그 즉시 구축됩니다. 참조 SQL 데이터 저장소 환경에서의 파티셔닝에 대한 추가 정보는 MSDN사이트에서 제공되는 백서 Microsoft SQL Server 2000 Data Warehouse에서 파티션 사용하기nbsp; 를 참조하십시오. 파티셔닝이 Analysis Services 큐브에 유용하긴 하지만 이는 어떤 파티션 테이블에 어떤 열들이 속해 있는지를 확인하기 위해 Master Update로 하여금 각 파티션별로 Staging 데이터베이스에 있는 팩트 테이블을 한번씩 스캔하도록 하는 추가 작업을 하도록 합니다. 이 추가 작업은 어떤 열이 각 파티션 테이블에 속하게 되는지 정의하기 위한 것입니다. 일반 증분 업데이트와 같이 스캐닝은 단일 파티션에 대한 데이터가 Staging 데이터베이스에 있는 테이블에 포함되어 있는 경우 큰 오버헤드를 발생시키지 않습니다. 하지만, Master Update가 동일한 테이블에 대한 수 개월 동안의 데이터를 갖고 있는 큰 초기 데이터를 처리하는 경우에는 오버헤드가 커지게 됩니다. 일억 열 데이터베이스는 48 개월 동안의 데이터를 포함하고 있기 때문에, 대부분 Staging 데이터베이스의 팩트 테이블이 요구하는 수준을 초과합니다. 이것은 파티셔닝 프로세스에 있어서 최악의 시나리오입니다. 파티션이 사용되는 경우 Master Update가 항상 그 대가를 요구한다고 할지라도 이 대가는 대게 예제에서 설명된 바와 같이 심각한 수준은 아닙니다. 증분 업데이트 시나리오에서 한번의 업데이트는 한 달에 해당하는 데이터를 가지게 됩니다. 따라서 팩트 테이블의 48 패스 대신 단지 하나만 사용하게 됩니다. 아래의 표는 파티셔닝된 데이터와 파티셔닝되지 않은 데이터를 Staging 데이터베이스로부터 Subject Matter로 옮길 때 Master Update가 시간 별로 처리하는 열의 수를 보여주고 있습니다. | 구성 | 시간 별로 처리되는 열의 | | 표준 | 23,523,262 | | 파티션된 구성 | 8,081,715 |
파티셔닝은 큰 이점을 제공하기 때문에, Master Update의 이러한 오버헤드를 해결할 수 있는 다른 방법을 찾기 위해 노력해야 합니다. 성능을 향상시킬 수 있는 한가지 기술은 시간 별로 데이터를 사전 구분하는 것입니다. 아래의 표에 있는 데이터는 천만 열 데이터베이스에서 Master Update를 실행함으로써 얻은 수치이며, 다소 향상된 것을 볼 수 있습니다. | 구성 | 시간 별로 처리되는 열의 수 | | 표준 | 5,966,192 | | 파티션되고 분류된 구성 | 6,325,778 |
다른 방법은 클러스터링된 인덱스를 Master Update가 Subject Matter 데이터베이스의 각 파티션 테이블에 속해 있는 열을 보다 신속하게 선택할 수 있도록 돕는 Staging 데이터베이스의 팩트 테이블에 위치한 시간 키 필드에 추가하는 것입니다. 클러스터링된 인덱스는 Master Import 작업을 다소 더디게 만들지만, 데이터를 사전 분류한다면 그 영향을 최소화할 수 있습니다. 앞에서 언급한 바와 같이 이 사항은 계속 진행되는 증분 업데이트의 경우에는 해당되지 않지만 많은 양의 기록 데이터를 로드하는 경우에는 가장 먼저 고려해야 하는 사항입니다. 이러한 큰 규모의 기록 데이터를 로드하는 경우, 소스 데이터가 월 별로 기록되어 있다면 다른 방법을 사용할 수도 있습니다. 월 별로 Master Import를 실행한 다음, 해당 월의 데이터에 Master Update를 실행함으로써 Master Update가 스캔을 여러 번 수행하지 않아도 되도록 할 수 있습니다. 배치 크기와 오류 확인특정 글로벌 변수 설정을 사용하면, Master Update의 성능을 향상시킬 수 있습니다. Global Variable Configuration 유틸리티를 사용해 구성 모음의 글로벌 변수를 설정할 수도 있고, 이들을 명령줄 인수로서 Master Update에 전송할 수도 있습니다. 글로벌 변수인 giCommitBatchSize는 데이터가 데이터베이스에 발생하는 빈도를 제어함으로써 데이터베이스와 글로벌 변수 giProgressRowCount는 프로그레스가 얼마나 자주 로그에 보고되는지를 결정할 수 있습니다. 기본적으로 이들은 1,000으로 설정되어 있지만, 이 실험에서는 10,000으로 설정되었습니다. gbDontCheckErrors설정은 관계형 무결성(relational integrity) 확인이 수신되는 열에 대해 수행되는지 여부를 확인합니다. 이것은 BI Accelerator가 수행하는 유일한 오류 확인 방법입니다. 하지만, 이것은 모든 열을 확인하기 때문에 성능에 영향을 미치게 됩니다. 기본적으로 Staging 데이터베이스에 위치한 각 팩트 테이블 열의 내츄럴 키 (또는 코드)는 해당 디멘션에 대해 일관성 검사를 수행하게 되며, 잘못된 열은 오류 테이블에 복사됩니다. 이 작업을 수행하지 않는다면, 테이블 조인이 이들을 필터링해서 제거하므로 잘못된 열은 Subject Matter 데이터베이스에 들어가지 못합니다. 하지만 오류 확인은 Browse Batch 유틸리티를 이용하여 잘못된 데이터를 간편하게 찾아내고 오류 테이블을 참조하여 이를 수정할 수 있도록 해줍니다. 수신되는 데이터의 무결함성을 확신할 수 있는 경우에만 오류 확인 설정을 해제할 수 있습니다. gbDontCheckErrors 값이 trUE로 설정되어 있는 경우, 오류 확인을 사용할 수 없게 되며 약간의 시간을 절약할 수 있게 됩니다. 아래의 표는 파티셔닝된 큐브를 갖고 있는 천만 열 데이터베이스에서 이 설정을 사용했을 때 나타나는 결과를 보여주고 있습니다. 다소 규모가 큰 배치 크기를 사용한 이 실험에서는 giCommitBatchSize와 giProgressRowCount가 모두 10,000으로 설정되었다는 점을 기억하십시오. | 설정 | 시간 별로 처리되는 열의 수 | | 없음 | 5,966,192 | | 10 KB로 설정된 배치 크기 | 6,198,347 | | 오류 확인이 꺼진 경우 | 6,562,158 | | 10 KB로 설정된 배치 크기이며 오류 확인이 꺼진 경우 | 6,449,301 |
배치 크기의 증가로 인해 약간의 변경 사항이 생긴데 반해 오류 확인 기능 비활성화로 인해 10%가량 성능이 향상되었습니다. 비록 이들 두 가지 기술을 동시에 사용한다고 할지라도 더 큰 향상을 기대할 수는 없습니다. 배치 크기의 증가가 Master Update에는 많은 영향을 끼치지 않더라도 Master Import에는 매우 큰 영향을 끼친다는 점을 기억하십시오. 비록 Master Import가 충분히 빠르다고 할지라도, 배치 크기의 증가로 더욱 빨라질 수 있습니다. 아래의 표에 명시되어 있는 데이터는 천만 열 데이터베이스에서 Master Import를 실행한 결과를 보여주고 있습니다. | 배치 크기 | 파티셔닝되지 않은 데이터베이스 | 파티셔닝된 데이터베이스 | | 기본값으로 설정된 배치 크기 | 52,023,121 | 70,312,500 | | 10KB로 설정된 배치 크기 | 93,264,249 | 122,448,980 |
사전 할당된 RDBMS 저장소기본적으로 처음에는 Staging 데이터베이스와 Subject Matter 데이터베이스가 각각 50MB 정도로 상당히 작습니다. 이 데이터베이스에 대한 파일들은 일정한 크기로 계속 커져갈 것이고 데이터베이스 관리자는 그에 상응하는 공간을 제공해야만 합니다. 새로운 데이터의 RDBMS 입력 속도를 높이는 일반적인 기술은 이 데이터베이스에 충분한 파일 시스템 저장소를 할당함으로써 일반 작업을 수행하는 동안에는 확장되지 않도록 하는 것입니다. 이는 파티셔닝된 천만 열 데이터베이스에서 테스트되었습니다. 우리는 Master Update를 실행하기 전에 Subject Matter 데이터베이스의 크기를 설정하기 위해 ALTER DATABASE 명령을 사용하였습니다. 아래의 표는 Subject Matter 데이터베이스를 위해 사전 할당된 공간이 있는 경우와 사전 할당된 공간이 없는 경우에서의 Master Update의 처리 속도를 보여주고 있습니다. | 구성 | 시간 별로 처리되는 열의 수 | | 파티셔닝된 구성 | 5,966,192 | | 파티셔닝되고 사전 할당된 공간이 있는 구성 | 6,517,017 |
업데이트 비율과 데이터베이스 크기 이 문서에서 언급되는 데이터 준비 측정값의 대부분은 소규모 (천만 열) 데이터베이스를 기반으로 하였습니다. 소형 데이터세트를 사용하면, 수 분 이내에 구성을 실행할 수 있기 때문에 다양한 실험을 보다 간편하게 실시할 수 있습니다. 하지만, 데이터 세트가 커질수록 처리량이 더욱 더 커진다는 점을 기억하여야 합니다. 아래의 표는 다양한 크기의 데이터베이스에 대한 Master Update 속도를 시간당 열의 개수로 보여주고 있습니다. 대형 데이터베이스를 통해 얻은 성능 부분은 보다 큰 데이터베이스에 있는 많은 열의 평균을 구하는 오버헤드 비용으로 설명될 수 있습니다. 하지만, 이 때 얻은 값은 오버헤드 경비의 평균값보다 훨씬 큽니다. 비록 이러한 이점이 생기는 정확한 이유는 아직 조사되지 않았지만 이 결과는 SQL Server 작업의 자율 조종 기능이 계속 작동되고 있다는 것을 보여주고 있습니다. | 데이터베이스의 크기 | 파티셔닝된 구성 | 표준 | | 10,000,000 열 | 5,966,192 | 20,156,775 | | 100,000,000 열 | 7,973,775 | 22,932,858 | | 1,000,000,000 열 | | 27,161,612 |
집계Analysis Services 큐브에 포함되어 있는 집계의 수와 크기는 큐브 또는 큐브 파티션을 처리하는데 소요되는 시간에 큰 영향을 미칩니다. 집계의 영향을 나머지 Master Update 작업과 구분하여 보기 위해 우리는 집계 디자인을 다양하게 만들었으며 Analysis Manager를 사용하여 큐브를 처리하였습니다 (병렬 계산을 사용하지 않음). 우리는 다음의 세 가지 집계 디자인을 사용하였습니다. No Aggregations (기본값), 10% 성능 강화를 위한 디자인, 사용 기반 최적화를 기반으로 하는 디자인 (우리는 Analysis Manager의 Usage-Based Optimization Wizard를 사용하여 설계하였으며, 이 문서의 뒷 부분에서 권장하는 바와 같이 Partition Aggregation 유틸리티를 사용하여 파티션으로 전파하였습니다). 참조 다음 그림에서는 집계 디자인이 성능에 어떤 영향을 미치는지, No Aggregations, 10% 성능 향상 디자인 및 사용 기반 최적화 디자인을 표시하기 위해 집계 Agg0, Agg10 및 Agg UBO가 어떻게 사용되었는지를 보여주고 있습니다. 그림 2는 다양한 집계 디자인에 대한 처리 비율을 보여주고 있습니다. 이 실험에서 우리는 Backlog, Order 및 Sales 테이블이 차례로 처리되어 있는 파티셔닝된 그리고 파티셔닝 되지 않은 일억개의 열 데이터베이스를 사용하였습니다.
브라우저가 인라인 프레임을 지원하지 않는다면, 여기를 클릭하여 별도의 페이지에서 볼 수 있습니다.
그림 2 시간 당 처리되는 열의 개수 - 다양한 집계 디자인 이 데이터에서는 두 가지 사항을 알 수 있습니다. - 집계의 수가 충분히 커져서 컴퓨팅의 오버헤드가 예비 파티션의 오버헤드를 초과할 때까지는 파티셔닝된 큐브보다 파티셔닝되지 않은 큐브 (단일 파티션)가 보다 신속하게 처리됩니다. 파티션을 사용하는 디자인은 대개 보다 적고 작은 집계를 필요로 합니다. 월별 파티션을 가지고 있는 큐브에서는 시간을 월별 또는 년별로 분할하는 집계가 필요하지 않으며, 각 파티션의 집계는 보다 적은 열을 포함하고 있기 때문에 더욱 작아지게 됩니다. 이것은 그림 2의 10% 성능 향상 디자인의 집계 디자인에서 볼 수 있습니다.
- 사용 기반 최적화의 주 목적은 사용자 쿼리에 가장 유용한 집계를 사전 산출하는 것이지만, 사용자가 사용할 수 있는 결론을 시스템이 산출하지 않아도 된다는 또 다른 장점이 있습니다. 대신, 시스템은 어떤 집계가 유용하고 추가 집계를 산출하지 않는지를 보다 정확하게 확인할 수 있습니다. 이는 사용 기반 최적화 디자인과 10% 성능 향상 디자인을 비교해봄으로써 알 수 있습니다. 사용자 기반 최적화 디자인은 데이터를 훨씬 빠르게 처리합니다. 사용 기반 최적화의 이점은 데이터의 양이 증가함에 따라 증가하며, 사용 기반 최적화 디자인을 성능이 10% 이상 더 높은 디자인과 비교하여 볼 때에도 그 차이가 현저합니다.
Backlog, Orders 및 Sales 테이블이 차례로 처리되는 다양한 크기의 파티셔닝된 큐브에 대한 처리 비율을 보여주고 있는 그림 3에서는 또 다른 흥미로운 사실을 볼 수 있습니다. 큐브의 크기가 증가함에 따라 프로세싱 속도도 증가합니다. 거의 100% 가까이 향상될 때, 이러한 향상은 단지 더 많은 열의 수에 대한 오버헤드를 해결함으로써 얻어진 것이 아니라, 주 원인은 SQL Server의 자율 조정 기능이 실행되고 데이터가 Subject Matter 데이터베이스로부터 보다 신속하게 전달되기 때문일 것입니다. 여기에서 주목해야 할 점은 소형 큐브를 사용해 대형 큐브의 처리 시간을 추측해서는 안 된다는 점입니다. 프로세싱 성능 실험은 작업의 예상 범위에서 실시되어야 하며, 실제 집계 디자인과 최대한 비슷한 추정 값으로 실시되어야만 합니다.
브라우저가 인라인 프레임을 지원하지 않는다면, 여기를 클릭하여 별도의 페이지에서 볼 수 있습니다.
그림 3 시간당 처리되는 열의 수-다양한 크기의 데이터베이스 리소스의 사용BI 시스템 배포를 계획할 때 가장 먼저 고려해야 하는 중요한 리소스는 디스크 저장소 공간입니다. 모든 데이터를 유지하기에 충분한 공간이 필요합니다. 일단 충분한 저장소 공간이 확보되고 난 후, CPU 시간, 메모리 사용, 디스크 I/O 대역폭, 네트워크 I/O 대역폭 등과 같은 다른 리소스를 고려할 수 있습니다. 저장소 요구사양일반적으로 팩트 테이블은 중요도의 우선 법칙에 따라 디멘션 테이블보다 커지기 때문에, 이 섹션에서는 팩트 테이블에 대한 저장소 요구사양을 중점적으로 다룰 것입니다. 아래의 표는 각기 다른 처리 단계에서 동일한 데이터를 사용하기 위해 다양한 위치에서 사용되는 저장소 공간을 보여주고 있습니다. 이 값은 데이터베이스의 크기와 크게 다르지 않지만, 지나치게 많은 집계가 산출되는 경우 Analysis Services 큐브의 크기가 증가합니다. 이 문서에 소개되는 수들은 SMA 스키마를 기반으로 하며, 키의 수와 팩트 테이블의 측정값 및 그들의 데이터 유형이 실제 배포에서는 달라지는 경우엔 증가하거나 감소할 수 있습니다. | 데이터의 위치 | 열 별 바이트 | | 플랫 파일 | 103 | | Staging 데이터베이스 팩트 테이블 | 195 | | Subject Matter 데이터베이스 팩트 테이블 | 142 | | Analysis Services 큐브: Agg0 | 33 | | Analysis Services 큐브: AggUBO | 38 | | Analysis Services 큐브: Agg10 | 65 |
Master Import가 이 데이터를 Staging 데이터베이스에 로드하기 전에 데이터는 플랫 파일에 위치해 있습니다. 플랫 파일은 임시의 저장소 위치입니다. 우리는 사이트가 데이터를 이러한 형식으로 유지하지는 않을 것으로 추정합니다. 일단 데이터가 Staging 데이터베이스에 로드되면, 플랫 파일이 삭제됩니다. Master Import를 자신의 ETL 프로세스로 교체하는 사이트는 데이터를 제공하는 플랫 파일을 필요로 하지 않습니다. 플랫 파일에서 팩트 데이터의 열은 대략 103 바이트를 가지게 됩니다. Master Update 배치 파일이 데이터를 준비하고 이를 Subject Matter 데이터베이스로 옮기도록 실행될 때까지 데이터는 Staging 데이터베이스에 머물게 됩니다. Staging 데이터베이스도 임시의 저장소 위치입니다. 데이터가 성공적으로 Subject Matter 데이터베이스로 옮겨진 다음엔 이 데이터베이스로부터 삭제되어야 합니다. 따라서, 여기에서는 데이터가 반복적으로 생기지 않습니다. Staging 데이터베이스에서 팩트 데이터의 열은 대략 195 바이트를 가지게 됩니다. Subject Matter 데이터베이스로 옮겨진 이후 이 동일한 데이터는 열 별로 약 142 바이트를 가지게 됩니다. 이러한 크기의 차이는 우선적으로 Staging 데이터베이스 팩트 테이블이 문자 필드인 열에 여전히 생산 키 또는 코드를 가지고 있기 때문입니다. 숫자 대체 키가 Subject Matter 데이터베이스에서 교체됨으로써 상당한 공간이 절약됩니다. 어떠한 인덱스도 데이터베이스의 팩트 테이블에 구축되지 않으며 인덱스를 위한 공간도 필요로 하지 않습니다. Subject Matter 데이터베이스는 BI Accelerator로 구축된 시스템의 장기 데이터 보관소입니다. 작은 수의 집계가 저장됨과 동시에 위의 데이터가 Analysis Services 큐브로 처리되면, 이 데이터는 열 별로 40 바이트 보다 작은 크기를 가지게 됩니다. 이러한 공간의 큰 효율성은 Analysis Services가 데이터를 저장하기 위해 실행하는 압축 기능과 사용하는 고유한 인덱스 메커니즘 때문입니다. 10% 성능 향상 디자인에서 설명한 바와 같이 보다 큰 집계가 저장될수록 필요한 공간도 증가하게 됩니다. 이 데이터는 십억 열 데이터베이스를 사용하여 수집되었으며, 이는 이 연구에 가장 큰 집계 모음이 사용되었다는 것을 의미합니다. 사용 기반 최적화 디자인의 저장소 효율성은 이러한 방법을 사용하는 데에 따른 또 다른 논점입니다. CPU 사용앞 부분에서 살펴보았던 그림 1은 여러 팩트 테이블을 병렬로 처리할 때 CPU를 훨씬 많이 사용한다는 것을 보여주고 있으며, 이는 보다 높은 처리량을 산출합니다. 다른 리소스가 병목현상이 되지 않을 경우엔, 보다 새로운 프로세서가 Master Update의 실행 횟수를 더욱 증가시킨다고 볼 수 있습니다. 이 작업을 700 MHz 프로세서에서 실행되었던 것과 비교하면 오늘날의 시스템은 이 작업을 두 배나 빠른 속도로 수행할 수 있게 되었습니다. 특히, 집계를 산출할 때 Analysis 서버의 CPU 사용률이 증가한다고 할지라도, Master Update가 실행되는 경우 RDBMS 서버에서의 작업과 비교하여 볼 때 Analysis 서버의 CPU 사용률은 낮은 편입니다. 이 실험에서와 마찬가지로 RDBMS와 Analysis Services가 각기 다른 서버에 설치되어 있는 경우, 지나치게 많은 집계의 수가 사용되지 않는다면 Analysis 서버는 Master Update가 실행될 때 병목현상을 경험하지는 않습니다. 우수한 Master Update 성능을 위해 두 대의 컴퓨터가 필요한 것은 아니지만, 이들 두 서버에 나누어서 설치할 경우 사용자가 업데이트를 진행하면서 쿼리를 할 때 매우 유용합니다. Master Update를 실행하는 동안의 CPU 사용과 관련하여 RDBMS와 Analysis Services를 별도의 컴퓨터에 두면 다소 유리할 것으로 보입니다.
| 쿼리 성능 테스트 | | |
쿼리를 위해 데이터를 준비하는 동안 시스템의 성능을 측정하기 위해 충분한 작업을 완료하였다면, 사용자가 데이터를 쿼리할 수 있도록 해주려는 BI 시스템의 실제 목적을 달성한 것이 됩니다. 복잡한 시스템의 경우, 쿼리 응답 시간은 배제하기 어려운 여러 가지 요인들에 의해 영향을 받습니다. 아래의 섹션에서는 이 요소들을 최대한 배제해보도록 하겠습니다. 쿼리 작업로드(workload)에 대한 설명은 이 문서의 앞 부분에서 다룬 “하드에어와 소프트웨어 구성 및 테스트 데이터” 섹션을 참조하십시오.
| 집계 디자인 | | |
사전 집계된 데이터 요약 기능은 온라인 분석 프로세싱 (OLAP: Online Analytical Processing) 시스템을 빠르게 해주는 핵심 기술들 중 하나이며, Analysis Services는 이 기술을 광범위하게 사용합니다. Analysis Services는 산출될 집계를 확인하는데 사용할 수 있는 두 개의 메커니즘을 제공하는데 이는 Storage Design Wizard와 Usage-Based Optimization Wizard입니다. Storage Design Wizard는 어떠한 집계가 필요한지를 결정하기 위해 알고리즘을 적용합니다. 이 알고리즘은 디멘션의 모든 수준의 구성원 수와 각각의 큐브 또는 파티션에 있는 열의 수를 기반으로 이러한 결정을 내립니다. 이 알고리즘은 서버에 제출되는 쿼리에 대한 정보는 가지고 있지 않으며, 여러 수준이 조합되어 있는 쿼리도 다른 쿼리들과 마찬가지로 제출될 것이라고 가정합니다. 열의 개수를 사용하여, 알고리즘은 적절한 쿼리 성능을 확보하거나 주어진 저장소 공간을 사용할 수 있도록 하는 집계 모음을 결정합니다. 이 알고리즘은 전적으로 열의 개수에 따라 달라집니다. 따라서, 디멘션 값과 파티션 열의 수에 대한 값를 올바르게 설정해주어야 합니다. 이 정보는 Analytics Builder 유틸리티에서는 사용할 수 없는데, 이로써 큐브는 집계를 전혀 가지고 있지 않은 BI Accelerator를 이용하여 생성됩니다. 이는 큐브에 데이터가 채워진 다음 정확한 열의 개수를 제공하거나 예상 열 개수를 입력하기 위해 Partition Aggregation 유틸리티를 사용할 것이라고 가정합니다. Partition Aggregation 유틸리티를 사용하여 집계를 설계할 수도 있습니다. Partition Aggregation 유틸리티는 Storage Design Wizard와 동일한 알고리즘을 사용하는 집계를 구축합니다. 두 번째 메커니즘은 Analysis Manager의 Usage-Based Optimization Wizard입니다. 이 Usage-Based Optimization Wizard도 열의 개수를 필요로 하지만, Usage-Based Optimization Wizard는 모든 수준의 조합이 동일하다고 가정하지 않고 대신에 Analysis 서버에 의해 유지되는 쿼리 로그의 정보를 사용합니다. 이 로그는 서버로 들어오는 쿼리의 수준을 기록하지만, 쿼리 자체를 기록하지는 않습니다. 이 정보를 사용함으로써 Usage-Based Optimization Wizard는 로그에 기록된 쿼리 형식을 위한 최적의 집계 모음을 설계합니다. 쿼리 형식은 변경이 가능하기 때문에 수시로 사용자 기반 최적화 집계 디자인을 변경할 수 있습니다. 앞에서 언급한 바와 같이 쿼리 형식을 위해 최적의 집계를 설계하는 것 외에도 Usage-Based Optimization Wizard를 사용하여 시스템이 처리 시간과 저장소 공간을 절약하기 위해 사용되지 않는 집계는 설계하지 않도록 만들 수 있습니다. 이 연구에서는 세 개의 집계 디자인이 사용됩니다. 이들은 No Aggregations, Storage Design Wizard 및 Partition Aggregation 유틸리티에 의해 정의되는 10% 성능 향상, 100% 성능 향상을 위한 사용 기반 최적화 디자인입니다. 세 번째 집계 디자인은 다른 두 디자인을 실행하는 동안 모든 쿼리에 로깅함으로써 사용할 수 있으며, 이 로그를 사용해 사용 기반 최적화 디자인을 수행합니다. 파티셔닝되지 않은 일억 열 데이터베이스의 초당 쿼리 응답 시간을 보여주는 그림 4는 시스템의 성능이 우리의 예상과 일치한다는 것을 보여주고 있습니다. 10% 성능 향상 집계 디자인은 No Aggregations 보다 빨랐으며, 그 속도는 10% 이상이었습니다. 이는 매우 일반적인 현상입니다. 사용 기반 최적화 디자인은 가장 속도가 빨랐습니다. 또한, 동시 사용자의 수가 증가함에 따라 평균 쿼리 응답 시간도 점차적으로 느려졌습니다. 사용자 기반 최적화 집계 디자인으로 운영되는 경우, 비록 500명의 동시 사용자가 있다고 할지라도 응답 시간이 늘어나지는 않았습니다. 쿼리 작업로드를 증가시키기 위한 실험 리소스가 충분하지 않았습니다.
브라우저가 인라인 프레임을 지원하지 않는다면 여기를 클릭하여 별도의 페이지에서 볼 수 있습니다.
그림 4 쿼리 응답 시간 - 다양한 집계와 사용자의 수를 갖고 있는 파티셔닝 되지 않은 일억 열 데이터베이스, 콜드 캐시(cold cache) 한 명의 사용자에 대한 응답 시간이 100명의 사용자에 대한 응답 시간보다 느리다는 점을 기억하십시오. 이것이 바로 콜드 캐시 시나리오입니다. Analysis Services는 쿼리가 실행되기 전에 다시 시작되었기 때문에, 쿼리 결과 캐시에는 유용한 정보가 포함되어 있지 않습니다. 이러한 데이터는 파일 시스템 캐시에 데이터를 가져오는 것처럼 쿼리 캐시를 보관하고 일시적인 비용만을 발생시키기 위해 Analysis 서버를 다시 시작한 다음 몇 가지 일반 쿼리들을 실행하는 것이 좋다는 것을 의미합니다. 이로써 쿼리를 제출하는 첫 번째 사용자는 이러한 비용을 발생시키지 않게 됩니다. 파티셔닝과 데이터베이스 크기 그림 5는 집계가 없는 천만 열 데이터베이스의 파티셔닝된 버전과 파티셔닝 되지 않은 버전에 대한 평균 쿼리 응답 시간 (초당)을 보여주고 있습니다. 비록 집계가 없다고 할지라도 데이터베이스는 전례없이 빠른 응답 시간을 제공합니다. 서버는 파일 시스템 캐시에 전체 (압축된) Analysis 데이터베이스를 포함할 수 있기 때문에, 디스크 입출력은 데이터가 이미 읽어진 쿼리에 대해선 응답할 필요가 없습니다. 보다 규모가 큰 데이터베이스는 집계 디자인과 기타 조정 문제에 대해 더 많은 주의를 기울여야 합니다.
브라우저가 인라인 프레임을 지원하지 않는다면 여기를 클릭하여 별도의 페이지에서 볼 수 있습니다.
그림 5 쿼리 응답 시간 - 집계가 없는 파티셔닝된 천만 열 데이터 베이스와 파티셔닝 되지 않은 천만 열 데이터베이스, 콜드 캐시 이제 그림 6에 있는 일억 열 데이터베이스의 결과를 살펴보도록 하겠습니다. 데이터베이스는 더 이상 메모리에 적합하지 않게 되었기 때문에, 집계 디자인과 파티셔닝이 더욱 더 중요해 졌습니다. 다음의 두 기술은 쿼리 성능에 큰 이점을 제공합니다. 이 정도 크기의 데이터베이스에는 10% 성능 향상 집계 디자인이면 충분하며, 20% 성능 향상 디자인은 엄청난 처리 시간을 필요(이렇게 많은 집계 수를 실행하는 것은 비효율적임)로 한다는 점을 기억하십시오. 쿼리 성능을 향상시키기 위해서는 사용자 기반 최적화가 필수적입니다.
브라우저가 인라인 프레임을 지원하지 않는다면 여기를 클릭하여 별도의 페이지에서 볼 수 있습니다.
그림 6 여러 집계 디자인에 대한 쿼리 응답 시간 - 파티셔닝된 그리고 파티셔닝 되지 않은 십억 열 데이터베이스, 콜드 캐시 마지막으로 그림 7은 십억 열 데이터베이스에 대한 결과를 보여주고 있습니다. 이러한 크기에서 시스템을 운영하는 실용적인 방법은 파티션을 사용하는 것입니다. 쿼리 성능면에서 볼 때 집계를 오프 상태로 두거나 10% 성능 향상 디자인을 사용하는 것은 비효율적이며, 사용자 기반 최적화 디자인만이 뛰어난 응답 시간을 제공합니다. 사용자 기반 최적화 응답 시간을 보려면 숫자를 살펴보십시오. 표에는 표시되어 있지 않습니다.
브라우저가 인라인 프레임을 지원하지 않는다면 여기를 클릭하여 별도의 페이지에서 볼 수 있습니다.
그림 7 다양한 집계 디자인에 대한 쿼리 응답 시간 - 십억 열 데이터베이스, 콜드 캐시 콜드 캐시 vs. 웜 캐시그림 8은 Analysis Services 쿼리 결과 캐시가 콜드이며 캐시가 왐일 때와 동일한 쿼리를 실행하는 경우 쿼리 실행 시의 영향에 대해 보여주고 있습니다. 왐 캐시의 결과는 사용자 세션의 새로운 모음에서 동일한 쿼리를 다시 실행하여 얻을 수 있으며 이 때, Analysis 서버를 다시 시작할 필요는 없습니다. 캐시는 쿼리 응답을 즉시 제공할 수 있습니다. 하지만, 실험에서 제공되는 모든 결과 값을 찾기는 힘듭니다. 일반적으로 평균 응답 시간은 이 문서에서 제시하는 콜드 캐시 시나리오와 왐 캐시 시나리오의 평균 응답 시간입니다. 얼마나 많은 쿼리가 캐시에서 결과를 찾는지는 사용자의 쿼리 패턴이 얼마나 유사한가에 의해 결정됩니다. 쿼리 결과 캐시를 워밍하기 위해 시스템을 다시 시작할 때엔 알려진 일반 쿼리 모음을 실행하는 것도 좋습니다.
브라우저가 인라인 프레임을 지원하지 않는다면 여기를 클릭하여 별도의 페이지에서 볼 수 있습니다.
그림 8 쿼리 응답 시간, 콜드 캐시 vs. 왐 캐시 - 파티셔닝된 일억 열 데이터베이스 쿼리의 복잡성이 실험에서 사용된 템플릿 쿼리는 매우 간단한 것으로부터 매우 복잡한 것까지 다양한 복잡성을 가지고 있습니다. 일부는 다양한 디멘션에 따라 데이터를 간단하게 분리시켜야 하며, 일부는 교차 병합 디멘션을 필요로 하며, 일부는 정렬된 데이터 모음을 필요로 합니다. 쿼리 복잡성의 특정 요소는 일반적으로 보다 많은 리소스를 필요로 하며 실행을 위해 더 많은 시간을 필요로 한다고 평가되어 왔습니다. 이러한 요소들은 아래와 같습니다. - Topcounts, Sorting 등. 수 많은 사용자가 다섯 명의 상위 고객, 열 개의 상위 제품 등을 보고자 합니다. 이것은 충분히 이해할 수 있는 상황이지만, 이 쿼리는 모든 고객과 제품을 열거한 다음에 최고 고객과 제품을 분류하는 작업을 요합니다. 모음을 분류할 수는 있지만, 매우 큰 모음을 분류하는 것은 훨씬 오랜 시간을 필요로 합니다.
- 대규모 모음 Cross-joining(크로스 조이닝)하기. Cross-joining 모음은 분석에 있어서 일반적이고 필수적인 부분입니다. 하지만, 매우 큰 모음을 크로스 조이닝하기 위해서는 상당한 양의 계산을 필요로 합니다. 예를 들면, 수 만개의 공항이 존재하는 경우 모든 도착 공항을 출발 공항과 크로스 조이닝하는 쿼리는 실행 시 시간이 훨씬 오래 걸립니다.
- 팩트 수준의 세부 사항 측정하기. 팩트 수준의 데이터를 필요로 하는 측정값은 더 높은 수준으로 집계되지 못하므로 계산 시간이 훨씬 오래 걸립니다. 측정값의 평균 값 (산술 평균)은 계산이 간편한데 이는 측정값의 합과 항목의 수를 집계할 수 있으며 이 집계의 모든 수준에서 평균을 계산할 수 있기 때문입니다. 하지만 중앙값의 산출은 이렇게 간단하지 않습니다. 모든 개별 팩트 측정값을 나열하고, 이들을 분류한 다음, 모음의 중앙 항목을 찾아야만 합니다.
- 클라이언트에 많은 디멘션 모음 가져오기. 클라이언트 컴퓨터로 가져와야 하는 많은 수의 디멘션 구성원은 보다 느리게 실행됩니다. 서버에 많은 부하를 주지는 않지만, 정보가 네트워크 상에서 전송될 때 발생하는 대기 시간이 응답 시간을 보다 더디게 합니다.
이 문서에서 제시되는 결과는 모든 쿼리 응답 시간의 평균을 의미하는 것이며 복잡성 별로 쿼리를 식별하지는 않습니다 (쿼리 결과는 Analysis Services 큐브에서 산출된 평균을 사용하여 분석됩니다. 결과는 데이터베이스 크기, 집계 디자인 등으로 나눠집니다). 명명된 모음명명된 모음은 Analysis Services에서 수시로 사용되는 모음을 사전 정의하는 작업에 있어서 유용하게 사용됩니다. 예를 들면, BI Accelerator는 지난 네 분기를 참조하기 위해 쿼리가 언제 실행되는지에 상관없이 모든 쿼리를 사용할 수 있는 Standard Last 4 Quarters 모음을 정의합니다. 이 모음의 실제 컨텐츠는 Time 디멘션에서 현재 일자를 확인함으로써 시스템에 의해 지속적으로 정의됩니다. 명명된 모음은 서버로 연결이 구축되었을 때 사용자 세션에서 평가됩니다. 이는 모든 명명된 모음이 사용 여부에 상관 없이 평가된다는 것을 의미합니다. 이러한 이유로 기능의 일부 형식은 시스템 수준 기반으로 정의된 모음에 포함되지 않아야 합니다. 이러한 기능 형식에 대한 예제는 SMA 스키마에서 찾을 수 있습니다. Sales 큐브의 Top 5 Customers 모음은 아래 코드에서 볼 수 있습니다. TOPCOUNT( { DESCENDANTS( [Customer].[Direct].[All Customers],
[Customer].[Direct].[Customer] ) },
5,
( [Time].[Standard].[Year].[Current],
[Measures].[Actual Net Sales Amt] )
)
이 모음을 평가하려면 시스템은 반드시 해당 년도의 총 판매를 고객별로 합계를 낸 다음, 최고 다섯 명의 고객을 찾기 위해 판매 목록 별로 고객을 분류해야 합니다. 만일 예제 SMA 데이터세트와 같이 고객 모음이 작은 경우, 이 모음을 평가하는 데에 아무런 문제가 없습니다. 하지만, 이 성능 연구에서 백만명의 고객을 사용한 것처럼 고객 모음이 큰 경우라면, 이 모음을 평가하기 위해 보다 많은 작업이 요구됩니다. 명명된 모음이 중요하긴 하지만 모든 사용자 세션에 대해 평가하지 않아도 되는 작업을 상당히 많이 해야 하는 경우, MDX의 CREATE SET 명령문을 사용해 세션 별로 정의하거나SELECT 명령문의 WITH 절을 사용해 쿼리 별로 정의할 수도 있습니다. 이 성능 연구를 위해 Top 5 Customers 모음은 Sales 큐브로부터 삭제되었습니다.
| 배포 권장사항 | | |
이 섹션은 BI 시스템을 배포하고 관리하는 것에 대한 여러 가지 권장사항을 제시합니다. 이 섹션의 권장사항은 성능 실험의 결과와 개발팀이 알고 있는 최상의 구현 방법을 기반으로 합니다. 몇몇 권장사항은 성능 실험 도중 발견한 사항들을 기반으로 합니다. 이 섹션의 일부 항목은 사용 가능하다고 확신되었으며, 이 연구에서 특별히 실험하지는 않았습니다. 이 항목들은 추측 또는 가정법을 사용하여 표현되었습니다. 모든 규칙에는 예외가 있다는 말이 있습니다. 이 문서의 모든 권장 사항도 모든 사이트에 적용되지는 않을 것입니다. 특정 프로젝트의 컨텍스트에 대한 각 권장사항을 신중하게 고려함으로써 적합 여부를 판단해야만 합니다. 집계 관리우리는 이미 사전 산출된 집계가 신속한 쿼리 성능을 위해서는 필수적이라는 점을 이미 살펴보았습니다. 또한, 사전 산출된 집계를 사용하기 위해서는 집계를 처리하기 위해 더 많은 CPU 시간이 필요로 한다는 점에 대해서도 살펴보았습니다. 앞에서 언급한 바와 같이 BI Accelerator는 열 개수 정보를 갖고 있지 않기 때문에 BI 어플리케이션이 생성될 때 집계 디자인을 결정하지 않습니다. 이점을 감안할 때 어떻게 집계를 관리할 수 있습니까? 앞에서 살펴본 바와 같이 천만 팩트 열 또는 이보다 작은 열을 갖고 있는 작은 데이터베이스는 집계 디자인에 의해 큰 영향을 받지 않습니다. 서버가 주요 데이터베이스 정보를 보관하기에 충분한 메모리를 갖고 있다면, 시스템은 신속하게 실행됩니다. 일억 열 또는 그 이상의 팩트 열을 가지고 있는 큰 데이터베이스는 적절한 집계 계획이 필요합니다. 아래에는 일반적인 가이드라인이 제공됩니다. - 파티셔닝을 사용. 비록 파티셔닝이 Master Update를 느려지게 한다고는 하지만, 쿼리 성능을 향상시키기 위해서는 유용하게 사용됩니다 (이것은 집계 디자인과 관련이 없어 보일 수도 있지만, 집계 디자인은 파티션이 사용될 때 변경되기 때문에 연관되어 있습니다).
- 데이터베이스에 집계가 없는 초기 기록 데이터 로드와 전체 큐브 프로세싱을 실행합니다.
- 집계를 디자인하기 전에 디멘션 구성원의 수와 열의 수를 설정합니다. 만일 이 단계를 수행하지 않는다면, 집계 디자인이 무용 지물이 됩니다. 이 Partition Aggregation 유틸리티는 특히 모든 디멘션과 수준을 한번에 산출하고 큐브의 모든 파티션을 한번에 산출하기 때문에 이 작업에 매우 유용하게 사용될 수 있는 도구입니다. 이 작업은 매우 느리게 진행되지만, 인내심을 갖고 기다린다면 작업이 수행될 것입니다.
- 이 연구에서 사용되는 10% 성능 향상과 같이 적절한 성능 향상을 얻기 위해 일반 집계를 설계합니다. 앞에서 언급한 바와 같이 이것은 쿼리 혼합에 따라 10% 이상의 성능 향상을 제공할 수도 있습니다. 집계를 설계한 다음, 데이터의 양이 지나치게 긴 프로세스가 아니라면 큐브를 다시 처리하거나 Partition Aggregation 유틸리티의 재집계(Re-aggregate) 옵션을 사용합니다. Analysis Services는 Subject Matter 데이터베이스에서 가져온 데이터를 다시 읽는 대신 이미 읽은 데이터를 사용해 다시 집계하기 때문에, 이것은 데이터를 매우 신속하게 얻을 수 있으며 CPU 로드는 높아집니다. 사용자가 서버에 대해 쿼리하는 경우에는 다시 집계하지 않습니다.
참조 매우 큰 데이터세트 (예를 들면 십억 또는 그 이상의 열)인 경우, 예상 성능 향상을 기반으로 하는 집계는 실행 시 많은 비용이 요구될 수도 있습니다. 그러므로 사용자 기반 최적화로 신속하게 이동시켜야 할 것입니다. - 서버에서 쿼리 로깅이 가능한지 확인합니다. 만일 최초 사용자 채우기가 작다면, 모든 열 번째 쿼리에 로깅하도록 설정되어 있는 기본값 대신 모든 쿼리에 로깅하는 것을 고려해 보십시오.
- 시스템에 파일럿 배포를 수행하거나 첫 번째 사용자가 액세스할 수 있도록 합니다. 쿼리 로그는 사용자 기반 최적화 집계 디자인을 위해 정보를 수집하기 시작할 것입니다.
- 사용자가 사용자 형식을 구축하기 위해 충분한 시간을 가진 이후 또는 형편없는 성능의 쿼리에 대해 즉시 조치해야 한다면, 사용자 기반 최적화를 사용하는 집계 모음을 설계합니다. 아래에는 이와 관련해 기억해야 하는 주요 사항이 제공됩니다.
- 만일 최적화를 위해 가장 느리게 실행되는 쿼리를 선택했다면, 새로운 사용자 기반 최적화 집계를 기존 설정에 추가합니다. 기존 설정을 교체하는 경우, 이전 집계에 의해 처리된 쿼리는 느려집니다. 이를 위해 선택할 수 있는 또 다른 방법은 모든 쿼리를 최적화할 모음에 포함시키는 것입니다.
- 새로운 사용자 쿼리는 이전 파티션에서 쿼리를 수행하던 것보다 자주 쿼리를 수행합니다. 만일 파티셔닝된 큐브를 가지고 있다면, 현재 파티션에 집계를 설계하고 이를 다른 파티션에 복사합니다. 이전 파티션의 사용 기반 최적화를 사용하지 말고 이 디자인을 현재 파티션에 복사합니다.
- 가장 느린 쿼리만 Usage-Based Optimization Wizard를 정기적으로 다시 실행하고 새로운 집계를 이 모음에 추가합니다. 이것은 사용자가 점차적으로 쿼리 형식의 변경 사항에 대처할 수 있도록 합니다. 모든 파티션에 대해 Uasge-Based Optimization Wizard를 다시 실행할 필요는 없습니다. 가장 최근 파티션에 디자인을 구축하고 이 디자인을 기본 파티션에 복사함으로써 향후 파티션을 위한 템플릿을 준비합니다.
- 해당 (최근) 파티션에 사용 기반 최적화를 사용한 다음, Partition Aggregation 유틸리티를 사용하여 이 집계 디자인을 큐브의 기본 파티션으로 복사합니다. 이 파티션은 어떠한 데이터도 포함하고 있지 않지만, 새로운 파티션을 위한 기본 집계 디자인을 갖고 있습니다. 예를 들면, Sales 큐브에서 Sales 파티션은 기본 파티션이며, Sales_2002_01은 2002년 1월에 대한 데이터를 포함하고 있습니다. 사용자 작업로드에 따라 집계 디자인을 다른 파티션으로 복사하는 것이 바람직할 수도 있습니다.
- 새로운 집계 디자인을 구현하기 위해 파티션을 다시 처리합니다 (처리되지 않은 새로운 집계는 파티션에 어떠한 영향도 주지 못합니다). 새로운 디자인을 기반으로 집계를 구축하려면, 파티션을 다시 처리하거나 Partition Aggregation 유틸리티를 사용해 다시 집계해야 합니다.
파티션 관리Master Update는 파티션 관리의 가장 복잡한 요소를 자동으로 처리합니다. Master Update는 들어오는 데이터를 기반으로 새로운 데이터가 언제 필요한 지를 결정하고, 관련 테이블과 필요한 경우 큐브 파티션을 구축하고, 각각의 파티션 테이블에 올바른 데이터가 포함되었는지를 확인한 다음, 업데이트의 일부분으로 적절한 큐브 파티션을 프로세스합니다. 실행해야 하는 두 가지 작업은 아래와 같습니다. - 파티션이 이전 섹션에서 설명한 내용에 적절한 집계 디자인을 갖고 있는지 확인합니다. 모든 파티션이 동일한 집계 디자인을 가지고 있어야 하는 것은 아니지만, 기본 파티션의 디자인이 새로운 파티션으로 전파된다는 점을 명심하십시오.
- 시스템의 데이터에 대해 적절한 수명을 결정하고 적절한 시점에 파티션을 삭제합니다. 일부 시스템에는 이 작업이 필요 없으며, 다른 시스템들에서는 반드시 필요합니다. 큐브 파티션 내에서 또는 단일 파티션 큐브 내에서는 데이터를 삭제할 수 없습니다. 이전 데이터를 삭제하는 방법은 데이터가 들어있는 파티션을 제거하는 것입니다. 파티션을 제거하는 방법은 다음과 같습니다. :
- 관련 데이터베이스와 Analysis 데이터베이스를 백업합니다.
- Analysis Manager를 사용해 큐브로부터 파티션을 삭제합니다.
- 관련 테이블을 삭제합니다.
최초 로드 계획하기 대부분 사이트의 경우 Master Update의 성능은 최초 데이터 로드를 위해 충분하지 못합니다. 만일 사이트가 많은 양의 최초 데이터를 로드하고 있으며 Master Update가 사용할 수 없게 되었다면, 이것은 Master Update가 엄청난 양의 작업을 수행하고 있기 때문입니다. 또한, Multi-day를 실행하는 것도 실패하는 경우 다시 시작하도록 요청하기 때문에 프로세스를 위험하게 할 수 있습니다. 아래에는 프로세스가 더 빠르고 원활하게 수행되도록 하는 옵션들이 소개됩니다. - 사전 할당 저장소 공간과 배치 크기의 증가는 약간의 성능 향상을 제공할 수 있습니다. 이 옵션에 대한 추가 정보는 이 문서의 앞부분에서 다룬 “사전 할당 RDBMS 저장소”와 “배치 크기와 오류 확인” 섹션을 참조하십시오.
- 오류 확인을 비활성화시키는 것도 성능을 향상시킬 수 있지만, 데이터의 무결성을 전적으로 확신하지 않는다면 이를 시도해서는 안됩니다. 우리는 데이터가 완전하게 무결하다고 확신하는 고객의 데이터가 실제로는 그렇지 않은 경우를 많이 보았기 때문에 이 옵션을 고려할 때에는 매우 신중해야 합니다.
- 특히 데이터를 로드한 다음 집계 디자인을 변경할 계획이라면, BI Accelerator를 사용할 때 일반적으로 수행하는 것과 마찬가지로 초기 데이터를 로드할 때까지 큐브를 처리하지 않고 기다리는 것이 바람직합니다.
- 전부 한꺼번에 로드하는 대신 데이터를 묶음으로 로드하는 것은 다음 세 가지 이점을 제공합니다. 첫 번째, Master Update가 실행을 완료하는 즉시 데이터베이스로부터 데이터를 삭제할 수 있기 때문에 Staging 데이터베이스는 보다 적은 공간만을 필요로 합니다. 두 번째, 데이터가 시간 기반 배치 (예, 월별)로 로드될 수 있다면, 파티셔닝이 성능에 끼치는 대부분의 영향을 제거할 수 있습니다. 앞에서 언급한 바와 같이 성능에 끼치는 이러한 영향은 한번에 한 파티션씩 로드하는 Staging 데이터베이스 팩트 테이블의 멀티 스캐닝 때문입니다. 세 번째 로드하는 도중 불시에 실패되는 경우 배치는 롤백이 가능합니다. 팩트 데이터를 배치 로드할 경우엔, 프로세스에 대한 체크포인트를 제공합니다.
- 다른 옵션을 사용해 충분한 성능 향상을 얻지 못했다면 데이터를 Subject Matter 데이터베이스로 직접 로딩하는 것이 도움이 될 수도 있습니다. 하지만, Master Update로 수행되는 모든 기능은 사전에 수행되어야 한다는 점을 명심하십시오. 이 방법은 프로세스를 수행하기 전에 도구와 절차를 개발하고 테스트해야 하기 때문에 최종적인 효과를 기대하기는 힘듭니다. 일반적으로 이 옵션은 Master Update를 실행하기 위해 소요되는 시간보다 오랜 시간을 필요로 합니다.
증분 로드 계획하기 대부분의 경우, 증분 로드는 자동으로 실행되도록 설정함으로써 Master Import와 Master Update가 적절한 시기에 호출되도록 하는 것이 바람직합니다. 일부 사이트는 영업일 일과시간에 데이터를 가져올 수 있지만 설정된 시간(일반적으로 일과시간 종료 이후)까지는 변경할 수 있도록 데이터를 사용자가 볼 수 있는 큐브에 두는 것은 원하지 않을 수도 있습니다. 이러한 경우 데이터는 큐브 데이터를 수정하지 않고도 Subject Matter 데이터베이스에서 확인, 준비, 저장될 수 있으며, 이 큐브 데이터는 나중에 처리될 수 있습니다. 다음 섹션에서는 이 작업을 수행하는 방법에 대해 설명하도록 하겠습니다. Master Update 외부에서의 큐브 프로세싱 일단 데이터가 Subject Matter 데이터베이스에 안전하게 저장되면, 큐브를 처리하는 것은 주로 Master Update의 작업입니다. 이 작업은 Subject Matter 데이터베이스가 업데이트되는 시점이 아닌 다른 시간으로 연기될 수 있습니다. 이는 사용자가 보는 데이터를 변경하지 않고도 Master Update가 지속적으로 또는 하루 종일 실행될 수 있도록 하기 위해서 입니다. 그런 다음, 계획된 시간에 큐브를 처리할 수 있도록 함으로써 훨씬 빠르게 작업을 수행할 수 있도록 합니다. 또 다른 이유는 대용량의 초기 로드 작업과 관련되어 있습니다. 이 데이터는 Subject Matter 데이터베이스에서 준비될 수 있으며, 집계를 설계하고, 큐브를 처리할 수 있습니다. 디멘션를 처리하지 않은 상태에서 Master Update를 실행하려면, 글로벌 변수 gbManualProcessDim를 trUE로 설정합니다. 큐브를 처리하지 않은 상태에서 Master Update를 실행하려면, 글로벌 변수 gbManualProcessFact를 trUE로 설정합니다. 이러한 설정은 Analysis 데이터베이스를 수정하지 않고도 적절한 Subject Matter 데이터베이스 업데이트가 실행되도록 합니다. 아래에는 Analysis Services 구조를 위해 사용할 수 있는 도구들이 소개됩니다. - Analysis Manager는 프로세싱을 포함해 모든 관리작업을 위한 기본 사용자 인터페이스를 제공합니다.
- BI Accelerator에 포함되어 있는 Partition Aggregation 유틸리티는 프로세싱하기 위해 여러 파티션을 선택하는 경우 유용하게 사용될 수 있습니다. 하지만, 여러 인스턴스가 동시에 시작되는 경우를 제외하고 이 유틸리티는 여러 큐브 또는 파티션을 병렬로 처리하지 않습니다. 앞의 “집계 디자인” 섹션에서 설명한 바와 같이 Partition Aggregation 유틸리티는 큐브를 다시 집계하는 작업에서도 중요한 역할을 담당하고 있습니다.
- DTS의 Analysis Services Processing Task를 사용하면, 자동 실행에 디멘션과 큐브 프로세싱을 포함시킬 수 있습니다.
- 병렬 프로세싱 도구는 SQL Server 2000 Resource Kit에서 제공됩니다. 이 도구를 사용하여 Analysis Services 큐브와 파티션을 병렬로 처리할 수 있습니다. 자동 스크립트는 정기 작업을 위해 사용되는 도구를 호출할 수 있습니다.
시스템 구성하기 BI 어플리케이션에서 사용되는 플랫 파일, Staging 데이터베이스, Subject Matter 데이터베이스 및 Analysis 데이터베이스에 필요한 디스크 공간을 추정하는 것은 어렵지 않습니다. 또한, 작은 범위와 추정에 대한 디스크 공간 요구사항을 측정할 수도 있습니다. 열 별 바이트는 열의 개수가 증가하더라도 바뀌지 않습니다. Subject Matter 데이터베이스와 Analysis 데이터베이스의 데이터를 저장할 수 있는 충분한 공간이 있는지, 플랫 파일과 Staging 데이터베이스의 임시 데이터를 위한 공간이 있는지, 데이터베이스 로그와 임시 파일을 위한 공간을 확보하고 있는지 확인합니다. 이 항목 모두는 RAID-5 또는 RAID-10과 같이 빠르고, 풍부한 멀티 드라이브 구성이어야 합니다. 여러 설치가 동일한 서버의 RDBMS와 Analysis Services 모두에서 실행될 수 있지만, 사용자 응답 시간이 RDBMS의 데이터 준비 작업에 의해 부정적인 영향을 받거나 메모리에 대한 논점이 문제가 된다면 그리 권장할만한 방법이 아닙니다. 이 연구의 결과에서 알 수 있듯이 표준 4-CPU 서버는 우수한 장치이며, 더욱 새로운 장치일수록 이 실험에서 사용한 장치보다 훨씬 빠릅니다. 컴퓨터는 운영체제, SQL Server RDBMS 및 Analysis Services를 실행하기에 충분한 메모리를 갖추고 있어야만 합니다. 대형 디멘션을 실행해야 하는 시점이 되면 메모리가 종종 문제로 대두됩니다. Analysis Services는 메모리의 모든 디멘션 구성원을 저장하고 수 백만의 구성원을 갖고 있는 디멘션은 메모리에 대한 부담을 서버에 둡니다. 제한 요소는 단일 프로세스가 사용할 수 있는 주소 공간입니다. 이것은 운영체제에 의해 결정됩니다. 4 GB 이상의 물리 메모리를 단지 Analysis Services 만을 지원하는 컴퓨터에 추가하는 것은 도움이 되지 않습니다. 구성에 대한 추가 제안을 원한다면, BI Accelerator 참고 문서를 참조하십시오. 오류 확인의 활성화 개발 주기 동안 개발자는 일반적으로 BI Accelerator를 사용하여 완전한 오류 확인을 비활성화한 상태의 DTS 패키지를 구축합니다. Analytics Builder Workbook의 Processing 페이지에 있는 Generate DTS packages with error handling for each package step 옵션은 기본적으로 비활성화됩니다. 하지만, 어플리케이션이 생산 작업을 시작하면 이 옵션을 활성화되도록 설정해야 합니다. DTS 패키지는 중요한 오류 형식을 발견하고 이것을 패키지 로그에 기록하지만, 오류 확인이 활성화 되어있지 않다면 Browse Batch 유틸리티에서는 볼 수 없습니다. 예를 들어, Master Import 또는 Master Update가 실행되는 동안 컴퓨터의 메모리가 부족하다면, 패키지는 로그에 있는 오류와 실패를 정확하게 보고합니다. 하지만, 패키지가 만들어질 때 오류 확인이 활성화되지 않았다면, Browse Batch 유틸리티를 사용해 오류를 볼 수 없습니다. RDBMS 통계치 업데이트하기SQL Server 관련 엔진은 SQL 명령문을 실행하기 위한 최적의 방법을 결정하기 위해 관계형 테이블의 통계를 사용합니다. 통계치가 정확하지 않은 경우, 성능이 악화됩니다. 이러한 사실은 이 문서에서 대형 데이터세트를 사용할 때 밝혀졌으며, 이는 테이블로부터 많은 양의 데이터가 삭제되고 재 입력되는 경우에 종종 나타납니다. 예를 들어, 사이트가 파일럿 프로그램에서 많은 양의 데이터를 로드 한다고 가정해 보도록 하겠습니다. 생산 작업에 들어가기 전에 사이트는 Master Delete와 Master truncate를 사용하는 데이터로부터 모든 데이터를 삭제한 다음, 데이터를 임시 파일로부터 다시 로드 합니다. Master Update는 두 번째 실행될 때 첫 번째보다 더디게 실행됩니다. 이것은 RDBMS 통계치가 시스템의 변경 사항을 유지하지 않았기 때문입니다. DBCC REINDEX (tablename) 또는 UPDATE STASTISTICS (tablename) WITH FULLSCAN들 중 하나를 사용하여 모든 테이블에 있는 통계치를 다시 설정할 수 있습니다. 이 문서의 목적 상, 어떠한 테이블을 업데이트할 지 결정하기 위한 어떠한 작업도 수행되지 않았기 때문에 신속하게 업데이트할 수 있었으며 우리는 모든 테이블을 업데이트하였습니다.
| 성능과 확장성 실험 설계하기 | | |
이 문서는 하나의 스키마, 하나의 하드웨어 구성 및 하나의 데이터세트의 여러 변수를 갖고 있는 성능 실험 결과에 대해 다루고 있습니다. 물론 이러한 요소들 중 하나라도 변경된다면 결과는 달라질 것입니다. 이렇기 때문에 개별 사이트의 성능을 예측하기가 어렵습니다. 특히, 쿼리 성능 결과는 사이트의 실제 쿼리 형식과 집계 디자인에 의해 크게 영향을 받습니다. 이러한 이유로 우리는 아래의 문제가 대두될 때 성능 실험을 실시할 것을 권장합니다. - 시스템은 보다 높은 수준의 결과를 제공하기 위해 가장 세부적인 수준의 데이터를 필요로 하는 쿼리를 수신합니다. 앞에서 언급한 바와 같이 topcounts는 중앙값과 백분율의 경우에도 가장 일반적인 예제입니다.
- 예를 들어, 일억 개 이상의 열과 같이 큰 데이터세트를 갖고 있는 경우
- 예를 들어, 이 백만 이상의 구성원과 같이 큰 디멘션을 갖고 있는 경우
- 100명 보다 많은 동시 사용자 같이 많은 동시 사용자를 갖고 있는 경우
이러한 실험은 사용자가 제출하는 쿼리 형식에 대한 정확한 추정을 할 수 있을 때에만 유용하게 사용될 수 있다는 점을 기억하십시오. 작업로드성능 테스트를 계획할 때에는 시스템 작업로드의 두 가지 사항을 고려해야 합니다: 사용할 데이터와 쿼리 모음. 작은 데이터세트를 사용하여 성능을 산출하지 마십시오. 이 연구에서는 천만 열 데이터 세트에서부터 일억 열 데이터세트에 이르는 테스트 결과를 산출하였다고 가정하고 있습니다. 데이터 준비 속도와 쿼리 성능에 대한 측정 작업은 엄청난 용량에 의해 중단될 것이며 디스크 공간 요구 사항만이 부합하였습니다. 일반적으로 시스템 성능은 데이터세트에 있는 측정 값에 의해 영향을 받지 않습니다. 대부분의 경우, 이 측정 값은 사용자가 생산에 사용하게 될 값을 만족시키는 임의 값과 측정 수치입니다. 디멘션에서의 데이터 분배는 어느 정도 사실적이어야 합니다. 쿼리 성능은 쿼리 형식과 집계 디자인에 대해 매우 민감합니다. 만일 가능하다면, 생산을 위한 쿼리 도구를 사용하는 파일럿 사용자가 등록한 실제 쿼리를 수집하십시오. Analysis Services의 클라이언트 구성요소인 Microsoft Pivottable Service는 등록된 MDX 쿼리의 실제 텍스트를 로깅하는 기능을 갖고 있습니다. 이는 서버 로그와 같은 기능이 아니며, 쿼리에서 사용되는 각 디멘션의 수준만을 기록합니다. 로깅 MDX 쿼리에 대한 추가 정보는 SQL Server 2000 Books Online의 “로그 파일 속성”을 참조하십시오. 테스트를 위해 쿼리 모음을 설계하는 것에 대한 추가 정보는, 이 연구에서 사용된 쿼리 모음에 대한 앞부분의 설명을 참조하십시오. 모든 Analysis Services 성능 연구에 있어서 클라이언트와 서버를 캐시하는 것에 주의해야 하며, 유용한 실험 결과를 얻기 위해서는 충분한 양의 다양한 쿼리를 생성해야만 합니다. 이러한 쿼리 모음을 생성하는 것은 Analysis Services의 배포 성능을 특성화하는 것에 있어서 또 다른 문제점들 중 하나가 되고 있습니다. 측정 사항이 연구에서와 같이 데이터 준비 성능 (업데이트 비율)과 쿼리의 응답 시간을 측정하는 것은 항상 중요합니다. 시스템이 여러 사용자의 작업로드에 의해 영향을 받는 경우 시스템이 지원할 수 있는 동시 사용자의 수를 결정하기 위해 응답 시간을 측정하여야 합니다. 게다가, 만일 시스템의 최적 크기를 결정하기 위해 데이터가 입력으로 사용되었다면, CPU 사용의 측정, 메모리 사용, 디스크 공간, 대역폭 및 네트워크 사용이 유용하게 사용될 것입니다. 정교한 분석을 실시하고 있지 않다면, 이것만으로도 작업을 하기에 충분할 것입니다. 필요한 도구주어진 플랫 파일의 데이터 모음에서는 단순히 Master Import와 Master Update를 호출함으로써 시스템의 업데이트 비율을 테스트할 수 있습니다. Browse Batch 유틸리티에 의해 보고되는 시간 스탬프가 시간 정보를 제공합니다. 쿼리 성능은 더욱 복잡합니다. 일단 쿼리 모음이 사용 가능해지면, 이것을 서버에 등록하고 결과를 측정하기 위한 도구가 필요합니다. Analysis Services와 함께 예제로 제공되는 MDX Sample Application은 MDX 쿼리를 제출하기 위해 필요한 모든 코드를 보여줍니다. 쿼리를 제출하는 코드 주위의 래퍼는 경과된 쿼리 시간을 보고할 수 있습니다. 각각의 에뮬레이트 된 사용자 세션은 Pivottable Service의 별도 인스턴스를 사용하고 있는지, 혹은 클라이언트측 캐싱이 인위적으로 서버의 작업로드를 감소시키는지 확인해야 합니다. 또한, 클라이언트 컴퓨터가 오버로드 되지 않도록 확인해야만 합니다. 클라이언트 컴퓨터가 병목현상을 겪게 된다면, 성능 연구는 유효하지 않게 됩니다. 이 연구에서 우리는 각 클라이언트 컴퓨터에 실행할 수 있는 에뮬레이트 된 클라이언트 세션이 몇 개인지 결정하는 실험을 실시하였습니다. 반복성성능 실험 테스트의 반복성과 정확도에 각별히 주의하십시오. 알려진 혹은 알려지지 않은 다른 요소의 영향에 의한 변화를 전제로 측정을 수행한 다음 이 측정 값이 안정적이지 못하다는 것을 알아차리지 못하는 경우가 많습니다. 아래에는 이 연구에서 우리가 직면한 이런 요소들 중 일부가 제시됩니다. - Analysis Services를 다시 시작할 경우 자신의 쿼리 캐시를 플러시합니다.
- RDBMS를 다시 시작할 경우 자신의 페이지 캐시를 플러시합니다.
- 서버를 다시 시작할 경우 파일 시스템 캐시를 플러시하고 네트워크 연결을 파괴합니다.
- RDBMS 저장소 공간을 다시 사용한다는 것은 서버가 이를 다시 할당할 필요가 없다는 것을 의미합니다.
- RDBMS 테이블로부터 열을 삭제한 다음 이를 다시 입력할 경우 테이블 통계에 예상치 못한 값을 제공할 수도 있습니다.
- 서버 파일 시스템의 안티바이러스 스캐닝은 리소스의 사용을 증가시킬 수 있습니다.
- 공유 네트워크는 실험에 포함되지 않은 사용자에 의해 포화 상태가 될 수 있습니다.
- 파일 시스템은 간단한 테스트 스크립트에 의해 탐지되지 않을 수도 있는 원인 오류를 보충할 수 있습니다.
| 결론 | | |
이 문서에서는 많은 데이터가 다양한 결과와 권장사항을 제시하였습니다. 아래에는 일부 주요 요점이 소개됩니다. - 데이터 준비
- 병렬 테이블 로드는 팩트 테이블들이 유사한 크기인 경우 유용하게 사용됩니다.
- 많은 파티션들이 데이터를 수신해야 하는 경우, 파티셔닝된 로드는 많은 비용을 필요로 합니다. 데이터를 월별 모음으로 나누거나 이를 월별로 처리합니다.
- 10 KB의 배치 크기는 Master Import를 실행하기 위한 기본 배치 크기 이상의 실질적인 성능 향상을 제공합니다.
- 쿼리 성능
- Analysis Services는 포괄적인 범위의 쿼리를 필요로 하는 최소한 500명의 동시 사용자 세션을 위한 하위 이차 쿼리 성능을 안정적으로 제공할 수 있습니다.
- 사용자 기반 최적화와 파티셔닝은 이러한 수준의 성능을 제공하기 위해 필수적입니다.
- 왐 쿼리 결과 캐시는 성능을 향상시킵니다. 만일 가능하다면, 사용자가 시스템에 액세스하기 전에 일반 쿼리를 실행함으로써 쿼리 결과 캐시를 준비하십시오.
- 대략 천만 열의 팩트 데이터를 보유하고 있는 시스템은 집계 작업 없이도 우수한 쿼리 응답 시간을 제공할 수 있습니다.
- 시스템 관리
- 플랫 파일에 열 별로 103 바이트를 필요로 했던 팩트 테이블 데이터는 주요 지정 작업 이후 RDBMS에서 열 별로 142 바이트 또는 40% 이상을 사용하였습니다. Analysis Services 큐브로 처리될 때, 이 데이터는 열 별로 40 바이트 이하 또는 60%가량 줄어든 공간을 필요로 하였습니다
- 데이터를 파티셔닝 하면 보다 확실하게 시스템에서 데이터 업데이트를 관리하고 데이터 주기를 제어할 수 있습니다.
| 부록 A: 쿼리의 예 | | |
이 성능 테스트에 사용된 23개의 각 쿼리 템플릿에는 서버가 이전 캐시 결과를 기반으로 하여 모든 쿼리에 응답하지 못하도록 하는 변수(variations)가 들어있습니다. 이 섹션에서는 템플릿을 기반으로 생성된 일부 쿼리들을 소개합니다. 이들은 성능 실험 시 실행되는 실제 쿼리들입니다. 이 쿼리들은 다양한 디멘션 수준과 Multidimensional Expressions (MDX) 기능을 처리합니다. 이 쿼리들은 사용자가 SMA 모델에 대해 질문할 수도 있는 실제 쿼리를 반영하기 위해 만들어졌습니다. -- Show discounts for sales regions (ordered by margin) for a month.
SELECT { [Measures].[Actual Discount %] } ON COLUMNS ,
{ ORDER (
{ DESCENDANTS (
[Sales Force].[Standard].[All Sales Force],
[Sales Force].[Standard].[Region] ) },
( [Measures].[Actual Gross Margin] ),
BDESC ) } ON ROWS
FROM [Sales Force Performance]
WHERE ( [Time].[Standard].[Quarter].&[1/1/1998] )
-- Show invoice count by manufacturer for last four quarters for one marketing area.
SELECT { [Standard Last 4 Quarters] } ON COLUMNS ,
{ [Manufacturer].[Standard].[Manufacturer].members } ON ROWS
FROM [Sales]
WHERE ( [Measures].[Actual Invoice Count],
[Geography].[Marketing].[Direct Mktg Area].&[110] )
-- Show count of returns by manufacturer for four quarters for one marketing area.
SELECT { [Standard Last 4 Quarters] } ON COLUMNS ,
{ [Manufacturer].[Standard].[Manufacturer].members } ON ROWS
FROM [Sales]
WHERE ( [Measures].[Actual Invoice Count],
[Geography].[Marketing].[Direct Mktg Area].&[110],
[Sales Type].[Standard].[Sales Type].[Return] )
-- For a manufacturer and the last two quarters, show the sum of order amounts.
SELECT { [Manufacturer].[Standard].[Manufacturer].&[7] } ON COLUMNS,
{ [Time].[Standard].[Quarter].&[10/1/2000].lag(1),
[Time].[Standard].[Quarter].&[10/1/2000] } ON ROWS
FROM [Orders]
WHERE [Measures].[Order List Sales Amt]
-- Find the top three sales cities in a region, and show units sold in the current quarter.
SELECT { [Measures].[Actual Sales Units] } ON COLUMNS ,
{ TOPCOUNT(
descendants([Geography].[Standard].[Region].&[2],
[Geography].[Standard].[City]),
3,
[Measures].[Actual Sales Units] ) } ON ROWS
FROM [Sales]
WHERE ([Standard Current Quarter].item(0))
-- Find the top the sales zip codes in a city, and show the units sold in the current quarter.
SELECT { [Measures].[Actual Sales Units] } ON COLUMNS ,
{ TOPCOUNT(
descendants([Geography].[Standard].[City].&[11844],
[Geography].[Standard].[Postal Code]),
3,
[Measures].[Actual Sales Units] ) } ON ROWS
FROM [Sales]
WHERE ([Standard Current Quarter].item(0))
-- Define a calculation of gross profit. Show that, show the sales amount, and show
-- the product cost for all days in a quarter, for one product.
WITH MEMBER [Measures].[Gross Profit] AS
'[Measures].[Actual List Sales Amt]-
[Measures].[Actual Product Cost]'
SELECT { [Measures].[Actual List Sales Amt],
[Measures].[Actual Product Cost],
[Measures].[Gross Profit] } ON COLUMNS ,
{ [Time].[Standard].[Quarter].&[1/1/1900].CHILDREN } ON ROWS FROM [Sales]
where ( [Product].[Standard].[Product Item].&[804] )
-- Find the top three product lines by sales units. Show those sales
-- for the three named quarters for a given industry.
SELECT { [Time].[Standard].[Quarter].&[1/4/1900].lag(2),
[Time].[Standard].[Quarter].&[1/4/1900].lag(1),
[Time].[Standard].[Quarter].&[1/4/1900] } ON COLUMNS ,
TOPCOUNT( {[Product].[Standard].[Product Line].members},
3,
( [Standard Current Year].item(0),
[Measures].[Actual Sales Units] ) ) ON ROWS
FROM [Sales]
WHERE ( [Measures].[Actual Sales Units],
[Customer].[Direct].[Industry].&[126] )
-- For a product group, show units sold for each day of a month.
SELECT { [Measures].[Actual Sales Units] } ON COLUMNS ,
{ CROSSJOIN( { [Product].[Standard].[Product Group].&[2] },
Descendants([Time].[Standard].[Quarter].&[1/1/1999],
[Time].[Standard].[Day]) ) } ON ROWS
FROM [Sales]
WHERE ( [Sales Type].[Standard].[Sales Type].[sale])
-- For three different manufacturers, show backlog by day of week for open
-- orders for a given quarter.
SELECT {[Day Of Week].[Standard].[Day Of Week].members} ON COLUMNS,
{[Manufacturer].[Standard].[Manufacturer].&[4],
[Manufacturer].[Standard].[Manufacturer].&[6],
[Manufacturer].[Standard].[Manufacturer].&[2] } ON ROWS
FROM [Backlog]
WHERE ( [Measures].[Backlog Count],
[Order Status].[Standard].[Order Status].[open],
[Time].[Standard].[Quarter].&[1/3/1900] )
공지사항 이 문서에 들어 있는 정보는 발행 시점에 논의된 문제점에 대한 Microsoft Corporation 의 최근 견해를 소개하고 있으며 Microsoft가 시장 상황의 변화에 반드시 대처해야 하므로 이 내용을 Microsoft 사가 제시하는 약속사항으로 해석하지 말아야 하며, 발행일 이후에 제공된 정보에 대해서도 Microsoft는 정확성을 보장하지 않습니다. 이는 단지 정보 제공만을 위한 백서이며 MICROSOFT는 이 문서에서 어떠한 명시적, 묵시적 보장도 하지 않습니다. 사용자는 적용되는 모든 저작권 관련 법률을 반드시 준수해야 할 책임이 있습니다. Microsoft Corporation의 서면 승인 없이 이 문서의 어떠한 부분도 재출판되거나, 검색 시스템에 등록 또는 저장되거나, 어떠한 목적이나 수단 (전자, 기계, 사진 복사, 저장 등)을 사용하여 다른 형식으로 변경할 수 없습니다. Microsoft사는 이 문서에서 다루는 내용에 대하여 특허권과 특허 출원, 상표권, 저작권 혹은 다른 지적 재산권 등을 보유하고 있을 수 있습니다. Microsoft사로부터 서면 라이센스를 제공받은 경우를 제외하고는, 이 문서의 공급 자체가 여러분들에게 특허권, 상호, 저작권 혹은 다른 지적재산권에 관한 어떠한 라이센스 제공을 의미하는 것은 결코 아닙니다. ⓒ 2002 Microsoft Corporation. All rights reserved. Microsoft, Pivottable 및 Windows는 등록된 상표이거나 미국 또는 다른 국가들에서 등록된 Microsoft Corporation의 상표입니다. 이 문서에서 사용된 실제 기업 이름과 제품들은 이들을 소유하고 있는 기업의 상표일 수 있습니다. |
개요
