블로그

두 개의 아키텍처, 간단히

위의 다이어그램은 TURBOARD의 레이어가 어떻게 함께 맞는지 보여줍니다. 나머지 게시물은 주변의 조건이 어려워짐에 따라 각 아키텍처가 수행하는 작업을 조사합니다.

공정한 시나리오 : 인메모리가 승리 할 때

분명히 말할 가치가 있습니다 : 데이터 세트가 RAM에 편안하게 맞을 때, 동시성이 겸손 할 때, 그리고 응용 프로그램에 대한 환경 크기가 클 때 Qlik Sense는 진정으로 빠릅니다. 연관 엔진은 성숙한 엔지니어링이며 필터를 클릭하고 집계가 밀리 초 단위로 다시 계산되는 것을 보는 사용자 경험은 그 날에 탁월합니다. 부서별 배포, 집중된 분석 애플리케이션 및 데이터 모델이 안정적이고 잘 이해되는 워크로드의 경우 인메모리 접근 방식이 진정한 강점입니다.

이것은 대부분의 제품 데모가 주변에 구축되는 시나리오입니다. 또한 데이터가 성장한 후 사용자 기반이 확장되고 동일한 서버에 3 개의 응용 프로그램이 더 배포 된 후 플랫폼이 생산에 1 년 동안 어떻게 행동 할 것인지에 대해 최소한으로 알려주는 시나리오이기도합니다.

스케일링 시나리오: 아키텍처가 분기하는 위치

Qlik의 자체 지원 문서는 메모리 모델을 자세히 설명합니다. 엔진은 다음과 같이 알려진 두 가지 구성 가능한 임계값에 대해 작동합니다. 작업 세트 낮음 및 작업 설정 높음, 기본값 70% 및 물리적 RAM의 90% 각각. 낮은 임계값 아래에서 엔진은 사용하지 않는 메모리가 낭비되는 메모리라는 원리로 캐시된 계산 결과를 공격적으로 유지합니다. 낮은 임계값이 교차되면 엔진은 새로운 결과를 얻기 위해 캐시된 결과를 퇴거하기 시작하여 연령, 크기 및 원래 계산 시간에 따라 퇴거를 우선시합니다. 높은 임계값이 교차되면 캐싱이 효과적으로 중지되고 운영 체제의 페이지 파일이 엔진을 계속 유지하도록 할 수 있습니다. Qlik의 문서에 따르면 페이지 파일 사용은 성능을 크게 저하시킬 수 있습니다.

그 문턱 사이에서 일어나는 일의 역학은 문턱 자체보다 더 중요합니다. 퇴거되는 모든 캐시된 결과는 사용자가 다음에 요청할 때 다시 계산해야 하는 계산입니다. 퇴거가 가속화됨에 따라 계산 부하가 메모리에서 CPU로 이동합니다. 많은 사용자가 더 이상 답변을 캐시하지 않은 계산을 동시에 트리거하는 높은 동시성 환경에서 CPU는 새로운 병목 현상이 됩니다. 메모리 압력과 달리 CPU 압력은 사용자 가시 대기 시간으로 직접 나타납니다. 대시보드는 매달려 있고, 적용하는 데 몇 초가 걸리는 필터, 시간 아웃 세션입니다.

TURBOARD의 하이브리드 접근 방식은 부하를 다르게 분산시킵니다. 집계되지 않은 데이터 집합은 RAM을 차지할 필요가 없습니다. 원주 저장소는 디스크에서 분석 쿼리에 효율적으로 응답하도록 설계되었습니다. — 쿼리가 터치하는 열만 읽고, 무거운 압축을 악용하고, XNUMX년 전에 메모리 내 처리가 필요한 속도로 집계를 제공합니다. 증분 로딩은 반복적 인 전체 재 장전을 강요하지 않고 원주 저장소를 신선하게 유지합니다. 즉, 사용자는 RAM에 전체 데이터 세트를 보유하는 메모리 비용없이 거의 라이브 데이터를 경험합니다. 그런 다음 Redis 캐시는 가속에서 가장 많은 이점을 얻는 쿼리를 가속화합니다. 실제 엔터프라이즈 배포에서는 총 쿼리 볼륨의 작은 하위 집합입니다. 다음 섹션은 그 이유를 설명합니다.

라이브 데이터: Direct Discovery 문제

사용 가능한 메모리를 초과하는 워크로드에 대한 Qlik의 대답은 Direct Discovery로, 치수 필드가 메모리에 로드되는 동시에 측정 필드가 소스 데이터베이스에 남아 있고 주문형으로 쿼리되는 모드입니다. 설계 의도는 합리적이며 문서화 된 한계는 중요합니다.

