Administrowanie dużymi bazami danych

Obiecałem Czytelnikom, że przedstawię niektóre problemy związane z administrowaniem dużymi bazami danych i ich rozwiązania, prezentowane oraz proponowane w ramach światowej konferencji użytkowników Informixa w San Jose. Problemy i kłopoty administratorów dużych baz danych są podobne, niezależnie od tego pod jakim systemem dane są przechowywane.

Obiecałem Czytelnikom, że przedstawię niektóre problemy związane z administrowaniem dużymi bazami danych i ich rozwiązania, prezentowane oraz proponowane w ramach światowej konferencji użytkowników Informixa w San Jose. Problemy i kłopoty administratorów dużych baz danych są podobne, niezależnie od tego pod jakim systemem dane są przechowywane.

Duża baza danych

Definicja dużej bazy trochę przypomina definicję horyzontu, może tylko w nieco zmienionym aspekcie - w czasie, nie w odległości. Jeszcze kilka lat temu za dużą uważało się bazę do pojemności 100 MB, zaś bazy o pojemnościach 100 GB i więcej można było policzyć na palcach jednej ręki. Teraz uważa się, że duża baza zaczyna się od kilkudziesięciu gigabajtów. Coraz częściej zaś mówi się o zastosowaniach komercyjnych korzystających z baz 100 GB do kilku TB. Jednakże nie sama wielkość bazy jest czynnikiem decydującym o problemach związanych z jej zarządzaniem. Decyduje podejście i planowanie.

Czynniki w administrowaniu

Im większa baza tym pozornie mało znaczące czynniki, wręcz nieistotne przy zarządzaniu małymi bazami, zaczynają odgrywać pierwszoplanową rolę. Dużo czasu należy poświęcić początkowemu etapowi planowania i konfigurowania bazy, monitorowaniu oraz strojeniu wydajności i planowaniu odzyskiwania bazy po awarii.

W pracy z dużym systemem te czynniki ulegają znacznemu powiększeniu z powodu ogromnych pojemności obsługiwanych danych. Na przykład budowanie indeksu do tabeli może potrwać kilka dni lub nawet tygodnie, nie minuty czy godziny, jak w małej bazie. Także odtwarzanie bazy po awarii i rozwiązywanie innych problemów może spowodować brak dostępu do bazy dla tysięcy użytkowników, trudno mierzalne straty produkcyjne, utratę klientów itp.

Cele administratora

Administrator bazy powinien tak zaplanować zarówno samą bazę, jak jej obsługę i konserwację aby:

* wyeliminować całkowicie potrzebę odtwarzania bazy

* zredukować ryzyko utraty danych

* uzyskać zadowalającą wydajność bazy

* zapobiegać kosztownej konserwacji bazy przez właściwe planowanie.

Poniższy przykład pokazuje, jakie problemy mogą nas czekać przy obsłudze dużej bazy. Weźmy bazę o pojemności 10 GB. Typowy napęd taśmy do składowania (backupu) danych ma szybkość zapisu wynoszącą ok. 50 MB na minutę. Oznacza to, że wspomnianą bazę zapiszemy na taśmę w ciągu ok. 200 minut (ponad trzy godziny; w praktyce znacznie więcej jeśli uwzględnić konieczność dokonania dodatkowych operacji związanych z samą procedurą składowania, wymiany taśm, oznakowania itp.). Dla bazy 100 GB operacje te zajmą nam już co najmniej cały weekend! Oczywiście zakładamy przy tym, że wszystko idzie zgodnie z naszymi życzeniami i baza nie "pada" w dni robocze. Bo jeśli tak się stanie, to najbliższe kilkadziesiąt godzin może oznaczać być albo nie być firmy (nie mówiąc już o karierze administratora).

Kluczem do sukcesu jest planowanie

Jeżeli sądzisz, że planowanie bazy można odłożyć do czasu, aż przybędzie danych i bazę należy uznać za dużą - jesteś w błędzie.

