Bazy danych. Plan wykładu. Czynniki wpływajce na fizyczny projekt bazy danych. bazy danych

Transkrypt

1 Plan wykładu Bazy danych Wykład 13: Praktyczne projektowanie i strojenie baz danych. Wstp do transakcji. Budowa fizycznego projektu bazy danych Strojenie bazy danych Transakcje Małgorzata Krtowska Katedra Oprogramowania mmac@ii.pb.bialystok.pl Bazy danych (studia dzienne) 2 Czynniki wpływajce na fizyczny projekt bazy danych Projektowanie fizyczne to działanie, którego celem jest nie tylko otrzymanie odpowiedniej struktury przechowywania danych, ale równie dokonanie tego w sposób gwarantujcy wysok wydajno działania: Analiza zapyta i transakcji w bazie danych Zapytania naley okreli: Pliki, do których zapytanie bdzie uzyskiwało dostp. Atrybuty, na których s okrelone warunki wyboru zapytania Atrybuty, na których s okrelone warunki złcze Atrybuty, których wartoci bd zwracane przez zapytanie Atrybuty z pkt. 2 i 3 s kandydatami do okrelenia struktur dostpu Transakcje naley okreli: Pliki, które bd aktualizowane Rodzaj operacji wykonywanej na kadym pliku (wstawianie, aktualizowanie...) Atrybuty, na których s okrelone warunki wyboru dla operacji usuwania lub aktualizowania Atrybuty, których wartoci bd zmieniane przez operacj aktualizacji Atrybuty z pkt. 3 to kandydaci do struktur dostpowych. Atrybuty z pkt. 4 nie powinny by wykorzystywane do definiowania struktur dostpowych. Bazy danych (studia dzienne) 3 Czynniki wpływajce na fizyczny projekt bazy danych Analiza spodziewanej czstotliwoci wywoływania zapyta i transakcji dziki temu mona uzyska informacje o spodziewanej czstoci uycia kadego atrybutu jak atrybutu wyboru lub złczenia. Analiza wizów czasowych na zapytaniach i transakcjach niektóre zapytania i transakcje mog posiada ograniczenia co do wydajnoci ich działania np. transakcja ma w 95 % przypadków koczy swoje działanie przed upływem 5 sekund i nie powinna by wykonywana dłuej ni 20 sekund. Powoduje to ustalenie priorytetów ustalania struktur dostpu do odpowiednich atrybutów Analiza spodziewanej czstotliwoci operacji aktualizacji dla pliku, który podlega czstym aktualizacjom naley okreli minimaln liczb cieek dostpu Analiza wizów unikatowoci na atrybutach cieki dostpu powinny zosta okrelone na wszystkich atrybutach klucza kandydujcego (klucz główny albo wizy unikatowoci). Wówczas wszystkie wartoci atrybutu wystpuj w wierzchołkach lici indeksu. Bazy danych (studia dzienne) 4