TURBOARD의 경우 라이브 연결은 메모리 압력의 해결 방법이 아닙니다. 그것은 건축의 일류 부분입니다. 일반 ODBC 연결이 아닌 네이티브 데이터베이스 드라이버는 Apache Kudu와 같은 빅 데이터 플랫폼을 포함하여 소스 시스템에 대한 직접 고성능 액세스를 제공합니다. 캐시 트리거 메커니즘은 모든 사용자 클릭에서 소스 데이터베이스가 충돌하는 것을 방지합니다. TURBOARD는 지정된 트리거 필드(예: 마지막 업데이트된 타임 스탬프)를 시청하고 기본 데이터가 변경되지 않은 경우 Redis의 캐시된 결과를 제공하여 트리거가 새로운 데이터를 사용할 수 있음을 나타내는 경우에만 소스를 쿼리합니다. 고급 분석 기능은 위젯이 캐시, 원주 저장소 또는 라이브 소스에서 읽는지 여부에 관계없이 완전히 사용할 수 있습니다. 단일 대시보드는 타협 없이 세 가지를 모두 혼합할 수 있습니다.

파레토 통찰력, 그리고 그것을 보호하는 특허

모든 엔터프라이즈 BI 배포에서 사용자 동작은 예측 가능한 패턴을 따릅니다. 대략 80 %의 사용자가 동일한 핵심 대시 보드로 반복적으로 돌아갑니다. — 임원 요약, 월간 성과 보고서, 지역 롤업. 나머지 20%는 동일한 형태로 다시 실행되지 않을 수 있는 임시 쿼리를 실행하는 전력 사용자입니다. 메모리 관리의 의미는 직접적입니다. 모든 캐시 된 결과가 똑같이 가치있는 것은 아니며,이를 동등한 것으로 취급하는 시스템은 가장 비싼 자원을 낭비하고 있습니다.

Qlik의 퇴거 모델은 행동 블라인드입니다. 캐시된 결과는 연령, 크기 및 원래 계산 시간에 따라 제거됩니다. 실제 사용자가 실제로 요청하는 빈도에 따라 제거되지 않습니다. 메모리가 채워지면 엔진은 매일 아침 전체 임원 팀이 점검하는 대시 보드를 최근에 캐시 된 일회성 쿼리와 구별 할 수 없습니다.

TURBOARD는 반대의 접근 방식을 취합니다. 보고서를 볼 때마다 Redis Sorted Set에서 인기 점수가 증가합니다. 이는 이러한 종류의 순위 액세스 패턴을 위해 설계된 데이터 구조입니다. 시스템은 보고서가 실제로 사용되는 연속 리더 보드를 유지하고 해당 리더 보드를 사용하여 메모리가 빡빡 할 때 캐시에 남아있는 것을 결정합니다. 가장 많이 요청되는 보고서는 Redis에서 보호되며,이 보고서는 레디스에 의존하는 대부분의 사용자에게 지연 시간이 0으로 돌아갑니다. 캐시를 놓친 전원 사용자 쿼리는 원주 저장소 또는 라이브 소스로 라우팅됩니다. 둘 다 고부가가치 캐시된 콘텐츠를 대체하지 않고 해당 쿼리에 빠르게 응답하도록 설계되었습니다.

나란히

결론

Qlik Sense는 유능한 메모리 내 분석 플랫폼으로 남아 있으며, 제한된 데이터 세트, 예측 가능한 동시성, 관대 한 메모리 프로비저닝을 위해 설계된 조건에서 잘 수행됩니다. 이 게시물이 대답하려고 시도한 질문은 이러한 조건이 충족하기 어려워짐에 따라 어떤 일이 일어나는지입니다. 데이터 볼륨이 줄어들지 않습니다. 동시성 기대는 편안하지 않습니다. 그리고 메모리의 비용과 가용성은 오랫동안 처음으로 잘못된 방향으로 움직이고 있습니다.

TURBOARD의 아키텍처는 향후 10년 동안 BI 성능이 플랫폼에서 획득될 것이라는 내기입니다. 메모리를 풍부하게 사용하기보다는 지능적으로 사용하십시오. 하이브리드 데이터 액세스, 원주 스토리지, 네이티브 라이브 연결 및 특허받은 사용 점수 캐시를 통해 TURBOARD는 순전히 메모리 내 아키텍처가 생활하기 어려운 메모리 예산에 대한 엔터프라이즈 규모의 성능을 제공 할 수 있습니다.

차이를 볼 준비가 되셨습니까?

Qlik Sense를 평가하거나 이미 실행 중이며이 게시물에 설명 된 메모리 압력을 느끼기 시작하면 TURBOARD의 하이브리드 아키텍처가 동일한 워크로드를 처리하는 방법을 보여주고 싶습니다.

우리 팀과 함께 연습을 예약하고 자신의 데이터로 플랫폼을 볼 수 있습니다. 압력 없음 - 우리는 오히려 당신이 당신의 특정한 필요를 위해 적당한 적합을 찾아내고 싶습니다.

당신은 또한 우리의 탐구 할 수 있습니다 전체 BI 비교 페이지는 우리가 더 많은 엔터프라이즈 시나리오에 걸쳐 쌓이는 방법을 확인합니다.