Przeskocz do zawartości głównej

Optymalizacja wydajności aplikacji

Wydajność aplikacji można poprawić dzięki zmniejszeniu rozmiaru aplikacji, uproszczeniu modeli danych i strategicznemu wykorzystaniu analizy zestawów. Ta sekcja pomoże uniknąć problemów z wydajnością, wskazując obszary, które mogą negatywnie wpływać na wydajność, a także wyjaśniając, jak można oceniać i monitorować wydajność aplikacji.

Dzięki narzędziu do oceny wydajności możesz sprawdzić, jak działa Twoja aplikacja. Więcej informacji zawiera temat Ocena 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ą skomplikowanych analiz zestawów ani instrukcji If().
  • Nie zawierają dużych tabel.
  • Wykorzystują prosty model danych.
  • Zawierają proste obliczenia.
  • Mogą zawierać duże ilości danych.

Umiarkowanie złożone aplikacje:

  • Mają model danych z wieloma tabelami, ale bazują na najlepszych praktykach.
  • Wykorzystują analizę zestawu i kilka instrukcji If().
  • Mają duże lub szerokie tabele w arkuszach (15 kolumn lub więcej).

Złożone aplikacje:

  • Mają bardzo skomplikowany model danych.

  • Łączą się z dużymi ilościami danych.
  • Zawierają złożone obliczenia, wykresy i tabele.

Duże ilości danych

Te strategie architektoniczne można zastosować przy łączeniu się z dużymi ilościami danych.

Segmentacja

Można segmentować QVDs według wymiarów, takich jak przedział czasu lub region. Można na przykład mieć:

  • Plik QVD zawierający dane z dwóch ostatnich lat.
  • Plik QVD zawierający dane historyczne z okresu dłuższego niż dwa lata.
  • Plik QVD zawierający wszystkie dane zagregowane na wyższym poziomie. Na przykład na poziomie miesiąca zamiast daty lub według kraju zamiast według klientów indywidualnych.

  • Jeden duży QVD plik ze wszystkimi danymi, który jest używany tylko przez małą grupę użytkowników.

Aplikacje można segmentować podobnie. Mniejsze aplikacje zaspokoją potrzeby analityczne większości użytkowników. To oszczędza pamięć.

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

Generowanie aplikacji na żądanie (ODAG)

Aplikacje na żądanie Qlik Sense zapewniają użytkownikom zbiorcze 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:

  1. Koszyk zakupowy ze zagregowanymi danymi.
  2. Pusta aplikacja szablonu służąca do wyświetlania szczegółów.

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

Łączenie łańcuchowe dokumentów

Łączenie łańcuchowe dokumentów oznacza, że istnieje zagregowana aplikacja, której użytkownicy regularnie używają. Jeśli użytkownik potrzebuje więcej szczegółów, wybory mogą zostać przekazane ze zagregowanej aplikacji do aplikacji szczegółowej, tak aby można było zobaczyć niższy poziom szczegółowości. Oszczędza to pamięć, ponieważ użytkownicy nie ładują niepotrzebnych szczegółów. Łączenie łańcuchowe dokumentów jest obsługiwane poprzez APIs.

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 poprawia 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. Należy jednak rozwiązywać wszystkie ostrzeżenia związane z odwołaniami cyklicznymi, patrz 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 w celu uzyskania maksymalnej szybkości odczytu danych ze skryptu 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

Pliki QVD mogą być odczytywane w dwóch trybach: standardowym (szybkim) i zoptymalizowanym (szybszym). 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 aplikacja łączy się z dużą ilością danych z baz danych, które są na bieżąco aktualizowane, przeł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 płatka śniegu 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ść. Aby uzyskać więcej informacji, zobacz 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żna użyć tej samej funkcji Floor(), a następnie utworzyć nowe pole z wyodrębnionym czasem, używając na przykład: 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 pliki QVD mogą następnie obsługiwać wiele różnych aplikacji, które niekoniecznie będą potrzebować wszystkich danych.

Wydajność arkuszy

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

Najlepsze praktyki w zakresie wydajności arkuszy
Działanie Opis

Unikanie funkcji If() w miarę możliwości

Jeśli funkcja If() jest używana wewnątrz funkcji agregującej, będzie działać na poziomie rekordu i zostanie wielokrotnie oceniona.

W przypadku 1000 rekordów w agregacji warunek If() zostanie oceniony 1000 razy. To może szybko kaskadować w przypadku zagnieżdżania instrukcji. Zamiast niej należy użyć analizy zestawów. Przed agregacją stosowany jest filtr analizy zestawów, co powoduje szybszą odpowiedź. Odpowiedzi te mogą być również buforowane za pomocą analizy zestawów, tymczasem 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 w tabeli agregacji unika się pól z różnych tabel.

Podczas oceny agregacji obliczenia przebiegają w dwóch etapach:

  1. Pierwszym krokiem jest znalezienie odpowiednich kombinacji, na których należy dokonać obliczeń. Ten krok jest jednowątkowy.

  2. Drugim krokiem jest wykonanie obliczeń. Ten krok jest wielowątkowy.