Wiele systemów zarządzania bazami danych ma wbudowane pewne ograniczenia, dotyczące rozmiarów tzw. kawałka dysku (chunk), na którym znajduje się baza, liczby tych kawałków, liczby dopuszczalnych tzw. przestrzeni bazy (dbspaces), liczby wierszy w tabeli czy liczby rozszerzeń (extents), które można dynamicznie dołączać do tabeli w celu zwiększenia jej rozmiaru. Nowe (Informix OnLine 7, Oracle7, BD2 wersja 4) mają te granice ustawione na tak dużym poziomie, że - przynajmniej chwilowo - nie trzeba się nimi martwić. Jeżeli jednak korzystamy z dawniejszych wersji systemu, może się okazać konieczne przejście na nową wersję już przy bazach przekraczających kilkadziesiąt gigabajtów. Przykładowo dla baz Informix OnLine maksymalny rozmiar "kawałka" dysku wynosi 2 GB. W wersji 6 do bazy nie można było dołączyć więcej niż 113 takich kawałków - pojedyncza baza nie mogła przekraczać 226 GB! W razie potrzeby obsługiwania większej bazy, należy korzystać z kilku serwerów bazy na odpowiedniej liczbie komputerów. To ograniczenie nie występuje już w Informix OnLine 7.

Jeżeli jednak zaczynamy wchodzić w bazy o rozmiarach GB, należy dokładnie rozważyć wszystkie ograniczenia przed instalacją bazy.

Rozkład bazy na dyskach

Ma zasadnicze znaczenie dla wydajności bazy i jej bezpieczeństwa. Aby jednak dobrze zaplanować rozkład danych na dostępnych nośnikach, należy sporo wiedzieć o charakterze danych, obsługiwanej aplikacji i najczęściej używanych poleceniach . Jeżeli np. polecenie SQL łączy dwie duże tabele, znajdujące się na tym samym dysku, to wydajność radykalnie spada, gdyż nie ma możliwości równoległego wykonania operacji odczytu tych tabel.

Podstawowe zalecenie sprowadza się do maksymalnego uproszczenia rozkładu. W tej dziedzinie należy stosować się do znanego powiedzenia KISS (keep it simple stupid - im prościej, tym lepiej). Każdy kawałek (chunk) bazy powinien znajdować się na oddzielnym dysku fizycznym (nie logicznym).

Producenci systemów dyskowych oferują tzw. logiczny menedżer wolumenów (Logical Volume Manager - LVM), rozdzielający każdy dysk logiczny na wszystkie dostępne dyski fizyczne. W efekcie tabela, umieszczona na tym dysku logicznym będzie rozmieszczona na wielu dyskach fizycznych, bez żadnej interwencji ze strony użytkownika. Jest to rozwiązanie bardzo ładne, ale fatalne w przypadku baz danych, gdyż odbiera administratorowi kontrolę nad bazą. Techniczna elegancja rozwiązania rozkładu danych na dyskach i duże bazy danych są ze sobą sprzeczne. Wniosek - wyłączyć LVM.

Odzyskiwanie bazy

Małą bazę (100 MB) odzyskuje się w pół godziny. Dużą (100 GB) już w kilkadziesiąt godzin. Nikt więc nie może sobie pozwolić na taką operację. Powszechnie uważa się, że jakość współczesnych dysków jest wysoka. I tak istotnie jest - typowy czas międzyawaryjny nowoczesnego dysku 1 GB wynosi 5 lat (lub więcej). Jeżeli jednak mamy tych dysków 600 (bo mamy bazę 600 GB), to okazuje się, że jeden dysk ulega uszkodzeniu średnio co miesiąc! Nie można sobie pozwolić na odzyskiwanie bazy tylko dlatego, że "padł" dysk. Jakie jest rozwiązanie?

Przy dużych bazach jedynym rozwiązaniem problemu zarówno stałej dostępności bazy, jak i wymiany uszkodzonych elementów, jest stosowanie lustrzanej kopii bazy. Niestety, związane jest to z niebagatelnym kosztem zakupu dodatkowo takiej samej liczby dysków, jakie przewidziano w systemie, ale korzyści są niewspółmierne do kosztów. Znika zmora odzyskiwania bazy po awarii systemu czy dysku. Nawet jeśli jeden system plików ulegnie uszkodzeniu, drugi jest sprawny, a dziennik bazy (log) pozwala na cofnięcie (undo) lub powtórne zrealizowanie (redo) transakcji w toku w chwili awarii.

