앱 성능 최적화
앱 성능은 축소된 앱 크기, 간단한 데이터 모델 및 집합 분석의 전략적 사용을 통해 개선할 수 있습니다. 이 섹션에서는 성능에 영향을 줄 수 있는 영역과 앱 성능을 평가하고 모니터링할 수 있는 방법을 설명하여 성능 문제를 방지하는 데 도움을 줍니다.
성능 평가 도구를 사용하여 앱의 성능을 확인할 수 있습니다. 자세한 내용은 앱 성능 평가을 참조하십시오.
앱 복잡성
다음과 같이 포괄적인 범주로 분류하면 문제를 진단하는 데 도움이 됩니다. 가장 복잡한 앱이 성능이 가장 낮습니다.
간단한 앱:
- 복잡한 집합 분석이나 If() 문을 포함하지 않습니다.
- 큰 테이블을 포함하지 않습니다.
- 간단한 데이터 모델이 있습니다.
- 간단한 계산을 포함합니다.
- 큰 데이터 볼륨이 있을 수 있습니다.
보통 앱:
- 테이블이 많은 데이터 모델이 있지만 모범 사례를 따릅니다.
- 집합 분석 및 여러 개의 If() 문을 사용합니다.
- 시트에 15개 이상의 열이 있는 큰 테이블 또는 긴 테이블이 있습니다.
복잡한 앱:
-
매우 복잡한 데이터 모델이 있습니다.
- 큰 데이터 볼륨에 연결됩니다.
- 복잡한 계산, 차트 및 테이블을 포함합니다.
큰 데이터 볼륨
큰 데이터 볼륨에 연결하는 경우 다음과 같은 아키텍처 전략을 사용할 수 있습니다.
분할
QVDs를 차원(예: 시간 프레임, 지역, 집계 수준)별로 분할할 수 있습니다. 예를 들어 다음을 확인할 수 있습니다.
- 가장 최근 2년 동안의 데이터를 포함하는 QVD
- 2년 이상의 기록 데이터를 포함하는 QVD
상위 수준에서 집계된 모든 데이터를 포함하는 QVD. 예를 들어 날짜 대신 월별로 집계하거나 개별 고객 대신 국가별로 집계합니다.
- 모든 데이터를 포함하는 하나의 큰 QVD, 소규모의 사용자 하위 집합에서만 사용
유사한 방식으로 앱을 분류할 수 있습니다. 작은 앱이 대부분 사용자의 분석 요구를 해결합니다. 이 앱은 메모리가 절약됩니다.
다른 지역에 중점을 둔 여러 앱을 사용할 수도 있습니다. 이렇게 하면 사용자가 관심이 없는 데이터를 포함한 앱이나 액세스 권한이 없는 앱을 열지 않습니다. Section Access를 통해 액세스할 수 없는 데이터도 여전히 메모리에 영향을 미칩니다.
On-demand 앱 생성ODAG
Qlik Sense On-demand 앱은 사용자에게 빅 데이터 저장소 집계 보기를 제공합니다. 사용자는 자세한 분석을 위해 관련 데이터 하위 집합을 식별하고 로드할 수 있습니다.
사용자 관점에서 다음 두 앱이 있습니다.
- 집계된 데이터가 있는 장바구니
- 세부 정보를 표시하는 데 사용되는 빈 템플릿 앱
사용자는 장바구니 앱에서 선택을 수행합니다. 임계값에 도달하면, 요청한 세부 정보로 템플릿 앱을 채우는 사용자 지정 LOAD 스크립트가 만들어집니다.. 자세한 내용은 On-demand 앱으로 빅 데이터 관리를 참조하십시오.
응용 프로그램 연결
응용 프로그램 연결(QlikView에서는 문서 연결이라고 함)은 사용자가 정기적으로 사용하는 집계된 앱이 있음을 의미합니다. 사용자에게 더 자세한 정보가 필요한 경우 선택 항목을 집계된 앱에서 상세 앱으로 전달하여 더 낮은 수준의 세분성을 볼 수 있습니다. 이렇게 하면 사용자가 불필요한 세부 정보를 로드하지 않기 때문에 메모리가 절약됩니다. 시트에 버튼 개체를 추가하여 응용 프로그램 연결을 수행할 수 있습니다.자세한 내용은 응용 프로그램 연결을 참조하십시오.
응용 프로그램 연결은 APIs를 통해서도 지원됩니다. 예를 들어, 앱 통합 API를 사용하여 사용자 지정 응용 프로그램 연결을 만들 수 있습니다. 자세한 내용은 앱 통합 API (영어로만 제공)를 참조하십시오.
동적 보기
동적 보기를 통해 많은 데이터 볼륨 또는 빠르게 변환하는 데이터 시나리오에 대한 시각화를 최신으로 유지할 수 있습니다. 동적 보기 작업 시 다음 사항을 고려합니다.
동적 보기를 업데이트하면 데이터 소스가 직접 로드됩니다. 업데이트 성능은 기본 데이터 소스의 성능에 영향을 받습니다.
동적 보기 템플릿 앱을 사용하면 동적 차트를 만드는 데 도움이 됩니다.
동적 보기 사용에 대한 자세한 내용은 동적 보기를 사용한 데이터 관리를 참조하십시오.
Direct Query
인 메모리 앱이 권장되지만 Direct Query를 사용하면 데이터를 원본 소스에 유지할 수 있습니다. Direct Query 사용을 최적화하려면 다음 사항을 고려하십시오.
Direct Query의 성능은 기본 데이터 소스의 성능의 영향을 크게 받습니다.
복잡한 쿼리로 인해 성능 문제가 발생할 수 있으므로 Direct Query 데이터 모델을 최대한 단순하게 유지하십시오.
Direct Query에 대한 자세한 내용은 로 클라우드 데이터베이스에 직접 액세스Direct Query를 참조하십시오.
데이터 모델 성능
다음은 데이터 모델 성능에 영향을 미칠 수 있는 표시기입니다. 각각은 앱 유용성을 개선하는 각각의 모범 사례입니다.
동작 | 설명 |
---|---|
가상 키 제거 | Qlik Sense는 둘 이상의 데이터 테이블에 둘 이상의 공통 필드가 있는 경우 가상 키를 만듭니다. 이는 스크립트 또는 데이터 모델에 오류가 있음을 의미할 수 있습니다. 가상 키를 진단하려면 가상 키를 참조하십시오. |
데이터 모델에서 순환 참조 제거 | 두 개의 필드에 둘 이상의 연결이 있는 경우 순환 참조가 발생합니다. Qlik Sense는 테이블 중 하나에 대한 연결을 변경하여 이 문제를 해결하려고 합니다. 하지만 모든 순환 참조 경고를 해결해야 합니다. 순환 참조에 대한 이해 및 해결를 참조하십시오. |
적절한 데이터 세분성 | 필요한 데이터만 로드해야 합니다. 예를 들어 사용자 그룹에서 주, 월 및 연도로 나뉜 데이터만 필요합니다. 집계된 데이터로 로드하거나 로드 스크립트 내에서 데이터를 집계하여 메모리를 절약할 수 있습니다. 사용자가 낮은 수준의 세분성으로 데이터를 시각화해야 하는 경우 ODAG 또는 문서 연결을 사용할 수 있습니다. |
가능한 경우 QVDs 사용 | QVD는 Qlik Sense에서 내보낸 데이터의 테이블을 포함한 파일입니다. 이 파일 형식은 스크립트에서 데이터를 읽는 속도에 최적화되어 있지만 크기는 매우 작습니다. 파일 형식은 스크립트에서 데이터를 읽는 속도에 최적화되어 있지만 크기는 매우 작습니다. QVD 파일에서 데이터를 읽는 속도는 일반적으로 다른 데이터 소스에서 데이터를 읽는 것보다 10-100배 정도 빠릅니다. 자세한 내용은 QVD 파일 작업을 참조하십시오. |
로드 시 QVD 파일 최적화 | QVD 파일은 표준(빠름) 모드와 최적화(매우 빠름) 모드에서 읽을 수 있습니다. 모드 선택은 스크립트 엔진에서 자동으로 결정합니다. 최적화된 로드에는 몇 가지 제한 사항이 있습니다. 필드의 이름을 변경할 수는 있지만 다음 작업 모두 표준 로드를 발생시킵니다.
|
증분 로드 활용 | 앱이 지속적으로 업데이트되는 데이터베이스의 대용량 데이터에 연결되는 경우 전체 데이터 집합을 다시 로드하려면 시간이 오래 걸릴 수 있습니다. 대신 증분 로드를 사용하여 데이터베이스의 새 레코드나 변경된 레코드를 검색해야 합니다. 자세한 내용은 증분 로드를 통해 새 레코드 및 업데이트된 레코드 로드를 참조하십시오. |
Snowflake 모델 통합 | 눈송이형 데이터 모델이 있는 경우 Join 접두사 또는 기타 매핑을 사용하여 데이터 테이블 중 일부를 조인함으로써 데이터 테이블 수를 줄일 수 있습니다. 이것은 큰 팩트 테이블에 특히 중요합니다. 실제 좋은 방법은 하나의 큰 테이블만 갖는 것입니다. 자세한 내용은 조인하거나 조인하지 않으려면을 참조하십시오. |
필드 수가 적은 테이블 비정규화 | 필드 수가 적은 두 개의 테이블이 있는 경우 두 테이블을 조인하여 성능을 개선할 수 있습니다. 자세한 내용은 Join 및 Keep을 사용한 테이블 결합를 참조하십시오. |
매핑 로드를 사용하여 조회(리프) 테이블 비정규화 | 한 테이블의 필드를 다른 테이블에 하나만 추가해야 하는 경우 Join 접두사를 사용하면 안 됩니다. ApplyMap 조회 함수를 사용해야 합니다. 조인하지 말고 ApplyMap 사용을 참조하십시오. |
날짜 필드에서 타임스탬프 제거 또는 분리 | 문자열 표현이 더 크고 고유 값의 수가 더 많아 타임스탬프가 있는 경우 날짜 필드가 공백을 채울 수 있습니다. 분석에 정밀도가 필요하지 않은 경우 Timestamp(Floor(YourStimestamp, 1/24))를 사용하여 타임스탬프를 가장 가까운 시간 등으로 반올림하거나 Date(Floor(YourTimestamp))를 사용하여 시간 구성 요소를 완전히 제거할 수 있습니다. 타임스탬프가 필요한 경우 날짜 자체에서 분리할 수 있습니다. 동일한 Floor() 함수를 사용하고 다음 줄과 함께 사용하여 추출된 시간으로 새 필드를 만들 수 있습니다. Time(Frac(YourTimestamp)). |
데이터 모델에서 불필요한 필드 제거 | 데이터 모델에서 필요한 필드만 로드해야 합니다. Load *와 SELECT를 사용하지 마십시오. 다음 필드는 유지합니다.
|
볼륨이 큰 데이터를 처리할 때 링크 테이블 방지 | 가능한 경우 링크 테이블을 사용해야 합니다. 그러나 큰 데이터 볼륨을 처리하는 경우 연결된 테이블이 링크 테이블보다 성능이 뛰어납니다. |
연결된 차원을 새 필드로 분리 | 연결된 차원을 별도의 필드로 분리해야 합니다. 이렇게 하면 필드에서 고유한 값의 발생 수가 줄어듭니다. 이 방법은 타임스탬프를 최적화하는 방법과 유사합니다. |
가능한 경우 AutoNumber 사용 | 먼저 QVD 파일에서 데이터를 로드하여 최적화된 로드를 만든 다음 AutoNumber 문을 사용하여 값을 기호 키로 변환할 수 있습니다. 자세한 내용은 AutoNumber를 참조하십시오. |
데이터 섬 방지 | 데이터 섬은 유용하기도 하지만 대부분 성능에 영향을 미칩니다. 선택 값에 대한 섬을 만드는 경우 변수를 사용합니다. |
증분 타임프레임을 기반으로 QVD 저장 | QVD를 분할하여(예: 월별) 저장해야 합니다. 그러면 이 소규모 월별 QVD는 모든 데이터가 필요하지 않을 수 있는 다양한 앱을 지원할 수 있습니다. |
시트 성능
다음은 시트 및 시각화의 성능을 개선하는 모범 사례입니다.
동작 | 설명 |
---|---|
가능한 경우 If() 함수 사용 방지 | 집계 함수 내에서 If() 함수를 사용하면 레코드 수준에서 작동하고 여러 번 평가됩니다. 예를 들어 집계에 1000개의 레코드가 있는 경우 If() 조건이 1000번 평가됩니다. 이로 인해 문을 포함하는 경우 신속히 계단식으로 적용될 수 있습니다. 대신 집합 분석을 사용해야 합니다. 집합 분석 필터는 집계 전에 적용되므로 응답 속도가 빨라집니다. 이러한 응답은 집합 분석을 통해 캐시될 수도 있습니다. If()의 경우는 그렇지 않습니다. 데이터 모델에 다른 함수 및 수정을 고려할 수도 있습니다. |
집계 테이블 내 여러 테이블의 필드는 가능하면 피합니다. | 집계를 평가할 때 계산은 다음 두 단계를 통해 실행됩니다:
단일 스레드 부분은 성능에 상당한 영향을 미칠 수 있습니다. 한 가지 예는 집계 내에 여러 필드가 있는 경우입니다(예: Sum(Quantity*ListPrice)). Quantity이 팩트 테이블에 있고 ListPrice이 마스터 제품 테이블에 있는 경우 엔진은 먼저 두 테이블을 조인하여 조합을 찾아야 제품을 합산할 수 있습니다. 조인은 단일 스레드 부분이고 합산은 다중 스레드입니다. 두 필드가 동일한 테이블에 있는 경우 조인이 필요하지 않으며 집계가 훨씬 빠르게 평가됩니다. |
Aggr() 및 중첩 Aggr() 함수 최소 사용 | Aggr() 함수는 성능에 매우 큰 영향을 미칩니다. 잘못 사용하면 부정확한 결과가 발생할 수 있습니다. 예를 들어 Aggr() 함수 내의 차원과 다른 차원이 있는 테이블에서 사용하는 경우입니다. 자세한 내용은 AGGR을 사용해서는 안 되는 경우를 참조하십시오. |
가능한 경우 집합 분석 사용 | 집합 분석을 사용하여 현재 선택에 의해 정의된 일반 집합과 다른 데이터 값의 집합을 정의할 수 있습니다. 자세한 내용은 집합 분석을(를) 참조하십시오. |
가능한 경우 문자열 비교 사용 방지 | 문자열 비교는 집합 분석만큼 효과적이지 않습니다. 예를 들어, Match(), MixMatch(), WildMatch() 및 Pick()은 사용하지 않아야 합니다. 대신 스크립트에서 플래그를 만들거나 집합 분석을 사용합니다. 자세한 내용은 조건부 함수 및 조건부 집계의 성능을 참조하십시오. |
계산이 많은 개체에 계산 조건 사용 | 선택하지 않은 레코드가 많은 시각화가 있을 수 있습니다. 계산 조건을 개체에 추가하여 특정 선택 후에만 렌더링되도록 하는 것이 좋습니다. 이렇게 하면 아주 큰 하이퍼큐브가 만들어지지 않습니다. 예: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. 이 경우 사용자가 단일 국가를 선택하거나 단일 국가만 가능한 다른 선택을 하지 않을 경우 시각화가 렌더링되지 않습니다. |
가능한 경우 스크립트에서 측정값 사전 계산 | 데이터 모델의 최하위 세분성 수준에 있는 측정값은 스크립트에서 계산해야 합니다. 예를 들어, 테이블의 동일한 레코드에 Sales 및 Cost가 있는 경우 Sales - Cost AS Margin을 계산하여 수익을 파생할 수 있습니다. 값이 선택에 따라 달라지지 않거나 다른 세분성 수준에 바인딩되어 있는 것을 알고 있다면 다른 값을 미리 집계할 수도 있습니다. |
테이블에 15개 미만의 열 포함 및 계산 조건 포함 | 15개의 열이 포함된 테이블은 넓은 것으로 간주할 수 있습니다. 테이블이 여러 개의 레코드로 구성된 경우 특정 선택 또는 기준이 충족될 경우에만 렌더링되도록 테이블 개체에서 계산 조건을 사용해야 합니다. 테이블이 매우 넓은 경우 다음을 수행하는 것이 좋습니다.
|
시트에 과도한 수의 개체를 포함하지 않음 | 사용자가 시트로 이동하면 개체가 계산됩니다. 사용자가 해당 시트에서 선택을 수행할 때마다 현재 상태가 캐시에 없는 경우 각 개체는 다시 계산됩니다. 여러 개의 차트가 포함된 시트가 있는 경우 사용자는 모든 개체가 거의 모든 선택을 계산할 때까지 기다려야 합니다. 이렇게 하면 엔진에 상당한 부하를 줍니다. Dashboard/Analysis/Reporting (DAR) 개념에 따라 간단한 최소 앱을 개발하는 것이 좋습니다. 자세한 내용은 DAR 방법론을 참조하십시오. |
스크립트에서 집합 분석에 사용할 숫자 플래그 활용 | 플래그를 사용한 집합 분석은 문자열 비교 또는 곱셈을 사용하는 것보다 더 효율적일 수 있습니다. |
마스터 항목을 사용하여 관리되는 메트릭을 끌어서 놓으면 표현식이 캐시되도록 할 수 있습니다. 예를 들어 Sum(Sales)은 SUM(Sales)과 다릅니다. 표현식은 철자 및 대소문자로 캐시되며 축자가 일치해야 다시 사용할 수 있습니다. |
데이터 로드 성능
Qlik Cloud에서 앱을 사용할 때 원활하고 응답성이 뛰어난 환경을 위해서는 데이터 로드 최적화가 중요합니다. 이 섹션에서는 성능에 영향을 미치는 요소를 강조 표시하고 성능 문제를 방지하는 방법에 대한 지침을 제공합니다.
Qlik 데이터 게이트웨이 - 직접 액세스
Qlik 데이터 게이트웨이 - 직접 액세스를 사용하여 데이터를 앱에 다시 로드하면 다음 요소가 성능에 영향을 미칩니다.
데이터 게이트웨이를 호스팅하는 컴퓨터와 데이터베이스 간의 연결 속도 및 지연 시간입니다.
데이터 게이트웨이를 호스팅하는 컴퓨터와 Qlik Cloud 테넌트 간의 연결 속도 및 지연 시간입니다. 이상적으로는 성능 향상을 위해 Qlik Cloud 테넌트와 동일한 지역에서 데이터 게이트웨이를 호스팅합니다.
데이터베이스 저장소
저장소 연결 속도가 느리면 다시 로드 시간이 늘어날 수 있습니다. 온프레미스 또는 클라우드에서 호스팅되는 데이터베이스의 경우 다음을 고려하십시오.
온프레미스: 데이터베이스가 온프레미스에 있고 다른 응용 프로그램과 서버를 공유하는 경우 이러한 다른 응용 프로그램의 활동으로 인해 성능이 영향을 받을 수 있습니다.
클라우드: 적정 크기의 클라우드 데이터베이스는 일반적으로 온프레미스 데이터베이스보다 우수한 성능을 제공합니다. 최적의 결과를 얻으려면 Qlik Cloud 테넌트에 가까운 클라우드 저장소 지역을 선택합니다.