Część jednowątkowa może znacząco wpłynąć na wydajność. Jednym z przykładów jest sytuacja, gdy w agregacji znajduje się wiele pól, na przykład Sum(Quantity*ListPrice). Jeżeli Quantity znajduje się w tabeli faktów, a ListPrice znajduje się w tabeli produktów głównych, aparat musi najpierw połączyć obie tabele, aby znaleźć kombinacje, zanim będzie mógł rozpocząć sumowanie produktu. Łączenie jest częścią jednowątkową, a sumowanie jest wielowątkowe. Jeśli oba pola znajdują się w tej samej tabeli, łączenie nie jest konieczne, a agregacja jest oceniana znacznie szybciej.

Korzystanie z funkcji Aggr() i zagnieżdżonej funkcji Aggr() w stopniu minimalnym

Funkcja Aggr() znacząco wpływa na wydajność. Niewłaściwe użycie może dać niedokładne wyniki. Na przykład w tabeli z wymiarami, które różnią się od wymiarów w funkcji Aggr(). Więcej informacji w temacie Kiedy nie używać AGGR?

Stosowanie analizy zestawów, gdy jest to możliwe

Za pomocą analizy zestawów można zdefiniować zestaw wartości danych, który różni się od zwykłego zestawu określonego przez aktualne wybory. Więcej informacji można znaleźć w temacie Analiza zestawów.

Unikanie porównań ciągów w miarę możliwości

Porównania ciągów nie są tak wydajne jak analiza zestawów. Na przykład należy unikać Match(), MixMatch(), WildMatch() oraz Pick(). Należy tworzyć flagi w skrypcie lub używać analizy zestawów. Więcej informacji w temacie Funkcje warunkowe oraz Wydajność agregacji warunkowych.

Stosowanie warunków obliczania na obiektach zawierających złożone obliczenia

Można mieć wizualizacje z wieloma rekordami, gdy nie ma żadnych wyborów. Najlepszą praktyką jest dodawanie warunków obliczania do obiektów, tak aby były one renderowane dopiero po dokonaniu określonych wyborów. Zapobiega to powstawaniu bardzo dużych hiperkostek. Na przykład: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. W tym scenariuszu wizualizacja nie zostanie wyrenderowana, jeśli użytkownik nie wybierze jednego kraju lub nie dokona innych wyborów, w których możliwy jest tylko jeden kraj.

Wstępne obliczanie miar w skrypcie w miarę możliwości

Każda miara, która znajduje się na najniższym poziomie szczegółowości modelu danych powinna być obliczana w skrypcie. Jeśli na przykład w tym samym rekordzie w tabeli występuje Sales oraz Cost, można uzyskać wartość marży poprzez obliczenie Sales - Cost AS Margin. Można również agregować inne wartości z wyprzedzeniem, jeśli wiadomo, że nie będą się one różnić w zależności od wyboru lub że są one związane z innym poziomem szczegółowości.

Tabele mają mniej niż 15 kolumn i mają warunki obliczania

Tabelę z 15 kolumnami można uznać za szeroką. Jeśli tabele składają się z wielu rekordów, należy użyć obliczonych warunków na obiekcie tabeli tak, aby renderował się tylko po spełnieniu pewnych kryteriów lub wyborów. Jeśli tabela jest bardzo szeroka, należy rozważyć następujące opcje:

  • Utworzenie wielu mniejszych tabel, które są wyświetlane warunkowo.
  • Używanie metod do warunkowego wyświetlania kolumn.
  • Ograniczanie tabel tylko do tych pól, które są niezbędne do analizy.

Arkusze nie mają zbyt wielu obiektów

Obiekty są obliczane, gdy użytkownik przechodzi do arkusza. Za każdym razem, gdy użytkownik dokonuje wyboru na tym arkuszu, każdy obiekt zostaje ponownie obliczony, jeśli ten aktualny stan nie istnieje w pamięci podręcznej. W przypadku arkusza z wieloma wykresami użytkownik będzie musiał czekać na obliczenie każdego obiektu przy niemalże każdym wyborze. Stanowi to znaczne obciążenie dla silnika. Najlepiej postępować zgodnie z koncepcją Dashboard/Analysis/Reporting (DAR) , aby utworzyć przejrzystą i minimalistyczną aplikację. Więcej informacji w temacie Metodologia DAR.

Stosowanie flag numerycznych w skrypcie do wykorzystania w analizie zestawów

Analiza zestawów z flagami może być bardziej efektywna niż porównywanie lub mnożenie ciągów.

Używanie elementów głównych lub zmiennych w wyrażeniach

Elementy główne umożliwiają przeciąganie i upuszczanie zarządzanych wskaźników oraz gwarantują, że wyrażenia zostaną zbuforowane. Na przykład Sum(Sales) różni się od SUM(Sales). Wyrażenia są buforowane z pisownią oraz wielkością liter i muszą pasować słowo w słowo, aby mogły być ponownie użyte.