Planowanie Azure Database for PostgreSQL wdrożeń pod kątem wydajności operacyjnej

Przetwarzanie w chmurze znacznie zmieniło krajobraz hostingu bazy danych. Zapewnia zespołom dostęp do skalowalności, odporności, zasięgu globalnego i możliwości, które były wcześniej nieosiągalne. Zamiast ponosić znaczne koszty i nakłady pracy, planując największe możliwe obciążenie (i przenosząc ten koszt od pierwszego dnia), zespoły mogą teraz optymalizować wokół dokładnej skali, której potrzebują, gdy tego potrzebują, i dostosować w miarę zmian wymagań.

Introduction

Elastyczność wybierania odpowiedniej równowagi zasobów jest szczególnie cenna w przypadku wdrożeń bazy danych PostgreSQL. Obciążenia bazy danych PostgreSQL mogą zaczynać się od małych obciążeń, szybko rosnąć, zwiększać sezonowo, zmieniać się z dominujących odczytów na dominujące zapisy lub ewoluować z obciążeń transakcyjnych w hybrydowe systemy operacyjno-analityczne w czasie rzeczywistym. Azure Database for PostgreSQL zapewnia, że rozwiązania trafią do Twoich celów, oferując szeroką gamę wyborów w zakresie zasobów obliczeniowych, magazynu, dostępności, replikacji, zabezpieczeń, kopii zapasowych i zarządzania operacyjnego.

Jednak wraz z całą tą mocą wiąże się odpowiedzialność, szczególnie podczas planowania wdrożeń. Aby osiągnąć najlepszą możliwą wydajność, decyzje dotyczące wdrażania muszą być zgodne z wymaganiami ogólnego obciążenia.

Pomyślne wdrożenie Azure Database for PostgreSQL nie jest tylko kwestią wyboru "najbardziej potrzebnych rdzeni i pamięci". Zamiast tego maksymalna wydajność operacyjna wynika z zrozumienia zachowań aplikacji, zachowań klienta, obliczeń, magazynu i właściwości wzrostu bazy danych oraz sposobu, w jaki wszystkie te elementy przecinają się i wchodzą w interakcje.

Najlepszą architekturą jest ta, w której te elementy są celowo wyrównane.

Planowanie wydajności chmury jest wspólną odpowiedzialnością

Jedną z głównych zalet przejścia na zaufaną platformę w chmurze jest model wspólnej odpowiedzialności. Microsoft zapewnia globalną infrastrukturę, usługi zarządzane, innowacje sprzętowe, niezawodność, zabezpieczenia i inżynierię operacyjną. Zespoły mają wiedzę kontekstową specyficzną dla aplikacji: krytyczność biznesową, zachowanie obciążenia, projekt modelu danych, profil ruchu sieciowego, oczekiwania dotyczące wzrostu, cele odzyskiwania i wymagania dotyczące środowiska użytkownika końcowego.

Najsilniejsze wyniki pojawiają się, gdy te dwie siły są ujednolicone.

Azure zapewnia wysoce skalowalną infrastrukturę Postgres, ale twój zespół musi uzyskiwać szczegółowe informacje w następujących obszarach:

Ilu równoczesnych użytkowników oczekuje się w normalnych i szczytowych okresach?
Czy najważniejsze operacje charakteryzują się dużą liczbą odczytów, dużą liczbą zapisów czy są mieszane?
Czy skok w zapotrzebowaniu występuje w okresach zakończenia miesiąca, kwartału, świąt, wprowadzeń na rynek lub okien raportowania?
Jak szybko rośnie zestaw danych?
Które operacje są wrażliwe na opóźnienia?
Które zapytania lub zadania mogą tolerować dłuższy czas wykonania?
Czy obciążenie jest głównie OLTP, OLAP, czy hybrydowe?
Czy klienci znajdują się w pobliżu regionu bazy danych, globalnie rozproszonego lub skoncentrowanego w jednej lokalizacji geograficznej?

Przechwyć te szczegóły przed wdrożeniem, a nie po incydencie produkcyjnym. Wdrożenia w chmurze ułatwiają skalowanie, ale najbardziej wydajne i najbardziej opłacalne projekty nadal zaczynają się od solidnego zbierania wymagań oraz właściwego planowania. W większości przypadków te pytania można sprowadzić do relacji między połączeniami współbieżnymi, maksymalną liczbą operacji we/wy na sekundę i wymaganą przepustowością.

Wydajność ma wiele warstw

Wydajność bazy danych jest rzadko określana przez pojedyncze ustawienie. Pomyślne doświadczenia z wdrażaniem zależą od kilku warstw, które działają wspólnie.

Wydajność warstwy aplikacji.
Ta warstwa obejmuje kod aplikacji, wzorce zapytań, pokrycie indeksów, użycie wyzwalaczy, partycjonowanie danych, zarządzanie połączeniami, buforowanie, logikę ponownych prób, zachowanie puli, zachowanie ORM, projektowanie transakcji i zachowanie zadań w tle.
Wydajność warstwy klienta i sieci.
Ta warstwa obejmuje lokalizację klientów, sposób nawiązywania połączeń, czy żądania przekraczają regiony i strefy dostępności, opóźnienia sieciowe, narzut protokołu TLS, rotację połączeń oraz czy aplikacja efektywnie używa pulowania połączeń.
Wydajność platformy bazy danych.
pl-PL: Ta warstwa obejmuje konfigurację wdrożenia Postgres, rozmiar mocy obliczeniowej, pamięć, procesor, typ magazynu, rozmiar magazynu, IOPS magazynu, przepływność magazynu, wysoką dostępność, repliki i operacje konserwacyjne.

Ten artykuł koncentruje się przede wszystkim na trzeciej warstwie: planowanie wdrożenia bazy danych Postgres na platformie Azure w taki sposób, aby wybory dotyczące mocy obliczeniowej i magazynu wspierały wymagany profil wydajności.

Azure Database for PostgreSQL oferuje elastyczność, ale planowanie jest niezbędne

