Optymalizacja wydajności aplikacji

Wydajność aplikacji można poprawić poprzez zmniejszenie rozmiaru aplikacji, uproszczone modele danych i strategiczne użycie analizy zestawów. Ta sekcja pomoże uniknąć problemów z wydajnością, wskazując obszary, w których wydajność może ulec pogorszeniu, oraz sposoby oceny i monitorowania wydajności aplikacji.

Możesz monitorować wydajność swojej aplikacji za pomocą narzędzia do oceny wydajności, a także przetestować jej działanie na różnych rozmiarach silników, ręcznie przypisując większe silniki. Więcej szczegółów zawiera Ocena wydajności aplikacji oraz Przypisywanie silników w celu poprawy wydajności aplikacji.

Złożoność aplikacji

Są to luźne kategorie, które mogą pomóc w diagnozowaniu problemów. Najbardziej złożone aplikacje mają najniższą wydajność.

Proste aplikacje:

Nie zawierają złożonej analizy zestawów ani instrukcji If().
Nie zawierają dużych tabel.
Mają prosty model danych.
Zawierają proste obliczenia.
Mogą mieć duże wolumeny danych.

Umiarkowane aplikacje:

Mają model danych z wieloma tabelami, ale stosują najlepsze praktyki.
Używają analizy zestawów i kilku instrukcji If().
Mają duże lub szerokie tabele w arkuszach (15 kolumn lub więcej).

Złożone aplikacje:

Mają bardzo złożony model danych.
Łączą się z dużymi wolumenami danych.
Zawierają złożone obliczenia, wykresy i tabele.

Duże wolumeny danych

Możesz zastosować te strategie architektury podczas łączenia się z dużymi wolumenami danych.

Segmentacja

Możesz segmentować QVDs według wymiarów, takich jak ramy czasowe, region lub poziom agregacji. Na przykład możesz mieć:

QVD, który zawiera dane z dwóch ostatnich lat.
QVD, który zawiera dane historyczne starsze niż dwa lata.
QVD, który zawiera wszystkie dane zagregowane na wyższym poziomie. Na przykład według miesiąca zamiast daty lub według kraju zamiast poszczególnych klientów.
Jeden duży QVD ze wszystkimi danymi, który jest używany tylko przez niewielką podgrupę użytkowników.

W podobny sposób można segmentować aplikacje. Mniejsze aplikacje zaspokoją potrzeby analityczne większości użytkowników. Pozwala to zaoszczędzić pamięć.

Możesz również mieć wiele aplikacji skoncentrowanych na różnych regionach. W ten sposób użytkownicy nie będą otwierać aplikacji z danymi, którymi nie są zainteresowani lub do których nie mają praw dostępu. Dane, które nie są dostępne przez dostęp do sekcji nadal wpływają na pamięć.

Generowanie aplikacji na żądanie (ODAG)

Aplikacje na żądanie Qlik Sense zapewniają użytkownikom zagregowane widoki dużych magazynów danych. Mogą oni identyfikować i ładować odpowiednie podzbiory danych do szczegółowej analizy.

Z perspektywy użytkownika istnieją dwie aplikacje:

Koszyk z zagregowanymi danymi.
Pusta aplikacja szablonu używana do wyświetlania szczegółów.

Użytkownik dokonuje wyborów w aplikacji koszyka. Po osiągnięciu progu tworzony jest niestandardowy skrypt LOAD, który wypełnia aplikację szablonu żądanymi szczegółami. Więcej informacji zawiera temat Zarządzanie danymi big data za pomocą aplikacji On-demand.

Łączenie aplikacji

Łączenie aplikacji (znane jako łączenie dokumentów w QlikView) oznacza, że istnieje zagregowana aplikacja, z której użytkownicy regularnie korzystają. Jeśli użytkownik potrzebuje więcej szczegółów, wybory mogą zostać przekazane z zagregowanej aplikacji do aplikacji szczegółowej, dzięki czemu może on wyświetlić niższy poziom szczegółowości. Pozwala to zaoszczędzić pamięć, ponieważ użytkownicy nie ładują niepotrzebnych szczegółów. Łączenie aplikacji można wykonać, dodając obiekty przycisków do arkusza. Więcej informacji zawiera temat Tworzenie łańcuchów aplikacji.

