서론
소규모 또는 중간 규모의 QlikView 응용 프로그램은 성능과 관련한 응용 프로그램의 설계에 대해 너무 걱정할 필요가 없습니다. 응용 프로그램이 부적절하게 설계된 경우 데이터 양이 증가함에 따라 시간과 메모리 제약 조건이 매우 명백하게 드러날 수 있습니다. 일부 간단한 설계 변경으로 성능을 충분히 개선할 수 있습니다. 이 부록에서는 흔히 빠지기 쉬운 몇 가지 함정을 지적하고 그 해결책을 제안합니다.
일반적으로 "문제"를 응용 프로그램 개체에서 스크립트 원본 데이터베이스로 옮기면 성능을 개선할 수 있습니다. 이는 대개 이율배반적인 상황입니다. 응답 시간은 향상되지만 임시 대응 역량은 감소됩니다. 따라서 아래 권장 사항을 보편적으로 유익한 것으로 간주하지 않아야 합니다. 응용 프로그램의 일반적인 상태를 개선하거나 성패를 가름하는 작은 차이를 만들어낼 수 있을 때 사용하십시오.
아래 목록은 위 문제의 처리에 적용되는 방법의 예입니다. 이는 문제를 설명하고 유용한 QlikView 기능을 가리키도록 고안되었습니다. 최선의 방법에 대한 보편적인 권장 사항을 제시할 수는 없지만 예제의 순서가 하나의 지표입니다.
If ( Condition(Text),....)
텍스트 비교가 사용되는 If 절은 일반적으로 성능 요구가 높습니다. 예를 들어 autonumber(이전 섹션의 예 참조)를 사용하거나 및/또는 스크립트 내에서 테스트를 수행하여 텍스트를 숫자에 매핑하는 것이 해결책이 될 수 있습니다.
텍스트 문자열의 테스트는 숫자 테스트보다 느립니다. 다음과 같은 표현식을 예로 들겠습니다.
If (Alfa= ‘ABC’, ‘ABC’, left (Alfa, 2))
유연성의 저하 없이 스크립트 내에서 직접 테스트를 수행할 수 있습니다.
Load
*,
If (Alfa = ‘ABC’, 1, 0) as Flag
resident table_1 ;
이 표현식은 다음과 같이 됩니다.
If ( Flag = 1,’ABC’, left (Alfa, 2))
그러면 테스트가 더 간단해집니다.
Sum ( If (Condition, ‘FieldName’…))
여기서 집계는 테이블 차원에 독립적이며, 결과는 테이블의 여러 차원에 걸쳐 분산됩니다. 스크립트 내에서 테스트를 수행하고 테이블 내에 집계하거나 스크립트 내에서 전체 연산을 수행하는 것으로 문제를 처리할 수 있습니다. 여기에는 interval match, group by, peek, if....then....else 등과 같은 다양한 기법이 있습니다.
이 경우에는 "Condition"의 테스트와 결과의 집계라는 두 가지 단계가 사용됩니다. 이전 예제에 집계를 추가하면 다음과 같이 됩니다.
Sum ( If (Alfa= ‘ABC’, Num*1.25 , Num) )
Load
*,
If (Alfa = ‘ABC’, 1, 0) as Flag
resident table_1 ;
이 표현식은 다음과 같이 됩니다.
Sum ( If ( Flag = 1, Num* 1.25 , Num ) )
또한 다음과 같이 스크립트 내에서 직접 집계를 수행할 수도 있습니다.
table_2:
Load
*,
If (Alfa = ‘ABC’, 1, 0) as Flag
resident table_1 ;
table_3:
Load
Alfa,
If ( Flag = 1, Num* 1.25 , Num ) as NewNum
resident table_2 ;
table_4:
Load
Alfa,
Sum( NewNum ) as SumNum
resident table_3
group by Alfa ;
If ( Condition, Sum(‘FieldName’)..)
이 구성은 이전 사례와의 차이점을 강조할 목적으로만 여기에 추가되었습니다. 이 집계는 완전히 문맥상의 것이며 일반적으로 말하자면 성능 문제를 일으키지 않습니다.
If ( Condition1, Sum(‘FieldName’), If (Condition2, Sum(‘FieldName’)……..
중첩된 If...then else...의 논리는 개념적으로 간단하지만 때로 관리자에게 골칫거리가 될 수 있습니다. 수백 단계가 중첩된 경우도 목격되었습니다. 이 경우 메모리뿐 아니라 CPU 점유율도 높아집니다. "Condition"은 대개 변환하여 대체할 수 있습니다. 그 전형적인 예가 quantity*price의 집계이며, 여기서 price는 변수입니다. 이는 "확장 간격 일치"로 처리할 수 있습니다. 예를 들어 "A AND B"의 두 조건이 만족되면 테스트를 "C" 조건으로 대체할 수 있습니다.
예:
sum((GAC12_STD_COST * GAC15_EXCHANGE_RATE) * GIV24_DISP_QTY)
Replaces
Sum(
If((GAC12_EFCT_DT<= GIV23_REJ_DT and
GAC12_EXPIRE_DT>GIV23_REJ_DT) and
(GAC15_EFCT_DT<= GIV23_REJ_DT and GAC15_EXPIRE_DT>GIV23_REJ_DT),
GAC12_STD_COST * GAC15_EXCHANGE_RATE) * GIV24_DISP_QTY,
Null
그리고
Sum(
If(GAC12_EFCT_DT<= GIV23_REJ_DT,
If(GAC12_EXPIRE_DT>GIV23_REJ_DT,
If(GAC15_EFCT_DT<= GIV23_REJ_DT,
If(GAC15_EXPIRE_DT>GIV23_REJ_DT,
(GAC12_STD_COST * GAC15_EXCHANGE_RATE) * GIV24_DISP_QTY,
Null())))))
GAC12_STD_COST 및 GAC15_EXCHANGE_RATE 필드를 느리게 변화하는 차원으로 읽습니다.
확장된 intervalmatch 구문을 사용하여 느리게 변화하는 차원 문제 해결
텍스트 정렬
QlikView는 Field를 numeric, text 또는 general로 처리해야 할지를 자동으로 평가합니다. Text로 평가된 필드는 가장 느린 정렬 연산인 text로 정렬됩니다. 이를 로드 순서로 정렬하도록 수동으로 바꿀 수 있습니다. 목록 상자 등의 정렬이 필요 없다면 기능을 끄십시오.
QlikView는 문자와 숫자가 혼합된 문자열을 영숫자 순서대로 정렬합니다. 즉, 기존 ASCII만의 정렬 순서가 아니라 숫자가 값의 순서대로 정렬되고 숫자가 아닌 문자는 ASCII 순서대로 정렬됩니다. 예:
| ASCII 정렬 | 영숫자 정렬 |
|---|---|
| A1 | A1 |
| A10 | A4 |
| A11 | A5 |
| A30 | A6 |
| A4 | A10 |
| A5 | A11 |
| A6 | A30 |
동적 캡션 및 텍스트 개체
텍스트를 입력할 수 있는 거의 모든 곳에 동적으로 계산되는 표현식을 입력할 수 있습니다. 하지만 표현식을 평가하는 데 필요한 리소스는 환경에 따라 결정됩니다. 표현식 대화 상자에서 정의된 차트 및 테이블 내의 표현식은 개체가 표시되고 데이터가 변경될 때만 계산됩니다. 즉, 개체가 최소화된 경우 계산되지 않습니다.
반면, 개체 제목이 계산되는 경우 매번 변경이 일어날 때마다 해당 계산이 수행됩니다. 또한 수많은 방법으로 표시 조건, 계산 조건 등을 정의할 수 있습니다. 이러한 테스트 또한 항상 수행됩니다.
일부 표현식은 다른 표현식보다 성능 요구가 많으며, 더 자주 평가되어야 할수록 더 요구가 많아집니다. 비동기 계산이 도입되면서 이러한 행태가 변했으며, 사용자 응용 프로그램에서 그 영향이 더 두드러질 수 있습니다.
예를 들어 Now() 및 Today()와 같은 시간 함수는 재계산이 필요할 때마다 평가됩니다. 특히 Now() 함수는 매 초 응용 프로그램의 재계산을 요구하므로 상당히 요구가 클 수 있습니다.
예:
If ( ReloadTime()+3>Now(), 'Old Data', 'New Data')
여기서 다음과 같은 표현식을 고려할 수 있습니다.
If ( ReloadTime()+3>Today(), 'Old Data', 'New Data')
간단한 테스트를 위해 텍스트 상자에 표현식을 입력하면 됩니다. 그 다음 텍스트 상자 안의 Now()를 사용하여 텍스트 상자의 크기를 조정해 보십시오.
매크로 트리거("변경 시")
응용 프로그램에서 이벤트가 발생할 때마다 거의 매번 매크로가 트리거되도록 설정할 수 있습니다. 한 이벤트가 차례로 다음 이벤트를 트리거하는 계단식 또는 반복 이벤트에 주의하십시오.