Azure Database for PostgreSQL serwer elastyczny oferuje szeroką gamę opcji wdrażania, w tym:

Obszar wdrażania	Dostępne opcje
Compute	Warstwy obliczeniowe, generacje maszyn wirtualnych, konfiguracje ogólnego przeznaczenia i konfiguracje zoptymalizowane pod kątem pamięci.
Magazyn	Azure Premium SSD (v1), Premium SSD (v2), skalowanie magazynu, konfiguracja IOPS oraz konfiguracja przepustowości.
Availability	Wysoka dostępność, tworzenie kopii zapasowych i przywracanie oraz geograficznie nadmiarowe kopie zapasowe w obsługiwanych konfiguracjach.
Replication	Repliki danych przeznaczonych do odczytu i repliki geograficzne.
Zabezpieczenia	Klucze zarządzane przez klienta i integracja z zabezpieczeniami przedsiębiorstwa.

Ta elastyczność jest wydajna, ponieważ różne obciążenia wymagają różnych możliwości. System transakcyjny z dużą liczbą zapisów nie potrzebuje tego samego profilu co system z dużym obciążeniem raportowaniem. Globalna aplikacja SaaS nie wymaga tego samego projektu co wewnętrzna aplikacja regionalna. Baza danych, która rośnie o 5% rocznie, nie potrzebuje tego samego planu przechowywania, co baza danych rosnąca 200% miesiąc do miesiąca.

Celem planowania jest zidentyfikowanie potrzeb profilu wydajności obciążenia, a następnie zaimplementowanie odpowiednich wyborów zarówno w opcjach obliczeniowych, jak i magazynowych, aby pomyślnie dostarczyć kompleksowe rozwiązania.

Zacznij od profilu obciążenia

Przed wybraniem środowiska obliczeniowego lub magazynu zdefiniuj obciążenie. Przydatne wymiary planowania obejmują:

Obszar planowania	Pytania, na które należy odpowiedzieć
Geografia	Gdzie znajdują się użytkownicy, aplikacje, repliki i integracje?
Concurrency	Ile równoczesnych połączeń i aktywnych zapytań oczekuje się?
Rozmiar danych	Jaki jest bieżący rozmiar bazy danych i jaki jest oczekiwany współczynnik wzrostu?
Częstotliwość zmian	Jak szybko dane rosną w miesiącu? Ile dzienników zapisu z wyprzedzeniem (WAL) jest generowanych?
Typ obciążenia	Czy system jest typu OLTP, OLAP, obciążony raportowaniem, obciążony przetwarzaniem wsadowym czy hybrydowy?
Kombinacja odczytu/zapisu	Jaki procent operacji to odczyty i zapisy?
Szczytowe zachowanie	Czy istnieją przewidywalne cykle biznesowe, sezonowe szczyty lub okna wsadowe?
Czułość opóźnienia	Które transakcje są skierowane do użytkownika i krytyczne pod względem opóźnienia?
Wymagania dotyczące przepływności	Czy są duże skanowania danych, eksporty, importy lub ekstrakcja, transformacja i ładowanie (ETL) procesów?
Oczekiwania w zakresie skalowalności	Czy obciążenie będzie potrzebować tymczasowych skoków lub utrzymującej się wyższej wydajności?

Celem nie jest przewidywanie przyszłości idealnie. Celem jest unikanie projektowania ślepo.

Zrozumieć trzy podstawowe pojęcia dotyczące wydajności przechowywania

Planowanie wydajności magazynu Azure zwykle sprowadza się do trzech pojęć, które są powiązane, ale odrębne: IOPS, przepływności i opóźnień. Te czynniki mają kluczowe znaczenie dla planowania wydajności aplikacji.

liczba operacji we/wy na sekundę

IOPS oznacza operacje wejścia/wyjścia na sekundę. Mierzy liczbę operacji odczytu lub zapisu, które baza danych może wysyłać do magazynu na sekundę.

IOPS jest szczególnie ważne w przypadku obciążeń OLTP. Te systemy często wykonują wiele małych, losowych operacji odczytu i zapisu, takich jak wstawianie, aktualizacje, wyszukiwanie indeksów, odczyty punktów i krótkie transakcje. Obciążenie transakcyjne z tysiącami równoczesnych użytkowników może wymagać wysokiego IOPS, nawet jeśli każda pojedyncza operacja jest mała.

Typowe scenariusze wrażliwe na IOPS obejmują:

Przetwarzanie zamówień o dużej ilości
Aktualizacje profilu użytkownika
Systemy spisu
Pozyskiwanie zdarzeń
Systemy płatności lub rozliczeń
Wysoce współbieżne aplikacje SaaS

Produktywność

Przepływność, czasami nazywana przepustowością, mierzy ilość danych, które można odczytywać lub zapisywać w magazynie danych w czasie. Jest wyrażona w MB/s.

Przepływność ma znaczenie, gdy operacje przenoszą duże ilości danych. Zapytania analityczne, kopie zapasowe, przywracania, zadania wsadowe, kompilacje indeksów, skanowania tabel i przepływy pracy ETL mogą wymagać wysokiej przepustowości, nawet jeśli nie wymagają najwyższej liczby operacji we/wy na sekundę.

Typowe scenariusze wrażliwe na przepływność obejmują:

Raportowanie zapytań dotyczących dużych tabel
Importy zbiorcze lub eksporty
Skanowanie w stylu magazynu danych
Operacje tworzenia kopii zapasowych i przywracania
Operacje tworzenia lub ponownego kompilowania dużych indeksów
Przetwarzanie wsadowe

Opóźnienie

Opóźnienie to czas potrzebny na ukończenie pojedynczego żądania we/wy. Niskie opóźnienie jest niezbędne w przypadku operacji baz danych, które są skierowane do użytkowników, zwłaszcza gdy wiele małych operacji jest powiązanych w ramach jednej transakcji.

System może mieć wysokie teoretyczne IOPS, ale nadal działać wolno, gdy opóźnienia są wysokie. W przypadku obciążeń Postgres opóźnienie dostępu do pamięci masowej może mieć bezpośredni wpływ na czasy odpowiedzi zapytań, przebieg zatwierdzania transakcji, zachowanie punktu kontrolnego i ogólną responsywność aplikacji.

