Database server i embedded database: porównanie architektury oraz charakterystyk I/O

Serwer bazy danych

Serwer bazy danych to baza danych działająca jako niezależny proces serwerowy, który obsługuje żądania aplikacji przesyłane przez sieć. Większość znanych nam systemów RDBMS, takich jak MySQL, PostgreSQL czy Oracle DB, należy do tego modelu. Serwer bazy danych charakteryzuje się następującymi zaletami.

Scentralizowane zarządzanie: Dane są zintegrowane i zarządzane w jednym miejscu, co ułatwia zapewnienie spójności, bezpieczeństwa oraz tworzenie kopii zapasowych i odzyskiwanie danych.
Niezależność zasobów: Serwer otrzymuje własne zasoby CPU, pamięci i pamięci masowej, co gwarantuje stabilną wydajność niezależnie od stanu aplikacji.
Wysoka współbieżność i skalowalność: Serwer jest zoptymalizowany pod kątem jednoczesnego dostępu wielu użytkowników, a skalowanie poziome poprzez klastrowanie lub replikację jest stosunkowo proste.

Dzięki tym cechom serwer bazy danych przez kilka ostatnich dziesięcioleci ugruntował swoją pozycję standardu w infrastrukturze oprogramowania. Jednak wraz z rozwojem technologii i zmianami środowiska wady serwera bazy danych zaczęły ujawniać się w niektórych kontekstach, a jako alternatywa ponownie zyskały uwagę bazy danych osadzone.

Nowy trend: osadzone bazy danych

Osadzona baza danych to silnik bazy danych, który nie wymaga oddzielnego procesu serwerowego, lecz jest dołączany do aplikacji w postaci biblioteki i działa w obrębie tego samego procesu. Typowymi przykładami osadzonych baz danych są SQLite, LevelDB i RocksDB. Powody, dla których osadzone bazy danych stały się silną alternatywą w nowoczesnym środowisku technologicznym, są następujące.

Pojawienie się SSD
W dawnych systemach opartych na dyskach HDD wydajność losowego dostępu była znacznie niższa niż wydajność sekwencyjnego odczytu i zapisu danych. Dlatego kluczem do optymalizacji wydajności było minimalizowanie operacji I/O na dysku oraz maksymalne wykorzystanie buforowania w pamięci. Serwery baz danych dostosowywały się do tego, utrzymując rozległe pamięci podręczne i grupując operacje zapisu, co pozwalało przezwyciężać fizyczne ograniczenia HDD.
Pojawienie się SSD całkowicie zmieniło jednak te założenia. SSD charakteryzują się wydajnością losowego dostępu I/O wielokrotnie wyższą niż HDD, a czas opóźnienia jest znacząco krótszy. W rezultacie dawne przekonanie, że „operacje I/O na dysku stanowią największe wąskie gardło”, straciło aktualność, a opóźnienia wynikające z dostępu do zdalnego serwera bazy danych przez sieć zaczęły być postrzegane jako nowe wąskie gardło.
MSA a niezależność danych
Dawniej powszechną strukturą była sytuacja, w której jedna duża aplikacja monolityczna zależała od jednej scentralizowanej bazy danych. Rozwiązanie to było proste, lecz wraz ze wzrostem skali usług zmiana schematu danych stawała się trudna, a wszystkie usługi, współdzieląc tę samą bazę, były nadmiernie silnie powiązane.
We współczesnych architekturach mikroserwisowych w celu rozwiązania tych problemów przywiązuje się dużą wagę do zasady „Database per Service”. Gdy każda usługa posiada i hermetyzuje własne, dedykowane repozytorium danych, zapewniona jest niezależność między usługami, a izolacja awarii i skalowanie stają się prostsze. W tym kontekście osadzona baza danych staje się idealnym wyborem jako repozytorium danych na poziomie usługi. Jest lekka i szybka, a ponieważ może być wdrażana razem z kodem usługi, bardzo dobrze pasuje do środowiska MSA.
Przykładowo, w środowisku Kubernetes powszechnie stosuje się wzorzec sidecar, w którym osadzona baza danych umieszczana jest obok kontenera aplikacji w celu optymalizacji lokalnego przetwarzania danych. Pozwala to ograniczyć opóźnienia sieciowe i zminimalizować czas dostępu do danych.
Uproszczenie środowiska operacyjnego
Serwer bazy danych wymaga złożonych procedur operacyjnych, takich jak instalacja, aktualizacje, tworzenie kopii zapasowych, odzyskiwanie po awarii, replikacja i monitorowanie wydajności, a do ich realizacji niezbędni są dedykowani administratorzy DBA oraz wykwalifikowany personel operacyjny. Szczególnie w środowiskach na dużą skalę obciążenie związane z zarządzaniem jest bardzo duże.
Osadzone bazy danych znacząco łagodzą te problemy. Gdy baza danych zostaje zintegrowana wewnątrz aplikacji, testy jednostkowe, budowanie, kontrola wersji i wdrażanie odbywają się razem, dzięki czemu nie jest potrzebne oddzielne zarządzanie serwerem. Ponadto wraz ze skalowaniem poziomym aplikacji skaluje się także osadzona baza danych, a dzięki kulturze DevOps i potokom CI/CD możliwe jest zautomatyzowane zarządzanie. Szczególnie w startupach, małych usługach i środowiskach tworzenia prototypów osadzone bazy danych znacznie obniżają złożoność operacyjną oraz istotnie przyspieszają rozwój i wdrażanie.
Języki systemowe o wysokiej wydajności i rozwój ekosystemu
Dawniej powszechne było tworzenie bazy danych i aplikacji w różnych językach programowania. Na przykład silniki baz danych wymagających wysokiej wydajności były zazwyczaj pisane w językach C i C++, natomiast aplikacje rozwijano w językach takich jak Java, Python czy PHP. Takie podejście było skuteczne z punktu widzenia optymalizacji wydajności, jednak wiązało się z ograniczeniami, do których należały problemy z bezpieczeństwem pamięci, złożona obsługa współbieżności, opóźnienia oraz trudności w integracji bibliotek i wdrażaniu.
Jednak wraz z pojawieniem się nowoczesnych języków programowania systemowego, takich jak Go i Rust, ograniczenia te znacznie złagodniały. Szczególnie Go, będący odpowiednim narzędziem zarówno do tworzenia wydajnych aplikacji, jak i programów niskopoziomowych, takich jak silniki baz danych, umożliwił pracę nad bazą danych i aplikacją w obrębie jednego ekosystemu językowego.
Rzeczywiście, w języku Golang powszechnie wykorzystywane są wydajne osadzone bazy danych, takie jak BadgerDB oraz PebbleDB. Oznacza to, że osadzone bazy danych nie są już jedynie lekką alternatywą dla serwera bazy danych, lecz stały się istotnym wyborem o własnej, konkurencyjnej pozycji.

Podsumowanie

W warunkach wymagających scentralizowanego zarządzania dużymi ilościami danych, złożonych transakcji i wysokiej współbieżności serwer bazy danych nadal stanowi najpotężniejsze rozwiązanie. Jednak w przypadku poszczególnych usług w środowisku MSA, urządzeń brzegowych IoT, szybkiego prototypowania oraz projektów, w których kluczowa jest efektywność operacyjna, osadzone bazy danych mogą okazać się wydajniejszym i bardziej racjonalnym wyborem. Ostatecznie istotne jest dobranie optymalnego narzędzia najlepiej odpowiadającego danej sytuacji i wymaganiom, a rozwój osadzonych baz danych zapewnia nam szersze i bardziej zróżnicowane możliwości wyboru.