응용 프로그램 성능 최적화

응용 프로그램 성능은 응용 프로그램 크기 축소, 단순화된 데이터 모델 및 집합 분석의 전략적 사용을 통해 향상될 수 있습니다. 이 섹션은 성능에 영향을 미칠 수 있는 영역과 응용 프로그램 성능을 평가하고 모니터링하는 방법을 지적하여 성능 문제를 방지하는 데 도움이 됩니다.

성능 평가 도구를 사용하여 응용 프로그램의 성능을 모니터링할 수 있으며, 더 큰 엔진을 수동으로 할당하여 다양한 엔진 크기에서 어떻게 작동하는지 테스트할 수도 있습니다. 자세한 내용은 응용 프로그램 성능 평가 및 응용 프로그램 성능 향상을 위한 엔진 할당을 참조하십시오.

응용 프로그램 복잡성

다음은 문제를 진단하는 데 도움이 될 수 있는 느슨한 범주입니다. 가장 복잡한 응용 프로그램의 성능이 가장 낮습니다.

단순한 응용 프로그램:

복잡한 집합 분석이나 If() 문을 포함하지 않습니다.
큰 테이블을 포함하지 않습니다.
단순한 데이터 모델을 갖습니다.
단순한 계산을 포함합니다.
데이터 볼륨이 클 수 있습니다.

보통의 응용 프로그램:

많은 테이블이 있는 데이터 모델을 갖지만 모범 사례를 따릅니다.
집합 분석과 여러 If() 문을 사용합니다.
시트에 크거나 넓은 테이블(15개 이상의 열)이 있습니다.

복잡한 응용 프로그램:

매우 복잡한 데이터 모델을 갖습니다.
대용량 데이터 볼륨에 연결합니다.
복잡한 계산, 차트 및 테이블을 포함합니다.

대용량 데이터 볼륨

대용량 데이터 볼륨에 연결할 때 이러한 아키텍처 전략을 사용할 수 있습니다.

세분화

기간, 지역 또는 집계 수준과 같은 차원별로 QVDs를 세분화할 수 있습니다. 예를 들어 다음과 같이 할 수 있습니다.

가장 최근 2년의 데이터를 포함하는 QVD.
2년 이전의 과거 데이터를 포함하는 QVD.
더 높은 수준에서 집계된 모든 데이터를 포함하는 QVD. 예를 들어 날짜 대신 월별로, 또는 개별 고객 대신 국가별로 집계합니다.
소수의 사용자 하위 집합에서만 사용하는 모든 데이터가 포함된 하나의 큰 QVD.

비슷한 방식으로 응용 프로그램을 세분화할 수 있습니다. 더 작은 응용 프로그램은 대부분의 사용자의 분석 요구 사항을 해결합니다. 이렇게 하면 메모리가 절약됩니다.

또한 다른 지역에 초점을 맞춘 여러 응용 프로그램을 가질 수도 있습니다. 이렇게 하면 사용자가 관심이 없거나 액세스 권한이 없는 데이터가 포함된 응용 프로그램을 열지 않습니다. 섹션 액세스를 통해 액세스할 수 없는 데이터도 여전히 메모리에 영향을 미칩니다.

주문형 응용 프로그램 생성(ODAG)

Qlik Sense 주문형 응용 프로그램은 사용자에게 빅 데이터 저장소의 집계 보기를 제공합니다. 상세한 분석을 위해 데이터의 관련 하위 집합을 식별하고 로드할 수 있습니다.

사용자 관점에서 두 가지 응용 프로그램이 있습니다.

집계된 데이터가 있는 장바구니.
세부 정보를 표시하는 데 사용되는 빈 템플릿 응용 프로그램.