Uwaga / Notatka

Dyski SSD Premium v1 zostały zaprojektowane pod kątem opóźnień rzędu pojedynczych milisekund dla większości operacji wejścia/wyjścia, a buforowanie dysku może dodatkowo zmniejszyć opóźnienie odczytu dla konfiguracji dysków poniżej 4 TB. Dyski Premium SSD v2 i Ultra Disk oferują opóźnienie na poziomie poniżej milisekundy.

Liczba operacji we/wy na sekundę, przepływność i opóźnienie muszą być rozważane łącznie.

IOPS i przepustowość są ze sobą powiązane. Obciążenie wykonujące wiele małych operacji 8 KiB może prowadzić do dużych IOPS bez wysokiej przepływności. Obciążenie generujące rozległe operacje wielomegabajtowe może zwiększyć przepustowość przy mniejszej liczbie operacji we/wy na sekundę.

Prosty sposób, aby o tym pomyśleć:

Liczba operacji we/wy na sekundę x rozmiar we/wy = przepustowość

W przypadku bazy danych Postgres praktyczną implikacją jest to, że planowanie magazynu obciążenia powinno być oparte na obserwowanym lub szacowanym zachowaniu obciążenia, a nie na samym rozmiarze bazy danych. Przykład:

System OLTP o wysokiej współbieżności może wymagać większej liczby IOPS i mniejszego opóźnienia.
System z dużą liczbą raportów może potrzebować większej przepływności.
System hybrydowy może wymagać obu, zwłaszcza podczas cykli szczytowych.
System OLTP o wysokiej współbieżności może wymagać większej liczby IOPS i mniejszego opóźnienia.
System z dużą liczbą raportów może potrzebować większej przepływności.
System hybrydowy może wymagać obu, zwłaszcza podczas cykli szczytowych.

Wybór wdrożenia ma bezpośredni wpływ na wydajność magazynu

Typowym błędem jest ustawienie parametrów magazynowania pod kątem docelowej wydajności bez pełnego rozważenia, czy wybrana jednostka SKU dla zasobów obliczeniowych może osiągnąć te same poziomy wydajności.

Wydajność pamięci masowej Azure wymaga uwzględnienia wielu czynników. Te szczegóły obejmują następujące elementy:

Zestaw możliwości obliczeniowych (maksymalne limity liczby operacji we/wy na sekundę i przepływności obliczeniowej).
Generacja pamięci masowej (SSD w wersji 1, SSD w wersji 2, Ultra Disk).
Rozmiar dysku magazynu (dyski SSD v1 poniżej 4096 GB obsługują cache hosta, co umożliwia wzrost liczby IOPS powyżej standardowych bazowych poziomów).
Wydajność operacji we/wy na sekundę (IOPS) magazynowania.
Przepustowość pamięci.

W praktyce: efektywny limit wydajności jest najniższym odpowiednim limitem w łańcuchu.

Jeśli konfiguracja magazynowania może zapewnić 80 000 operacji we/wy na sekundę, ale jednostka SKU obliczeniowa może obsługiwać tylko 20 000 operacji we/wy na sekundę, wdrożenie nie zapewnia 80 000 operacji we/wy na sekundę. Z drugiej strony, jeśli generacja maszyny wirtualnej obsługuje dużą liczbę operacji IOPS, ale wybrana warstwa magazynowania jest ograniczona do niższego poziomu, warstwa magazynowania stanie się limitem.

Planowanie zasobów obliczeniowych i magazynu powinno odbywać się razem.

Dysk SSD Premium v1: wysoka podstawowa wydajność z istotnym zachowaniem buforowania.

Premium SSD v1 jest typowym wyborem dla obciążeń produkcyjnych Azure Postgres wymagających przewidywalnej, zagwarantowanej wydajności. Pamięć Azure Postgres SSD v1 obsługuje maksymalnie 32 TB przestrzeni, 20 000 IOPS i 900 MB/s przepustowości.

Premium SSD w wersji 1 dobrze sprawdza się w przypadku obciążeń, które korzystają z buforowania przez hosta. Azure Postgres obsługuje buforowanie hostów dla dysków SSD w wersji 1 mniejszych niż 4096 GB. Każdy dysk aprowizowany do 4095 GB może korzystać z buforowania hosta. Gdy magazyn zostanie przydzielony o rozmiarze 4096 GB lub większym, buforowanie hosta nie jest obsługiwane. Granica ta ma znaczenie. W przypadku wdrożeń Premium SSD v1 o pojemności poniżej 4 TB, buforowanie może zwiększyć wydajność odczytu i zmniejszyć opóźnienie odczytu. To buforowanie zapewnia doskonałą wydajność kosztową dla obciążeń wymagających odczytu lub mieszanych, które mieszczą się poniżej progu buforowania.

Dlaczego granica 4 TB ma znaczenie

Gdy wdrożenie SSD w wersji 1 w warstwie Premium wykracza poza zakres obsługiwany przez buforowanie, profil wydajności może ulec zmianie:

Odczyty nie korzystają już z pamięci podręcznej hosta.
Więcej operacji odczytu pochodzi bezpośrednio z dysku bazowego.
Odczyty wpływają na limit operacji we/wy na sekundę (IOPS) dysku oraz ograniczenia przepustowości.
Obciążenia odczytu z uwzględnieniem opóźnienia mogą mieć inne zachowanie.
Konfiguracja, która była wcześniej wydajna, może potrzebować większej liczby IOPS, większej przepustowości, skalowania obliczeń, optymalizacji zapytań lub innej opcji magazynowania.

Przekroczenie 4 TB nie jest złe, ale musisz to zaplanować.

Jeśli spodziewasz się, że baza danych przekroczy 4 TB, rozważ przyszły stan podczas projektowania architektury. Projekt, który dobrze sprawdza się na poziomie 2 TB z buforowaniem, może potrzebować innego planu wydajności o pojemności 5 TB bez buforowania.