Łączenie aplikacji jest również obsługiwane przez APIs. Na przykład można użyć API integracji aplikacji do utworzenia niestandardowego łączenia aplikacji. Więcej informacji zawiera temat API integracji aplikacji (tylko w języku angielskim).

Widoki dynamiczne

Widoki dynamiczne umożliwiają tworzenie aktualnych wizualizacji w przypadku dużej ilości danych lub szybko zmieniających się danych. Podczas pracy z widokami dynamicznymi należy wziąć pod uwagę następujące kwestie:

Podczas aktualizacji widoków dynamicznych źródło danych jest ładowane bezpośrednio. Na wydajność aktualizacji wpływa wydajność bazowego źródła danych.
Szablony aplikacji widoków dynamicznych mogą pomóc w tworzeniu dynamicznych wykresów.

Więcej informacji na temat korzystania z widoków dynamicznych zawiera sekcja Zarządzanie danymi za pomocą widoków dynamicznych.

Direct Query

Chociaż zalecane są aplikacje w pamięci, Direct Query pozwala na przechowywanie danych w ich oryginalnym źródle. Aby zoptymalizować korzystanie z Direct Query, należy wziąć pod uwagę następujące kwestie:

Na wydajność Direct Query duży wpływ ma wydajność bazowego źródła danych.
Model danych Direct Query powinien być jak najprostszy, ponieważ złożone zapytania mogą powodować problemy z wydajnością.

Więcej informacji o Direct Query zawiera sekcja Bezpośredni dostęp do baz danych w chmurze za pomocą Direct Query.

Wydajność modelu danych

Są to wskaźniki, które mogą mieć wpływ na wydajność modelu danych. Każdy z nich stanowi najlepszą praktykę, która poprawi użyteczność aplikacji.