사용자는 장바구니 응용 프로그램에서 선택을 수행합니다. 임계값이 충족되면 요청된 세부 정보로 템플릿 응용 프로그램을 채우는 사용자 지정 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 파일은 표준(빠름) 모드와 최적화(매우 빠름) 모드에서 읽을 수 있습니다. 모드 선택은 스크립트 엔진에서 자동으로 결정합니다. 최적화된 로드에는 몇 가지 제한 사항이 있습니다. 필드의 이름을 변경할 수는 있지만 다음 작업 모두 표준 로드를 발생시킵니다. 로드된 필드의 모든 변환 where 절을 사용하여 Qlik Sense가 레코드를 압축 해제하게 함 로드된 필드에서 맵 사용
증분 로드 활용	응용 프로그램이 지속적으로 업데이트되는 데이터베이스에서 대량의 데이터에 연결되는 경우 전체 데이터 집합을 다시 로드하는 데 시간이 오래 걸릴 수 있습니다. 대신 증분 로드를 사용하여 데이터베이스의 새 레코드나 변경된 레코드를 검색해야 합니다. 자세한 내용은 증분 로드를 통해 새 레코드 및 업데이트된 레코드 로드를 참조하십시오.
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() 함수 내의 차원과 다른 차원이 있는 테이블의 경우입니다. 자세한 내용은 When should AGGR not be used?를 참조하십시오.
가능한 경우 집합 분석을 사용합니다.	집합 분석을 사용하여 현재 선택 항목으로 정의된 일반 집합과 다른 데이터 값 집합을 정의할 수 있습니다. 자세한 내용은 집합 분석를 참조하십시오.
가능한 경우 문자열 비교를 피합니다.	문자열 비교는 집합 분석만큼 효율적이지 않습니다. 예를 들어 Match(), MixMatch(), WildMatch() 및 Pick()을 피해야 합니다. 스크립트에서 플래그를 만들거나 대신 집합 분석을 사용하십시오. 자세한 내용은 조건부 함수 및 Performance of conditional aggregations를 참조하십시오.
집중적인 계산이 포함된 개체에 계산 조건을 사용합니다.	선택 항목이 없을 때 많은 레코드가 있는 시각화가 있을 수 있습니다. 모범 사례로, 특정 선택이 이루어진 후에만 렌더링되도록 개체에 계산 조건을 추가하십시오. 이렇게 하면 매우 큰 하이퍼큐브가 생성되는 것을 방지할 수 있습니다. 예: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. 이 시나리오에서 사용자가 단일 국가를 선택하거나 단일 국가만 가능한 다른 선택을 하지 않는 한 시각화는 렌더링되지 않습니다.
가능한 경우 스크립트에서 측정값을 미리 계산합니다.	데이터 모델의 가장 낮은 세분성 수준에 있는 모든 측정값은 스크립트에서 계산되어야 합니다. 예를 들어 테이블의 동일한 레코드에 Sales 및 Cost가 있는 경우 Sales - Cost AS Margin을 계산하여 마진을 도출할 수 있습니다. 선택에 따라 달라지지 않거나 다른 세분성 수준에 바인딩되어 있다는 것을 알고 있는 경우 다른 값을 미리 집계할 수도 있습니다.
테이블의 열이 15개 미만이고 계산 조건이 있습니다.	15개의 열이 있는 테이블은 넓은 것으로 간주될 수 있습니다. 테이블이 많은 레코드로 구성된 경우 특정 선택 또는 기준이 충족된 후에만 렌더링되도록 테이블 개체에 계산된 조건을 사용해야 합니다. 테이블이 매우 넓은 경우 다음을 고려하십시오. 조건부로 표시되는 여러 개의 작은 테이블을 만듭니다. 열을 조건부로 표시하는 방법을 사용합니다. 분석에 필요한 필드로만 테이블을 제한합니다.
시트에 개체 수가 너무 많지 않습니다.	사용자가 시트로 이동할 때 개체가 계산됩니다. 사용자가 해당 시트에서 선택할 때마다 현재 상태가 캐시에 없으면 각 개체가 다시 계산됩니다. 차트가 많은 시트가 있는 경우 사용자는 거의 모든 선택에서 모든 개체가 계산될 때까지 기다려야 합니다. 이는 엔진에 상당한 부하를 줍니다. 모범 사례로 Dashboard/Analysis/Reporting (DAR) 개념을 따라 깔끔하고 최소한의 응용 프로그램을 개발하십시오. 자세한 내용은 DAR methodology를 참조하십시오.
집합 분석에 사용하기 위해 스크립트에서 숫자 플래그를 활용합니다.	플래그가 있는 집합 분석은 문자열 비교나 곱셈을 사용하는 것보다 더 효율적일 수 있습니다.
표현식에 사용되는 마스터 항목 또는 변수	마스터 항목을 사용하면 관리되는 메트릭을 끌어서 놓기할 수 있으며 표현식이 캐시되도록 보장합니다. 예를 들어 Sum(Sales)은 SUM(Sales)과 다릅니다. 표현식은 철자와 대소문자를 기준으로 캐시되며 재사용하려면 정확히 일치해야 합니다.

데이터 로드 성능

Qlik Cloud에서 응용 프로그램으로 작업할 때 원활하고 반응형 환경을 위해서는 데이터 로드를 최적화하는 것이 중요합니다. 이 섹션에서는 성능에 영향을 미치는 요소를 강조하고 성능 문제를 방지하는 방법에 대한 지침을 제공합니다.

Qlik 데이터 게이트웨이 - 직접 액세스

Qlik 데이터 게이트웨이 - 직접 액세스를 사용하여 응용 프로그램에 데이터를 다시 로드할 때 다음 요소가 성능에 영향을 미칩니다.

Data Gateway를 호스팅하는 컴퓨터와 데이터베이스 간의 연결 속도 및 대기 시간.
Data Gateway를 호스팅하는 컴퓨터와 Qlik Cloud 테넌트 간의 연결 속도 및 대기 시간. 성능 향상을 위해 Data Gateway를 Qlik Cloud 테넌트와 동일한 지역에 호스팅하는 것이 이상적입니다.

데이터베이스 스토리지

스토리지 연결이 느리면 다시 로드 시간이 늘어날 수 있습니다. 온프레미스 또는 클라우드에서 호스팅되는 데이터베이스의 경우 다음 사항을 고려하십시오.

온프레미스: 데이터베이스가 온프레미스에 있고 다른 응용 프로그램과 서버를 공유하는 경우 해당 성능은 이러한 다른 응용 프로그램의 활동에 영향을 받을 수 있습니다.
클라우드: 크기가 올바르게 조정된 경우 클라우드 데이터베이스는 일반적으로 온프레미스 데이터베이스보다 더 나은 성능을 제공합니다. 최적의 결과를 얻으려면 Qlik Cloud 테넌트와 가까운 클라우드 스토리지 지역을 선택하십시오.

이 페이지가 도움이 되었습니까?

이 페이지 또는 해당 콘텐츠에서 오타, 누락된 단계 또는 기술적 오류와 같은 문제를 발견하면 알려 주십시오!

여기에 피드백을 남겨주십시오.