Wybuchowy wzrost pomaga przy nagłych skokach, ale nie zastępuje trwałej wydajności.

Azure alokacje pamięci dla Postgres Premium SSD v1 o pojemności poniżej 4 TB wspierają wybuchy buforowania hosta, co może pomóc w scenariuszach, takich jak:

Aktywność startowa
Krótkie zadania wsadowe
Nagłe wzrosty ruchu
Przetwarzanie na koniec miesiąca
Tymczasowe wzrosty obciążenia

Podczas gdy pęknięcie jest przydatne, należy go ostrożnie użyć. Wzrost może pochłaniać tymczasowe skoki, ale nie powinien być podstawą trwałego zapotrzebowania na obciążenia. Jeśli obciążenie często działa powyżej planu bazowego, lepiej aprowizować wyższą warstwę wydajności, dostosować ustawienia wydajności magazynu, skalować obliczenia lub przeprojektować wzorzec obciążenia.

Dobrym pytaniem do planowania jest: Czy to jest tymczasowy skok, czy to nowa norma?

Tymczasowe skoki mogą być dobrymi kandydatami do pęknięć. Obsługa trwałego zapotrzebowania z celowym planowaniem pojemności.

Premium SSD v2 rozłącza pojemność, liczbę operacji we/wy na sekundę (IOPS) i przepływność.

Premium SSD v2 zmienia model planowania przez oddzielenie rozmiaru dysku, liczby operacji we/wy na sekundę i przepustowości. Azure Database for PostgreSQL serwer elastyczny SSD Premium w wersji 2 obsługuje:

Pojemność z 32 GB do 64 TB.
Do 80 000 operacji we/wy na sekundę.
Do 1200 MB/s przepływności.
Dostosowanie pojemności w małych przyrostach co 1 GB.
Elastyczna konfiguracja operacji we/wy na sekundę (IOPS) i przepustowości.
Niższe opóźnienie niż Premium SSD v1.
Brak buforowania hosta.

Ta zmiana jest ważną zmianą. Dzięki Premium SSD v1 wydajność jest bardziej powiązana z rozmiarem dysku. Dzięki dyskom SSD w warstwie Premium w wersji 2 można skonfigurować wydajność bardziej bezpośrednio wokół potrzeb związanych z obciążeniem.

Na przykład baza danych z dużą ilością transakcji może wymagać wysokiej liczby operacji IOPS bez potrzeby dużej ilości przestrzeni magazynowej. Azure Postgres zapewnia podstawowe operacje we/wy na sekundę i przepustowość bez dodatkowych kosztów, a dodatkowe operacje we/wy na sekundę i przepustowość są dostępne za dodatkowe koszty. Oferta SSD Premium v2:

Dyski do 399 GB otrzymują plan bazowy wynoszący 3000 operacji we/wy na sekundę i 125 MB/s.
Dyski o pojemności 400 GB lub większej otrzymują podstawowe parametry wydajności 12 000 IOPS i 500 MB/s.
Dyski mogą osiągać do 80 000 IOPS, gdy dostępna przestrzeń wynosi co najmniej 160 GB.
Przepływność może być skalowana do 1200 MB/s.

Premium SSD wersja 2 jest często atrakcyjne, gdy potrzebujesz dokładniejszej kontroli nad kosztami i wydajnością. Zamiast skalować pojemność magazynu tylko w celu odblokowania wydajności, możesz aprowizować wydajność bardziej celowo.

Ultra Disk (wersja zapoznawcza): najwyższej klasy klasa wydajnościowa dysków Azure

Dysk Ultra jest dyskiem o najwyższej wydajności. Azure Ultra Disk oferuje poziomy wydajności do:

400 000 IOPS
Przepływność 10 000 MB/s
Pojemność 64 TB
Cele projektowe dla opóźnienia poniżej milisekundy
Niezależnie konfigurowalna pojemność, liczba operacji we/wy na sekundę (IOPS) i przepustowość

Dysk Ultra jest przeznaczony do obsługi obciążeń o intensywnym zapotrzebowaniu na operacje wejścia-wyjścia dla baz danych klasy najwyższej, SAP HANA i systemów o dużej liczbie transakcji. Ta nowa oferta przechowywania zapewnia najwyższej klasy wydajność dla krytycznych obciążeń. Jednak zespół musi rozważyć niektóre kluczowe możliwości wdrażania, regionalne ograniczenia dostępności i opcje konfiguracji podczas planowania wdrożenia:

Automatyczne skalowanie magazynu nie jest obsługiwane w przypadku serwerów korzystających z dysku Ultra Disk.
Szyfrowanie danych przy użyciu kluczy zarządzanych przez klienta nie jest obsługiwane w przypadku serwerów z dyskiem Ultra Disk
Dyski Ultra nie obsługują buforowania dysków

Ważne jest, aby zrozumieć możliwości Ultra Disk w kontekście szerszego krajobrazu wydajności przechowywania Azure. Należy jednak zweryfikować dostępność i obsługę usługi dla określonego obciążenia Azure Postgres. Sprawdź przedstawiciela Microsoft, czy wersja Ultra Disk Preview jest dostępna dla wdrożenia Azure Postgres.

Praktyczny wniosek: Ultra Disk reprezentuje górny koniec wydajności magazynu Azure, ale projekt end-to-end Postgres musi zawierać porównywalnie obsługiwane kombinacje dla wybranego SKU obliczeniowego, regionu i wersji oprogramowania.

Generowanie maszyn wirtualnych ma znaczenie: limity magazynu obliczeniowego w wersji 5 i 6 są różne

Generowanie zasobów obliczeniowych może mieć istotny wpływ na wydajność magazynu. Podczas eksplorowania najwyższego poziomu wydajności magazynowania Azure, należy unikać nieporozumień, że "zasób obliczeniowy" automatycznie oznacza "maksymalny magazyn". Należy zweryfikować wybrany SKU obliczeniowy względem docelowej warstwy magazynowania. Zilustrujmy ten punkt, biorąc pod uwagę dwie generacje obliczeniowe o podobnym rozmiarze: Ddsv5 i Ddsv6.