2 Decyzje projektowe dotyczce indeksów Atrybuty, których wartoci wystpuj w warunkach wyboru oraz te, które s kluczami lub wystpuj w warunkach złcze wymagaj okrelenia cieek dostpu. Z drugiej strony operacje wstawiania, usuwania, aktualizacji przy obecnoci indeksów trwaj dłuej. Okrelenie, czy naley indeksowa dany atrybut atrybut musi by kluczem lub musi wystpowa zapytanie wykorzystujce ten atrybut w warunku wyboru lub złczeniu. Tworzenie wielu indeksów -> niektóre zapytania mog by przetwarzane poprzez przegld samego indeksu, bez pobierania danych z bazy. Okrelenie, jaki atrybut (atrybuty) powinien by indeksowany tworzenie indeksu zbudowanego z kilku atrybutów pochodzcych z jednej relacji ma sens wówczas, gdy s one uwzgldniane razem w kilku zapytaniach. Kolejno atrybutów w indeksie powinna by taka sama jak w zapytaniu Decyzje projektowe dotyczce indeksów Okrelenie, czy naley utworzy indeks klastrowania w przypadku kadej tabeli moe istnie tylko jeden indeks główny (atrybut jest kluczem) lub klastrowania (atrybut nie jest kluczem). Jeeli tabela wymaga kilku indeksów decyzja o tym, który powinien by indeksem klastrowania zaley od tego, czy istnieje konieczno uporzdkowania tabeli według danego atrybutu. Jeeli odpowied dla zapytania ma by uzyskiwana tylko przez przegld indeksu, nie powinien by on indeksem klastrowania -> najwiksze korzyci przynosi indeks klastrowania, gdy pobierane s rekordy danych. Okrelenie, czy naley uy indeksu mieszajcego (haszowanego) zamiast drzewa SZRBD wykorzystuj przewanie B + -drzewa w celu indeksowania. Obsługuj one zarówno zapytania równociowe jak te zakresowe. W przypadku indeksu mieszajcego jest on wykorzystywany w warunkach równociowych, szczególnie w trakcie złcze. Bazy danych (studia dzienne) 5 Bazy danych (studia dzienne) 6 Denormalizacja Normalizacja celem jest rozdzielenie logiczne powizanych atrybutów midzy tabele w celu zminimalizowania nadmiarowoci, a przez to uniknicia anomalii aktualizacji Denormalizacja zmiana logicznego projektu bazy danych na słabsz posta np. 2NF w celu uzyskania moliwoci szybszego wykonywania czsto wystpujcych zapyta i transakcji. Zazwyczaj projektant dodaje do tabeli atrybuty, które s wymagane w celu uzyskania odpowiedzi na zapytanie, tak aby mona było unikn złczenia z inn tabel. Powoduje to powstanie odpowiednich problemów z redundancj danych. Strojenie baz danych Poprawa działania bazy danych po jej wdroeniu i uruchomieniu, majca na celu uwzgldnienie problemów i czynników, których nie uwzgldniono w czasie pocztkowego projektowania bazy. Konieczne stałe monitorowanie działania bazy. Cele procesu strojenia: Przyspieszenie działania aplikacji Skrócenie czasu odpowiedzi na zapytania i transakcje Zwikszenie ogólnej przepustowoci transakcji Decyzje zwizane z etapem strojenia s takie same jak decyzje podejmowane na etapie budowy projektu fizycznego, przy czym danymi wejciowymi procesu strojenia s dane zebrane w trakcie działania systemu: Rozmiary poszczególnych tabel Liczba odrbnych wartoci w kolumnie Liczba powtórze danego zapytania lub transakcji w danym okresie czasu Czas wymagany dla rónych etapów przetwarzania zapyta i transakcji Bazy danych (studia dzienne) 7 Bazy danych (studia dzienne) 8

3 Strojenie baz danych Inne informacje otrzymywane na podstawie monitorowania działania systemu bazy danych: Statystyki dotyczce składowania danych podział obszaru składowania na przestrzenie tabel i indeksów Statystyki dotyczce operacji wejcia-wyjcia i wydajnoci urzdze dane zwizane z operacjami odczytu i zapisu na dysku, obszary dysku o najwikszej aktywnoci Statystyki dotyczce przetwarzania zapyta i transakcji - czas wykonania tych operacji, czas optymalizacji zapyta Statystyki dotyczce blokad i rejestrowania zdarze Statystyki dotyczce indeksów np. liczba poziomów indeksu Strojenie bazy danych wie si z pokonywaniem nastpujcych problemów: Unikanie zbyt czstych rywalizacji o zasoby dzielone Minimalizowanie narzutu zwizanego z rejestrowaniem i niepotrzebnym kopiowaniem danych Optymalizowanie rozmiaru bufora i szeregowanie procesów Przydzielanie zasobów takich jak dyski, pami RAM i procesy w sposób zapewniajcy jak najwydajniejsze ich wykorzystanie. Strojenie indeksów i zapyta Pocztkowy wybór indeksów mona zmieni z nastpujcych powodów: Okrelone zapytania mog działa zbyt długo ze wzgldu na brak indeksu Niektóre indeksy mog w ogóle nie by uywane Niektóre indeksy mog nakłada spory narzut zwizany z tym, e s zdefiniowane na atrybutach czsto podlegajcych zmianom Strojenie zapyta Zapytanie generuje zbyt wiele operacji dostpu do dysku Plan zapytania ujawnia, e odpowiednie indeksy nie s uywane Bazy danych (studia dzienne) 9 Bazy danych (studia dzienne) 10 Strojenie projektu bazy danych Systemy jedno- i wielouytkownikowe Istniejce tabele mog by łczone (denormalizacja), poniewa niektóre atrybuty pochodzce z dwóch lub wikszej liczby tabel s czsto wymagane wspólnie. W przypadku danego zbioru tabel mog istnie alternatywne rozwizania projektowe, dajce w efekcie schemat w postaci 3NF lub BCNF. Partycjonowanie pionowe tabeli jeeli tabela zawiera bardzo du liczb wierszy mona j rozbi na wiksz liczb tabel z podzbiorami atrybutów i replikacjami klucza tabeli. Zapytania do kadej z tabel s niezalene. Atrybuty jednej tabeli mog by powtórzone w innej Partycjonowanie poziome podział tabeli w poziomie na kilka oddzielnych tabel np. tabela sprzeday produktów jest podzielona na na kilka tabel w oparciu na róne linie produkcyjne Bazy danych (studia dzienne) 11 System jednouytkownikowy jeeli w danym momencie z systemu moe korzysta tylko jeden uytkownik System wielouytkownikowy w danym momencie z systemu moe korzysta wielu uytkowników współbienie. Przetwarzanie z przeplotem Przetwarzanie równoległe A B A B t 1 t2 t 3 t 4 czas Bazy danych (studia dzienne) 12 C D CPU 1 CPU 2

