Zarządzanie obliczeniami dla dedykowanej puli SQL (dawniej SQL DW) w usłudze Azure Synapse Analytics
Dowiedz się więcej o zarządzaniu zasobami obliczeniowymi dedykowaną pulą SQL (dawniej SQL DW) w usłudze Azure Synapse Analytics. Niższe koszty dzięki wstrzymaniu dedykowanej puli SQL lub skalowaniu dedykowanej puli SQL w celu spełnienia wymagań dotyczących wydajności.
Co to jest zarządzanie obliczeniami?
Architektura dedykowanej puli SQL (dawniej SQL DW) oddziela magazyn i zasoby obliczeniowe, dzięki czemu każda z nich może być skalowana niezależnie. W rezultacie można skalować zasoby obliczeniowe w celu spełnienia wymagań związanych z wydajnością niezależnie od magazynu danych. Można również wstrzymywać i wznawiać działanie zasobów obliczeniowych. Naturalną konsekwencją tej architektury jest to, że rozliczenia dla zasobów obliczeniowych i magazynu są oddzielne. Jeśli na chwilę nie musisz używać dedykowanej puli SQL (dawniej SQL DW), możesz zaoszczędzić koszty obliczeń, wstrzymując zasoby obliczeniowe.
Skalowanie zasobów obliczeniowych
Zasoby obliczeniowe możesz skalować w poziomie i zmniejszać ich skalę przez dostosowywanie ustawienia jednostek magazynu danych dla dedykowanej puli SQL (dawniej SQL DW). Wydajność ładowania i zapytań można zwiększać liniowo w miarę dodawania większej liczby jednostek magazynu danych.
Aby uzyskać instrukcje skalowania w poziomie, zobacz przewodniki Szybki start dotyczące witryny Azure Portal, programu PowerShell lub języka T-SQL . Operacje skalowania w poziomie można również wykonywać za pomocą interfejsu API REST.
W celu wykonania operacji dedykowana pula SQL (dawniej SQL DW) najpierw zabija wszystkie przychodzące zapytania, a następnie wycofuje transakcje w celu zapewnienia spójnego stanu. Skalowanie jest realizowane dopiero po ukończeniu wycofywania transakcji. W przypadku operacji skalowania system odłącza warstwę magazynu od węzłów obliczeniowych, dodaje węzły obliczeniowe, a następnie ponownie dołącza warstwę magazynu do warstwy obliczeniowej. Każda dedykowana pula SQL (dawniej SQL DW) jest przechowywana jako 60 dystrybucji, które są równomiernie dystrybuowane do węzłów obliczeniowych. Dodanie większej liczby węzłów obliczeniowych zwiększa moc obliczeniową. Wraz ze wzrostem liczby węzłów obliczeniowych liczba dystrybucji na węzeł obliczeniowy zmniejsza się, zapewniając większą moc obliczeniową zapytań. Podobnie zmniejszenie liczby jednostek magazynu danych zmniejsza liczbę węzłów obliczeniowych, co zmniejsza zasoby obliczeniowe zapytań.
W poniższej tabeli pokazano, jak zmienia się liczba dystrybucji na węzeł obliczeniowy w miarę zmiany jednostek magazynu danych. DW30000c zapewnia 60 węzłów obliczeniowych i osiąga znacznie wyższą wydajność zapytań niż DW100c.
| Jednostki magazynu danych | Liczba węzłów obliczeniowych | Liczba dystrybucji na węzeł |
|---|---|---|
| DW100c | 1 | 60 |
| DW200c | 1 | 60 |
| DW300c | 1 | 60 |
| DW400c | 1 | 60 |
| DW500c. | 1 | 60 |
| DW1000c | 2 | 30 |
| DW1500c | 3 | 20 |
| DW2000c | 4 | 15 |
| DW2500c | 5 | 12 |
| DW3000c | 6 | 10 |
| DW5000c | 10 | 6 |
| DW6000c | 12 | 5 |
| DW7500c | 15 | 4 |
| DW10000c | 20 | 3 |
| DW15000c | 30 | 2 |
| DW30000c | 60 | 1 |
Znajdowanie odpowiedniego rozmiaru jednostek magazynu danych
Aby zobaczyć korzyści z wydajności skalowania w poziomie, szczególnie w przypadku większych jednostek magazynu danych, chcesz użyć co najmniej zestawu danych o rozmiarze 1 TB. Aby znaleźć najlepszą liczbę jednostek magazynu danych dla dedykowanej puli SQL (dawniej SQL DW), spróbuj przeprowadzić skalowanie w górę i w dół. Uruchom kilka zapytań z różnymi liczbami jednostek magazynu danych po załadowaniu danych. Ponieważ skalowanie jest szybkie, możesz wypróbować różne poziomy wydajności w ciągu godziny lub mniej.
Rekomendacje w celu znalezienia najlepszej liczby jednostek magazynu danych:
- W przypadku dedykowanej puli SQL (dawniej SQL DW) w programowania rozpocznij od wybrania mniejszej liczby jednostek magazynu danych. Dobrym punktem wyjścia jest DW400c lub DW200c.
- Monitoruj wydajność aplikacji, obserwując liczbę wybranych jednostek magazynu danych w porównaniu z obserwowaną wydajnością.
- Załóżmy skalę liniową i określ, ile trzeba zwiększyć lub zmniejszyć liczbę jednostek magazynu danych.
- Kontynuuj wprowadzanie korekt, dopóki nie osiągniesz optymalnego poziomu wydajności dla wymagań biznesowych.
Kiedy należy skalować w poziomie
Skalowanie jednostek magazynu danych wpływa na następujące aspekty wydajności:
- Liniowo poprawia wydajność systemu na potrzeby skanowania, agregacji i instrukcji CTAS.
- Zwiększa liczbę czytelników i składników zapisywania do ładowania danych.
- Maksymalna liczba współbieżnych zapytań i gniazd współbieżności.
Rekomendacje, kiedy skalować w poziomie jednostki magazynu danych:
- Przed wykonaniem dużej ilości operacji ładowania lub przekształcania danych przeprowadź skalowanie w poziomie, aby umożliwić szybsze udostępnianie danych.
- W godzinach szczytu pracy przeprowadź skalowanie w poziomie, aby obsłużyć większą liczbę współbieżnych zapytań.
Co zrobić, jeśli skalowanie w górę nie poprawi wydajności?
Dodawanie jednostek magazynu danych zwiększających równoległość. Jeśli praca jest równomiernie podzielona między węzły obliczeniowe, dodatkowa równoległość zwiększa wydajność zapytań. Jeśli skalowanie wyprzedaje nie zmienia wydajności, istnieje kilka powodów, dla których może się to zdarzyć. Dane mogą być niesymetryczne w różnych dystrybucjach lub zapytania mogą wprowadzać dużą ilość przenoszenia danych. Aby zbadać problemy z wydajnością zapytań, zobacz Rozwiązywanie problemów z wydajnością.
Wstrzymywanie i wznawianie procesów obliczeniowych
Wstrzymanie obliczeń powoduje odłączenie warstwy magazynu od węzłów obliczeniowych. Zasoby obliczeniowe są zwalniane z konta. Opłaty za zasoby obliczeniowe nie są naliczane podczas wstrzymania obliczeń. Wznawianie ponownego dołączania magazynu do węzłów obliczeniowych i wznawia naliczanie opłat za zasoby obliczeniowe. W przypadku wstrzymania dedykowanej puli SQL (dawniej SQL DW):
- Zasoby obliczeniowe i zasoby pamięci są zwracane do puli dostępnych zasobów w centrum danych
- Koszty jednostek magazynu danych są zerowe przez czas trwania wstrzymania.
- Nie ma to wpływu na magazyn danych, a dane pozostają nienaruszone.
- Wszystkie uruchomione lub w kolejce operacje są anulowane.
- Liczniki dmV są resetowane.
Po wznowieniu dedykowanej puli SQL (dawniej SQL DW):
- Dedykowana pula SQL (dawniej SQL DW) uzyskuje zasoby obliczeniowe i pamięci dla ustawienia jednostek magazynu danych.
- Wznawianie opłat za zasoby obliczeniowe dla jednostek magazynu danych.
- Twoje dane staną się dostępne.
- Gdy dedykowana pula SQL (dawniej SQL DW) jest w trybie online, należy ponownie uruchomić zapytania obciążenia.
Jeśli zawsze chcesz, aby dedykowana pula SQL (dawniej SQL DW) była dostępna, rozważ skalowanie jej w dół do najmniejszego rozmiaru, a nie wstrzymując.
Aby zapoznać się z krokami wstrzymywania i wznawiania, zobacz przewodniki Szybki start dotyczące witryny Azure Portal lub programu PowerShell . Możesz również użyć interfejsu API REST wstrzymywania lub interfejsu API REST wznawiania.
Opróżnianie transakcji przed wstrzymywaniem i skalowaniem
Zalecamy, aby poczekać na zakończenie istniejących transakcji przed zainicjowaniem operacji wstrzymania lub skalowania.
W przypadku wstrzymania lub skalowania dedykowanej puli SQL (dawniej SQL DW) zapytania są anulowane podczas inicjowania żądania wstrzymania lub skalowania. Anulowanie prostego zapytania typu SELECT to szybka operacja, która nie ma prawie żadnego wpływu na czas wstrzymywania lub skalowania wystąpienia. Może jednak nie być możliwe szybkie zatrzymanie zapytań transakcyjnych, które modyfikują dane lub ich strukturę. Zapytania transakcyjne należy z założenia wykonać w całości lub wycofać ich zmiany. Całkowite cofnięcie wyników działania zapytania transakcyjnego może trwać równie długo lub nawet dłużej niż pierwotna zmiana wprowadzona przez zapytanie. Na przykład w przypadku anulowania zapytania, którego zadaniem było usunięcie wierszy i które było uruchomione przez godzinę, może upłynąć kolejna godzina, zanim system z powrotem wstawi wiersze, które zostały usunięte. W przypadku uruchomienia procedury wstrzymywania lub skalowania w toku transakcji operacja wstrzymywania lub skalowania może zająć dużo czasu, ponieważ zanim będzie możliwe jej wykonanie, zmiany muszą zostać w pełni cofnięte.
Zobacz również Omówienie transakcji i Optymalizowanie transakcji.
Automatyzowanie zarządzania obliczeniami
Aby zautomatyzować operacje zarządzania obliczeniami, zobacz Zarządzanie obliczeniami za pomocą funkcji platformy Azure.
Wykonanie każdej operacji zwiększania skali w poziomie, wstrzymywania i wznawiania może potrwać kilka minut. Jeśli skalowanie, wstrzymanie lub wznawianie odbywa się automatycznie, zalecamy zaimplementowanie logiki, aby upewnić się, że niektóre operacje zostały ukończone przed kontynuowaniem innej akcji. Sprawdzanie stanu dedykowanej puli SQL (dawniej SQL DW) za pomocą różnych punktów końcowych umożliwia poprawne zaimplementowanie automatyzacji takich operacji.
Aby sprawdzić stan dedykowanej puli SQL (dawniej SQL DW), zobacz przewodnik Szybki start programu PowerShell lub języka T-SQL . Możesz również sprawdzić stan dedykowanej puli SQL (dawniej SQL DW) przy użyciu interfejsu API REST.
Uprawnienia
Skalowanie dedykowanej puli SQL (dawniej SQL DW) wymaga uprawnień opisanych w artykule ALTER DATABASE. Wstrzymywanie i wznawianie wymaga uprawnień współautora bazy danych SQL, w szczególności Microsoft.Sql/servers/databases/action.
Następne kroki
Zobacz przewodnik dotyczący zarządzania obliczeniami Inny aspekt zarządzania zasobami obliczeniowymi polega na przydzielaniu różnych zasobów obliczeniowych dla poszczególnych zapytań. Aby uzyskać więcej informacji, zobacz Klasy zasobów do zarządzania obciążeniami.