Seria Ddsv5 obsługuje Premium Storage (z buforowaniem), SSD w warstwie Premium w wersji 2 i Ultra Disk na poziomie rodziny maszyn wirtualnych. Jednak zagregowane limity magazynu zdalnego maszyny wirtualnej nadal definiują limit dla tego, co może napędzać ta maszyna wirtualna. Ddsv5-series zapewnia wydajność pamięci masowej wynoszącą do 80,000 IOPS i 2,600 MB/s.

Seria Ddsv6 zapenia wyższy zakres pojemności, sięgający do 400 000 IOPS oraz 12 000 MB/s. Obliczenia serii V6 oferują również większą skalowalność niż poprzednie generacje, z maksymalnie 192 procesorami wirtualnymi i pamięcią 768 GiB.

Ta zmiana pokoleniowa jest ważna dla projektowania Postgres o wysokiej wydajności. Jeśli architektura docelowa wymaga wysokiej wydajności pamięci masowej, wybranie generacji obliczeniowej o niższym zagregowanym pułapie pamięci masowej może uniemożliwić wdrożeniu pełne wykorzystanie pełnej możliwości przechowywania.

Przykład: dlaczego dopasowanie end-to-end ma znaczenie

Rozważ obciążenie bazy danych PostgreSQL z aspiracyjnym celem magazynowania wynoszącym 400 000 IOPS.

Na poziomie dysku, Azure Ultra Disk obsługuje do 400 000 IOPS na każdy dysk. Premium SSD v2 obsługuje maksymalnie 80 000 operacji we/wy na sekundę na dysk, a wyższe projekty agregacji mogą wymagać wielu dysków lub abstrakcji na poziomie platformy w zależności od obsługi usługi.

Jednak sama funkcja magazynowania nie wystarczy.

Konfiguracja serii V5 może mieć limit pamięci, który jest niższy od docelowej. Jak wspomniano wcześniej, SKU serii V5 obsługują do 260 000 IOPS dla przepustowości zdalnego dysku SSD klasy Premium. W tym przypadku wybranie warstwy obliczeniowej serii V5 dla tego celu staje się czynnikiem ograniczającym przed osiągnięciem celu 400 000 IOPS.

Natomiast dokumentacja serii Ddsv6 oferuje do 400 000 IOPS i 12 000 MB/s. To sprawia, że seria V6 i nowsze generacje są strategicznie ważne dla projektów, które muszą dostosować obliczenia i magazyn do najwyższych klas wydajności magazynu.

Lekcja jest prosta: maksymalna wydajność bazy danych to kompleksowa właściwość, a nie właściwość tylko do magazynowania.

Planowanie cykli biznesowych, a nie tylko stanu stałego

Wiele systemów nie ma jednego profilu wydajności. Mają one kilka elementów:


Normalny ruch w dni powszednie.	Szczytowe godziny pracy.
Rozliczanie końcowe miesiąca lub kwartału.	Zapotrzebowanie na wakacje lub sezon.
Zdarzenia uruchamiania produktu.	Okna raportowania.
Okna konserwacyjne.	Okresy przetwarzania Azure Batch.
Scenariusze tworzenia kopii zapasowych i przywracania.	Zdarzenia odzyskiwania po awarii.

Baza danych dopasowana do średniego wykorzystania może mieć trudności w najważniejszych momentach. Z drugiej strony, baza danych zaplanowana na stałe pod kątem szczytowego obciążenia występującego raz w miesiącu może być niepotrzebnie kosztowna.

Elastyczność Azure umożliwia zespołom podejmowanie bardziej zniuansowanych wyborów. Przykład:

Użyj Premium SSD w wersji 2, aby dostosować IOPS i przepływność w miarę zmieniających się potrzeb obciążenia.
Użyj replik odczytu, aby odciążyć obciążenia związane z intensywnym odczytem tam, gdzie to właściwe.
Skaluj zasoby obliczeniowe pod kątem znanych okresów szczytowych.
Dostrajanie zapytań, indeksów i puli połączeń przed skalowaniem infrastruktury.
Użyj funkcji obserwowalności, aby określić, czy wąskim gardłem jest CPU, pamięć, IOPS, przepustowość, rywalizacja o blokadę, obciążenie połączeń lub projekt zapytań.

Najlepsze wdrożenie nie zawsze jest największym wdrożeniem. Jest to projekt zgodny z obciążeniem i może bezpiecznie ewoluować.

Obserwowanie jest częścią architektury

Planowanie wydajności nie powinno zatrzymywać się we wdrożeniu. Obciążenia Postgres zmieniają się w czasie. Rośnie ilość danych, zmiany wzorców zapytań, uruchamianie nowych funkcji, zmiany ruchu klientów i gromadzenie zadań operacyjnych.

Obszar monitorowania	Sygnały do przeglądu
Compute	Wykorzystanie procesora CPU i obciążenie pamięci.
Connections	Aktywne połączenia, bezczynne połączenia i zachowanie puli połączeń.
Queries	Czas trwania zapytania, zmiany planu zapytania i użycie indeksu.
Magazyn	Procent wykorzystania pamięci masowej, opóźnienie odczytu, opóźnienie zapisu, wykorzystanie IOPS i statystyki przepustowości.
Maintenance	Wzdęcie tabeli, wzdęcie indeksu, charakterystyka WAL, harmonogramy tworzenia kopii zapasowych i harmonogramy konserwacji.
Replication	Opóźnienie repliki, jeśli jest to istotne.

Azure Database for PostgreSQL dokumentacja przedstawia monitorowanie zużycia operacji we/wy za pośrednictwem portalu Azure lub metryk Azure CLI, w tym maksymalnej pojemności magazynowania, procentowego wykorzystania przestrzeni magazynowej, użytej przestrzeni magazynowej i procentowego wykorzystania operacji we/wy.

Te metryki pomagają odpowiedzieć na najważniejsze pytanie operacyjne: która warstwa rzeczywiście ogranicza wydajność?

