Baza danych jako usługa PaaS ma wiele zalet – finansowych, jak i technologicznych. Zastąpienie kosztów inwestycyjnych (zakupu sprzętu i oprogramowania) kosztami operacyjnymi (opłatami za korzystanie z usługi) zwiększa elastyczność zarządzania środkami.

Rozwiązanie chmurowe to nie tylko niwelowanie wydatków i usprawnienie pracy działu IT, to również korzyści technologiczne. Usługi PaaS są odporne na awarie, gwarantują ciągłą dostępność, wydajność i skalowalność, są też – w zestawieniu z fizycznymi serwerami baz danych – łatwiejsze do zabezpieczenia. Żeby jednak w pełni wykorzystać te zalety, musimy wybrać właściwą usługę bazy danych i odpowiednio ją skonfigurować.

> Relacyjne bazy danych

Azure oferuje kilkanaście rozwiązań, począwszy od otwartych systemów, takich jak MySQL czy PostgreSQL, aż do SQL Server firmy Microsoft. Ten ostatni oferowany jest w różnych modelach – zaczynając od maszyny wirtualnej z zainstalowanym serwerem SQL (usługa typu IaaS), poprzez usługę Azure SQL Managed Instance (model typu PaaS, w ramach którego otrzymamy serwer baz danych), na usłudze SQL Data­base (PaaS z bazą danych) kończąc. Wybierając jedną opcję, powinniśmy najpierw rozważyć usługi typu PaaS. Nie tylko są one tańsze, ale również lepiej dostosowane do chmury, co oznacza że zapewnienie ich ciągłej dostępności, skalowalności, wydajności i bezpieczeństwa jest łatwiejsze. Maszynę wirtualną z zainstalowanym serwerem SQL wybieramy, gdy planujemy migrację istniejącego systemu bazodanowego, przy czym zakres tej migracji ogranicza się do przeniesienia istniejącego rozwiązania do chmury, a samo rozwiązanie nie jest kompatybilne z usługą Azure SQL Managed Instance. SQL Database sprawdza się podczas tworzenia nowego rozwiązania lub przy dostosowaniu już istniejącego do wymagań usługi. W modelu klasycznym płacimy za jednostki wydajności DTU (Database Transaction Unit). Ponieważ są one logicznym połączeniem czasu procesora, pamięci i operacji IO potrzebnych do wykonania pojedynczej operacji, w tym modelu zasoby bazy zawsze są zrównoważone, tj. wraz ze wzrostem mocy obliczeniowej rośnie ilość pamięci i wydajność dysków. Oferowane są wersje: podstawowa, standardowa oraz premium baz danych. Opcje zakupu oparte na rdzeniach wirtualnych pozwalają wybrać model rozliczeniowy warstwy obliczeniowej. Płaci się wówczas za zarezerwowane zasoby (nawet jeżeli nie korzystamy z nich w pełni) albo za rzeczywiste obciążenie procesorów. Do wyboru mamy bazy ogólnego przeznaczenia, krytyczne dla działania firmy i superskalarne. Jednym z wariantów jest Azure SQL Database Hyperscale, który został udostępniony użytkownikom do zastosowań produkcyjnych w maju 2019 roku. Cechą charakterystyczną baz jest ich nieograniczona skalowalność. W czasie powstawania artykułu maksymalny rozmiar początkowy bazy danych wynosił 100 TB, ale Azure SQL Database Hyperscale pozwala przydzielać bazom nieograniczone zasoby i nie ogranicza ich aktualnej wielkości.

> Jak przebiega instalacja?

Tworzoną bazę danych musimy podłączyć pod logiczny serwer SQL. Taki serwer można utworzyć na potrzeby konkretnej bazy albo użyć już istniejącego. Ten sam logiczny serwer SQL może być używany do łączenia się z różnymi bazami danych, czyli możemy podłączyć do niego bazę SQL Database warstwy podstawowej, bazę SQL ogólnego przeznaczenia, hurtownię Synapse Analytics i bazę w wersji superskalarnej. Przeprowadzając konfigurację, należy wybrać model rozliczeniowy oparty na rdzeniach wirtualnych, a następnie zaznaczyć opcję Hiperskala (rys. 1). Jest to też moment, by zdecydować się na maszyny piątej generacji, jeżeli nasza baza wymaga zrównoważonych zasobów pamięci i obliczeniowych (maszyny czwartej generacji, choć nadal dostępne, są mniej wydajne i żeby uzyskać tę samą efektywność bazy, będziemy musieli użyć większej liczby wirtualnych rdzeni, a więc zapłacimy wyższy rachunek). Jeżeli nasza baza wymaga więcej mocy obliczeniowej niż pamięci, wybierzmy maszyny serii FSv2, a jeżeli potrzeba więcej pamięci niż mocy obliczeniowej – maszyny serii M.

Dysponując licencją na serwer SQL z pakietem Software Assurance, możemy użyć jej na potrzeby tworzonej bazy danych. Obniży to koszt podstawowej repliki bazy danych o 35%. Koszt bazy superskalarnej w przeliczeniu na rdzeń wirtualny jest o kilkanaście procent wyższy niż bazy ogólnego przeznaczenia i ponad dwukrotnie tańszy niż koszt bazy krytycznej dla działania firmy. Następnie określamy liczbę wirtualnych rdzeni i replik pomocniczych. Repliki pomocnicze to kopie bazy danych dostępne tylko do odczytu. W maju 2020 roku ich maksymalna liczba była ograniczona do 4. Konfiguracja każdej repliki pomocniczej jest taka sama jak konfiguracja repliki podstawowej. Po ukończeniu wdrożenia będziemy mogli połączyć się z superskalarną bazą danych dokładnie w ten sam sposób, w jaki łączymy się z każdą inną bazą SQL. Nie tylko praca z bazą wygląda tak samo – możemy też skorzystać ze znanych z innych wersji baz narzędzi automatycznej optymalizacji wydajności, szyfrowania baz danych czy też klasyfikacji i dynamicznego maskowania danych. Warto pamiętać o opcji zamiany typu istniejącej bazy danych SQL na Azure SQL Database Hyperscale. Zmiana taka możliwa jest z poziomu portalu, przy użyciu SSMS lub Azure Studio lub programowo (rys. 2):

ALTER DATABASE [AdwentureWorksLT]
MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');

[...]