Objaśnienie opcji wdrażania
Usługa Azure SQL Database, platforma jako usługa (PaaS), oferuje wysoką skalowalność i minimalną konserwację, dzięki czemu jest doskonałym rozwiązaniem dla konkretnych obciążeń. Jest ona odpowiednia dla nowego tworzenia aplikacji, zapewniając deweloperom znaczną elastyczność tworzenia nowych usług i oferując szczegółowe opcje wdrażania na dużą skalę. To rozwiązanie o niskiej konserwacji jest idealne dla różnych obciążeń, zapewniając wydajne i efektywne tworzenie aplikacji.
Omówienie modeli wdrażania
Podczas wdrażania usługi Azure SQL Database istnieją dwa podstawowe modele wdrażania: pojedyncza baza danych i elastyczne pule. W modelu elastycznych pul zasoby są współużytkowane przez wiele baz danych w tej samej puli, natomiast w modelu pojedynczej bazy danych zasoby są zarządzane niezależnie dla każdej bazy danych.
Podobnie jak w przypadku maszyn wirtualnych, usługę SQL Database można wdrożyć przy użyciu różnych metod, w tym programu PowerShell, interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal.
Pojedyncza baza danych
Model wdrażania pojedynczej bazy danych to najprostszy sposób korzystania z usługi Azure SQL Database. W tym modelu każda baza danych jest zarządzana indywidualnie pod względem skali i rozmiaru danych. Każda baza danych ma własne dedykowane zasoby, nawet jeśli na tym samym serwerze logicznym wdrożono wiele baz danych.
Wykorzystanie zasobów każdej bazy danych można monitorować za pośrednictwem witryny Azure Portal. Ta funkcja umożliwia łatwe śledzenie i ocenę wydajności baz danych.
Pule elastyczne
Pule elastyczne umożliwiają przydzielanie zasobów magazynu i zasobów obliczeniowych do grupy baz danych, upraszczając zarządzanie w porównaniu z obsługą poszczególnych baz danych osobno. Są one łatwiejsze do skalowania niż pojedyncze bazy danych, ponieważ zmiany w elastycznej puli automatycznie dostosowują zasoby dla wszystkich uwzględnionych baz danych.
Ten model jest opłacalny dla oprogramowania jako aplikacji usług, ponieważ zasoby są współużytkowane przez wszystkie bazy danych. Zasoby można skonfigurować przy użyciu modelu zakupów opartego na jednostkach DTU lub opartego na rdzeniach wirtualnych.
Ważne jest, aby stale monitorować zasoby w celu identyfikowania skoków wydajności, które mogą mieć wpływ na inne bazy danych w puli. Regularne ponowne sprawdzanie strategii alokacji zapewnia wystarczającą ilość zasobów dla wszystkich baz danych.
Elastyczne pule są idealne w przypadku architektur wielodostępnych o niskim średnim wykorzystaniu, gdzie każda dzierżawa ma własną kopię bazy danych.
Omówienie modeli zakupów
Po wybraniu odpowiedniego modelu wdrażania dla usługi SQL Database następnym krokiem jest wybranie modelu zakupów, który najlepiej pasuje do wymagań dotyczących obciążenia i budżetu. Usługa Azure SQL Database oferuje dwa modele zakupów: model vCore i model DTU. Każdy model ma własne zalety, dlatego ważne jest, aby zrozumieć, który z nich najlepiej pasuje do wymagań dotyczących obciążenia i zagadnień dotyczących kosztów.
Oparty na rdzeniach wirtualnych
Jest to zalecany model zakupów, w którym zasoby obliczeniowe i magazynowe są oddzielone. Oznacza to, że można skalować zasoby magazynu i zasobów obliczeniowych niezależnie od siebie. Ta elastyczność zapewnia możliwość dostosowywania zasobów zgodnie z konkretnymi potrzebami bez wpływu na inne składniki.
W modelu zakupów opartym na rdzeniach wirtualnych koszty zależą od kilku czynników, w tym warstwy usług, konfiguracji sprzętu, liczby rdzeni wirtualnych i ilości pamięci, magazynu zarezerwowanej bazy danych i rzeczywistego magazynu kopii zapasowych.
Uwaga
Aby uzyskać szczegółowe informacje o cenach, zobacz stronę cennika usługi Azure SQL Database.
Warstwa usługi to wstępnie zdefiniowana konfiguracja, która określa wydajność, typ magazynu, wysoką dostępność, opcje odzyskiwania po awarii i dostępność niektórych funkcji bazy danych.
Model zakupów rdzeni wirtualnych oferuje trzy opcje warstwy usług:
| Warstwa usług | Możliwość |
|---|---|
| Ogólnego przeznaczenia | Ta warstwa usługi została zaprojektowana pod kątem mniej intensywnych operacji i oferuje ekonomiczne równoważenie opcji zasobów obliczeniowych i magazynowania. Obejmuje ona zarówno aprowizowane, jak i bezserwerowe warstwy obliczeniowe, zapewniając elastyczność w celu spełnienia różnych wymagań związanych z obciążeniami podczas optymalizowania budżetu. |
| Krytyczne dla działania firmy | Ta warstwa jest idealna w przypadku aplikacji wymagających małych opóźnień i magazynu o wysokiej wydajności. Obsługuje In-Memory OLTP i zawiera wbudowaną replikę dedykowaną do odczytu. Ponadto oferuje więcej pamięci na rdzeń i używa lokalnego magazynu SSD, co czyni go idealnym rozwiązaniem dla obciążeń wrażliwych na wydajność. |
| Hiperskala | Ta warstwa jest dostosowana do aplikacji z dużymi bazami danych i wymaganiami dotyczącymi wysokiej przepływności. Hiperskala wprowadza zaawansowane funkcje skalowania w poziomie, co pozwala na dodawanie węzłów obliczeniowych w miarę zwiększania rozmiaru danych. Jest ona obsługiwana wyłącznie w pojedynczych bazach danych SQL i umożliwia znaczne skalowanie zasobów magazynu i zasobów obliczeniowych poza limity warstw ogólnego przeznaczenia i Krytyczne dla działania firmy warstw usług. |
Oparty na jednostkach DTU
W modelu DTU istnieją trzy warstwy usług: Podstawowa, Standardowa i Premium. Zasoby obliczeniowe i magazynowe zależą od poziomu jednostek DTU, oferując szereg możliwości wydajności ze stałymi limitami magazynu, przechowywaniem kopii zapasowych i kosztami.
Jeśli na przykład baza danych osiągnie maksymalny limit magazynu, musisz zwiększyć pojemność jednostek DTU, nawet jeśli wykorzystanie zasobów obliczeniowych jest niskie. Ponadto operacje skalowania w usłudze Azure SQL Database mogą powodować krótkie przerwy w połączeniu na końcu procesu. Może się to zdarzyć w dwóch głównych scenariuszach:
- Inicjowanie operacji skalowania, która wymaga wewnętrznego przejścia w tryb failover.
- Dodawanie lub usuwanie baz danych z elastycznej puli.
Uwaga
Aby obsłużyć błędy połączenia, zaimplementuj odpowiednią logikę ponawiania prób w aplikacji.
Zrozumienie współdziałania między modelami wdrażania i zakupów ma kluczowe znaczenie dla optymalizacji wydajności i wydajności kosztowej. Starannie wybierając odpowiednią kombinację, możesz upewnić się, że wdrożenie usługi Azure SQL Database spełnia wymagania aplikacji, pozostając w budżecie.
Jeśli na przykład zdecydujesz się na model wdrażania pojedynczej bazy danych, możesz użyć modelu zakupów rdzeni wirtualnych, aby zapewnić elastyczność skalowania zasobów obliczeniowych i magazynowych niezależnie. Z drugiej strony, jeśli wybierzesz model wdrażania elastycznej puli, model zakupów oparty na jednostkach DTU może być bardziej ekonomiczny, ponieważ umożliwia udostępnianie zasobów między wieloma bazami danych w puli.
Wykonywanie kopii zapasowej i przywracanie
Platforma Azure zapewnia bezproblemowe możliwości tworzenia kopii zapasowych i przywracania dla usługi SQL Database. Oto kilka kluczowych funkcji:
Ciągła kopia zapasowa
Usługa Azure SQL Database zapewnia regularne kopie zapasowe, stale kopiując je do magazynu geograficznie nadmiarowego dostępnego do odczytu (RA-GRS). Pełne kopie zapasowe są wykonywane co tydzień, różnicowe kopie zapasowe co 12 do 24 godzin, a kopie zapasowe dziennika transakcji co 5 do 10 minut.
Przywracanie geograficzne
Dzięki geograficznie nadmiarowym kopiom zapasowym można domyślnie łatwo przywracać bazy danych do różnych regionów, co jest przydatne w przypadku mniej rygorystycznych scenariuszy odzyskiwania po awarii. Magazyn kopii zapasowych jest rozliczany oddzielnie, ale tworzony bez dodatkowych kosztów z maksymalnym rozmiarem wybranej warstwy danych. Czas trwania przywracania geograficznego zależy od rozmiaru bazy danych, dzienników transakcji i równoczesnych żądań przywracania.
Uwaga
Przywracanie geograficzne jest dostępne, gdy właściwość nadmiarowości magazynu kopii zapasowych jest ustawiona na geograficznie nadmiarowy magazyn kopii zapasowych.
Przywracanie do punktu w czasie (PITR)
Umożliwia skonfigurowanie określonych zasad przechowywania do punktu w czasie dla każdej bazy danych, począwszy od 1 do 35 dni (wartość domyślna to siedem dni). Bazy danych można również przywrócić do określonego punktu w czasie na tym samym serwerze przy użyciu witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia lub interfejsu API REST.
Długoterminowe przechowywanie (LTR)
Długoterminowe przechowywanie jest przydatne w scenariuszach, które wymagają ustawienia zasad przechowywania poza tym, co jest oferowane przez platformę Azure. Można ustawić zasady przechowywania przez maksymalnie 10 lat, a ta opcja jest domyślnie wyłączona.
Aby uzyskać więcej informacji na temat automatycznych kopii zapasowych, zobacz Automatyczne kopie zapasowe — Azure SQL Database i Azure SQL Managed Instance.
Włączanie automatycznego dostrajania
Automatyczne dostrajanie to zaawansowana wbudowana funkcja, która stosuje uczenie maszynowe w celu zoptymalizowania wydajności zapytań. Automatycznie identyfikuje możliwości dostrajania i implementuje je w celu zwiększenia wydajności bazy danych.
Obecnie automatyczne dostrajanie obejmuje następujące funkcje:
- Identyfikowanie kosztownych zapytań
- Wymuszanie ostatniego dobrego planu wykonania
- Dodawanie indeksów
- Usuwanie indeksów
Usługi platformy Azure używają zaawansowanych algorytmów do określania najlepszych indeksów dla wzorców zapytań. Te indeksy są początkowo testowane na kopii bazy danych przed zastosowaniem do środowiska na żywo, zapewniając minimalne zakłócenia.
Wszystkie bazy danych dziedziczą konfigurację z serwera nadrzędnego i w razie potrzeby można ją łatwo wyłączyć. Ta elastyczność umożliwia deweloperom utrzymanie kontroli przy jednoczesnym korzyść z automatycznych ulepszeń wydajności.
Korzystanie z zapytania elastycznego
Zapytanie elastyczne umożliwia uruchamianie zapytań T-SQL w wielu bazach danych w usłudze SQL Database. Ta funkcja jest przydatna w przypadku aplikacji korzystających z trzech i czterech części nazw, których nie można zmienić, i zwiększa przenośność przez ułatwienie migracji.
Zapytania elastyczne obsługują następujące scenariusze partycjonowania:
| Warstwa usługi | Możliwość |
|---|---|
| Partycjonowanie pionowe | Nazywane również zapytaniami między bazami danych. Dane są partycjonowane w pionie w wielu bazach danych z różnymi schematami. Na przykład możesz mieć jedną bazę danych dla danych klientów, a drugą dla informacji o płatnościach. Partycjonowanie pionowe umożliwia uruchamianie zapytań między bazami danych między tymi bazami danych. |
| Partycjonowanie poziome | Znany również jako fragmentowanie. Dane są partycjonowane w poziomie, aby dystrybuować wiersze w kilku skalowanych bazach danych, a wszystkie współużytkują ten sam schemat. Ta topologia obsługuje zarówno modele jednodostępne, jak i wielodostępne. |
Ta elastyczność sprawia, że elastyczne zapytania są zaawansowanym narzędziem do zarządzania danymi i wykonywania zapytań względem ich w wielu bazach danych.
Konfigurowanie zadań elastycznych
Funkcja zadań elastycznych służy jako zamiennik agenta programu SQL Server dla usługi Azure SQL Database, podobnie jak funkcja Administracja wieloma serwerami w lokalnym wystąpieniu programu SQL Server.
Za pomocą zadań elastycznych można wykonywać polecenia języka T-SQL w różnych wdrożeniach docelowych, w tym w bazach danych SQL, elastycznych pulach usługi SQL Database i bazach danych SQL w mapach fragmentów. Te zasoby bazy danych mogą obejmować różne subskrypcje i regiony platformy Azure. Możliwość wykonywania równoległego jest przydatna do automatyzowania zadań konserwacji bazy danych, zapewnienia wydajności i spójności wdrożeń.
Przenoszenie danych przy użyciu usługi SQL Data Sync
Usługa SQL Data Sync umożliwia przyrostową synchronizację danych w wielu bazach danych, niezależnie od tego, czy są one uruchomione w usłudze SQL Database, czy w lokalnym programie SQL Server. Ta funkcja jest przydatna do odciążania intensywnych obciążeń produkcyjnych do oddzielnej bazy danych na potrzeby analiz lub nieplanowanych operacji.
Usługa Data Sync działa w topologii koncentratora, gdzie jedna baza danych w grupie synchronizacji jest wyznaczona jako piasta. Grupa synchronizacji może zawierać wiele baz danych członkowskich, a synchronizacja odbywa się między bazami danych centrum i poszczególnymi elementami członkowskimi. Zmiany są śledzone przy użyciu wyzwalaczy wstawiania, aktualizowania i usuwania za pomocą tabeli historycznej utworzonej w bazie danych użytkownika.
Podczas tworzenia grupy synchronizacji należy określić bazę danych do przechowywania metadanych grupy synchronizacji. Ta baza danych metadanych może być nowa lub istniejąca, o ile znajduje się w tym samym regionie co grupa synchronizacji.
Aby uzyskać więcej informacji na temat konfigurowania usługi SQL Data Sync, zobacz Samouczek: konfigurowanie synchronizacji danych SQL między bazami danych w usłudze Azure SQL Database i programie SQL Server.