Bez obserwacji zespoły mogą skalować niewłaściwe rzeczy. Problem z planem zapytania może wyglądać jak problem z przechowywaniem. Szturmy połączeń mogą wyglądać jak obciążenie procesora. Brakujący indeks może wyglądać jak niewystarczająca liczba IOPS. Problem z umieszczaniem klienta regionalnego może wyglądać jak opóźnienie bazy danych.

Monitorowanie pomaga zespołom wprowadzać ukierunkowane zmiany zamiast kosztownych zgadywania.

Lista kontrolna dotycząca praktycznego planowania

Przed wybraniem konfiguracji Azure Database for PostgreSQL produkcyjnej należy przechwycić następujące informacje.

Category	Planowanie danych wejściowych
Typ obciążenia	OLTP, OLAP, hybrydowe, raportowanie, wsadowe i pozyskiwanie.
Kombinacja odczytu/zapisu	Procentowe odczyty, zapisy, losowe operacje we/wy i sekwencyjne operacje we/wy.
Bieżąca wydajność	Podstawowa liczba operacji we/wy na sekundę, przepływność, opóźnienie, procesor CPU, pamięć i połączenia.
Szczytowa wydajność	90. i 99. percentyl wymagań dotyczących obciążenia.
Rozmiar danych	Bieżący rozmiar, oczekiwany wzrost, duże użycie obiektów i wzrost indeksu.
Wskaźnik wzrostu	Prognozy dotyczące przechowywania miesiąc do miesiąca i rok do roku.
Concurrency	Aktywne sesje, bezczynne sesje i zachowanie puli połączeń.
Cykle biznesowe	Dzienne, tygodniowe, miesięczne, sezonowe i związane z uruchomieniem szczyty.
Availability	Wysoka dostępność, repliki, odzyskiwanie po awarii, kopia zapasowa, przywracanie, cel punktu odzyskiwania (RPO) i cel czasu odzyskiwania (RTO).
Wybór magazynu	Ssd w warstwie Premium, SSD w warstwie Premium w wersji 2, obsługiwane regiony i obsługiwane funkcje.
Wpływ buforowania	Czy buforowanie hostów SSD w wersji 1 w warstwie Premium ma zastosowanie poniżej 4 TB.
Generowanie obliczeń	Określa, czy wybrana jednostka SKU może obsługiwać wymagane operacje we/wy na sekundę i przepływność.
Model skalowania	Ręczne skalowanie, zaplanowane skalowanie, korekta wydajności i repliki.
Możliwość obserwowania	Metryki, alerty, szczegółowe informacje o zapytaniach i proces przeglądu obciążenia.

Zalecane zasady projektowania

Podczas planowania Azure wdrożeń Postgres na potrzeby wydajności operacyjnej należy stosować następujące zasady.

Dostosuj rozmiar do kształtu obciążenia, a nie tylko do rozmiaru danych.
Baza danych o rozmiarze 500 GB może potrzebować większej liczby operacji we/wy na sekundę niż 5 TB bazy danych, jeśli jest ona wysoce transakcyjna i wrażliwa na opóźnienia. Rozmiar ma znaczenie, ale zachowanie obciążenia ma większe znaczenie.
Weryfikuj zasoby obliczeniowe i pamięć masową razem.
Nie wybieraj magazynu tylko na podstawie limitów dysków. Upewnij się, że wybrane SKU obliczeń może obsługiwać wymagane IOPS i przepustowość.
Traktuj granicę buforowania SSD o pojemności 4 TB w warstwie Premium jako kamień milowy projektu.
Wdrożenia SSD Premium poniżej 4 TB mogą korzystać z buforowania hosta. Przy 4096 GB i nowszych buforowanie hostów nie jest obsługiwane. Jeśli wzrost przekroczy ten próg, zaplanuj przyszły model wydajności na wczesnym etapie.
Rozważ użycie dysków SSD w warstwie Premium w wersji 2 w celu elastycznego dostrajania wydajności.
SSD w warstwie Premium w wersji 2 umożliwia bardziej szczegółową kontrolę nad pojemnością, IOPS i przepływnością. Może to być odpowiednie rozwiązanie, gdy wymagania dotyczące wydajności nie są ściśle powiązane z określonymi rozmiarami dysków.
Używaj trybu burstowania do obsługi nagłych wzrostów, a nie stałego zapotrzebowania.
Wzrost może pomóc w krótkotrwałych skokach, ale częste lub trwałe pęknięcie zwykle oznacza, że konfiguracja linii bazowej powinna zostać ponownie zwrócona.
Dopasuj pokolenie do ambicji.
W przypadku celów wysokiej wydajności nowsze generacje obliczeniowe, takie jak seria v6, mogą uwidaczniać wyższe zagregowane limity magazynu zdalnego niż wcześniejsze generacje ogólnego przeznaczenia. Jeśli celem jest architektura klasy 400 000 IOPS, wybierz odpowiednio generację obliczeniową.
Mierzenie przed zmianami i po nim.
Skalowanie jest łatwiejsze w chmurze, ale pomiar sprawia, że skalowanie jest skuteczne. Przechwyć metryki punktu odniesienia, szczytu i po zmianie, dzięki czemu decyzje dotyczące wydajności są oparte na dowodach.

Praktyczny test wydajnościowy: porównanie konfiguracji pamięci pod obciążeniem.

Zasady opisane w tym artykule nie są teoretyczne. Aby zademonstrować sposób interakcji obliczeń, magazynu i obciążenia w praktyce, w tej sekcji podsumowano pgbench testy porównawcze, które porównują konfiguracje magazynu i warstwy obliczeniowe w kontrolowanych, mierzonych warunkach.

Konfiguracja i metodologia testów porównawczych

