Według Bureau of Labor Statistics perspektywy dla stanowisk związanych z zarządzaniem architekturą danych i bazami danych wyglądają całkiem nieźle: liczba specjalistów zajmujących się zarządzaniem danymi jest ze względu na wzrost o osiem procent od 2022 r. do 2032 r. Jednak podczas gdy liczba ról zajmujących się danymi rośnie, w rzeczywistości spada pozycja samego administratora bazy danych (DBA). Zamiast tego rola specjalisty DBA została zastąpiona przez inżyniera niezawodności witryn DevOps (SRE). 

Rola SRE rozwinęła się w Google, wykorzystując swoje umiejętności w zakresie zarządzania witrynami internetowymi i operacji w innych obszarach technologii. Zakres zadań SRE jest znacznie szerszy niż administratora baz danych i obejmuje te same rodzaje zadań, jak zarządzanie operacyjne, dostępność, redundancja systemu i bezpieczeństwo, ale całą infrastrukturę IT, a nie tylko istniejące bazy danych. Jednak zadania wykonywane przez administratorów baz danych nie zmniejszyły się i istnieją niuanse, które administratorzy baz danych mogą zrozumieć, a inni pracownicy nie.

Z jakimi problemami borykają się administratorzy baz danych? 

Chociaż większość SRE będzie w stanie zarządzać instancjami baz danych i utrzymywać je w działaniu, nie będą one miały takiego doświadczenia i wiedzy, jakie będzie miała osoba, która skoncentrowała się na teorii baz danych i zarządzaniu nimi. Kiedy wydarzy się coś niezwykłego, SRE będą musieli zrozumieć, co się dzieje i czy mogą rozwiązać problem, czy może będą musieli wezwać eksperta.

Dobrym przykładem jest konfiguracja i zarządzanie Structured Query Languagelub SQL. SQL może być najpopularniejszym językiem IEEE w 2023 r., ale ma skomplikowaną składnię, której opanowaniem zajmuje się stosunkowo niewiele osób. Wielu programistów nie wie, jak pisać efektywne i wydajne zapytania SQL, dlatego mogą wyświetlać żądania o niskiej wydajności, których wyniki wymagają więcej czasu. Alternatywnie programiści często zwracają się do maperów obiektowo-relacyjnych (ORM), aby obsłużyć dla nich żądania SQL. Chociaż ORM mogą ułatwić programistom sytuację, mogą one ucierpieć z powodu tej samej słabej wydajności i złego projektu zapytań, co pisanie własnego kodu SQL, w połączeniu z koniecznością aktualizacji samego ORM i zarządzania nim. Kombinację tę często łączy się z skłonnością do wykorzystywania długoterminowych transakcji, które ograniczają wydajność. 

Dla administratorów baz danych wykrywanie tych problemów i ich korygowanie stanowiło część pracy na pełen etat. Jednakże w przypadku SRE, które nie są zaznajomione z wydajnością baz danych, te powolne transakcje można zaakceptować jako „tak po prostu jest”, a nie jako objaw czegoś złego. Alternatywnie programiści mogą spróbować przeznaczyć więcej zasobów na rozwiązanie problemu, kupując większe maszyny lub instancje w chmurze, na których będą działać.

Oprócz projektowania zapytań administratorzy baz danych byli również odpowiedzialni za konfigurowanie indeksów danych w swoich bazach danych. Indeksowanie danych to dla wielu mroczna sztuka w stylu Harry'ego Pottera, która albo nadmiernie, albo niedoindeksuje, co prowadzi do słabej wydajności. W przeszłości administratorzy baz danych szukali zbędnych indeksów, które nie były już używane, lub popularnych zapytań, które nie były indeksowane, a następnie poprawiali bazę danych w celu uzyskania lepszej wydajności. 

Wreszcie administratorzy baz danych byliby odpowiedzialni za samodzielne uruchamianie zapytań w celu śledzenia wydajności w czasie za pomocą ANALYZE TABLE. Dzięki temu statystyki optymalizatora będą aktualne i będą oznaczane obszary, w których zmiany lub uzupełnienia wpłynęły na poziom wydajności. Bez tej wiedzy SRE mogą pozostawić indeksy, które w najlepszym przypadku nie są już potrzebne lub w najgorszym przypadku negatywnie wpływają na wyniki. 