4 Transakcje Problem utraconej aktualizacji Transakcja jest wykonywanym programem, który tworzy logiczn jednostk przetwarzania w bazie danych. Transakcja składa si z jednej lub wielu operacji dostpu do bazy danych. Jednym ze sposobów okrelania zakresu transakcji jest wyrónienie jawnych instrukcji begin i end transaction. Jeeli operacje bazodanowe nalece do transakcji nie aktualizuj bazy danych, a tylko pobieraj dane, o transakcji mówimy e jest tylko do odczytu. Mechanizmy sterowania transakcjami oraz odtwarzania s z reguły zwizane z poleceniami dostpu do bazy danych w transakcjach. Operacje w równoległych transakcjach mog aktualizowa te same elementy danych. Jeeli współbieno nie jest kontrolowana moe to prowadzi do pewnych problemów. T1 X:=X-N; Zapisz_element (X); Odczytaj_element (Y); Y:=Y+N; Zapisz_element (Y); T2 X:=X+M; Zapisz_element(X); Bazy danych (studia dzienne) 13 Bazy danych (studia dzienne) 14 Problem aktualizacji tymczasowej Problem błdnego podsumowania T1 T2 T1 T2 X:=X-N; Zapisz_element (X); Zapisz_element (Y); X:=X+M; Zapisz_element(X); Transakcja T1 koczy si niepowodzeniem i musi zmieni warto X z powrotem do jej oryginalnego stanu; w tym czasie T2 odczytuje jej tymczasow niepoprawn warto Bazy danych (studia dzienne) 15 X:=X-N; Zapisz_element (X); Odczytaj_element (Y); Y:=Y+N; Zapisz_element (Y); Suma:=0; Odczytaj_element(A); suma:=suma+a;... suma:=suma+x; Odczytaj_element (Y); suma:=suma+y; Bazy danych (studia dzienne) 16

5 Potrzeba obsługi mechanizmów odtwarzania Po przekazaniu transakcji do wykonania, SZBD jest odpowiedzialny za zapewnienie, aby: Wszystkie operacje wykonywane w ramach transakcji zostały zakoczone z powodzeniem i wyniki zapisane w bazie danych, albo Transakcja nie miała wpływu na baz danych i inne transakcje Nie moe by sytuacji, gdy pewne operacje s uwzgldnione w bazie a inne nie. Taka moliwo moe zachodzi w przypadku, gdy transakcja ulegnie uszkodzeniu po wykonaniu tylko czci swoich operacji. Rodzaje awarii (transakcyjne, systemowe i noników): Awaria komputera błd sprztowy Błd transakcyjny lub systemowy uszkodzenie transakcji w trakcie jej wykonania np. dzielenie przez 0; błd programisty; przerwanie transakcji przez uytkownika Potrzeba obsługi mechanizmów odtwarzania Błdy lokalne lub wyjtki wykryte przez transakcj np wymagane przez transakcj dane s niedostpne Wymuszenie sterowania współbienego metoda sterowania współbienego moe zdecydowa o anulowaniu transakcji i póniejszym jej wznowieniu np. stan zakleszczenia kilku transakcji Awaria dysku Problemy i katastrofy fizyczne zanik napicia, poar, zamontowanie nieodpowiedniej tamy Bazy danych (studia dzienne) 17 Bazy danych (studia dzienne) 18 Operacje zwizane z transakcjami Transakcja jest niepodzieln jednostk działa, które musz by wykonane w całoci lub w ogóle. Do celów odtwarzania system musi ledzi nastpujce operacje: ROZPOCZNIJ_TRANSAKCJ ODCZYTAJ lub ZAPISZ operacje odczytu i zapisu przeprowadzane na elementach bazy danych ZAKO CZ_TRANSAKCJ naley zweryfikowa czy zmiany wprowadzone przez transakcj mog zosta zatwierdzone, czy transakcja ma by anulowana ZATWIERD_TRANSAKCJ oznaczenie udanego zakoczenia transakcji WYCOFAJ nieudane zakoczenie transakcji Diagram przej stanów zwizanych w wykonaniem transakcji Rozpocznij transakcj Odczytaj zapisz Aktywna Zakocz transakcj Anuluj Zatwierdzona czciowo awaria Anuluj zatwierd Zatwierdzona Zakoczona Bazy danych (studia dzienne) 19 Bazy danych (studia dzienne) 20