Testy porównawcze używają pgbench standardowego narzędzia do testów porównawczych PostgreSQL, aby symulować obciążenie transakcyjne w pięciu różnych konfiguracjach pamięci i obliczeń. Test rozpoczyna się od 500 połączeń współbieżnych i zwiększa do 750 równoczesnych połączeń po początkowym okresie, utrzymując to podwyższone obciążenie połączenia dla pozostałej części okna testowego. Ten wzorzec ramp-up symuluje, jak wiele rzeczywistych aplikacji zwiększa obciążenie wraz ze wzrostem ruchu, oraz mierzy, jak baza danych reaguje zarówno na początkowy wzrost, jak i utrzymujące się wysokie współbieżności.

Wszystkie testy porównawcze są uruchamiane na serwerze elastycznym Azure Database for PostgreSQL w tym samym regionie w tej samej strefie dostępności przy użyciu tej samej testowej bazy danych i profilu obciążenia. Izolując magazyn i obliczenia jako zmienne, upewnij się, że różnice wydajności odzwierciedlają rzeczywiste możliwości platformy, a nie różnice w zakresie sieci, aplikacji lub obciążenia.

Szczegóły konfiguracji

Przetestuj pięć różnych konfiguracji, różniąc się zarówno warstwą magazynowania, jak i rozmiarem obliczeniowym, aby zilustrować kluczowe pojęcia dotyczące planowania.

Konfiguracja	Jednostka SKU obliczeniowa	vCores	Memory	Maksymalna liczba operacji IOPS obliczeniowych	Typ magazynu	Capacity	liczba operacji we/wy na sekundę	Produktywność
Konfiguracja 1	Standard_D16ds_v5	16	64 GB	25 600 (40 000 wybuch)	SSD Premium (P50)	4095 GB	7,500	250 MB/s
Konfiguracja 2	Standard_D16ds_v5	16	64 GB	25 600 (40 000 wybuch)	SSD Premium (P50)	4096 GB	7,500	250 MB/s
Konfiguracja 3	Standard_D16ds_v5	16	64 GB	25 600 (40 000 wybuch)	Premium SSD (P80)	32 TB	20,000	900 MB/s
Konfiguracja 4	Standard_D16ds_v5	16	64 GB	25 600 (40 000 wybuch)	Premium SSD wersja 2	4095 GB	40,000	1200 MB/s
Konfiguracja 5	Standard_D32ds_v5	32	128 GB	51 200	Premium SSD wersja 2	4095 GB	60,000	1200 MB/s

Kluczowe obserwacje projektu konfiguracji:

Konfiguracja 1 a konfiguracja 2: Te konfiguracje różnią się tylko rozmiarem magazynu, 4095 GB w porównaniu z 4096 GB. To porównanie sprawdza granicę buforowania hosta dla dysków Premium SSD v1.
Konfiguracja 2 a Konfiguracja 3: Obie konfiguracje używają dysków SSD w wersji 1, ale Konfiguracja 3 skaluje się do pojemności 32 TB, aby zwiększyć liczbę operacji we/wy na sekundę oraz przepustowość.
Konfiguracja 3 a konfiguracja 4: Obie konfiguracje korzystają z tych samych zasobów obliczeniowych, ale konfiguracja 4 demonstruje elastyczne IOPS i przepustowość w wersji Premium SSD v2, niezależnie od pojemności.
Konfiguracja 4 a Konfiguracja 5: Konfiguracja 5 podwaja SKU obliczeniowego, aby zademonstrować, w jaki sposób zasoby obliczeniowe wyższej klasy odblokowują większą wydajność pamięci masowej.

Wyniki wydajności

Konfiguracja 1: 4,095-GB Premium SSD v1 z buforowaniem hosta

Konfiguracja 1 korzysta z dysku Premium SSD v1 o rozmiarze 4095 GB, który korzysta z buforowania na hoście na Premium SSD v1. Podczas obciążenia ta konfiguracja utrzymała stabilność.

Maksymalna liczba operacji we/wy na sekundę: 24 773, ograniczona do 7500 aprowizowanych operacji we/wy na sekundę na dysku SSD w warstwie Premium w wersji 1, przy czym buforowanie zwiększa efektywną wydajność.
Maksymalna liczba operacji we/wy odczytu: 21 330, dzięki korzystaniu z pamięci podręcznej hosta w operacjach z dużym obciążeniem odczytu.
Maksymalna liczba IOPS zapisu: 7610.

Buforowanie hosta zapewnia wzmocnienie odczytu, dzięki czemu efektywne IOPS chwilowo przekracza 7500 przydzielonych limitów IOPS dysku i osiąga limity pojemności pamięci obliczeniowej.

Konfiguracja 2: 4096-GB Premium SSD v1 bez buforowania przez hosta

Konfiguracja 2 używa rozmiaru Premium SSD v1 4096 GB, przekraczając granicę pamięci podręcznej i tracąc zalety pamięci podręcznej hosta. Wpływ jest widoczny:

Maksymalna liczba operacji we/wy na sekundę: Niższa efektywna liczba operacji we/wy na sekundę w porównaniu z konfiguracją 1 ze względu na utratę buforowania.
Maksymalna liczba IOPS odczytu: Znacznie zmniejszona przy braku pamięci podręcznej hosta.
Maksymalna liczba operacji we/wy zapisu na sekundę: 7610 bez zmian.

Ta konfiguracja pokazuje praktyczne znaczenie granicy buforowania 4 TB. Przejście z 4095 GB do 4096 GB zmienia profil wydajności, usuwając buforowane odczyty. W przypadku rosnących baz danych, które zbliżają się do tego progu, zaplanuj z wyprzedzeniem.

Konfiguracja 3: 32-TB Premium SSD v1 z wyższymi IOPS

Konfiguracja 3 rozwiązuje problem górnych limitów IOPS i przepustowości dysków Premium SSD wersja 1 poprzez skalowanie do pojemności 32 TB. Tej konfiguracji osiągnięto:

Maks. IOPS: 20 000.
Maksymalna liczba operacji we/wy odczytu na sekundę: Około 12 000.
Maksymalna liczba operacji we/wy zapisu na sekundę: Około 5000.

Zwiększenie podstawowej pojemności magazynu SSD Premium w wersji 1 zwiększa IOPS i przepustowość. Nadal możesz osiągnąć górne limity zakresu magazynu obliczeniowego dla intensywnych obciążeń.

