Nowy sposób zarządzania bazami danych Open Source

Jeszcze nie tak dawno branża baz danych składała się z kilku dostawców. Bazy danych były głównie relacyjne i działały na pojedynczych komputerach. Wysoka dostępność została wdrożona za pośrednictwem „klastrów” w trybie aktywnego czuwania. W pionowym modelu „skalowania w górę” chodziło głównie o współużytkowaną pamięć masową (SAN lub DRBD) lub asynchroniczną replikację dzienników w celu synchronizacji stanu z węzłem rezerwowym. W 2001 roku, kiedy zacząłem pracować z klastrem NDB (który później stał się klastrem MySQL), koncepcja utrzymywania całej bazy danych w pamięci głównej była dziwna – „co jeśli wyłączysz serwer?”. Dystrybucja bazy danych na wielu serwerach była niepokojąca – „masz fragmenty danych tu i tam”. A cały pomysł na bazę danych o otwartym kodzie źródłowym dla obciążeń o znaczeniu krytycznym był śmiechu warty.

Szybko do przodu o 15 lat, a teraz mamy na rynku dziesiątki dostawców baz danych - głównie open source, różne modele (wartość klucza, dokument, wykres, …) i domyślnie dystrybuowane. Dane rezydujące w pamięci to w zasadzie norma umożliwiająca osiągnięcie wysokiej wydajności i małych opóźnień. Trzy z pięciu najpopularniejszych baz danych (według rankingu db-engines) to bazy danych typu open source (MySQL, PostgreSQL i MongoDB). W dzisiejszych czasach istnieje większe prawdopodobieństwo zarządzania flotą serwerów baz danych rozmieszczonych w różnych centrach danych. Możesz nawet mieć niektóre bazy danych zarządzane przez zewnętrznego dostawcę chmury.

Jak to jest zarządzać bazami danych w 2018 roku?

AUTOMATYZACJA

Przy tak wielu zadaniach do zarządzania i tylko tylu godzinach w ciągu dnia, szaleństwem byłoby robienie rzeczy ręcznie.

Automatyzacja to świetny sposób na załatwienie spraw. Gdy mieliśmy kilka baz danych do zarządzania, obsługa bazy danych byłaby bardzo praktyczna, z niektórymi zadaniami skryptowanymi w czymś w rodzaju bash lub perl - np. skrypt do tworzenia kopii zapasowych bazy danych, inny do przenoszenia plików kopii zapasowych w jakieś miejsce. Przełączanie awaryjne byłoby ręczne, a nawet dyskutowalibyśmy, czy powinno być zautomatyzowane, czy nie.

W dzisiejszych czasach automatyzacja to oczywistość. Istnieje wiele systemów automatyzacji lub zarządzania konfiguracją IT, które można wykorzystać – Puppet, Chef, Ansible i Salt oferują struktury ogólnego przeznaczenia, które można wykorzystać do budowania automatyzacji dla różnych topologii baz danych. Oprogramowanie do zarządzania klastrami napisane specjalnie do zarządzania konfiguracjami baz danych obejmuje MongoDB Ops Manager i ClusterControl. Umożliwiają zespołom operacyjnym zarządzanie klastrami za pomocą czegoś, co jest łatwo dostępne od ręki. Zbudowanie od podstaw systemu zarządzania klastrami przy użyciu systemu zarządzania konfiguracją to nie lada wyczyn. Wymaga znacznej wiedzy fachowej w zakresie narzędzia do automatyzacji, a także zrozumienia operacji zarządzania, takich jak planowanie i weryfikacja kopii zapasowych, automatyczne przełączanie awaryjne z późniejszą rekonfiguracją systemów, wprowadzanie zmian w konfiguracji, łatanie, uaktualnianie lub obniżanie wersji itp.

I oczywiście następuje rozwój platform usług DBaaS, w których wdrażanie, kondycja, przełączanie awaryjne, kopie zapasowe itp. są kontrolowane przez oprogramowanie. Dostawcy usług w chmurze są rzeczywiście bardzo dobrzy w automatyzacji. Amazon RDS jest doskonałym przykładem automatyzacji baz danych na dużą skalę - automatyzuje wdrażanie, aktualizacje poprawek, kopie zapasowe, przywracanie do punktu w czasie, skalowanie replik i wysoką dostępność/przełączanie awaryjne.

ZWIERZĘTA KONTRA BYDŁO

W latach 90. i przed boomem i krachem dotcomów Sun Microsystems i Oracle zarobiły fortunę, sprzedając skalowalne bazy danych na dużym sprzęcie SMTP. Dodaj tam trochę pamięci masowej SAN i oprogramowanie Veritas do przełączania awaryjnego, a uzyskasz najnowocześniejszy klaster przełączania awaryjnego z aktywnym trybem gotowości zapewniający wysoką dostępność. Serwery baz danych były stosunkowo nieliczne, ale potężne, ponieważ rosły w pionie. Zostały im nadane imiona (tak jak nazywasz swoje zwierzęta!) i opiekowali się nimi administratorzy baz danych.