Planowanie z wyprzedzeniem

Należy także ponownie nauczyć się operacyjnej strony baz danych. Na przykład istnieje stare powiedzenie, że administrator danych jest tak dobry, jak jego ostatnia kopia zapasowa. Choć możesz mieć nadzieję, że po wystąpieniu problemu nigdy nie będziesz musiał odzyskiwać danych, posiadanie działającej i w pełni przetestowanej kopii zapasowej każdego krytycznego pliku jest niezbędne. W świecie baz danych wiele SRE polega obecnie na tym, że dostawca usług w chmurze obsługuje to za nich. Czy to jednak wystarczy, aby było wystarczające? 

Chociaż możesz wskazać postanowienia Umowy dotyczącej poziomu usług dotyczące procesu tworzenia kopii zapasowych i przywracania, może to nie odzwierciedlać dokładnie tego, jak szybko możesz przywrócić działanie systemu po wystąpieniu problemu. Po pierwsze, umowa SLA zależy od tego, czy kopia zapasowa jest dobra i czy można ją w pełni odzyskać. Dopóki nie załadujesz kopii zapasowej i nie zaczniesz ponownie korzystać z tych danych, nie możesz być pewien, że w pełni zabezpieczyłeś swoje operacje. Po drugie, czas umowy SLA może bardzo różnić się od czasu, jaki możesz sobie pozwolić na bycie offline i nieprzetwarzanie. Kiedyś obowiązkiem administratora danych była możliwość wykrycia utraty danych i przywrócenia ich do dobrego stanu. Chociaż dostawca usług w chmurze może poinformować Cię, jaka jest jego umowa SLA dotycząca Twoich danych, niekoniecznie zapewni on wszystko, czego potrzebujesz, aby spełnić Twoje wewnętrzne wymagania dotyczące usług.

Podobnie tworzenie struktury tabel bazy danych wymaga dużej wiedzy na temat zarządzania danymi. Chociaż programiści mogą rozumieć, w jaki sposób bazy danych mogą być wykorzystywane do przechowywania, sortowania i zwracania danych potrzebnych im w ich aplikacjach, istnieją pewne niuanse związane z prawidłowym wyrównywaniem tabel, aby z czasem jak najlepiej wykorzystać te dane. Oprócz tego właściwe zrozumienie modelu relacyjnego pomaga zrozumieć, że podział danych na osobne tabele powoduje słabą wydajność. Istnieją również triki specyficzne dla bazy danych, które można zastosować w ramach bezpośredniego zarządzania tymi instancjami - na przykład wielu nie wie, że MySQL chce teraz, abyś miał klucze podstawowe w każdej tabeli lub że PostgreSQL może wymagać uzupełniania tabel, jeśli kolumny tego nie robią nie mieszczą się dobrze na granicy ośmiu bajtów. 

Przyszłość zarządzania danymi

Dane odgrywają coraz większą rolę w firmach. Stanowi podstawę do sprawnej obsługi klientów, ale jest także sercem nowych usług biznesowych czy projektów głębokiej analityki, które są wykorzystywane w nowych produktach. Bez tych danych te produkty – i generowane przez nie przychody – albo nie istnieją, albo nie zapewniają wartości, do której zapewnienia zostały zaprojektowane.

Jednocześnie umiejętności związane z zarządzaniem danymi wyciekają z organizacji, są przyjmowane w szerszych rolach lub przekazywane dostawcom usług. Gdy wszystko działa, wszystko jest w porządku. Ale kiedy pojawi się problem, będziesz potrzebować dogłębnej wiedzy, aby go rozwiązać i upewnić się, że nie powtórzy się. Oznacza to również, że możesz wydać więcej, niż potrzebujesz, na utrzymanie przechowywanych danych i obejście ich.

Choć rolę DBA przejęły nowsze stanowiska z okolic DevOps i SRE, to zadania z nią związane nadal są w nas. Dla specjalistów SRE i DevOps znajomość teorii danych może stanowić różnicę między wydawaniem pieniędzy na infrastrukturę a oszczędzaniem na wydajności.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• Źródło: https://www.dataversity.net/devops-and-data-lessons-teams-can-learn-about-managing-databases/