Hybrydowa układanka…

…ale czy w obszarze baz danych również się sprawdza?

W minioną środę, odbył się videowebinar, dot. rozwiązań hybrydowych w obszarze baz danych. Jeśli nie udało Ci się go zobaczyć, nic straconego, możesz skorzystać z opcji webinaru na żądanie .

W trakcie samej prezentacji omawiane były różne scenariusze, pozwalające na częściowe wykorzystanie rozwiązań dostępnych na platformie Azure do współdziałania z klasycznie działającym rozwiązaniem baz danych wewnątrz własnej serwerowni. Jednym z tematów, który wywoła sporo pytań podczas webinaru (po samym webinarze dostałem kilka  dodatkowych maili z prośbą rozszerzenie tej informacji), była kwestia wykorzystania funkcjonalności pozwalającej na umieszczenie plików bazy danych uruchamianej na lokalnej instancji SQL Server, w ramach przestrzeni dyskowej Azure (Blob storage).

Nie chcę w tym miejscu omawiać technicznego aspektu takiej konfiguracji, która wydaje się w pełni zrozumiała i stosunkowo prosta. Większość pytań dotyczyła natomiast scenariuszy użycia takiej konfiguracji i jej zasadności, oraz wydajności. Dla krótkiego przypomnienia i ustalenia uwagi, mówimy o rozwiązaniu wskazanym na ilustracji poniżej.

FilesInAzure

Nie trudno się domyśleć, że taka konfiguracja oparta jest o połączenie internetowe pomiędzy serwerownią, a Azure i faktycznie to połączenie jest wymagane dla zachowania ciągłości pracy.

Zacznijmy więc od wydajności takiego rozwiązania i sytuacjach awaryjnych, czyli, a co jeśli nie działa połączenie internetowe. Odpowiedź jest prosta – brak dostępu do bazy danych, ze względu na niedostępność pliku danych/dziennika transakcji.

W kwestii wydajności – odpowiedź również jest dość oczywista, jednak dla pewności poniżej również udokumentowana. Rozwiązania oparte o połączenie serwerownia-azure jest uzależnione od wydajności łącza. Realizowane testy potwierdzają, że umieszczenie plików danych i dziennika transakcji w Azure przekładają się na czas wykonania zapytań. Przykładowa statystyka poniżej dla bazy w pełni lokalnej oraz bazy z plikami w ramach Azure.

Perf_1.png

Próbka dla 10 000 operacji wprowadzenia danych (Insert)

Natomiast nie trudno się również domyśleć, że głównym aspektem wydajności takiego rozwiązania jest ulokowanie zarówno pliku danych jak i dziennika transakcji w Azure. W momencie gdy plik dziennika zostanie umieszczony lokalnie, a jedynie plik danych znajduje się w Azure, statystyki operacji Insert(analogicznie to powyższego testu), wyglądają następująco:

Perf_2

Próbka dla 10 000 operacji wprowadzenia danych (Insert)

Czyli efekt uzyskany np. poprzez poniższe polecenia tworzenia bazy danych

CREATE DATABASE TestDBAzureLogLocal
ON
(NAME = file_data1
, FILENAME = ‚https://_______________.blob.core.windows.net/sqlfiles/filedata2.mdf’
, SIZE = 10MB)
LOG ON
(NAME = file_log1
,FILENAME = ‚C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA\Azure.ldf’
, SIZE = 10MB)

Także nie jest tak źle, z tą wydajnością….

W kwestii scenariuszy i odpowiedzi na pytanie kiedy warto:

  • Przenaszalność plików pomiędzy maszynami wirtualnymi/instancjami serwera – bez przenoszenia plików możemy podpiąć bazę do innej instancji serwera (scenariusz DR/HA)
  • Ograniczenie kosztu lokalnej przestrzeni dyskowej dla baz archiwalnych oraz dużych baz np. podzielonych na dane archiwalne/aktualne na poziomie tabel czy grup plików
  • Jeden z najważniejszych elementów – możliwość skorzystania z opcji snapshot backup, dostępnej tylko dla takiego modelu działania bazy danych. O tym czym jest snapshot backup można przeczytać m.in tutaj