Ćwiczenie — omówienie problemów z wydajnością związanych z tabelami

Ukończone

Identyfikowanie problemów z wydajnością związanych z tabelami

1. Wybierz centrum Rozwoju.

   

2. Z menu Programowanie wybierz + przycisk (1) i wybierz pozycję Skrypt SQL (2) z menu kontekstowego.

   

3. W menu paska narzędzi połącz się z bazą danych SQL Pool, aby wykonać zapytanie.

   

4. W oknie zapytania zastąp skrypt następującym kodem:

   SELECT  
       COUNT_BIG(*)
   FROM
       [wwi_perf].[Sale_Heap]
   

5. Wybierz pozycję Uruchom z menu paska narzędzi, aby wykonać polecenie SQL.

   

   Wykonanie skryptu trwa do 15 sekund i zwraca liczbę ok. 340 milionów wierszy w tabeli.

   Jeśli skrypt nadal działa po 45 sekundach, kliknij przycisk Anuluj.

   Uwaga

   Nie wykonuj tego zapytania z wyprzedzeniem. Jeśli to zrobisz, zapytanie może działać szybciej podczas kolejnych uruchomień.

   

6. W oknie zapytania zastąp skrypt następującą instrukcją (bardziej złożoną):

   SELECT TOP 1000 * FROM
   (
       SELECT
           S.CustomerId
           ,SUM(S.TotalAmount) as TotalAmount
       FROM
           [wwi_perf].[Sale_Heap] S
       GROUP BY
           S.CustomerId
   ) T
   OPTION (LABEL = 'Lab03: Heap')
   

7. Wybierz pozycję Uruchom z menu paska narzędzi, aby wykonać polecenie SQL.

   

   Wykonanie skryptu trwa do 30 sekund i zwraca wynik. Tabela Sale_Heap wyraźnie ma problem, który wpływa na wydajność.

   Jeśli skrypt nadal działa po jednej minucie, kliknij przycisk Anuluj.

   

   Uwaga

   Klauzula OPTION, która została użyta w instrukcji. Przydaje się, gdy chcesz zidentyfikować zapytanie w DMV sys.dm_pdw_exec_requests.

   SELECT  *
   FROM    sys.dm_pdw_exec_requests
   WHERE   [label] = 'Lab03: Heap';
   

8. Wybierz centrum danych.

   

9. Rozwiń bazę danych SQLPool01 i jej listę tabel (1).. Kliknij prawym przyciskiem myszy wwi_perf.Sale_Heap (2), wybierz pozycję Nowy skrypt SQL (3), a następnie wybierz pozycję UTWÓRZ (4).

   

10. Przyjrzyj się skryptowi użytemu do utworzenia tabeli:

    CREATE TABLE [wwi_perf].[Sale_Heap]
    ( 
      [TransactionId] [uniqueidentifier]  NOT NULL,
      [CustomerId] [int]  NOT NULL,
      [ProductId] [smallint]  NOT NULL,
      [Quantity] [tinyint]  NOT NULL,
      [Price] [decimal](9,2)  NOT NULL,
      [TotalAmount] [decimal](9,2)  NOT NULL,
      [TransactionDateId] [int]  NOT NULL,
      [ProfitAmount] [decimal](9,2)  NOT NULL,
      [Hour] [tinyint]  NOT NULL,
      [Minute] [tinyint]  NOT NULL,
      [StoreId] [smallint]  NOT NULL
    )
    WITH
    (
      DISTRIBUTION = ROUND_ROBIN,
      HEAP
    )
    

    Uwaga

    Nie uruchamiaj tego skryptu! Jest to tylko do celów demonstracyjnych, aby przejrzeć schemat.

    Możesz natychmiast zauważyć co najmniej dwie przyczyny spadku wydajności.

    • ROUND_ROBIN Rozkład
    • Struktura HEAP tabeli

    Uwaga

    W takim przypadku, gdy szukamy szybkich czasów odpowiedzi na zapytania, struktura stert nie jest dobrym wyborem, ponieważ zobaczymy to za chwilę. Mimo to istnieją przypadki, w których użycie tabeli stert może pomóc w wydajności, a nie zaszkodzić. Jednym z takich przykładów jest to, że chcemy pozyskiwać duże ilości danych do puli SQL.

    Gdybyśmy szczegółowo przejrzeli plan zapytania, wyraźnie zobaczylibyśmy główną przyczynę problemu z wydajnością: przenoszenie danych między dystrybucjami.

    Przenoszenie danych to operacja, w której części tabel rozproszonych są przenoszone do różnych węzłów podczas wykonywania zapytania. Ta operacja jest wymagana, gdy dane nie są dostępne w węźle docelowym, najczęściej gdy tabele nie współużytkują klucza dystrybucji. Najczęstszą operacją przenoszenia danych jest przetasowanie. Podczas mieszania dla każdego wiersza wejściowego usługa Synapse oblicza wartość skrótu przy użyciu kolumn sprzężenia, a następnie wysyła ten wiersz do węzła, który jest właścicielem tej wartości skrótu. Jedna lub obie strony sprzężenia mogą uczestniczyć w procesie przetasowywania. Na poniższym diagramie przedstawiono przetasowanie w celu zaimplementowania sprzężenia między tabelami T1 i T2, w których żadna z tabel nie jest dystrybuowana według kolumny sprzężenia col2.

    

    Jest to w rzeczywistości jeden z najprostszych przykładów, biorąc pod uwagę niewielki rozmiar danych, które muszą być przetasowane. Możesz sobie wyobrazić, jak bardzo sytuacja się pogarsza, gdy rozmiar potasowanych wierszy się zwiększa.