RAID czy nie RAID?

Mogłoby się wydawać, że stosowanie typu RAID poziom 3, 4 lub 5 zapewnia niezbędną niezawodność bazy przy znacznej obniżce kosztów w porównaniu z rozwiązaniem z kopią lustrzaną (RAID poziom 1). Jednakże np. RAID 5 powoduje obniżenie wydajności transakcyjnej (charakteryzującej się dużą liczbą zapisów na dysk), gdyż dla zapisania jednego bloku na dysku należy faktycznie dokonać 5 operacji: trzech zapisów i dwóch odczytów. Wszystko zresztą zgodnie z zasadą - mało płacisz, mało dostajesz. Nadal więc jedynie KISS - kopia lustrzana. Żaden producent baz danych nie podaje wyników benchmarków stosując konstrukcje dyskowe RAID -i nie bez powodu.

Pozornie dość bezsensowne jest też zalecenie, aby nie wykonywać kopii lustrzanej danych na innym dysku logicznym, umieszczonym na tym samym dysku fizycznym (wrzecionie). W systemach komputerowych widziano już większe głupstwa. W razie uszkodzenia napędu (nie powierzchni dyskowej) znika nam cała baza i jej kopia.

Jak zwiększyć wydajność bazy

Popularne powiedzenie mówi, że nigdy nie da się rzucić dość dużej pamięci RAM na problem. Im więcej pamięci tym lepiej. Ograniczeniem systemów operacyjnych 32-bitowych jest niemożność obsługiwania pamięci ponad 2 GB; jednakże pojawienie się nowych 64-bitowych realizacji tych systemów (są już dostępne 64-bitowe wersje Digital Unix i OpenVMS) usuwa tę przeszkodę.

Częstym błędem programistów aplikacyjnych jest stosowanie dużych transakcji, zawierających nawet kilkadziesiąt poleceń SQL. Jest to poważny błąd, gdyż powoduje blokowanie rekordów, bloków pamięciowych; a czasem nawet całych tabel (zależnie od tzw. polityki eskalacji blokowania, używanej przez system) na długie odcinki czasu. Podobnie nie wolno dopuszczać do pozostawienia otwartych transakcji, dlatego np. że użytkownik bazy idzie na śniadanie.

Twórcy aplikacji, programiści, aplikacje

Mówi się, że programista wyczynia z bazami rzeczy, które administratorowi śnią się po nocach. Jak tego uniknąć? Nie dopuszczać programistów i twórców aplikacji do baz produkcyjnych. Niestety to nie wystarcza. Administrator bazy powinien być wybitnym specjalistą od języka SQL. Wydawałoby się proste polecenie SQL, zawierające operację logiczną OR, to nic groźnego. Tymczasem powoduje ono konieczność skanowania całej tabeli - a to trwa! Większość baz oferuje możliwość wyjaśnienia (explain) działania konkretnego polecenia SQL (pokazuje plan wykonania), z którego łatwo da się wywnioskować, jakich zasobów wymaga i jak długo będzie trwało. To aplikacja zabija twój system!

Znaczne obciążenie dla systemu transakcyjnego stanowią także wszelkie aplikacje typu wspomagania decyzji (Decision Support System - DSS) i informowania kierownictwa (Executive Information System - EIS). Powinny one działać na zupełnie innym systemie komputerowym, korzystając z kopii danych operacyjnych. Stąd zresztą szybki rozwój hurtowni danych (data warehouse), oferowanych przez głównych producentów systemów zarządzania bazami danych.

Pomoc techniczna

W przypadku dużych baz nie można oszczędzać na pomocy technicznej producenta. Jeżeli jednak mamy dużą bazę, to powinniśmy oczekiwać (i niestety opłacić) pomocy technicznej o najwyższym priorytecie dostępu. W razie awarti trzeba być jednak samemu przygotowanym do spełniania przedziwnych wymagań specjalistów od tejże pomocy i pracy przez okrągłą dobę aż do odzyskania bazy.