Ekosystem bazy danych. 5 architektur.

Architektura bazy danych powinna wspierać zadania realizowane przez przedsiębiorstwo. Przedstawię ci 5 różnych rodzajów architektury. Ostatni daje wiele możliwości.

Publikacja w formie wideo
Architektura klient-serwer

Użyteczność bazy danych gdy może z niej korzystać tylko jedna osoba i tylko w miejscu przechowywania danych jest ograniczona. Dlatego wiodące motory baz danych działaja w architekturze klient-serwer. Umożliwia ona zdalne podłączenie i współbieżną pracę z bazą danych wielu użytkowników.

Instancja bazy danych jest serwerem. Na żądanie klienta udostępnia dane z bazy danych. Klientem jest oprogramowanie potrafiące komunikować się z instancją bazy danych oraz umożliwiające użytkownikowi manipulowanie danymi w bazie danych.

Architektura klient-serwer

Klient z serwerem zazwyczaj działają na różnych komputerach i komunikują się poprzez sieć TCP/IP. Na przykład lokalną sieć przedsiębiorstwa czy internet. Klientów zazwyczaj jest wiele. Mogą pracować na najróżniejszych urządzeniach i systemach operacyjnych. Aby instancja bazy danych wydajnie serwowała im dane zazwyczaj instalowana jest na dedykowanym komputerze o odpowiednio dużej mocy obliczeniowej.

Obecnie coraz rzadziej można spotkać aplikacje którymi użytkownik bezpośrednio komunikuje się z instancją bazy danych. Zazwyczaj używana jest warstwa pośrednia nazywana serwerem aplikacji. Czyli baza danych przechowuje dane, serwer aplikacji je przetwarza, a aplikacja kliencka pozwala na ich wprowadzanie i wyświetlanie. Przykładowe serwery aplikacji to JBoss i Apache Tomcat.

Architektura klient-serwer z serwerem aplikacji

W internetach można znaleźć dyskusje jaką ilość przetwarzania danych zostawić w bazie danych, a jaką wynieść do serwera aplikacji. Wg mnie wynoszenie tzw. logiki biznesowej z bazy danych jest konsekwencją nieoptymalnego projektu bazy danych oraz nieumiejętnego korzystania z bazy danych. Skomentuj jak uważasz Ty.

Scentralizowana baza danych

Instancja bazy danych posadowiona na jednym komputerze z bazą danych umieszczoną na jednym zestawie dysków to przykład scentralizowanej bazy danych. Jest to najprostsza, najtańsza i najczęściej spotykana architektura. Gdy wydajność takiego zestawu przestaje wystarczać kupowany jest nowy komputer z większą liczbą szybszych procesorów oraz większą ilością pamięci RAM. A baza danych przenoszona jest na szybsze dyski. Wzrost mocy obliczeniowej i wydajności dysków pojedynczego komputera jest skalowaniem pionowym.

Rozproszona baza danych

Z różnych powodów, na przykład wydajność, bezpieczeństwo czy dostępność, scentralizowana baza danych może być niewystarczająca. Wtedy warto rozważyć rozproszoną bazę danych. W architekturze rozproszonej dane jednej bazy danych rozdystrybuowane są pomiędzy wiele komputerów i wiele zestawów dysków. Każdy z tych kompletów nazywany jest węzłem. Z angielska node. Węzły mogą być rozproszone geograficznie. Każdy pracuje w tym samym momencie na własnym zestawie danych.

Jeden z węzłów jest węzłem systemowym. Zawiera informacje o architekturze całej rozproszonej bazy danych oraz zarządza rozdziałem pracy pomiędzy węzły robocze. Z punktu widzenia użytkownika podział mocy obliczeniowej oraz danych pomiędzy węzły jest przezroczysty. Aplikacja kliencka użytkownika komunikuje się z węzłem systemowym, który rozdziela zadania na odpowiednie węzły robocze bazy danych. Tylko węzeł systemowy wie jakie dane posiadają pozostałe węzły.

Rozproszona baza danych

Dane bazy danych dzielone są wg potrzeb przedsiębiorstwa. Można wyróżnić 2 podziały. Podział poziomy oznacza, że na każdym węźle znajdują się wszystkie obiekty bazy danych, ale zawierają tylko wybrany podzbiór wszystkich danych. Podział pionowy, że poszczególne węzły zawierają jedynie podzbiór obiektów.

Na przykład baza danych rozproszona pomiędzy 2 węzły. Jeden w Warszawie, a drugi w Bydgoszczy. Podział poziomy danych oznaczałby, że Warszawa zawiera dane dotyczące Polski Wschodniej, a Bydgoszcz Polski Zachodniej. Podział pionowy mógłby oznaczać, że Bydgoszcz zawiera dane o sprzedaży, a Warszawa o płacach.

Rozproszona baza danych. Sharding - podział danych pomiędzy węzły.