Najlepsze praktyki w zakresie wydajności modelu danych
Działanie	Opis
Usunięcie kluczy syntetycznych	Qlik Sense tworzy klucze syntetyczne, gdy co najmniej dwie tabele danych mają dwa lub więcej wspólnych pól. Może to oznaczać, że w skrypcie lub modelu danych występuje błąd. Diagnostyka kluczy syntetycznych, patrz Klucze syntetyczne.
Usunięcie odwołań cyklicznych z modelu danych	Odwołania cykliczne występują, gdy dwa pola mają więcej niż jedną asocjację. Qlik Sense spróbuje je rozwiązać poprzez zmianę połączenia z jedną z tabel. Jednakże wszystkie ostrzeżenia o odwołaniach cyklicznych powinny zostać rozwiązane, zobacz Rozpoznawanie i naprawianie odwołań cyklicznych.
Odpowiednia szczegółowość danych	Należy ładować tylko te dane, które są niezbędne. Na przykład: grupa użytkowników potrzebuje tylko danych podzielonych według tygodnia, miesiąca i roku. W celu oszczędzenia w pamięci można załadować dane zagregowane lub zagregować dane w skrypcie ładowania. Jeśli użytkownik potrzebuje wizualizacji danych na niższym poziomie szczegółowość, można użyć ODAG lub powiązać łańcuchowego łączenia dokumentów.
Stosowanie plików QVDs tam, gdzie jest to możliwe	QVD to plik zawierający tabelę danych wyeksportowanych z programu Qlik Sense. Ten format pliku jest zoptymalizowany pod kątem szybkości podczas odczytywania danych ze skryptu, ale nadal jest bardzo kompaktowy. Format pliku jest zoptymalizowany w celu uzyskania maksymalnej szybkości odczytu danych przez skrypty przy zachowaniu niewielkich rozmiarów. Odczyt danych z pliku QVD jest zazwyczaj 10–100 razy szybszy niż odczyt z innych źródeł danych. Więcej informacji zawiera temat: Praca z plikami QVD.
Optymalizacja plików QVD podczas ładowania	Dostępne są dwa tryby odczytu plików QVD: standardowy (szybki) i zoptymalizowany (szybszy). Wybrany tryb jest automatycznie określany przez silnik obsługi skryptów. Istnieją pewne ograniczenia dotyczące ładowania zoptymalizowanego. Istnieje możliwość zmiany nazw pól, ale każda z tych operacji spowoduje standardowe ładowanie: Jakiekolwiek transformacje pól, które są ładowane. Użycie klauzuli where, co spowoduje, że program Qlik Sense rozpakuje rekordy. Użycie polecenia Map względem ładowanego pola.
Wykorzystanie ładowania przyrostowego	Jeśli Twoja aplikacja łączy się z dużą ilością danych z baz danych, które są stale aktualizowane, ponowne załadowanie całego zestawu danych może być czasochłonne. Zamiast tego do pobierania nowych lub zmienionych rekordów z bazy danych należy używać ładowania przyrostowego. Więcej informacji można znaleźć w temacie Ładowanie nowych i zaktualizowanych rekordów za pomocą funkcji ładowania przyrostowego.
Konsolidacja modelu Snowflake	W przypadku modelu danych Snowflake można zmniejszyć liczbę tabel danych, łącząc niektóre z nich przy użyciu prefiksu Join lub innego mapowania. Jest to szczególnie ważne w przypadku dużych tabel faktów. Dobrą zasadą ogólną jest stosowanie tylko jednej dużej tabeli. Więcej informacji w temacie Łączyć, czy nie łączyć.
Tabele z małą ilością pól są zdenormalizowane	W przypadku dwóch tabel z kilkoma polami połączenie ich może poprawić wydajność. Więcej informacji zawiera temat Łączenie tabel operatorami Join i Keep.
Zdenormalizowane tabele wyszukiwania (liść) z mapowaniem ładowania	Nie należy używać prefiksu Join , jeśli chce się tylko dodać jedno pole z jednej tabeli do drugiej. Należy użyć funkcji wyszukiwania ApplyMap , patrz Nie łącz – używaj funkcji ApplyMap.
Usunięcie lub odłączenie znaczników czasu od pola daty	Pola dat mogą wypełniać przestrzeń, gdy obecny jest znacznik czasu, ponieważ reprezentacja w postaci ciągu i liczba odrębnych wartości są większe. Jeśli precyzja nie jest konieczna do analizy, możesz zaokrąglić znacznik czasu do np. najbliższej godziny za pomocą funkcji Timestamp(Floor(YourTimestamp,1/24)) lub całkowicie usunąć składnik czasu za pomocą funkcji Date(Floor(YourTimestamp)). Jeśli znacznik czasu ma być obecny, można go odłączyć od samej daty. Możesz użyć tej samej funkcji Floor(), a następnie utworzyć nowe pole z wyodrębnionym czasem, używając czegoś w rodzaju: Time(Frac(YourTimestamp)).
Usunięcie niepotrzebnych pól z modelu danych	Do modelu danych należy ładować tylko niezbędne pola. Należy unikać Load * i SELECT. Pamiętaj, aby zachować: Pola, które są niezbędne do analizy. Pola, które są faktycznie używane w aplikacji.
Unikanie tabel łączy w przypadku dużych ilości danych	W miarę możliwości należy korzystać z tabel łączy. Jednakże w przypadku dużych ilości danych skonkatenowane tabele mogą zapewniać wyższą wydajność niż tabele łączy.
Rozdzielanie skonkatenowanych wymiarów na nowe pola	Skonkatenowane wymiary należy rozdzielać na osobne pola. Zmniejsza to liczbę unikatowych wystąpień wartości w polach. Jest to podobne do optymalizacji znaczników czasu.
Używanie funkcji AutoNumber, gdy jest to możliwe	Ładowanie zoptymalizowane można utworzyć, najpierw ładując dane z pliku QVD, a następnie używając instrukcji AutoNumber celem przekształcenia wartości na klucze symboli.Więcej informacji zawiera temat AutoNumber.
Unikanie wysp danych	Wyspy danych mogą być użyteczne, ale zazwyczaj wpływają na wydajność. W przypadku tworzenia wysp dla wartości wyboru należy używać zmiennych.
Przechowywanie plików QVD w oparciu o przyrostowe przedziały czasu	Pliki QVD należy przechowywać w segmentach, np. miesięcznych. Te mniejsze miesięczne QVD mogą następnie obsługiwać wiele różnych aplikacji, które niekoniecznie będą potrzebować wszystkich danych.

