Rozproszone bazy danych prowadzący: mgr Leszek Siwik autorzy: Michał Żelechowski, Marcin Wielgus

Główne zagadnienia Zapotrzebowanie Problemy rozproszenia Szczegóły techniczne

Trochę historii Duże komputery typu mainframe + terminale, scentralizowana baza danych, stanowi 100% mocy obliczeniowej Rozwój komputerów osobistych, obsługa GUI u klienta Dalszy rozwój, migracja procesów do klienta, odciążenie bazy danych, wykorzystanie rozproszonej mocy obliczeniowej, nadal model scentralizowany Pojawia się problem, bo pojedynczy serwer bazy danych nie jest w stanie obsłużyć w sposób efektywny wielu klientów

Zapotrzebowania Szybki dostęp do informacji, problem z wąskim gardłem na poziomie jednego serwera baz danych Rozproszenie geograficzne przedsiębiorstw, potrzeba przeźroczystego dostępu do danych Obniżanie kosztów, poprzez wykorzystanie pełnej mocy obliczeniowej już zakupionego sprzętu Idea migracji procesów jest rozwiązaniem, ale zarządzanie systemem robi się trudne Rozwiązanie problemu, dodać wiele serwerów bazodanowych, rozproszyć je zgodnie z zapotrzebowaniem

Rozwiązanie architektoniczne Grid services – ze względu na niskie koszty procesorów oraz coraz tańsze i szybsze sieci lokalne, rozpowszechnienie internetu, wspracie np.. Oracle 10g Architektura rozproszona globalnie – poszczególne węzły bazy danych rozproszone poprzez internet

Problemy z tego wynikające Sposoby składowania danych a przeźroczystość dostępu Dostęp do danych, przetwarzanie zapytań Architektura i awarie Spójność danych a protokoły dostępu, koordynacja Równoległy dostęp i usuwanie zakleszczeń

Składowanie danych Replikacja – każda dana ma jedną swoją kopię na każdym fizycznym elemencie bazy danych Fragmentacja – dane są „pokawałkowane” na poziomie relacji w fizycznie różnych miejscach Replikacja i fragmentacja – każda sfragmentowana relacja ma swoją fizyczną replikę

Replikacja Dostępność – duża, w przypadku awarii któregoś z węzłów, informacja jest dostępna na innym węźle Równoległość – szybki odczyt, możliwość jego wykonywania równolegle, na kilku węzłach Koszt aktualizacji – duży, system musi dbać o spójność zapisywanych danych

Fragmentacja Pozioma – relacja jest dzielona na części względem wartości konkretnego klucza. W wyniku otrzymuje się zbiór tablic, których suma daje rekonstrukcję oryginalnej tablicy (intuicyjnie rozcięcie wzdłuż wiersza) Pionowa – dekompozycja, fragmenty rekonstruują się w całość poprzez złączenie naturalne, do rozbicia potrzebny jest nowy klucz (intuicyjnie rozcięcie wzdłuż kolumny)

Replikacja i fragmentacja Stosujemy te dwie techniki w sposób mieszany Dopuszczalne są zagłębienia

Przeźroczystość dostępu Ważnym jest, aby klient rozproszonej bazy danych mógł z niej korzystać w taki sposób jak korzysta z bazy nie-rozproszonej Nazewnictwo – każdy fragment/replika ma swoją unikatową nazwę. Name server – każda nazwa jest rejestrowana, wada – w przypadku awarii serwera baza przestaje działać, wąskie gardło. Prefiksy – każda część dostaje identyfikator np.. f3 – fragment trzeci, r2 – druga replika Aktualizacja danych a przeźroczystość – użytkownik nie wie nic o nazewnictwie, każda replika musi zostać zaktualizowana

Przetwarzanie zapytań Mniejszy koszt – równoległa obsługa zapytań na wielu maszynach Większy koszt – przepustowość z uwagi na sieć Optymalizacja – nietrywialna Przekształcenia zapytań – kierowanie zapytań do replik, których koszt osiągnięcia jest najmniejszy / kierowanie zapytań w zależności od ich semantyki do odpowiedniego węzła, rozbijanie zapytań na części Operacje złączania – 1. Przesłać wszystkie dane do jednego miejsca i węzeł obciążyć operacją /lub/ 2. Umieścić dane z dwóch węzłów w jednym, przetworzyć, wynik przesłać do kolejnego, przetworzyć etc. Zrównoleglenie złączania – divide & conquer między różne węzły