Operacje dotyczące całej bazy danych rozdzielane są pomiędzy węzły. Dzięki temu wykonują się równolegle korzystając z mocy obliczeniowej wszystkich węzłów oraz wydajności dysków we wszystkich lokalizacjach. Czyli mając dane rozdzielone poziomo pomiędzy Bydgoszcz i Warszawę zapytanie dotyczące całego przedsiębiorstwa zostanie rozdzielone, przez węzeł systemowy, na 2 zapytania. Zostaną wykonane równolegle na odpowiednich węzłach roboczych, a wyniki zostaną scalone i przesłane do klienta przez węzeł systemowy.

W przypadku wzrostu zapotrzebowania na moc obliczeniową lub rozrostu przedsiębiorstwa istnieje możliwość dołożenia kolejnego węzła. Wiąże się to ze zmianą rozproszenia danych pomiędzy węzły. Na przykład do bazy danych, rozproszonej pomiędzy węzły w Bydgoszczy i Warszawie, dołożony zostaje węzeł w Berlinie. Dzieląc dane poziomo berliński węzeł będzie zawierał dane przedsiębiorstwa dotyczące Niemiec. Przy podziale pionowym węzeł w Berlinie może, na przykład, obsługiwać marketing. Dokładanie kolejnych węzłów nazywa się skalowaniem poziomym.

Rozproszona baza danych. Skalowanie poziome.

Przykładami rozproszonych baz danych są Citus, MongoDB i Apache Cassandra.

Oracle Real Applications Clusters

Oracle Real Applications Clusters jest produktem pośrednim pomiędzy scentralizowaną, a rozproszoną bazą danych. Potrafi wykorzystać moc obliczeniową wielu komputerów. Na każdym z komputerów uruchomiona jest instancja Oracle. Każda z instancji udostępnia całą i tę samą bazę danych, która składowana jest na współdzielonych przez komputery dyskach. Wszystkie instancje Oracle RAC są równoprawne i razem tworzą klaster. Nie ma podziału na instancję systemową i instancje robocze. Oracle RAC jest unikalnym produktem na rynku baz danych.

Architektura Oracle RAC

To do której instancji użytkownik podłączy się swoją aplikacją jest konfigurowalne. Może łączyć się do wskazanej lub dowolnej. Niezależnie od instancji użytkownik zawsze ma dostęp do całej bazy danych. Zapytania użytkownika nie są automatycznie rozdzielane pomiędzy instancje bazy danych. Niemniej odpowiednio napisana aplikacja kliencka może rozdzielić zadanie na wiele instancji.

Instancja bazy danych manipuluje danymi, które odczytała z bazy danych znajdującej się na dysku i umieściła w pamięci podręcznej w RAM. O składowych instancji bazy danych mówiłem w materiale o terminach bazodanowych. Oracle RAC to wiele instancji. Każda dysponuje własną pamięcią podręczną. Czyli jest jedna baza danych, ale pamięć podręczna podzielona jest na wiele komputerów. Konkretne dane – na przykład wysokość twojej wypłaty – mogą znajdować się tylko w jednej z nich. Instancje Oracle RAC komunikują się poprzez dedykowaną, bardzo szybką sieć aby ustalić, która instancja ma jakie dane i wymienić się nimi.

Interconnect w Oracle RAC

Aby poprawić wydajność czy dostępność bazy danych wystarczy dołożyć kolejny komputer z instancją Oracle RAC. Warto pamiętać, że w przypadku Oracle RAC skalowanie poziome ograniczone jest wspólną pamięcią podręczną i bazą danych klastra.

Skalowanie poziome Oracle RAC
Replikacja fizyczna

Wiodący producenci motorów baz danych dostarczają mechanizmów pozwalających na fizyczne replikowanie instancji bazy danych do innych instancji bazy danych. Fizyczne replikowanie to proces dystrybucji zmian w postaci binarnej. Czyli w postaci informacji jakie dane się zmieniły. Zmiany replikowane są z oryginalnej podstawowej bazy danych do jej identycznych kopii zapasowych. Kopie od oryginału może dzielić dowolna odległość. Dla użytkownika zapasowe bazy danych dostępne są tylko do odczytu lub w ogólne nie są dostępne.

Replikacja fizyczna zazwyczaj wykorzystywana jest do poprawy dostępności scentralizowanej bazy danych. Stosunkowo łatwo i szybko jest zamienić zapasową bazę danych w podstawową i przełączyć aplikacje. Część producentów motorów baz danych dostarcza mechanizmów pozwalających na łatwe odwrócenie kierunku replikacji. W takim przypadku zapas staje się oryginałem, a oryginał zapasem. Gdy motor bazy danych nie posiada takich mechanizmów, odwrócenie kierunku replikacji wykonują administratorzy baz danych. Co może być bardziej czasochłonne.

Replikacja fizyczna

Posiadanie fizycznej kopii instancji bazy danych na innym sprzęcie wydatnie skraca czas niedostępności bazy danych. Przełączenie użytkowników na zapas zazwyczaj jest znacznie szybsze niż naprawienie awarii oryginalnej instancji bazy danych. Trzeba też pamiętać o planowanych pracach konserwujących system operacyjny, binaria motoru bazy danych czy sprzęt na którym pracuje oprogramowanie. Jeśli prace powodują odłączenie użytkowników od podstawowej bazy danych można przełączyć ich do zapasowej. W zależności od potrzeb przedsiębiorstwa kopie oryginalnej bazy danych mogą znajdować się na innym komputerze, innych dyskach czy w innej serwerowni.