Konfiguracja 4: Ssd w warstwie Premium w wersji 2 z 40 000 operacji we/wy na sekundę

Konfiguracja 4 przedstawia elastyczną konfigurację wydajności dysków SSD Premium w wersji 2, udostępnianie 40 000 IOPS i 1200 MB/s przepustowości na 4095 GB pojemności.

Maksymalna liczba operacji we/wy na sekundę: Wyższe efektywne wykorzystanie dzięki możliwościom dysków SSD Premium v2, zarówno w zakresie opóźnień, jak i przepustowości.
Maksymalna liczba operacji we/wy odczytu na sekundę: Zwiększona wydajność w porównaniu z konfiguracjami Premium SSD v1.
Maksymalna liczba operacji we/wy zapisu na sekundę: Wyższa trwała wydajność zapisu.

Premiowe SSD v2 umożliwia aprowizację dużej liczby operacji we/wy na sekundę bez potrzeby posiadania dużej pojemności pamięci masowej, co czyni go wydajnym w przypadku obciążeń wymagających dużej liczby transakcji.

Konfiguracja 5: Premium SSD v2 z 60 000 IOPS na D32ds_v5 jednostce obliczeniowej

Konfiguracja 5 skaluje zarówno wydajność magazynowania przy 60 000 operacjach we/wy na sekundę, jak i zasoby obliczeniowe w ramach Standard_D32ds_v5 z 32 rdzeniami wirtualnymi. Ta konfiguracja demonstruje kompleksową zasadę wyrównania:

Maksymalna liczba operacji we/wy na sekundę: Znacznie wyższa niż we wszystkich wcześniejszych konfiguracjach.
Maksymalna liczba operacji we/wy odczytu na sekundę: Silna poprawa z dodatkową rezerwą obliczeniową.
Maksymalna liczba operacji we/wy zapisu na sekundę: Utrzymująca się większa wydajność zapisu.

Dzięki dopasowaniu zarówno zasobów obliczeniowych, jak i magazynu do wyższych warstw wydajności, ta konfiguracja zapewnia najlepszą przepływność i najniższe ciśnienie procesora CPU. Wyższy limit pojemności D32ds_v5 pozwala na pełniejsze wykorzystanie dysku SSD Premium v2 o 60 000 IOPS.

Wnioski z testów porównawczych

Te pięć konfiguracji ilustruje kluczowe zasady z tego artykułu:

Granica buforowania o pojemności 4 TB ma znaczenie.
Config 1 vs. Config 2 pokazuje, że buforowanie hostów zapewnia mierzalne zwiększenie wydajności odczytu, gdy pojemność jest poniżej 4 TB, a przekroczenie 4,096 GB eliminuje tę korzyść.
Pojemność nie jest wydajnością.
Konfiguracja 3 przydzieliła 32 TB, ale nie dostarczyła najwyższego IOPS. Sama pojemność magazynu nie określa przepływności transakcji.
Premium SSD w wersji 2 zapewnia elastyczną regulację wydajności.
Konfiguracja czterech wykazała wysoką liczbę operacji we/wy na sekundę w przypadku skromnej pojemności, co potwierdza model rozdzielony umożliwiony przez dysk Premium SSD v2.
Obliczenia i pamięć masowa muszą być wyrównane.
Konfiguracja 5 pokazuje, że maksymalizacja wydajności pamięci wymaga wystarczającego zapasu mocy obliczeniowej. Wyższy limit magazynowania D32ds_v5 był niezbędny do bardziej pełnego użycia aprowizacji 60 000 operacji we/wy na sekundę.

Wyniki testu porównawczego weryfikują podstawową zasadę: maksymalna wydajność jest kompleksową właściwością. Żadna pojedyncza warstwa, taka jak magazyn, obliczenia lub sieć, nie określa wyniku. Powodzenie wymaga zamierzonego wyrównania we wszystkich warstwach, zmierzonej walidacji i ciągłej obserwacji w miarę rozwoju obciążeń.

Podsumowanie

Azure Postgres zapewnia zaawansowaną i elastyczną platformę do tworzenia nowoczesnych, hostowanych w chmurze rozwiązań baz danych. Inżynieria w ramach Azure Compute, przechowywania, sieci, wysokiej dostępności, replikacji, zabezpieczeń i obserwowalności umożliwia korzystanie z najbardziej wydajnych i odpornych architektur Postgres.

Maksymalna wydajność nie jest przypadkowa.

Maksymalna wydajność operacyjna wymaga zrozumienia aplikacji, klientów, obciążenia, profilu wzrostu danych, kombinacji odczytu/zapisu oraz cykli biznesowych, które kształtuje zapotrzebowanie. Wymaga również dostosowania zarówno wyborów obliczeniowych, jak i wyborów pamięci masowej, dzięki czemu cele dotyczące liczby operacji we/wy na sekundę, przepływności i opóźnienia są osiągane kompleksowo.

Dysk SSD Premium v1 może zapewnić mocną, przewidywalną wydajność, zwłaszcza gdy buforowanie na poziomie hosta ma zastosowanie do danych poniżej granicy 4 TB. Premium SSD w wersji 2 oferuje bardziej elastyczną konfigurację wydajności dzięki rozdzieleniu pojemności, IOPS i przepustowości. Dysk Ultra Disk reprezentuje najwyższą klasę wydajności dysków zarządzanych w Azure, podczas gdy nowsze generacje zasobów obliczeniowych zapewniają znacznie wyższe zagregowane limity zdalnego magazynowania dla architektur wysokiej klasy.

Najlepsze wdrożenia PostgreSQL na platformie Azure łączą możliwości platformy z celowym planowaniem, ciągłym monitorowaniem i wyraźnym zarządzaniem operacyjnym. Dzięki odpowiednim wymaganiom i odpowiedniej architekturze zespoły mogą dostarczać światowej klasy środowiska Postgres, które zapewniają szczytową wydajność.

Opinia

Czy ta strona była pomocna?

Last updated on 2026-05-08