Obecnie bazy danych są tanie i działają dobrze na zwykłym sprzęcie. Jest ich dużo i nadajemy im numery - tak jak bydło. Jeśli któryś się zepsuje, możemy po prostu zdobyć nowy.

To także nowa rasa bydła – bydło open source! Według db-engines, trzy z pięciu najlepszych baz danych są open source – powoli, ale zdecydowanie tracą udział w rynku dwóch zastrzeżonych dostawców. Open source to nowy standard centrów danych, nie tylko dla systemu operacyjnego, ale także dla baz danych.

A więc co to dla ciebie znaczy? Cóż, w przyszłości bardziej prawdopodobne jest, że będziesz zarządzać bazą danych o otwartym kodzie źródłowym — lub nawet wieloma bazami dla aplikacji korzystających z heterogenicznych zbiorów danych. W świecie trwałości poliglotów i mikrousług bazowy magazyn danych jest teraz podyktowany charakterem danych. Z architektonicznego punktu widzenia bazy danych z pojedynczą instancją z dyskową HA ustąpiły miejsca klastrom, które są potencjalnie rozproszone w wielu centrach danych.

Czy potrzebujemy administratora baz danych?

Rola DBA jest rolą specjalistyczną – potrzeba lat doświadczenia, aby nią zostać. W przeszłości, gdy do wyboru było tylko kilku dostawców zastrzeżonych baz danych, mieliście wyspecjalizowanych administratorów baz danych z określonym zestawem umiejętności i doświadczenia. Było to również wymagane - bazy danych takie jak Oracle czy SQL Server mają ogromne zestawy funkcji, budowane przez dziesięciolecia. Nie są łatwe w zarządzaniu. Były one zwykle wdrażane jako jedyna baza danych dla aplikacji i wymagały monitorowania, tworzenia kopii zapasowych danych i rozwiązywania wszelkich pojawiających się problemów. Na tych zadaniach mieli się skupić administratorzy baz danych.

Jednak w ostatniej dekadzie pojawiła się zupełnie nowa branża baz danych – z dziesiątkami baz danych open source, a także usługami baz danych w chmurze. Jak widzieliśmy wcześniej, często zdarza się, że aplikacja korzysta z kilku różnych magazynów danych. Jednak firmy rzadko mają administratora baz danych dla tych baz danych, z których korzystają. Gdzie można znaleźć MongoDB lub Cassandrę lub DBA z ponad 5-letnim doświadczeniem produkcyjnym? Można argumentować, że nowa generacja baz danych NoSQL jest znacznie prostsza niż ich poprzednicy z zamkniętym kodem źródłowym i dlatego nie wymagałaby takiej samej krzywej uczenia się.

Zarządzanie nimi byłoby kolejnym zadaniem dodanym do listy zadań zespołu SysAdmin, DevOps lub Site Reliability Engineering (SRE). Widzimy dzisiaj, że wiele firm nie ma pełnoetatowych administratorów baz danych. Odpowiedzialność jest rozłożona na zespoły, a narzędzia do automatyzacji są coraz częściej wykorzystywane do wykonywania rutynowych, codziennych zadań. W przypadku baz danych, które zostały przeniesione do chmury, operacyjne aspekty przechowywania danych są w całości zlecane dostawcy chmury. Więc zamiast pracować nad sposobem przechowywania danych, zespół operacyjny może teraz skupić się na wykorzystaniu danych.

Cykl życia bazy danych

Przeciętny cykl życia bazy danych był kiedyś znacznie dłuższy niż obecnie. Kiedy już wybrałeś platformę bazodanową, to było to. Decyzja byłaby podejmowana między dwiema lub trzema relacyjnymi bazami danych, zwykle przez administratora baz danych lub kogoś wyższego w organizacji. Firma znalazłaby pieniądze na zakup licencji wieczystych. Po podjęciu decyzji trzeba było z nią żyć przez następne 10 lat. Bazy danych były monolityczne, a aplikacje zazwyczaj korzystały z jednej współdzielonej bazy danych.

Dzisiaj, w świecie kontenerów, chmury, mikroserwisów i potoków CI/CD, często zdarza się, że programiści dokonują wyborów technologicznych – zwłaszcza jeśli jest to baza danych typu open source, którą można łatwo pobrać lub zaoferować jako usługę, bez konieczności rozmowy z przedstawicielem handlowym lub szukania budżetu od kierownictwa. Organizacje stają przed wyzwaniem szybszego tworzenia wartości, więc tempo zmian w infrastrukturze/aplikacjach gwałtownie wzrosło. Monolityczne bazy danych są teraz podzielone na wiele małych baz danych, przy czym każda baza danych zarządza danymi domeny dla pojedynczej mikrousługi. Dzięki różnorodności produktów bazodanowych dostępnych obecnie w ekosystemie open source zespoły mają wybór i swobodę przejścia do lepszego magazynu danych. W miarę zamawiania i wycofywania usług, bazy danych również podążają za nimi – chociaż same dane mogą być archiwizowane lub przenoszone do jeziora danych. W krajobrazie infrastruktury, który jest dziś znacznie bardziej dynamiczny, stwierdzamy, że nasze bazy danych żyją krócej.

