실시간 OLAP의 실재
Dennis KennedyMicrosoft Corporation
February 2003
적용 대상: Microsoft SQL Server 2000 Analysis Services
요약: SQL Server 2000 Analysis Services의 핵심 기능인 실시간 OLAP의 기능과 구현에 대해 살펴보십시오.
목차
소개 실시간 OLAP 정의 실시간 OLAP 사용 실시간 OLAP 성능 개선 결론 추가 정보
소개
일반적으로 온라인 분석 처리(OLAP: Online Analytical Processing)는 공유된 다차원 데이터의 처리 및 분석으로서 정의됩니다. 실제로 OLAP 시스템은 대기 시간이 길고 트랜잭션이 적은 대용량의 관계형 데이터베이스(예: 데이터 웨어하우스)에서 가져온 데이터를 분석합니다. 이러한 분석의 목적은 즉시 액세스가 가능하고 사용이 쉬운 다차원 구조로 비즈니스 정보를 집계하고 구성하는 것입니다. OLAP 시스템은 집계된 정보의 일부 또는 전부를 관계형 OLAP(ROLAP) 저장소라고는 불리는 관계형 데이터베이스의 테이블 내에 저장하거나 다차원 OLAP(MOLAP) 저장소라고도 불리는 다차원 데이터베이스의 데이터 구조에 저장합니다. OLAP 쿼리는 유사한 관계형 쿼리보다 훨씬 더 신속하게 응답될 수 있는데 그 이유는 집계와 계산이 이미 완료되어 있으며 파생된 결과 값을 ROLAP 테이블 또는 MOLAP 저장소에서 즉시 사용할 수 있기 때문입니다.
대용량의 이력 데이터를 검색, 분석 및 집계하면 상당한 시간과 리소스가 소비될 수 있습니다. 일반적으로 OLAP 시스템은 OLTP(Online Transaction Processing) 또는 대기 시간이 짧고 트랜잭션이 많은 다른 관계형 데이터베이스에 대해 실행되지 않는데 그 이유는 필요한 시간과 리소스가 관계형 데이터베이스의 성능에 영향을 미칠 수 있기 때문입니다. 일반적으로 OLAP 시스템은 비교적 자주 업데이트되지 않는 데이터 웨어하우스에 대해 실행되며 대부분의 상업용 및 재무 분석에 필요한 요구 사항을 지원합니다. 대부분의 OLAP 시스템은 "스냅샷" 방식을 사용하며 나중에 표시하고 분석하기 위해 주기적으로 데이터를 검색하고 집계합니다. 일반적으로OLAP 시스템은 저장된 파생 값을 사용하여 쿼리에 응답하므로, 집계 프로세스는 지나치게 오래된 데이터가 표시되는 것을 막기 위해 기본 관계형 데이터 원본의 업데이트 대기 시간을 적절하게 조정해야 합니다.
대기 시간이 짧은 데이터 원본에서 다차원 데이터를 제공할 수 있을 만큼 빠른 속도로 집계를 수행할 수 있는 제품으로 인해 최근 들어 OLAP에 대한 기존의 생각이 바뀌고 있습니다. 실시간 OLAP라고도 불리는 이 기능은 재무 및 산업 분야에서 가장 흔히 사용됩니다. 이러한 산업 분야에서는 대기 시간이 짧은 데이터를 다차원으로 분석하는 것이 조직의 비즈니스 요구 사항에 있어 매우 중요합니다. 하지만 실시간 OLAP의 정의와 예상은 제품마다 다를 수 있습니다.
이 문서에서는 Microsoft SQL Server 2000 Analysis Services에 구현되어 있는 실시간 OLAP에 대해 설명합니다. 또한 강력하지만 잘못 이해되고 있는 이 기능에 대한 사용 방법과 기술 정보도 제공합니다.
이 문서에서는 차원 설계를 비롯하여 관계형 데이터베이스에 대한 기본적인 지식과 SQL Server 2000 Analysis Services에 대한 실제적인 지식을 사용자가 가지고 있다고 가정합니다.
실시간 OLAP 정의
실시간 OLAP의 정의는 제품마다 다릅니다. Analysis Services에서 실시간 OLAP란 기본 관계형 데이터 원본에서 데이터가 변경될 때마다 큐브와 차원을 위해 다차원 데이터를 신속하게 검색, 구성, 집계 및 표시할 수 있는 성능을 말합니다. 이 때 큐브나 차원을 명시적으로 먼저 처리할 필요가 없습니다. 이 정의는 다른 OLAP 제품에서 사용되는 정의와 다르기 때문에 이 정의를 이해하는 최선의 방법은 실시간 OLAP에 관련된 다양한 개체와 상호 작용을 조사하는 것입니다.
실시간 개체
실시간 OLAP를 사용하려면 먼저 Analysis Services에서 실시간 차원이나 실시간 큐브를 만들어야 합니다. 다음 섹션에서는 개체에 따라 먼저 충족되어야 하는 요구 사항에 대해 설명합니다.
실시간 차원
실시간 차원은 공유되는 일반 ROLAP 차원이며 실시간 업데이트를 지원합니다. 실시간 차원을 만들기 위한 요구 사항은 공유 변경 차원을 만들기 위한 요구 사항과 유사하며, 해당 구성원에서 차원의 최하위 수준 구성원에 대해 키가 고유해야 합니다. 또한 집계 사용은 공유 변경 차원에 사용할 수 있는 값의 목록으로 제한됩니다(SQL Server 2000 온라인 설명서 참조). 하지만 다른 변경 차원과 달리 개인 실시간 차원을 만들 수는 없습니다.
변경 차원의 요구 사항에 대한 자세한 내용은 SQL Server 2000 온라인 설명서의 "변경 차원"을 참조하십시오.
실시간 큐브
실시간 큐브는 하나 이상의 ROLAP 파티션 또는 차원이 실시간 업데이트를 지원하는 큐브입니다. 여러 차원이나 파티션이 실시간 업데이트를 공유할 수 있으며, 실시간 큐브에는 실시간 업데이트를 위해 활성화되거나 비활성화될 수 있는 여러 차원이나 파티션이 있을 수 있습니다. 실시간 큐브 데이터를 관리하는 것은 복잡하기 때문에 실시간 큐브를 만들기 위한 요구 사항은 일반적인 큐브보다 더 엄격합니다.
분산된 파티션 큐브에 사용되는 원격 파티션은 실시간 업데이트를 위해 활성화될 수 없습니다.
실시간 업데이트를 지원하려면 ROLAP 파티션이 집계를 저장해서는 안되거나 인덱싱된 뷰를 사용하여 집계를 생성하고 저장해야 합니다. 집계가 없는 실시간 파티션을 사용하면 SQL Server 2000 데이터베이스를 구조적으로 변경하지 않고도 실시간 업데이트를 지원할 수 있지만 성능은 저하됩니다. 인덱싱된 뷰는 대부분의 ROLAP 파티션에서 성능을 확실히 향상시키지만 비교적 엄격한 요구 사항을 충족시켜야 하며 SQL Server 2000 데이터베이스를 구조적으로 변경할 수 있는 기능이 필요합니다.
집계를 저장하기 위해 Analysis Server는 파티션(실시간 업데이트를 위해 활성화된 파티션) 내에 저장된 각 집계에 대해 인덱싱된 뷰를 만듭니다. 단일 파티션에 여러 개의 인덱싱된 뷰가 연결될 수 있습니다. 인덱싱된 뷰에는 해당 집계의 입도(granularity)로 정의된 수준에 따라 그룹화된 집계 측정값 데이터가 포함됩니다.
파티션에 대해 인덱싱된 뷰를 만들려면 저장소 디자인 마법사를 사용합니다. 먼저 파티션이 ROLAP 저장소를 사용하고 실시간 업데이트를 위해 활성화되어 있는지 확인합니다. 그런 다음, 하나 이상의 집계를 설계합니다. 각 집계에는 인덱싱된 뷰가 필요하며 Analysis Server에 의해 자동으로 만들어집니다. ROLAP 파티션에 대해 인덱싱된 뷰를 만드는 방법에 대한 자세한 내용은 SQL Server 2000 온라인 설명서의 "ROLAP 파티션에 대해 인덱싱된 뷰"를 참조하십시오.
또한 저장소 설계 마법사를 사용하면 실시간 업데이트를 위해 활성화된 파티션에서 기존의 인덱싱된 뷰를 제거할 수 있습니다. 기존 집계를 제거하려면 저장소 설계 마법사에서 Performance gain reaches 옵션을 선택하고 값을 0%로 설정합니다. 실시간 업데이트를 위해 활성화된 파티션에서 집계가 필요하지 않은 경우, 기존의 인덱싱된 뷰도 제거됩니다.
SQL Server 2000 온라인 설명서에 나열된 인덱싱된 뷰 요구 사항 이외에도 Analysis Services는 인덱싱된 뷰와 추적을 SQL Server 2000 데이터 원본에 만들 수 있어야 합니다. 즉, SQL Server 2000 데이터 원본 및 MSSQLServerOLAPService 서비스가 실행되는 사용자 계정에 적절한 보안 자격 증명을 부여해야 합니다.
인덱싱된 뷰를 만들려면 사용자 계정(SQL Server 2000 데이터 원본이 사용하는 사용자 계정)에는 서버 관리자 권한이 있어야 합니다. 왜냐하면 Analysis Manager 및 기본 의사 결정 지원 개체(DSO) 관리 개체 모델은 실시간 큐브에 의해 사용되는 파티션에 대해 집계를 만들기 때문입니다. SQL Server 2000 데이터 원본이 통합 보안을 사용하는 경우, Analysis Manager 사용 중에 로그인한 사용자 계정에는 서버 관리자 권한이 있어야 합니다. SQL Server 2000 데이터 원본이 SQL Server 인증을 사용하는 경우, 데이터 원본의 연결 문자열은 서버 관리자 권한이 있는 사용자 계정을 참조해야 합니다.
보안 참고 사항 가능하면 Windows 인증을 사용하십시오.
알림 메커니즘을 사용하려면 사용자 계정(MSSQLServerOLAPService 서비스가 사용하는 사용자 계정)에는 서버 관리자 권한이 있어야 합니다. 알림 메커니즘은 팩트 및 차원 테이블 데이터의 변경 사항을 Analysis Services에 알려주는 데 사용되는 특수한 SQL Server 2000 추적 이벤트입니다. MSSQLServerOLAPService 서비스는 실시간 큐브 또는 실시간 차원을 위해 추적 이벤트를 구독하고 수신하는 수신기 스레드를 사용합니다. 알림 메커니즘, 수신기 스레드 및 추적 이벤트에 대한 자세한 내용은 실시간 변경 알림을 참조하십시오.
실시간 큐브를 만들 때에 두 개의 다른 사용자 계정이 관련될 수 있으므로(SQL Server 2000 데이터 원본용 및 MSSQLServerOLAPService 서비스용), 실시간 큐브에 대해 인덱싱된 뷰를 만들 수 있지만 해당 큐브에 대해 실시간 업데이트를 지원하는 데 필요한 알림 이벤트를 받지 못할 수 있습니다. 두 사용자 계정에 필요한 SQL Server 2000 권한이 있는지 확인한 후에 실시간 큐브를 만드십시오.
실시간 변경 알림
실시간 업데이트를 지원하는 개체를 만들 경우, Analysis Services는 이 개체가 사용하는 데이터베이스 테이블에 대해 알림 이벤트를 만들기 위해 전용 추적 이벤트 클래스와 함께 SQL Server 2000의 추적 메커니즘을 사용합니다. 실시간 차원의 경우는 차원이 사용하는 모든 테이블에 대해 알림 이벤트가 만들어집니다. 실시간 큐브의 경우는 파티션(큐브를 위해 실시간 업데이트를 지원하는 파티션)이 사용하는 팩트 테이블에 대해서만 알림 이벤트가 만들어집니다. (실시간 큐브에서 파티션에 의해 사용되는 인덱싱된 뷰는 검색 및 집계 용도로만 사용됩니다.) Analysis Services상에서 실행되는 수신기 스레드는 알림 이벤트를 구독하고 수신합니다. 알림 이벤트는 작업 단위가 아니라 트랜잭션 단위로 발생합니다. 예를 들어, 큰 팩트 테이블에 대한 수천 개의 SQL UPDATE 작업이 단일 트랜잭션에 포함되어 있는 경우 이 트랜잭션이 수행되면 한 번의 알림 이벤트만 발생합니다.
데이터베이스 트랜잭션 중에 해당 테이블에 대해 알림 이벤트가 활성화되면(예: 정기적인 업데이트를 수신하는 차원 테이블에 실시간 차원이 만들어지는 경우) 이 트랜잭션에서 알림 이벤트가 발생하지 않을 수 있습니다. 하지만 이런 경우는 매우 드물며 관계형 데이터베이스 작업이 적은 시간에 실시간 업데이트를 활성화하여 이런 경우를 막을 수 있습니다.
알림 메커니즘에서 트랜잭션별 접근 방식을 취하는 것은 중요합니다. 왜냐하면 여러 SQL INSERT, UPDATE 및 DELETE 작업을 단일 트랜잭션에서 일괄적으로 수행하여 실시간 성능을 향상시킬 수 있기 때문입니다. 알림 이벤트를 수신할 때마다 서버 캐시에 있는 개체가 무효화됩니다. 이 무효화가 미치는 영향은 서버 캐시 및 클라이언트 캐시가 동기화를 시도할 때에 중요해집니다. 자세한 내용은 클라이언트 캐시 관리를 참조하십시오
서버 캐시 관리
Analysis Services 수신기 스레드가 데이터베이스 테이블의 알림 이벤트를 수신하면, 이 스레드는 이 데이터베이스 테이블을 사용하는 모든 실시간 개체에 대해 서버 캐시를 무효화하도록 Analysis Server에게 명령합니다. 무효화를 위해 Analysis Server는 다음에 클라이언트 응용 프로그램으로부터 요청을 수신할 때 실시간 개체의 메타데이터를 업데이트해야 합니다. 데이터 요청이 수신될 경우, 해당 개체의 메타데이터가 검색되고 구성된 후에만 요청 시에 해당 개체의 데이터를 로드합니다.
쿼리 및 요청
실시간 OLAP는 요청이 처리될 때의 효율성과 속도에 부분적으로 의존합니다. 데이터 및 메타데이터 요청은 서버 캐시에 대한 업데이트를 트리거하며 캐싱을 수행하려는 데이터의 깊이와 너비를 서버 캐시에게 알려줍니다. 하지만 쿼리와 요청이 동일한 것은 아니며 요청이 반드시 쿼리인 것은 아닙니다. Analysis Services에서 "쿼리"는 클라이언트 응용 프로그램에 의해 생성된 MDX(Multidimensional Expressions) 문을 말합니다. OLE DB 공급자가 Analysis Services에 액세스할 때 사용했던 Microsoft PivotTable Service는 데이터 또는 메타데이터를 위해 MDX 문을 하나 이상의 별도 요청으로 구분합니다. PivotTable Service가 클라이언트 캐시를 통해 요청을 충족시킬 수 있으면 이 요청이 Analysis Server로 보내지지 않습니다. 동일한 방식으로 쿼리의 모든 요청을 충족시킬 수 있으면 Analysis Server와의 통신이 필요 없습니다.
하지만 PivotTable Service가 다른 이유로 요청을 보낼 수 있습니다. 클라이언트 응용 프로그램에 의해 생성된 드릴업 또는 드릴다운 요청에 응답하여 요청을 보내거나 PivotTable Service에 의해 사용되는 동기화 메커니즘을 통해 요청을 보낼 수 있습니다. 이로 인해 PivotTable Service 및 Analysis Server 사이의 통신을 예측하거나 제어하기가 다소 어려울 수 있습니다. 동기화 메커니즘의 작동 방식에 대한 자세한 내용은 클라이언트 캐시 관리를 참조하십시오.
실시간 차원 및 서버 캐싱
위에서 설명했듯이 실시간 차원은 공유되는 일반 ROLAP 차원이며 실시간 업데이트를 위해 활성화됩니다. ROLAP 차원은 Analysis Services의 다른 차원과는 다른 방식으로 처리됩니다. MOLAP 차원 구성원 및 구성원 속성은 MSSQLServerOLAPService 서비스가 시작될 때 완전히 캐싱되지만 ROLAP 차원은 요청 시에 2단계 프로세스로 관계형 데이터베이스에서 캐싱됩니다.
ROLAP 차원의 상위 수준에서 시작되는 여러 개의 구성원이 검색되어 구조를 채웁니다. 이 구성원의 개수는 Analysis Server의 대형 수준 임계값과 동일합니다.
데이터 또는 메타데이터 요청이 수신되면 요청 시에 차원 하위 트리가 구성됩니다.
또한 실시간 차원의 처리는 다른 일반 ROLAP 차원의 처리와도 다릅니다. Analysis Services는 일반 ROLAP 차원을 변경 차원으로 간주합니다. 다른 차원과 달리 변경 차원의 구조는 다음과 같은 내용이 변경되는 경우에만 재구성됩니다.
맨 위 수준 또는 맨 아래 수준을 추가, 이동, 이름 변경 또는 삭제한 경우
구성원 그룹이 포함된 수준을 추가, 이동, 이름 변경 또는 삭제한 경우
다른 경우에는 변경 차원을 증분으로 업데이트할 수 있습니다. 증분 업데이트의 이점은 큐브와 같은 종속 요소를 다시 처리할 필요가 없다는 것입니다. 실시간 차원도 비슷하게 동작합니다. 즉, 실시간 차원의 구조를 변경하지 않으면 재구성이 필요 없습니다. 하지만 실시간 차원은 요청 시에 캐싱되므로 증분 업데이트가 필요하지 않습니다. 데이터 및 메타데이터 요청이 수신되면 실시간 차원의 캐시가 무효화되고 요청 시에 다시 캐싱됩니다. 위에서 설명한 방식으로 실시간 차원의 구조가 변경되면 실시간 차원을 재구성해야 합니다.
실시간 차원에는 더 많은 성능이 집중되는 경향이 있습니다. 왜냐하면 여러 큐브가 하나의 실시간 차원에 의존하므로 기본 차원 테이블이 변경될 때 큐브의 캐싱된 결과가 무효화될 수 있습니다. 실시간 차원의 차원 테이블을 업데이트하면 실시간 큐브의 팩트 테이블을 동일하게 업데이트할 때보다 훨씬 더 많은 영향을 서버 캐시에 미칠 수 있습니다. 따라서 실시간 차원은 리소스 및 성능의 관점에서 더 "값비싼" 차원이므로 아껴서 사용해야 합니다.
실시간 큐브 및 서버 캐싱
Analysis Server에 대해 실시간 큐브는 하나 또는 두 수준의 캐싱을 가질 수 있습니다. 실시간 큐브가 실시간 차원을 사용하지 않으면 Analysis Server가 요청 시에 실시간 큐브를 위해 데이터를 검색하고 집계하며, 그 결과(데이터 및 메타데이터)를 쿼리 결과 캐시에 저장합니다. 실시간 큐브가 실시간 차원을 사용하는 경우는 실시간 차원에 필요한 하위 트리를 먼저 캐싱하여 실시간 큐브에 구조 정보를 제공해야 합니다. 그러면 실시간 큐브가 관계형 데이터베이스에서 데이터를 검색하고 이 데이터를 새로 캐싱된 구조 내에 집계합니다.
실시간 큐브는 실시간 차원에 비해 성능이 덜 집중되는 경향이 있습니다. 왜냐하면 차원 데이터의 경우 팩트 테이블을 업데이트할 때 일반적으로 재구성이 필요 없기 때문입니다. 큐브가 실시간 차원을 사용하고 이 실시간 차원이 무효화될 경우, 이 큐브를 위해 캐싱된 관련 차원 하위 트리도 무효화됩니다. 큐브가 데이터 요청을 충족시키기 위해서는 이 하위 트리를 다시 로드하고 재구성해야 합니다.
클라이언트 캐시 관리
PivotTable Service에서는 클라이언트 캐시에 다시 로드를 필요로 하는 개체가 어떤 것인지를 결정할 수 있는 버전 정보가 포함된 동기화 기술을 사용합니다. 동기화는 PivotTable Service가 데이터 또는 메타데이터 요청을 Analysis Server에 생성하는 경우나 자동 동기화가 트리거되는 경우에 실행됩니다. 이 동기화 프로세스를 관리하는 것은 서버 캐시에서 실시간 개체가 무효화되는 경우에 중요해집니다.
위에서 설명했듯이 MDX 쿼리와 데이터 또는 메타데이터 요청은 동일한 것은 아닙니다. 각 데이터 또는 메타데이터 요청에서 PivotTable Service는 서버 캐시에 있는 버전 정보와 비교하여 클라이언트 캐시에 있는 버전 정보(이 요청에서 참조되는 개체의 버전 정보)를 검사합니다. 클라이언트 캐시에 있는 버전 정보와 서버 캐시에 있는 버전 정보가 일치하면 데이터 요청이 발생하지 않으며 PivotTable Service는 필요한 정보를 클라이언트 캐시에서 직접 제공합니다. 하지만 버전이 일치하지 않으면 클라이언트 캐시에 있는 참조되는 개체가 무효화됩니다.
또한 PivotTable Service는 MDX 쿼리가 생성되지 않더라도 클라이언트 캐시를 주기적으로 동기화하려고 시도합니다. PivotTable Service에 의해 사용되는 백그라운드 스레드는 Auto Synch Period 연결 문자열 속성에 의해 지정된 간격마다 서버 캐시에 있는 해당 개체와 비교하여 클라이언트 캐시에 있는 모든 개체를 검사합니다. 특정 개체의 버전 정보가 일치하지 않거나 특정 개체에 대해 서버 캐시가 무효화된 경우, 이 개체가 클라이언트 캐시에서 무효화됩니다.
서버 캐시와 클라이언트 캐시의 한 가지 차이점은 PivotTable Service에 대해 큐브만이 캐싱됩니다. 서버 캐시에서 실시간 차원이 무효화되면 이 실시간 차원에 의존하는 큐브에 의해 사용되는 차원 하위 트리도 클라이언트 캐시에서 무효화됩니다. 서버 캐시에서 실시간 큐브가 무효화되면 이 실시간 큐브의 데이터 및 메타데이터만이 클라이언트 캐시에서 무효화됩니다.
클라이언트 캐시에서 한 개체가 무효화되면 PivotTable Service는 이 개체의 데이터를 지우고 서버 캐시에서 개체 메타데이터를 재구성하려고 시도합니다. 참고로 이 시점에서는 PivotTable Service가 데이터를 재구성하지 않으며 개체를 다시 채우기 전에 데이터 요청을 기다린 다음 그제서야 데이터 요청을 충족시킵니다.
관계형 데이터베이스에서는 단 하나의 레코드를 변경하더라도 차원 또는 큐브의 메타데이터가 무효화됩니다. 개체가 무효화되면 이 개체에 대해 수행된 쿼리는 Analysis Server가 관계형 데이터베이스에 다시 쿼리를 수행하도록 요청하며 서버 캐시에 있는 개체를 위해 데이터 및 메타데이터를 재구성합니다. 이 시간 중에 PivotTable Service가 추가적인 데이터 또는 메타데이터 요청을 보낼 수 있습니다. 이러한 추가 요청이 해결되는 방식은 참조되는 개체에 따라 다릅니다. 실시간 차원에 대해 데이터 또는 메타데이터 요청이 생성되는 경우 해당 정보를 사용할 수 있을 때에 이 요청이 완료됩니다. 실시간 큐브에 대해 데이터 요청이 생성되는 경우는 정보의 상태가 요청 성공 여부에 영향을 미칩니다. 참조된 개체 중 하나가 무효화된 때에 요청이 실행된 경우는 이 요청이 다시 실행됩니다. 참조된 개체 중 하나가 무효화된 때에 요청이 생성된 경우는 이 요청이 컨텍스트를 벗어나며 이 요청에 의해 관리되는 데이터를 참조하려는 모든 시도가 실패합니다.
실시간 OLAP 사용
실시간 OLAP를 성공적으로 사용하기 위해서는 인지성과 타이밍이 중요합니다. 실시간 OLAP를 위해 성공적으로 수행되어야 하는 모든 단계를 인지해야 하며 이 단계의 성능도 함께 모니터링해야 합니다. 일부 단계나 모든 단계 중에 타이밍이 불균형을 이룰 경우 성능에 저하될 수 있습니다. 실시간 OLAP를 사용할 때 주로 고려할 사항은 다음과 같습니다.
실시간 큐브 및 실시간 차원에 의해 사용되는 팩트 테이블 및 차원 테이블의 변경 빈도.
팩트 또는 차원 테이블에서 트랜잭션이 너무 빨리 일어나는 경우, 서버 캐시를 업데이트하기 위해 데이터베이스와 씨름하므로 Analysis Server가 잠깁니다. 서버 캐시의 개체가 너무 자주 무효화되는 경우, PivotTable Service는 급속하게 변경되고 자주 무효화되는 서버 캐시를 클라이언트 캐시와 동기화시키기 위해 시도하므로 위의 씨름이 PivotTable Service로 전해집니다. "캐시 스래시(thrash)"라고 불리는 이 씨름은 데이터 요청이 너무 자주 컨텍스트를 벗어날 경우 오류의 형태로 클라이언트 응용 프로그램에 나타납니다.
관계형 데이터베이스에서 데이터를 검색할 때 Analysis Server가 수행한 쿼리의 대기 시간.
관계형 데이터베이스에서 데이터를 검색하고 구성하는 데 너무 많은 시간이 필요한 경우 PivotTable Service의 데이터 또는 메타데이터 요청이 컨텍스트를 벗어날 수 있습니다. 이 요청은 Analysis Server가 데이터를 집계하고 캐싱한 후에 다시 실행됩니다.
클라이언트 캐시를 Analysis Server와 동기화할 때 PivotTable Service가 수행한 데이터 또는 메타데이터 요청의 빈도.
PivotTable Service 요청이 너무 자주 발생하거나 Auto Synch Period 연결 문자열의 값이 너무 낮은 경우 PivotTable Service가 클라이언트 캐시를 재동기화하는 데 시간과 리소스를 낭비할 수 있습니다. 서버 캐시의 개체를 재구성하는 데는 시간이 걸리며, 요청을 너무 자주 생성하는 경우 재구성 중에 일부 요청이 컨텍스트를 벗어날 수 있기 때문에 클라이언트 응용 프로그램에 오류가 발생할 가능성이 있습니다.
팩트 테이블 업데이트와 차원 테이블 업데이트의 차이점.
차원 테이블 업데이트는 시간 및 리소스의 관점에서 팩트 테이블 업데이트보다 더 "값비싼" 업데이트입니다. 팩트 테이블 변경 시에는 차원 하위 트리를 다시 로드하여 재구성할 필요가 없지만 차원 테이블 변경 시에는 다시 로드 하여 재구성해야 하며 이로 인해 다른 많은 큐브에 영향을 미칠 수 있습니다.
실시간 OLAP 성능 개선
다음 목록에서는 위에서 언급한 문제를 줄이고 실시간 OLAP의 성능을 향상시키기 위해 취할 수 있는 단계에 대해 자세히 설명합니다.
실시간 OLAP에 사용되는 팩트 및 차원 테이블이 포함된 트랜잭션을 가능하면 일괄 처리합니다.
알림 메커니즘은 트랜잭션 단위로 실행되므로, 작업을 일괄 처리하면 Analysis Server가 수신하는 불필요한 알림 이벤트의 수를 최소화할 수 있습니다. 예를 들어, 응용 프로그램에서는 사용자가 매 10초마다 실시간 큐브의 변경 사항을 확인해야 하는데 데이터베이스는 매 초마다 50개의 기본 팩트 테이블 업데이트를 수신한다면, 이 업데이트를 단일 트랜잭션으로 일괄 처리하고 매 5-10초마다 업데이트를 입력하여 성능을 개선할 수 있습니다. 그러면 Analysis Server는 500개의 이벤트를 수신하는 대신 매 10초마다 하나 또는 두 개의 알림 이벤트를 수신합니다.
반드시 필요한 경우에만 실시간 차원을 사용합니다.
실시간 차원은 시간과 리소스를 소비합니다. 차원에 실시간 업데이트가 꼭 필요한지 아니면 차원에 빈번한 증분 업데이트가 필요한지를 고려해야 합니다. 차원이 변경되는 대기 시간 구간이 수 시간 이상으로 측정될 수 있는 경우는 실시간 차원을 사용하는 대신 변경되는 ROLAP 차원을 사용합니다. 실시간 차원 대신 실시간 큐브를 사용하여 비즈니스 요구 사항을 충족시킬 수 있다면 실시간 큐브를 선택합니다.
실시간 차원을 구성할 때 깊은 계층 구조를 사용하고 대형 수준 임계값을 조정합니다.
실시간 차원이 무효화되면 대형 수준 임계값에 따라 초기에 구성원이 로드됩니다. 실시간 차원을 더 자주 업데이트해야 하는 경우는 이 한도 설정이 더 낮아야 합니다. 왜냐하면 실시간 차원이 무효화될 때마다 이 개수의 구성원을 로드해야 하기 때문입니다. 이 구성원이 로드된 후 요청 요구 사항에 따라 차원 하위 트리가 요청 시에 로드됩니다. 계층이 더 깊을수록 요청을 충족시키기 위해 로드해야 하는 구성원이 더 적습니다(요청 자체의 요구 사항에 따라 다름). 초기 로딩 및 요청 시 로딩의 균형을 조정하면 차원의 용도 및 기본 차원 테이블의 업데이트 빈도에 따라 실시간 차원의 로딩을 최적화할 수 있습니다.
예를 들어, All 수준, Location 수준 및 OrganizationMember ID 수준(리프 수준으로 사용)의 세 수준만 있는 OrganizationMember 차원이 있다고 가정해 보겠습니다. Analysis Server의 대형 수준 임계값은 5,000개의 구성원입니다. 위치는 세 개만 있는데 리프 수준에 300,000개의 구성원이 있다면 이 차원의 단일 하위 트리를 로드하려면 한 번에 최소 100,000개의 구성원을 로드해야 합니다. 대형 수준 임계값은 이 구성원이 초기에 로드되는 것을 막아줍니다. 그 대신 이 구성원은 요청 시에 로드됩니다. 이 전략에서는 차원 테이블이 변경될 때 무효화 구간은 길어지지만 신속한 초기 로드를 제공합니다. Location 수준과 OrganizationMember ID 수준 사이에 PostalCode라는 이름의 새 수준을 추가하고 이 새 수준에 1,000개의 구성원(리프 구성원이 균일하게 분산된 구성원)가 있다면 이 수준이 초기에 로드될 수 있으므로 초기 로드 시간이 약간 더 걸립니다. 이제 각 차원 하위 트리에서는 차원 데이터 요청을 수행하기 위해 300개의 구성원만을 로드하면 되므로 요청 시에 데이터를 로드할 때 성능이 상당히 향상됩니다.
실시간 요구 사항에 따라 실시간 큐브를 파티션합니다.
다른 큐브와 마찬가지로 실시간 큐브에도 여러 개의 파티션이 포함될 수 있으며 실시간 업데이트를 위해 어떤 파티션이 활성화되어 있는지를 결정할 수 있습니다. 실시간 업데이트가 단일 파티션에만 필요하도록 실시간 큐브를 설계하고 또한 실시간 업데이트가 필요한 여러 파티션의 크기가 최대한 작도록 실시간 큐브를 설계하십시오. 이렇게 하는 목적은 팩트 테이블이 업데이트될 때마다 다시 로드되어야 하는 데이터의 양을 줄이기 위해서 입니다.
예를 들어, 실시간 큐브에 현재 구간과 이전 구간에 대한 변경 사항이 나타난 경우(예: 매일 또는 매주 단위로 제조라인의 현재 및 과거 성능을 모니터링하는 큐브), 이 큐브를 구간별로 파티션하고 현재 구간을 나타내는 파티션에 대해서만 실시간 업데이트를 활성화합니다.
실시간 차원은 변경 차원으로 간주되므로 실시간 차원은 파티션에 데이터 슬라이스를 설정하는 데 사용될 수 없습니다.
필요한 경우 실시간 개체의 빈도와 대기 시간에 맞게 PivotTable Service Auto Synch Period 연결 문자열 속성을 조정합니다.
Auto Synch Period 연결 문자열 속성의 기본값은 10초이지만 250밀리초까지 낮게 설정될 수 있습니다. 하지만 이러한 속성 설정의 효과에 다음과 같은 요인이 영향을 미칠 수 있습니다.
데이터베이스의 변경 빈도
서버 캐시 업데이트의 대기 시간
클라이언트 캐시 동기화의 대기 시간
실시간 개체를 위해 클라이언트 캐시를 더 빠르게 동기화하려는 의도에서 이 설정을 너무 낮게 설정하면 PivotTable Service의 데이터 및 메타데이터 요청이 서버에 쇄도할 수 있습니다. 이 속성을 너무 낮게 설정하면 오류 메시지, "#ERR" 셀 값 또는 쿼리 해결 시간의 지연과 같은 오류가 클라이언트 응용 프로그램에 나타날 수 있습니다. 예를 들어, 실시간 차원 및 큐브에 의해 사용되는 팩트 및 차원 테이블의 변경 빈도가 평균 약 10초이고 서버 캐시에서 이 개체를 업데이트하는 대기 시간이 약 2초이고 클라이언트 캐시를 서버 캐시와 동기화하는 시간이 약 2초인 경우, Auto Synch Period 속성을 250밀리초로 설정하면 PivotTable Service는 위의 동기화를 해결할 때보다 8배나 빠른 속도로 동기화를 시도하며 실제의 데이터베이스 변경 빈도보다 40배나 더 빨라집니다.
또한 PivotTable Service가 클라이언트 캐시를 서버 캐시와 동기화하려는 시기를 정확하게 예측하는 것도 어려울 수 있습니다. 왜냐하면 동기화는 이 속성에 의해 지정된 간격마다 발생할 뿐만 아니라 클라이언트 응용 프로그램과의 직접적인 상호 작용(예: 사용자가 실시간 차원을 드릴다운하거나 새 MDX 쿼리를 보낼 경우)에 의해서도 발생하기 때문입니다.
이 속성을 성공적으로 사용하기 위해서는 관찰과 실험이 중요합니다. 일반적으로 실시간 OLAP의 최소 대기 시간 구간은 10초이므로 대부분의 실시간 OLAP 응용 프로그램에서 Auto Synch Period 속성을 변경해서는 안됩니다.
결론
Analysis Services에서 실시간 OLAP는 대기 시간이 짧은 집계된 데이터에 액세스할 수 있는 효과적인 방법입니다. 실시간 OLAP의 성능과 예상은 네트워킹, 데이터베이스 및 Analysis Server 사용량을 비롯한 여러 요인과 큐브 및 차원의 설계에 따라 다를 수 있습니다. 하지만 설계 및 성능 튜닝을 통해 이러한 요인을 고려하고 경감시키면 실시간 OLAP의 이점이 명확해집니다.
추가 정보
SQL Server 온라인 설명서에는 Analysis Services에 대한 자세한 내용이 들어 있습니다. 자세한 내용은 다음 리소스를 참조하십시오.
Microsoft SQL Server 웹 사이트
Microsoft SQL Server Developer Center (영문)
SQL Server Magazine (영문)
SQL Server에 대한 MOC(Microsoft Official Curriculum) 과정 (영문)
microsoft.public.sqlserver.programming 및 microsoft.public.sqlserver.datawarehouse 뉴스 그룹 (영문) 페이지 맨 위로