Wydajność arkusza

Oto najlepsze praktyki, które poprawią wydajność arkuszy i wizualizacji.

Najlepsze praktyki dotyczące wydajności arkusza
Działanie	Opis
W miarę możliwości unika się funkcji If()	Jeśli funkcja If() jest używana wewnątrz funkcji agregacji, będzie działać na poziomie rekordu i będzie wielokrotnie obliczana. Na przykład, jeśli masz 1000 rekordów w agregacji, warunek If() zostanie obliczony 1000 razy. Może to szybko narastać kaskadowo w przypadku zagnieżdżania instrukcji. Zamiast tego należy użyć analizy zestawów. Filtr analizy zestawów jest stosowany przed agregacją, co skutkuje szybszą odpowiedzią. Odpowiedzi te mogą być również buforowane za pomocą analizy zestawów, podczas gdy w przypadku funkcji If() nie jest to możliwe. Można również rozważyć inne funkcje i modyfikacje modelu danych.
W miarę możliwości unika się pól z różnych tabel wewnątrz tabeli agregacji.	Gdy agregacja jest obliczana, proces ten przebiega w dwóch krokach: Pierwszym krokiem jest znalezienie odpowiednich kombinacji, na których ma zostać wykonane obliczenie. Ten krok jest jednowątkowy. Drugim krokiem jest wykonanie obliczenia. Ten krok jest wielowątkowy. Część jednowątkowa może znacznie wpłynąć na wydajność. Jednym z przykładów jest sytuacja, w której wewnątrz agregacji znajduje się wiele pól, na przykład Sum(Quantity*ListPrice). Jeśli pole Quantity znajduje się w tabeli faktów, a pole ListPrice w głównej tabeli produktów, silnik musi najpierw połączyć obie tabele, aby znaleźć kombinacje, zanim będzie mógł rozpocząć sumowanie iloczynu. Łączenie jest częścią jednowątkową, a sumowanie wielowątkową. Jeśli oba pola znajdują się w tej samej tabeli, łączenie nie jest konieczne, a agregacja jest obliczana znacznie szybciej.
Funkcja Aggr() i zagnieżdżone funkcje Aggr() są używane w minimalnym stopniu	Funkcja Aggr() znacznie wpływa na wydajność. Nieprawidłowe użycie może dać niedokładne wyniki. Na przykład w tabeli z wymiarami, które różnią się od wymiarów wewnątrz funkcji Aggr(). Więcej informacji można znaleźć w temacie Kiedy NIE należy używać funkcji AGGR?
Analiza zestawów jest używana tam, gdzie to możliwe	Możesz użyć analizy zestawów, aby zdefiniować zestaw wartości danych, który różni się od normalnego zestawu zdefiniowanego przez bieżące selekcje. Więcej informacji zawiera temat Analiza zestawów.
Porównania ciągów znaków są unikane tam, gdzie to możliwe	Porównania ciągów znaków nie są tak wydajne jak analiza zestawów. Na przykład należy unikać funkcji Match(), MixMatch(), WildMatch() i Pick(). Zamiast tego utwórz flagi w skrypcie lub użyj analizy zestawów. Więcej informacji zawierają tematy Funkcje warunkowe oraz Wydajność agregacji warunkowych.
Warunki obliczeń są używane w obiektach zawierających intensywne obliczenia	W przypadku braku selekcji wizualizacje mogą zawierać wiele rekordów. Najlepszą praktyką jest dodawanie warunków obliczeń do obiektów, aby były one renderowane dopiero po dokonaniu określonych selekcji. Zapobiega to tworzeniu bardzo dużych hiperkostek. Na przykład: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. W tym scenariuszu wizualizacja nie zostanie wyrenderowana, dopóki użytkownik nie wybierze jednego kraju lub nie dokona innych selekcji, w których możliwy jest tylko jeden kraj.
Miary są wstępnie obliczane w skrypcie tam, gdzie to możliwe	Każda miara znajdująca się na najniższym poziomie szczegółowości modelu danych powinna być obliczana w skrypcie. Na przykład, jeśli w tym samym rekordzie w tabeli masz Sales i Cost, możesz uzyskać marżę, obliczając Sales - Cost AS Margin. Możesz również wstępnie agregować inne wartości, jeśli wiesz, że nie będą się one zmieniać w zależności od selekcji lub że są powiązane z innym poziomem szczegółowości.
Tabele mają mniej niż 15 kolumn i mają warunki obliczeń	Tabelę z 15 kolumnami można uznać za szeroką. Jeśli tabele składają się z wielu rekordów, należy użyć warunków obliczeń w obiekcie tabeli, aby była ona renderowana dopiero po spełnieniu określonych selekcji lub kryteriów. Jeśli tabela jest bardzo szeroka, rozważ: Utworzenie wielu mniejszych tabel, które są wyświetlane warunkowo. Użycie metod do warunkowego wyświetlania kolumn. Ograniczenie tabel tylko do tych pól, które są niezbędne do analizy.
Arkusze nie mają nadmiernej liczby obiektów	Obiekty są obliczane, gdy użytkownik przechodzi do arkusza. Za każdym razem, gdy użytkownik dokona wyboru w tym arkuszu, każdy obiekt zostanie ponownie obliczony, jeśli bieżący stan nie istnieje w pamięci podręcznej. Jeśli masz arkusz z wieloma wykresami, użytkownik będzie musiał czekać na obliczenie każdego obiektu przy prawie każdym wyborze. Stanowi to znaczne obciążenie dla silnika. W ramach najlepszych praktyk należy stosować koncepcję Dashboard/Analysis/Reporting (DAR) , aby stworzyć przejrzystą i minimalistyczną aplikację. Więcej informacji można znaleźć w sekcji Metodologia DAR.
Flagi numeryczne są wykorzystywane w skrypcie do użycia w analizie zestawów	Analiza zestawów z flagami może być bardziej wydajna niż używanie porównań ciągów znaków lub mnożenia.
Elementy główne lub zmienne używane w wyrażeniach	Elementy główne pozwalają przeciągnąć i upuścić zarządzane metryki i gwarantują, że wyrażenia będą buforowane. Na przykład Sum(Sales) różni się od SUM(Sales). Wyrażenia są buforowane na podstawie pisowni i wielkości liter, i muszą dokładnie pasować, aby mogły zostać ponownie użyte.