Rozproszony model transakcji Manager transakcji – opiekuje się transakcjami lokalnymi lub częściami lokalnych transakcji, prowadzi logi, zapewnia bezpieczny dostęp do danych na poziomie równoległym Koordynator transakcji – koordynuje wykonaniem transakcji, rozpoczyna ją, dzieli na części i rozsyła do pozostałych węzłów, domyka transakcję, akceptując ją lub odrzucając na wszystkich węzłach

Rodzaje awarii Awaria fizyczna węzła – awaria zasilania, uszkodzenie dysku Błędy transmisji sieci, zator w sieci – np.. TCP/IP Awaria sieci – odcięcie pewnej grupy węzłów od reszty

Rodzaje połączeń - podział Ze względu na koszt instalacji, liczy się koszt założenia połączenia fizycznego Koszt komunikacji – koszt utrzymania łącza oraz czas przesłania danych Dostępność – wartość mówiąca o tym, jak często w jednostce czasu dane są dostępne

Rodzaje połączeń lokalnych – topologia Pełna sieć – połączenie każdy węzeł z każdym innym, wysoki koszt utrzymania i instalacji, wysoka dostępność, bardzo szybkie przesyłanie danych (O(1)) Sieć partycjonowana – różna ilość połączeń między węzłami, mniejszy koszt niż w przypadku sieci pełnej, większe prawdopodobieństwo, że uszkodzenie połączenie rozbije sieć na dwie części, istnieją wąskie gardła Drzewo – uszkodzenie linii oznacza odcięcie definitywne pewnej grupy węzłów, niski koszt konstrukcji, szybkość dostępu O(log(n)) Pierścień – Tania konstrukcja, uszkodzenie jednego węzła nie przeszkadza w komunikacji, długi czas przesyłania danych – O(n)

Znajdowanie się w awarii W przypadku zagubienia danych, system powinien zadbać o retransmisje W przypadku awarii łącza, system jest w stanie znaleźć nową, optymalną drogę przesyłania danych Maszyna, która startuje ponownie powinna zadbać o to, aby zaktualizować dane, które zostały zmienione w trakcie trwania awarii, z reguły wstrzymuje się działanie systemy na czas naprawienia awarii

Protokoły potwierdzania W przypadku potwierdzania transakcji, wszystkie strony w niej uczestniczącej muszą przyjąć status jej wykonania Two-phase-commit protocol (2PC) Three-phase-commit protocol (3PC)

Two-Phase Commit zasada działania Transakcja została zakończona na wszystkich węzłach Koordynator rozsyła do wszystkich węzłów biorących udział w transakcji zapytanie, czy ją akceptują. Każdy węzeł ją akceptuje lub odrzuca Jeśli wszystkie węzły zaakceptowały transakcję, koordynator też ją akceptuje i powiadamia o tym węzły. Gdy któraś ze stacji odrzuci transakcję lub upłynie czas odpowiedzi, koordynator odrzuca transakcję i powiadamia o tym wszystkie węzły W pewnych odmianach 2PC węzły dodatkowo przesyłają jeszcze jedno potwierdzenie (na wypadek gdyby któraś stacja zdążyła wysiąść)

Rozwiązywanie problemów dotyczących awarii Węzeł padnie, mimo że zaakceptował transakcję. W jego interesie leży, żeby dowiedział się (jak już wstanie) jak przebiegła akceptacja transakcji Koordynator przestaje działać – węzły czekają, aż się podniesie. Sytuacja niepożądana, bo awaria może się przedłużyć, dostęp do danych jest blokowany

Three-Phase Commit Działa podobnie do 2PC, istnieje jedna faza więcej Pierwsza faza identyczna z 2PC, druga jeśli zakończona sukcesem  koordynator wysyła prośbę potwierdzenia Jeśli co najmniej K stacji potwierdzi, transakcja jest akceptowana

Wybór koordynatora Koordynator nadzoruje zatwierdzenie / odrzucenie transakcji W przypadku gdy węzeł, na którym pracuje koordynator zawiedzie, powinien zacząć działać nowy koordynator na innym węźle, w przeciwnym wypadku dane transakcji są zablokowane Rozwiązanie  zapasowy koordynator lub algorytm elekcji

Zapasowy koordynator Działa równolegle z głównym koordynatorem, na innym węźle Odbiera wszystkie dane adresowane do głównego koordynatora, Nie podejmuje komunikacji z węzłami dopóki działa główny koordynator Utrzymuje połączenie z głównym koordynatorem, sprawdzając jego dyspozycyjność oraz synchronizując stan Jeśli łączność zostaje po jakimś czasie przerwana, uznaje, że główny koordynator nie działa, przejmuje jego zadania