Warto pamiętać, że powielanie podstawowej bazy danych na kolejne komputery przynosi wzrost kosztów utrzymania bazy danych nie dając wzrostu wydajności. Kopia oryginalnej bazy danych jest dostępna w bardzo ograniczonym zakresie. Moc obliczeniowa komputera z kopią nie jest wykorzystywana w pełni. Niemniej odpowiednie zaprojektowanie aplikacji oraz procedur administratorów baz danych może przenieść część obciążenia na zapas.

Replikacja fizyczna bazy danych możliwa jest także na poziomie systemu dyskowego. Czyli zmiany w danych replikowane są na poziomie bloków dyskowych zamiast bloków bazodanowych. Bloki dyskowe replikowane są bez udziału instancji bazy danych.

Ja wolę gdy dane nie opuszczają bazodanowego ekosystemu. A Ty?

Replikacja logiczna

Na koniec crème de la crème architektur czyli replikacja logiczna. Pozwala na wykorzystanie mocy obliczeniowej wszystkich komputerów z instancjami bazy danych oraz wydajności wszystkich dysków na których dane są przechowywane. Mam do niej awersję bo oprócz danych replikuje też problemy związane z kiepskim kodem SQL oraz kiepską strukturą bazy danych. Niemniej rozumiem, że dzięki funkcjonalnościom, których dostarcza adresuje wiele potrzeb przedsiębiorstwa.

Do sedna: replikacja logiczna replikuje, pomiędzy bazami danych, komendy modyfikujące dane. Można wybrać co jest replikowane. Zarówno poziomo jak i pionowo. Czyli jakie dane oraz jakie obiekty. Replikacja może działać dwukierunkowo. Czyli nie musi być jasnego podziału na bazę podstawową i zapasową. Wszystkie bazy danych wszystkich instancji mogą być modyfikowane w tym samym czasie.

Replikacja logiczna

Zapytania do bazy danych wykonuje jedynie instancja do której podłączony jest klient. Rozdzielenie bardziej zasobożernych zapytań na wiele instancji jest możliwe, ale musi zrobić to aplikacja kliencka. Podobnie jak późniejsze scalenie wyników. System replikacji logicznej możesz wyobrazić sobie jako rozproszoną bazę danych bez węzła systemowego odpowiedzialnego za automatyczne rozdzielanie pracy.

Replikacja logiczna jest wbudowana w niektóre motory bazy danych. W innych jest niedostępna. Istnieją także produkty firm trzecich. Część jest tak rozbudowana, że przy okazji replikacji dokona transformacji danych.

Największą zaletą replikacji logicznej jest elastyczność. Potrafi replikować dowolny fragment danych pomiędzy dowolnymi platformami. Czyli pomiędzy dowolnymi motorami baz danych pracującymi na dowolnych systemach operacyjnych. Jedynym ograniczeniem replikacji logicznej jest Twoja wyobraźnia.

Skaluje się poziomo. Wzrost mocy obliczeniowej całego systemu można uzyskać poprzez dołożenie dowolnego komputera, powielenie stosownego wycinka danych na jego dyski oraz rekonfigurację replikacji.

Podsumowanie
  • Architektura klient-serwer wskazuje na sposób komunikowania się użytkowników z instancją bazy danych. Jest typowa niezależnie od architektury rozdzielającej moc obliczeniową instancji oraz dane bazy danych.
  • Ze względu na rozdział mocy obliczeniowej oraz podział danych można wyróżnić
    • Scentralizowane bazy danych. Moc obliczeniowa i dane znajdują się w jednej centralnej lokalizacji
    • Rozproszone bazy danych. Moc obliczeniowa i dane rozdzielone są pomiędzy niezależne węzły.
    • Oracle rac. Moc obliczeniowa jest rozdzielona pomiędzy węzły, ale dane znajdują się w jednej lokalizacji.
    • Replikacja fizyczna. Moc obliczeniowa jest scentralizowana. Zmiany w danych, w postaci binarnej, kopiowane są jedynie z lokalizacji podstawowej do lokalizacji zapasowych. Lokalizacja zapasowa może udostępnić swoja moc obliczeniową gdy replikacja zostanie zatrzymana lub zmieni kierunek.
    • Replikacja logiczna. Moc obliczeniowa i dane rozdzielone są pomiędzy niekoniecznie jednorodne węzły. Pomiędzy węzłami, w dowolnym kierunku, replikowane są komendy modyfikujące dane. W trakcie replikowania danych możliwa jest ich transformacja.

Daj znać w komentarzu jeśli chcesz dowiedzieć się więcej o wybranej architekturze.

To druga część cyklu o ekosystemie bazy danych.

Poprzednia: 4 najważniejsze terminy bazodanowe.

Kolejna część cyklu dotyczy 7 zasobów niezbędnych instancji bazy danych.

Marcin Badtke

Przyjaźnie o SQL, bazach danych i ludziach

Może Ci się spodobać...

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *