Serwery baz danych i osadzone bazy danych

Serwer bazy danych

Serwer bazy danych oznacza bazę danych, która działa jako niezależny proces serwera i przetwarza żądania aplikacji za pośrednictwem sieci. Większość znanych nam RDBMS, takich jak MySQL, PostgreSQL i Oracle DB, należy do tego modelu. Serwer bazy danych ma następujące zalety:

Zarządzanie scentralizowane: Dane są scentralizowane w jednym miejscu, co ułatwia zarządzanie spójnością, bezpieczeństwem, tworzeniem kopii zapasowych i odzyskiwaniem.
Niezależność zasobów: Przydzielanie własnego CPU, pamięci i pamięci masowej zapewnia stabilną wydajność niezależnie od stanu aplikacji.
Wysoka współbieżność i skalowalność: Optymalizowany pod kątem jednoczesnego dostępu wielu użytkowników, a skalowanie horyzontalne poprzez klasteryzację lub replikację jest stosunkowo łatwe.

Dzięki tym cechom serwer bazy danych stał się standardem infrastruktury oprogramowania przez ostatnie dziesięciolecia. Jednak ze względu na rozwój technologiczny i zmiany środowiskowe w niektórych środowiskach zaczęły ujawniać się wady serwera bazy danych, a w odpowiedzi na to ponownie zyskały na znaczeniu wbudowane bazy danych.

Nowy trend: wbudowane bazy danych

Wbudowana baza danych to silnik bazy danych, który jest włączony do aplikacji jako biblioteka i działa w tym samym procesie, bez oddzielnego procesu serwera. SQLite, LevelDB, RocksDB są typowymi przykładami wbudowanych baz danych. Poniżej przedstawiono tło, dla którego te wbudowane bazy danych stały się potężną alternatywą w najnowszym środowisku technologicznym.

Pojawienie się SSD
W przeszłości, w środowiskach systemowych opartych na HDD, wydajność dostępu losowego była znacznie niższa niż wydajność sekwencyjnego odczytu/zapisu danych. Dlatego kluczem do optymalizacji wydajności było minimalizowanie operacji I/O dysku i maksymalizowanie buforowania pamięci. Serwery baz danych pokonywały fizyczne ograniczenia HDD, zarządzając dużymi pamięciami podręcznymi i przetwarzając operacje zapisu w sposób zbiorczy.
Jednak pojawienie się SSD całkowicie zmieniło te założenia. SSD jest tysiące razy szybszy w operacjach I/O losowego niż HDD i ma znacznie krótsze opóźnienia. W rezultacie zniknęło dotychczasowe przekonanie, że "I/O dysku jest największym wąskim gardłem", a opóźnienia wynikające z dostępu do zdalnego serwera DB przez sieć zaczęły stawać się nowym wąskim gardłem.
MSA i niezależność danych
W przeszłości powszechna była struktura, w której jedna duża aplikacja monolityczna opierała się na jednej scentralizowanej bazie danych. Chociaż to podejście było proste, w miarę wzrostu skali usług utrudniało to zmianę schematu danych, a wszystkie usługi współdzieliły tę samą bazę danych, co prowadziło do nadmiernie silnego sprzężenia.
We współczesnej architekturze mikrousług kluczowa jest zasada "Database per Service" w celu rozwiązania tych problemów. Każda usługa posiada i hermetyzuje własne dedykowane miejsce przechowywania danych, co zapewnia niezależność między usługami oraz ułatwia izolację awarii i skalowanie. W tym procesie wbudowane bazy danych stają się idealnym wyborem jako magazyn danych dla poszczególnych usług. Są lekkie, szybkie i mogą być wdrażane wraz z kodem usługi, co doskonale pasuje do środowiska MSA.
W środowisku Kubernetes, na przykład, powszechnie stosuje się wzorzec sidecar, umieszczając wbudowaną bazę danych obok kontenera aplikacji w celu optymalizacji lokalnego przetwarzania danych. Skutkuje to zmniejszeniem wąskich gardeł sieciowych i minimalizacją opóźnień w dostępie do danych.
Uproszczenie środowiska operacyjnego
Serwery baz danych wymagają skomplikowanych procedur operacyjnych, takich jak instalacja, stosowanie poprawek, tworzenie kopii zapasowych, odzyskiwanie po awarii, replikacja i monitorowanie wydajności, a to wymaga dedykowanego DBA i wyspecjalizowanego personelu operacyjnego. Zwłaszcza w środowiskach o dużej skali to obciążenie zarządzania jest bardzo duże.
Wbudowane bazy danych znacznie łagodzą te problemy. Kiedy baza danych jest zintegrowana z aplikacją, testy jednostkowe, kompilacja, zarządzanie wersjami i wdrażanie odbywają się jednocześnie, eliminując potrzebę oddzielnej obsługi serwera. Ponadto, gdy aplikacja skaluje się w poziomie, wbudowana baza danych również skaluje się wraz z nią, a automatyczne zarządzanie jest możliwe dzięki kulturze DevOps i potokom CI/CD. Zwłaszcza w środowiskach startupów, małych usług i prototypowania, wbudowane bazy danych znacznie zmniejszają złożoność operacyjną i znacznie przyspieszają rozwój i wdrażanie.
Rozwój wysokowydajnych języków systemowych i ekosystemów
W przeszłości było typowe, że bazy danych i aplikacje były pisane w różnych językach. Na przykład, silniki baz danych wymagające wysokiej wydajności były głównie pisane w C, C++, a aplikacje były rozwijane w językach takich jak Java, Python, PHP. To podejście było skuteczne w optymalizacji wydajności, ale miało swoje ograniczenia, takie jak problemy ze stabilnością pamięci, złożone przetwarzanie współbieżności, opóźnienia oraz trudności w integracji i wdrażaniu bibliotek.
Jednak niedawne pojawienie się nowoczesnych języków programowania systemowego, takich jak Go i Rust, znacznie złagodziło te ograniczenia. W szczególności Go nadaje się do pisania wysokowydajnych aplikacji, a także programów niskopoziomowych, takich jak silniki baz danych, co pozwala na jednoczesne zarządzanie bazami danych i aplikacjami w ramach jednego ekosystemu językowego.
W rzeczywistości w Golang aktywnie wykorzystywane są wysokowydajne wbudowane bazy danych, takie jak BadgerDB i PebbleDB. Oznacza to, że wbudowane bazy danych stają się ważną opcją z własną konkurencyjnością, wykraczającą poza bycie jedynie lekką alternatywą dla serwerów baz danych.

Wniosek

W warunkach wymagających scentralizowanego zarządzania dużymi zbiorami danych, złożonych transakcji i wysokiej współbieżności, serwer bazy danych nadal pozostaje najpotężniejszym rozwiązaniem. Jednak w środowiskach MSA dla poszczególnych usług, urządzeń brzegowych IoT, szybkiego prototypowania i projektów, w których kluczowa jest wydajność operacyjna, wbudowana baza danych może być bardziej efektywnym i racjonalnym wyborem. Ostatecznie, ważne jest, aby wybrać optymalne narzędzie, które najlepiej odpowiada danej sytuacji i wymaganiom, a rozwój wbudowanych baz danych zapewnia nam szerszy i bardziej zróżnicowany zakres opcji.