Algorytm elekcji Każdy węzeł posiada unikatowy numer Koordynator nie odpowiada przez określoną ilość czasu  trzeba wybrać nowy Węzeł zgłasza swoją kandydaturę na nowego koordynatora, rozsyła ją do wszystkich węzłów o numerze większym od numerze koordynatora, który przestał działać Jeśli nie dostaje odpowiedzi, oznacza to, że węzły nie działają, węzeł zostaje głównym koordynatorem, rozsyła tą informacje do wszystkich pozostałych węzłów, rozpoczyna zatwierdzanie transakcji od początku Jeśli dostaje odpowiedź, odczekuje na potwierdzenie, że inny węzeł będzie koordynatorem, jeśli potwierdzenie nie nadejdzie, algorytm jest restartowany W efekcie, węzeł o najwyższym numerze zostaje głównym koordynatorem

Kontrola współbieżności Single-Lock-Manager Multiple Coordinators Majority Protocol Biased Potocol Primary Copy

Single-Lock-Manager Manager znajduje się dokładnie w jednym miejscu w sieci Dane są blokowane na żądanie, jeśli manager nie może ich natychmiast zablokować, żądanie jest odkładane do momentu, w którym dane mogą zostać zablokowane W przypadku odczytu, dane mogą być pobrane z każdego serwera bazodanowego, zapis musi odbywać się na wszystkich węzłach Zalety  prostota implementacji, łatwe usuwanie zakleszczeń, wady  wąskie gardło, niski poziom niezawodności

Multiple Coordinators Każdy węzeł posiada swojego managera Zasada działania podobnie jak w przypadku pojedynczego managera Zalety większa przepustowość, większa niezawodność (awaria pojedynczego węzła nie blokuje systemu), wady  problem z zakleszczeniami

Majority Protocol W przypadku zapisu, należy zablokować każdą replikę Potwierdzenie blokady jest oczekiwane od każdego z węzłów zawierającego replikę Każda prośba blokady jest kolejkowana zgodnie z kolejnością przyjścia

Biased Potocol Rozróżniamy blokady typu Shared i Exclusive Shared  typowe dla odczytu, blokuje replikę na jednym z węzłów Exclusive  blokuje repliki na wszystkich węzłach, typowe dla zapisu Ten typ protokołu faworyzuje blokady typu Shared, działa podobnie do Majority, jest bardziej wydajny, gdyż odczyt występuje statystycznie częściej niż zapis

Primary Copy Jedna z replik jest uznawana za główną Blokada jest przetwarzana tylko na węźle głównej repliki Rzadziej występują zakleszczenia Jeśli węzeł z główną repliką padnie, dane stają się niedostępne, mimo, że fizycznie istnieją działające węzły z pozostałymi replikami

Zakleszczenia i jak sobie z nimi radzić Zakleszczenie powstaje np. wtedy gdy węzeł A chce zablokować dane zablokowane przez węzeł B, a węzeł B chce zablokować dane blokowane przez węzeł A W/w sytuację można rozszerzyć na większą ilość węzłów W celu określenia zapotrzebowania na dane możemy stworzyć graf, którego węzłami są transakcje, krawędziami zaś zapotrzebowanie na dostęp do danych Na każdym węźle fizycznym istnieje graf, który reprezentuje bieżącą sytuację

Zakleszczenia i jak sobie z nimi radzić, cd. Na każdym węźle fizycznym rezyduje kontroler, który buduje graf, uzupełnia go, wyszukuje zakleszczenia Każdy kontroler ma graf lokalny, na jednym węźle budowany jest graf globalny Jeśli kontroler wykryje zakleszczenie lokalne (na swoim węźle) usuwa je Usunięcie zakleszczenia polega na cofnięciu transakcji jednego z węzłów-ofiary, do momentu odblokowania zakleszczenia. Transakcja ta jest wznawiana, gdy pozostałe transakcje, biorące udział w zakleszczeniu zostaną zakończone Kontroler wysyła nową postać grafu do węzła z kompletnym grafem zakleszczeń

Pytania Wymień i krótko scharakteryzuj 3 metody składowania danych? Jakie dwie jednostki opiekują się wykonaniem transakcji, jakie są ich zadania? Rodzaj połączeń – podział, topologia Zasada działania 2PC Zasada działania algorytmu elekcji.

http://student.uci.agh.edu.pl/~zelechow/Rozproszone.ppt