ROLA DBA

DBA, tradycyjnie zarówno strażnik, jak i strażnik bazy danych, odpowiadałby na potrzeby baz danych różnych zespołów aplikacyjnych/infrastrukturalnych w organizacji. Wszelkie zmiany, które wymagały dostępu lub zmiany w bazie danych, wymagałyby usług DBA. Jednak sprzeczne priorytety i brak dostępności DBA mogą oznaczać, że projekt zostanie zablokowany/opóźniony i nastąpią nieuniknione tarcia.

Wysokie koszty współpracy i szybka innowacja/krótki czas wprowadzenia na rynek nie idą w parze. Jak widzieliśmy wcześniej, mikrousługi są przykładem tego, jak usługi infrastrukturalne i aplikacyjne są teraz projektowane w taki sposób, aby jak najwięcej oddzielić. Bazy danych są coraz bardziej zautomatyzowane, a kontrola nad bazą danych przechodzi na programistów lub zespoły projektowe. Nawet takie rzeczy jak zmiany schematu nie są tak ciężkie, jak kiedyś. Były znacznie trudniejsze w kontekście centralnej bazy danych dla aplikacji monolitycznej. Ponieważ dane są udostępniane między różnymi komponentami, zmiany schematu musiałyby być skoordynowane i starannie zaplanowane – zwykle z kilkumiesięcznym wyprzedzeniem. Administratorzy baz danych odegrali kluczową rolę w zrozumieniu i przeprowadzaniu zmian. Inaczej wygląda dziś dynamika, gdzie tempo zmian jest znacznie szybsze. Często zdarza się, że zespoły programistyczne wprowadzają zmiany w kodzie w środowisku produkcyjnym co tydzień lub codziennie – a nawet kilka razy dziennie! Bazy danych wymagają ciągłych aktualizacji, aby nadążyć za zmianami aplikacji, a te są wykonywane przez programistów. Niektóre nowsze bazy danych, takie jak MongoDB, czynią to bardzo prostym dzięki modelowi bez schematu. Skutecznie oznacza to, że schemat bazy danych przenosi się do kodu aplikacji.

Więc jeśli wszystkie typowe podstawowe zadania zostaną zautomatyzowane, co stanie się z rolą DBA w przyszłości? Zamiast skupiać się na zadaniach administracyjnych, DBA będzie pełnił rolę mentora dla innych zespołów w organizacji. Organizacje muszą zrozumieć, jakie mają dane i jak można je wykorzystać. W końcu dane są najcenniejsze, gdy są udostępniane i łączone z innymi zasobami, a nie tylko przechowywane. Bez schematu brzmi świetnie, ale nadal musimy śledzić nasze dane - w bazie danych lub w kodzie. Bezpieczeństwo to wyzwanie, a naruszenia danych stają się coraz gorsze. Jeśli więc mamy ponownie sprawić, że dane będą świetne, administrator baz danych musi przejść do roli doradcy poziomego/aktywatora, obejmującej różne zespoły. Z perspektywy kompetencji, współczesny administrator baz danych musi rozumieć, jak projektować rozproszone systemy o wysokiej dostępności i wdrażać wydajne systemy automatyki, aby zająć się przyziemnymi zadaniami. Ponieważ firmy wdrażają infrastrukturę w środowiskach chmurowych, a nawet kontenerowych, zrozumienie, jak budować wysoce dostępne i skalowalne bazy danych na tych platformach, zapewni przetrwanie DBA.

Podsumowanie

Znajdujemy się na fascynującym skrzyżowaniu w historii branży baz danych, która przeszła ogromną transformację w ciągu ostatnich dwóch dekad. Poniższa tabela próbuje to podsumować.

Chciałbym usłyszeć Twoje przemyślenia na temat zarządzania bazami danych typu open source i czy zaobserwowałeś te same trendy? Jak wyglądały twoje zmagania lub sukcesy z OSDB w ostatnich latach? A co przewidujesz w przyszłym roku?

My w Manynines będziemy oczywiście nadal walczyć, aby ułatwić zarządzanie i automatyzację Twoich baz danych typu open source w przyszłym roku i później. Czekajcie więc na aktualizacje na ten temat od przyszłego stycznia.

Ale w międzyczasie daj mi znać, co myślisz i do zobaczenia w 2019 roku!

Zdjęcia autorstwa SoRad (Shutterstock) i The Simpsons; inne zdjęcia należą do ich właścicieli.