Wydajność ładowania danych

Optymalizacja ładowania danych jest ważna dla zapewnienia płynnego i responsywnego działania podczas pracy z aplikacjami w Qlik Cloud. W tej sekcji omówiono czynniki wpływające na wydajność i przedstawiono wskazówki, jak zapobiegać problemom z wydajnością.

Brama danych Qlik — dostęp bezpośredni

Podczas używania Brama danych Qlik — dostęp bezpośredni do przeładowywania danych do aplikacji, na wydajność wpływają następujące czynniki:

Szybkość połączenia i opóźnienie między maszyną hostującą Data Gateway a bazą danych.
Szybkość połączenia i opóźnienie między maszyną hostującą Data Gateway a dzierżawą Qlik Cloud. W idealnym przypadku należy hostować Data Gateway w tym samym regionie co dzierżawa Qlik Cloud, aby poprawić wydajność.

Pamięć masowa bazy danych

Wolne połączenia z pamięcią masową mogą wydłużyć czas przeładowania. W przypadku baz danych hostowanych lokalnie lub w chmurze należy wziąć pod uwagę następujące kwestie:

Lokalnie: Jeśli baza danych znajduje się lokalnie i współdzieli serwer z innymi aplikacjami, na jej wydajność mogą mieć wpływ działania tych innych aplikacji.
Chmura: Przy odpowiednim doborze rozmiaru bazy danych w chmurze zazwyczaj oferują lepszą wydajność niż lokalne bazy danych. Aby uzyskać optymalne wyniki, wybierz region dla swojej pamięci masowej w chmurze, który znajduje się blisko Twojej dzierżawy Qlik Cloud.

Czy ta strona była pomocna?

Jeżeli natkniesz się na problemy z tą stroną lub jej zawartością — literówkę, brakujący krok lub błąd techniczny — daj nam znać!

Przekaż tu opinię