Vertipaq의 데이터 인덱싱: 행 저장소 대 열 저장소

이 자습서에서는 관계형 데이터베이스와 Vertipaq에서 데이터 인덱싱이 작동하는 방식의 차이점을 다룰 것입니다.

관계형 데이터베이스는 행 단위로 데이터를 저장합니다. 반면에 Vertipaq은 열 단위로 수행합니다.

데이터를 저장하고 인덱싱하는 이 두 가지 방법이 특히 쿼리를 실행할 때 보고서 개발 프로세스에 어떤 영향을 미칠 수 있는지 살펴보겠습니다.

목차

• 행당 데이터 인덱싱
• 열당 데이터 인덱싱
• 간단한 쿼리에서 실행 시간 비교
• 더 복잡한 쿼리에서 실행 시간 비교
• 결론

행당 데이터 인덱싱

행별로 데이터를 저장하는 것은 데이터를 저장하는 전통적인 방법입니다. 그러나 이 프로세스는 시간이 더 걸리므로 쿼리 성능에 영향을 미칩니다.

브랜드, 색상, 성별, 수량 및 순 가격이 포함된 테이블이 있다고 가정해 보겠습니다.

이 테이블의 모든 것을 데이터베이스에 저장하면 데이터가 행별로 저장됩니다. 그래서 전통적인 데이터 저장소 구조를 행 저장소라고도 합니다.

먼저, 같은 줄에 브랜드, 색상, 성별, 수량 및 순 가격과 같은 첫 번째 행에 있는 열 머리글을 저장합니다. 그런 다음 다음 줄로 이동하여 A. Datum, Azure, 공백, 1 및 103.2와 같은 각 열 아래의 첫 번째 항목을 저장합니다. 이것은 행별로 계속됩니다.

그렇다면 이 데이터 인덱싱 방법을 사용하여 Quantity의 계산하려면 어떻게 해야 할까요 ?

먼저 열 머리글을 포함하는 첫 번째 행부터 시작합니다. 그런 다음 다음 줄로 이동하여 처음 보는 수량(1)에 도달할 때까지 다른 데이터 조각을 건너뜁니다. 양이 발견됩니다.

각 행에서 모든 수량을 따로 설정하면 계산이 완료되는 유일한 시간입니다.

SQL 데이터 원본에 대한 DirectQuery 연결을 사용하는 LuckyTemplates 보고서를 준비하는 경우 프로세스가 얼마나 지루한지 상상할 수 있습니다. 이 경우 분석 서비스는 DAX 코드를 SQL 언어로 변환한 다음 데이터 구조를 행별로 살펴보기 시작합니다.

열당 데이터 인덱싱

관련된 긴 프로세스를 피하기 위해 가져오기 모드를 선택할 때 Vertipaq을 통해 열별로 데이터를 저장할 수 있는 옵션이 있습니다.

행 저장소 대신 열 저장소를 사용하면 브랜드, 색상, 성별, 수량 및 순 가격이 각각 다른 데이터 구조에 저장됩니다.

Quantity 열에 있는 값의 합계를 얻고 싶다고 가정해 보겠습니다. 브랜드, 색상 및 수량 열 외부의 기타 데이터를 통과할 필요가 없습니다. 단일 스캔에서 전체 Quantity 열을 위에서 아래로 읽고 모든 값을 합산합니다.

이 때문에 쿼리는 왼쪽에서 오른쪽으로 수행하는 것과 비교하여 더 빠르게 실행됩니다.

간단한 쿼리에서 실행 시간 비교

행 저장소와 열 저장소의 큰 차이를 실제로 확인하기 위해 SQL과 Vertipaq 모두에서 몇 가지 테스트 쿼리를 수행해 보겠습니다. 실행 시간은 한 프로세스가 다른 프로세스와 비교하여 얼마나 빠른지 알려줍니다.

SQL의 간단한 쿼리부터 시작하겠습니다. Sales 테이블에서 Quantity 열의 SUM을 계산할 것입니다.

보시다시피 총 실행 시간은 2.2초입니다.

이제 DAX Studio로 이동하여 EVALUATE 함수를 사용하여 동일한 쿼리를 실행해 보겠습니다. 서버 타이밍을 켜고 추적이 완료될 때까지 기다려야 합니다.

또한 쿼리를 실행할 때 "Clear Cache then Run" 옵션이 선택되어 있는지 확인해야 합니다.

쿼리가 실행되면 이전에 SQL에서 수행한 것과 동일한 쿼리를 완료하는 데 3밀리초밖에 걸리지 않는다는 것을 알 수 있습니다.

결과 집합도 SQL 및 DAX Studio 모두에 대해 일치해야 합니다. 나란히 놓으면 동일한 값을 반환하고 있음을 알 수 있습니다.

쿼리를 몇 번 더 실행하여 실행 시간이 얼마나 일관된지 확인할 수 있습니다.

더 복잡한 쿼리에서 실행 시간 비교

이번에는 더 복잡한 쿼리를 실행할 때의 실행 시간을 비교해 보겠습니다.

각 브랜드에 대한 판매 수량의 SUM을 식별하려고 한다고 가정해 보겠습니다 . 이를 위해 각 제품 브랜드의 에 대해 낮은 컨텍스트에서는 판매 수량의 합계를 계산할 Quantity라는 새 테이블도 생성합니다 .

이 코드를 실행하면 총 실행 시간이 7밀리초임을 알 수 있습니다.

백그라운드에서 이 코드는 실제로 두 개의 쿼리를 실행하고 있습니다. 첫 번째는 Products 테이블에서 Brand 열을 가져온 다음 Sales 열과 Products 열 모두에서 Product Key 열에 대해 OUTER JOIN을 실행합니다.

두 번째 쿼리는 단순히 Products 테이블에서 Brand 열을 검색합니다.

결과 화면으로 이동하면 총 수량 측정이 각 브랜드를 기준으로 분할된 것을 볼 수 있습니다.

이제 SQL 서버로 이동하여 동일한 쿼리를 작성해 보겠습니다.

DaxStudio Sales 테이블을 다음 줄로 푸시하여 Sales 테이블 AS S를 참조합니다. 그런 다음 AS P를 참조하는 DaxStudio Products 테이블에서 LEFT JOIN을 실행하고 S.Product 키는 P.제품 키. 또한 SELECT 문 에서 Quantity 및 Total Quantity의 SUM 과 함께 P.Brand를 사용할 것입니다 . 사용할 것입니다 .

이 코드를 실행하면 이전에 Vertipaq에서 얻은 것과 동일한 각 브랜드별로 분리된 총 수량을 포함하는 테이블을 얻게 됩니다.

총 실행 시간은 2.5초로 훨씬 느리게 유지됩니다.

LuckyTemplates용 DAX: DAX Studio에서 수식 엔진을 사용하여 최적화
DAX 쿼리 최적화 기술 및 학습
쿼리 성능 및 DAX Studio 설정

결론

Vertipaq을 통한 열 저장소가 SQL 데이터베이스의 행 저장소와 비교할 때 실제로 얼마나 빠른지는 분명합니다. 이는 다양한 플랫폼에서 데이터 인덱싱이 작동하는 방식을 실제로 파악하는 것의 중요성을 보여줍니다.

행 저장소가 쿼리를 실행하는 7밀리초에 비해 여전히 2.5초 동안 이동하도록 선택하는 경우 처음에는 작은 희생처럼 보일 수 있습니다. 그러나 우리는 모두 보고서를 만들 때 여러 쿼리를 실행하고 이러한 모든 실행 시간이 합산되어 장기적으로 생산성과 사용자 경험에 영향을 미칩니다.