6 Dziennik systemowy (ang. log) W celu umoliwienia odtwarzania po awariach wpływajcych na transakcje system przechowuje dziennik, w którym ledzi wszystkie operacje zwizane z transakcjami, majce wpływ na wartoci elementów bazy danych. Dziennik jest przechowywany na dysku i jest okresowo archiwizowany na tamie, w celu zabezpieczenia go przed awariami. Rodzaje wpisów do dziennika (rekordy dziennika): [rozpocznij_transakcj,t] [zapisz_element, T,X, stara warto, nowa warto] [odczytaj_element, T,X] [zatwierd, T] [anuluj,t] Punkt zatwierdzenia transakcji Transakcja osiga swój punkt zatwierdzenia, gdy wszystkie jej operacje zostan z powodzeniem wykonane oraz ich wyniki zostan zarejestrowane w dzienniku. Za punktem zatwierdzenia mówi si, ze transakcja została zatwierdzona, a jej działania za trwale zapisane w bazie Kolejn czynnoci jest zapisanie do dziennika rekordu zatwierdzenia. Jeeli nastpi awaria wszystkie transakcje które rozpoczły swoje działanie, a dla których nie ma wpisu w dzienniku naley wycofa. Bazy danych (studia dzienne) 21 Bazy danych (studia dzienne) 22 Podane właciwoci transakcji (ACID) niepodzielno (atomicity) - cała transakcja powinna zosta przeprowadzona, albo aden z jej elementów nie zostanie uwzgldniony spójno (consistency) - np. miejsce w danym rejsie lotniczym nie moe by przydzielone dwóm rónym pasaerom izolacja (isolation) - brak wpływu transakcji na siebie przy jednoczesnym ich przetwarzaniu trwało (durability) - po zakoczeniu transakcji jej wynik nie moe zosta utracony Harmonogramy transakcji Gdy transakcje s wykonywane współbienie w technice przeplotu, kolejno wykonywania operacji zwizanych z rónymi transakcjami okrela si mianem harmonogramu (historii). Harmonogram S zbioru n transakcji T1, T2,.., Tn jest uporzdkowaniem operacji transakcji podlegajcym ograniczeniu, które okrela, e dla kadej transakcji Ti nalecej do harmonogramu S, operacje tej transakcji w S musz wystpowa w tej samej kolejnoci, w jakiej wystpuj w Ti. Bazy danych (studia dzienne) 23 Bazy danych (studia dzienne) 24

7 Konflikt w harmonogramie Dwie operacje w transakcji s w stanie konfliktu, jeeli spełniaj wszystkie trzy z nastpujcych warunków: Nale do rónych transakcji Uzyskuj dostp do tego samego elementu X Przynajmniej jedna z operacji jest operacj zapisz_element(); Jakie operacje s w konflikcie? Sa: r1(x); r2(x); w1(x); r1(y); w2(x); w1(y) Harmonogram pełny Harmonogram składajcy si z n transakcji jest pełny, gdy: Operacje harmonogramu S s dokładnie tymi samymi operacjami, które wystpowały w transakcjach T1,..., Tn wliczajc w to operacje zatwierdzania lub anulowania dla kadej transakcji Dla dowolnej pary operacji nalecych do tej samej transakcji Ti kolejno ich wystpowania w harmonogramie S jest taka sama jak kolejno w transakcji Ti Dla dowolnych dwóch transakcji konfliktowych jedna z nich musi wystpowa w harmonogramie przed drug. r1(x), w2(x) r2(x), w1(x) w1(x), w2(x) Bazy danych (studia dzienne) 25 Bazy danych (studia dzienne) 26 Moliwoci odtwarzania harmonogramów Harmonogramy odtwarzalne dla których w momencie zatwierdzenia transakcji T ju nigdy nie było konieczne jej wycofanie Harmonogramy nieodtwarzalne nie spełniaj powyszego wymogu, std nie powinno si pozwala na ich wystpowanie Harmonogramy odtwarzalne Harmonogram S jest odtwarzalny, jeeli adna transakcja T w harmonogramie S nie jest zatwierdzana do momentu, a wszystkie transakcje T, które zapisały element odczytywany przez transakcj T, zostan zatwierdzone. Transakcja T czyta z transakcji T w harmonogramie S, jeeli pewien element X jest najpierw zapisywany przez T, a póniej odczytywany przez T. Ponadto, transakcja T nie powinna zosta anulowana zanim transakcja T odczyta element X i nie powinny wystpowa adne transakcje zapisujce X po dokonaniu zapisu przez T, a przed wykonaniem odczytu przez T. Bazy danych (studia dzienne) 27 Bazy danych (studia dzienne) 28

8 Szeregowalno harmonogramów Pojcie szeregowalnoci harmonogramów jest uywane w celu identyfikowania, które harmonogramy s poprawne w przypadku, gdy wykonanie transakcji dopuszcza przeplot ich operacji. Bazy danych (studia dzienne) 29