Przegląd algorytmów stosowanych w nierelacyjnych bazach danych.

Transkrypt

1 Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki Rok akademicki 2012/2013 PRACA DYPLOMOWA MAGISTERSKA Marcin Szymaniuk Przegląd algorytmów stosowanych w nierelacyjnych bazach danych. Opiekun pracy mgr inż. Piotr Salata Ocena: Podpis Przewodniczącego Komisji Egzaminu Dyplomowego 1

2 Specjalność: Inżynieria Systemów Informatycznych Data urodzenia: Data rozpoczęcia studiów: Życiorys Urodziłem się 16 sierpnia 1986 roku w Siemiatyczach. Uczęszczałem do Liceum Ogólnokształcącego imienia Józefa Pietruczuka w Łosicach, które ukończyłem w 2004 roku. W lutym 2005 podjąłem studia na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. W 2009 roku zdobyłem tytuł inżyniera i zdecydowałem o kontynuacji studiów na specjalności Inżynieria Systemów Informatycznych. EGZAMIN DYPLOMOWY... Podpis studenta Złożył egzamin dyplomowy w dniu r. z wynikiem... Ogólny wynik studiów:... Dodatkowe wnioski i uwagi Komisji:

3 STRESZCZENIE Celem pracy było dokonanie przeglądu wybranych rozwiązań stosowanych w nierelacyjnych bazach danych. Praca zawiera opis rozwiązań zastosowanych w trzech wybranych bazach danych oraz analizę ich najważniejszych cech. Znaczące miejsce w pracy zajmuje algorytm Consistent Hashing, którego różne modyfikacje zostały poddane badaniom i porównaniu. Integralną część pracy stanowi kod źródłowy symulatora, służącego porównaniu opisanych wersji algorytmu Consistent Hashing. Słowa kluczowe: NoSQL, Consistent Hashing, nierelacyjne bazy danych, partycjonowanie, replikacja. Overview of non-relational databases algorithms. ABSTRACT This paper shows various kind of algorithms used in non-relational database systems. It explores and examines the most important features and limitations of them. It also shows various modifications of the Consistent Hashing algorithm and compares them. The integral part of that work is a source code of simulator used to compare Consistent Hashing modifications. Keywords: NoSQL, non-relational databases, Consistent Hashing, partitioning, replication.

4 Wstęp Relacyjne bazy danych są fenomenem w świecie informatyki. Ciężko znaleźć produkt, który przetrwałby tak długo w niezmienionej postaci, zachowując jednocześnie tak silną pozycję na rynku. Ostatnie lata przyniosły jednak swego rodzaju rewolucję w podejściu do systemów bazodanowych, a rosnące wymagania związane z rozwojem aplikacji internetowych spowodowały powstanie wielu nowych typów baz danych. Nowe rozwiązania w różny sposób i w różnym kierunku odchodzą od klasycznego modelu relacyjnego. W żadnym stopniu nie oznacza to, że sugeruję tu nadchodzące zastąpienie relacyjnych baz danych nowymi produktami. Pozycja baz relacyjnych na rynku jest bardzo silna, a spektrum problemów, z jakimi sobie doskonale radzą, bardzo szerokie. Dynamiczny rozwój nierelacyjnych baz danych pokazuje jednak, że wymagania stawiane przed nowymi projektami są na tyle duże, że nie można dłużej mówić o uniwersalnym rozwiązaniu każdego problemu, jakim do niedawna mogły wydawać się bazy relacyjne. Głównym powodem, dla którego zaczęto szukać nowych kierunków rozwoju baz danych był dynamiczny rozwój aplikacji internetowych. Zwiększenie znaczenia Internetu sprawiło, że liczba użytkowników różnego rodzaju systemów dostępnych za jego pośrednictwem oraz ilość danych przez nich generowanych zanotowały w ostatnich latach bardzo dynamiczny wzrost. Poza tym pojawiły się nowe wymagania dotyczące analizy ogromnej ilości danych w celu np. poznawania preferencji użytkowników. Znajomość preferencji użytkowników i istniejących wzorców zachowania pozwala rozwijać system w sposób sprzyjający zwiększaniu zainteresowania nim użytkowników a tym samym generowaniu dodatkowych zysków. Trend związany z przetwarzaniem i analizą bardzo dużych ilości danych określany jest często angielskim terminem Big Data. Trend ten stał się jednym z głównych powodów tworzenia i rozwoju nowych typów baz danych. Jest on również znaczącym wyznacznikiem kierunku, w którym zmierza rozwój systemów bazodanowych. Wydajność tradycyjnych baz danych opartych na modelu relacyjnym w przypadku zwiększenia obciążenia systemu może być łatwo zwiększana poprzez poprawianie parametrów maszyn je obsługujących zakup szybszych dysków, większej ilości pamięci czy dodatkowych procesorów. Taki sposób skalowania nazywany jest skalowaniem wertykalnym. 1

5 Podlega on znaczącym ograniczeniom nie można rozbudowywać pojedynczej maszyny w nieskończoność. Skalowanie wertykalne ma jeszcze jedną znaczącą wadę zakup jednej maszyny o bardzo dużej wydajności jest znacznie droższy od zakupu kilku maszyn o takiej samej sumarycznej wydajności. Relacyjne bazy danych mogą podlegać klastrowaniu, jednak może odbywać się to w ograniczonym zakresie ze względu na konieczność synchronizacji pomiędzy poszczególnymi węzłami klastra. Alternatywnym rozwiązaniem pomagającym zwiększyć wydajność systemów relacyjnych jest podział danych pomiędzy kilka niezależnych podsystemów bazodanowych. W takim przypadku ważne jest, żeby dane pojedynczego podsystemu odpowiadały za pewną niezależną część logiki biznesowej, a tym samym, aby operacje na nich mogły być wykonywane niezależnie od operacji w pozostałych podsystemach. Taki sposób radzenia sobie z bardzo dużym obciążeniem stawia dodatkowe wymagania co do sposobu dostępu do danych przez aplikacje klienckie. Również podział danych na niezależne części nie zawsze jest możliwy ze względu na zasady logiki biznesowej. Wymienione wyzwania związane z trendem Big Data pobudziły powstawanie nowych typów baz danych rezygnujących z modelu relacyjnego. Klasę takich baz danych często określa się pochodzącym z języka angielskiego terminem NoSQL. Wyzwania związane z trendem Big Data są głównym wyznacznikiem kierunku rozwoju nierelacyjnych baz danych. Nie jest to jednak jedyny powód rozwoju baz nierelacyjnych, których powstanie bywa spowodowane koniecznością rozwiązania specyficznej klasy problemów jak na przykład zarządzanie danymi, których naturalną reprezentacją jest graf. Przykładami różnych klas baz typu NoSQL mogą być bazy typu klucz-wartość, bazy zorientowane na przechowywanie dokumentów, czy też bazy grafowe. Celem pracy jest przedstawienie wybranych algorytmów stosowanych w nierelacyjnych bazach danych w zagadnieniach takich jak partycjonowanie, wersjonowanie, fizyczny zapis danych oraz wykrywanie i obsługa sytuacji awaryjnych. Analiza posłuży do określenia cech poszczególnych rozwiązań ze szczególnym uwzględnieniem różnic w stosunku do relacyjnych baz danych. Analiza taka będzie miała na celu pokazanie zastosowań poszczególnych baz danych i określenie obszarów, w których bazy relacyjne mają godną uwagi alternatywę w postaci systemów nierelacyjnych. 2

6 Jednym z podstawowych rozwiązań systemowych stosowanych w nierelacyjnych bazach danych jest algorytm nazywany w jęz. angielskim Consistent Hashing (tego terminu będę używał dalej w pracy z braku dobrego polskiego odpowiednika). Wykorzystywany jest on do rozwiązania problemu partycjonowania danych systemu rozproszonego. Praca ta przedstawi testy różnych wersji tego algorytmu. Będą one miały na celu ustalenie cech poszczególnych wersji rozwiązania. Określone dzięki testom charakterystyki algorytmu Consistent Hashing pozwolą określić wady i zalety poszczególnych jego wersji, a tym samym ocenić ich przydatność w problemie partycjonowania w rozproszonej bazie danych. Analiza i eksperymenty będą również miały na celu pokazanie wpływu sposobu konfiguracji poszczególnych algorytmów na efektywność zastosowanych rozwiązań. W pierwszych trzech rozdziałach pracy przedstawione zostały opisy trzech wybranych różnych baz danych typu NoSQL i rozwiązań w nich stosowanych. Na podstawie analizy tych rozwiązań, w podsumowaniu każdego z rozdziałów podane są zastosowania opisywanej bazy danych. Rozdziały 1, 2, 3 opisują odpowiednio bazy danych: Amazon Dynamo, Cassandra i CouchDB. Rozdział 4 opisuje algorytm Consistent Hashing organizujący dane klastra w rodzaj pierścienia i dzielący odpowiedzialność za jego fragmenty pomiędzy węzły. Rozdział ten przedstawia również modyfikację polegającą na wykorzystaniu mechanizmu wirtualnych węzłów. Następnie przedstawione zostały dwa opisane w literaturze sposoby podziału pierścienia danych oraz usprawnienie jednego ze sposobów zaproponowane przez autora. Kluczową częścią rozdziału czwartego jest opis programu symulującego klastry używające różnych wersji algorytmu Consistent Hashing oraz wyniki doświadczeń prowadzących do porównania testowanych wersji. 3

7 1 Amazon Dynamo 1.1 Wprowadzenie System Amazon Dynamo [1] powstał w odpowiedzi na rosnące wymagania sklepu internetowego Amazon. Jest systemem bazodanowym, który pozwolił tej firmie na osiągnięcie oczekiwanego poziomu wydajności, skalowalności i dostępności. Jednym z głównych wymagań stawianym przed tym systemem, jak i całą infrastrukturą, było zapewnienie klientom doświadczenia permanentnej dostępności (ang. always on) i możliwości zapisu. Wynikało to z faktu, że każdy problem z funkcjonowaniem sklepu, np. z dodaniem produktu do koszyka, pociąga za sobą bezpośrednie konsekwencje finansowe oraz nadwątlenie zaufania klientów. Dynamo jest bazą typu klucz-wartość. Oznacza to, że przechowywane dane możemy traktować jako mapę, na której możemy wykonywać operacje put i get, a wszelkie aspekty związane z semantyką danych i związkami pomiędzy nimi osadzone są w aplikacji korzystającej z systemu Dynamo. Ważną i wartą zauważenia rzeczą jest fakt, że w celu osiągnięcia oczekiwanej dostępności, architekci systemu zdecydowali się na rezygnację z pełnej spójności danych, oferując jedynie spójność ostateczną (ang. eventual consistency) Podstawowe parametry systemu Mówiąc ogólnie, Dynamo jest systemem nie dostarczającym pełnej spójności danych, oferując jedynie spójność ostateczną. Taki sposób opisu jest jednak jedynie uproszczeniem. Dynamo dostarcza możliwości konfigurowania stopnia, w jakim system jest spójny (kosztem dostępności i vice versa) poprzez ustalenie kilku podstawowych parametrów: N współczynnik replikacji, określający, na ilu węzłach będą replikowane dane. Konfiguracja tego współczynnika odbywa się per węzeł. R minimalna liczba węzłów, które muszą uczestniczyć w operacji odczytu. W minimalna liczba węzłów, które muszą uczestniczyć w zapisie. 1.2 Maksymalizowanie dostępności zapisu wersjonowanie danych Dynamo dążąc do maksymalizacji dostępności zapisu, nie zapewnia pełnej spójności danych, pozwalając tym samym na ich asynchroniczną modyfikację. Może zatem zaistnieć sytuacja, 4

8 kiedy różne węzły jednego systemu zawierają różne dane zapisane pod tym samym kluczem. Biorąc za przykład konkretny scenariusz biznesowy, weźmy użytkownika sklepu internetowego, który dodaje produkt do swojego koszyka. Wyobraźmy sobie, że ostatnio wprowadzony stan koszyka nie został uaktualniony we wszystkich węzłach za niego odpowiedzialnych, a jednocześnie węzeł zawierający najbardziej aktualny stan uległ awarii. Aby sprostać wymaganiu dostępności w takiej sytuacji, Dynamo traktuje każdą modyfikację danych jako nową, niemodyfikowalną ich wersję. Kolejny nowo dodany w naszym scenariuszu produkt trafi zatem, do starszej znanej wersji koszyka, a w przypadku powrotu uszkodzonego węzła wystąpi sytuacja niespójnych danych, którą należy rozwiązać. Rozwiązanie to Dynamo zostawia aplikacji jako składowej systemu będącej najbliżej logiki biznesowej i w najlepszy sposób rozumiejącej dane oraz sam konflikt i sposoby rozwiązania go. Mechanizmem pozwalającym wykryć i naprawić konflikt jest algorytm Zegara wektorowego Zegar wektorowy Algorytm zegara wektorowego (ang. Vector clock) [2] pozwala określić historię operacji w systemie rozproszonym. Pojedynczy zegar jest właściwie listą par (węzeł, licznik) i jest powiązany z obiektem, którego historię opisuje. W przypadku modyfikacji obiektu, z którym powiązany jest zegar, następuje inkrementacja licznika węzła, który dokonał zmian. Zegar wektorowy pozwala stwierdzić, czy możemy określić przyczynowość (historię modyfikacji przez węzły) dwóch wersji tego samego obiektu, czy też powstały one w wyniku zrównoleglonej modyfikacji. Sprawdzenia takiego dokonuje się poprzez zbadanie, czy wszystkie liczniki zegara A są większe bądź równe odpowiednim licznikom zegara B. Jeżeli tak, oznacza to, że obiekt B jest poprzednikiem obiektu A i jako starsza wersja może zostać przez niego nadpisany. Jeżeli nie wszystkie liczniki, któregoś z porównywanych zegarów spełniają kryterium większy bądź równy, oznacza to, że odpowiadające im obiekty zostały zmodyfikowane równolegle i należy je traktować jako będące w konflikcie. W przypadku wykrycia sytuacji konfliktowej, Dynamo zwraca klientowi wszystkie znane wersje obiektu będące w konflikcie, wraz z ich zegarami. Klient otrzymujący taką informację powinien na podstawie ustalonej logiki biznesowej dokonać rekoncyliacji danych i zapisać nowo utworzoną wersję obiektu, nadpisując wersje konfliktowe. Dynamo wraz z informacją o obiekcie, który należy zmodyfikować otrzymuje także informację o kontekście, w którym dany obiekt jest modyfikowany kontekst taki zawiera zegar wektorowy określający wersję 5

9 obiektu, która jest uaktualniana. Przykład takiej sytuacji na podstawie pracy [1] znajduje się na rysunku Rysunek 1. Rysunek 1 Przykład sytuacji wykrycia i rozwiązania konfliktu przy pomocy algorytmu zegara wektorowego Na rysunku tym opisany został cykl życia tych samych danych (D1...D5) w różnych wersjach, uaktualnianych przez węzły W1, W2, W3. Pierwsze dwa zapisy dokonane zostały sekwencyjnie przez W1. Następnie doszło do równoległego zapisu przez węzły W2 i W3, co spowodowało powstanie zegarów, które nie pozwalają ustalić kolejności powstania wersji D3 i D4. Sytuacja taka zostaje przez Dynamo wykryta jako konflikt. Dalej, węzeł czytający dane (w tym przypadku W1) otrzymuje obie wersje danych i zobowiązany jest do ustalenia nowej wersji danych (w naszym przypadku D5), która nadpisze konfliktujące wersje wraz z odpowiednimi uaktualnieniami w nowym wektorze czasu. Wektor powiązany z wersją D5 danych jasno określa to, że zarówno D3 jak i D4 są poprzednikami D5, co oznacza, że ostatecznie będą mogły być przezeń zastąpione. 1.3 Partycjonowanie i replikacja danych Wprowadzenie Kluczową ideą przyświecającą architektom Dynama było osiągnięcie wysokiej wydajności, skalowalności oraz tolerancji awarii poprzez możliwość rozproszenia bazy danych na wielu serwerach. Podejście takie w oczywisty sposób uwalnia użytkownika 6

10 od bolączek związanych z ograniczeniami, jakim podlega rozbudowa pojedynczej maszyny. Z drugiej strony jednak, system rozproszony wprowadza całą klasę wyrafinowanych wyzwań, z którymi zmierzyć się musieli lub muszą, zarówno architekci Dynama, jak i administratorzy systemu w środowisku produkcyjnym. Partycjonowanie i replikacja danych jest jednym z popularniejszych zagadnień, z którymi w różny sposób radzą sobie różni producenci systemów bazodanowych. Umożliwienie łatwego i przewidywalnego partycjonowania danych pomiędzy wiele maszyn pozwala na skalowanie horyzontalne i niemal nieograniczoną kontrolę nad wydajnością systemu w zależności od potrzeb. Replikacja pozwala osiągnąć bezpieczeństwo danych dobrze zrobiona zapewnia, że awaria jednego (lub więcej, w zależności od przyjętych rozwiązań) węzła nie powoduje awarii systemu. Z drugiej strony sposób, w jaki dane zostały rozłożone pomiędzy węzłami i centrami danych, wpływa na algorytmy dostępu do nich, dlatego bardzo ważne było wybranie rozwiązań, pozwalających na spełnienie wszystkich wymagań stawianych przed systemem Consistent Hashing modyfikacja użyta w Amazon Dynamo. Amazon Dynamo partycjonując dane wykorzystuje algorytm Consistent Hashing, którego zarys znajduje się w rozdziale 4.1. Wersja podstawowa algorytmu pomimo bardzo eleganckiego i intuicyjnego rozwiązania problemu partycjonowania danych nie jest pozbawiona wad. Problematyczne wydają się sytuacje dołączenia nowych węzłów do klastra, kiedy trzeba zdecydować o nowym podziale klastra. Również usunięcie lub awaria węzła sprawia, że dane przestają być zbalansowane i jeden z węzłów zostaje znacznie mocniej obciążony od pozostałych. Mając to na uwadze, Amazon Dynamo początkowo używało modyfikacji opisanej w rozdziale 4.3.1, aby ostatecznie zdecydować się na wersję opisaną w Architekci systemu uzasadniając ten wybór piszą między innymi o możliwości łatwiejszej i efektywniejszej reakcji na awarie i dołączenie nowego węzła do systemu ponieważ podział na partycje został z góry ustalony, dane odpowiadające poszczególnym partycjom mogą być przechowywane w osobnych plikach. W przypadku konieczności migracji danych, partycja jest migrowana w całości, przez co nie ma konieczności losowego dostępu do danych w celu filtrowania danych, które mają zostać przeniesione. Więcej informacji na temat charakterystyk poszczególnych wersji algorytmu Consistent Hashing można znaleźć w rozdziale

11 1.4 Zapobieganie niezgodnościom danych Amazon Dynamo jest systemem rozproszonym, który musi sprostać realiom takim jak awarie sprzętu czy sieci. Awarie krótkotrwałe rozwiązywane mogą zostać przez mechanizm hinted-handoff (rozdział 1.5.1). Jednak w sytuacji, kiedy mamy do czynienia z awarią długotrwałą może zaistnieć niezgodność danych pomiędzy replikami, która nigdy nie zostanie naprawiona. Architekci Dynama zdecydowali się umożliwić okresowe bądź ręczne uruchamianie wyszukiwania i naprawy niezgodności pomiędzy replikami. Zastosowano rozwiązanie wykorzystujące drzewa haszujące Drzewa haszujące W celu okresowego sprawdzenia spójności danych między replikami i ewentualnej naprawy Amazon Dynamo używa drzew Merkla. Drzewo Merkla lub drzewo haszujące [3] to drzewiasta struktura danych, zawierająca informacje podsumowujące znacznie większe fragmenty danych (Rysunek 2) w postaci wartości funkcji haszującej, pozwalając w ten sposób na sprawdzenie ich poprawności. Kolejne węzły drzewa zawierają wartości funkcji haszującej swoich potomków. Pozwala to podczas porównania dwóch drzew sprawdzić, czy dane w poddrzewie są spójne. Takie same wartości odpowiednich węzłów dwóch drzew pozwalają przyjąć identyczność danych w poddrzewach. Wykrycie takiej sytuacji pozwala opuścić sprawdzanie poddrzew, a tym samym uniknięcie kosztownego przesyłania i porównywania samych danych. Rysunek 2 Schemat przedstawiający drzewo haszujące 8

12 Bardzo popularnym przypadkiem użycia drzewa haszującego są sieci peer to peer, ponieważ pozwala ono na precyzyjne zlokalizowanie przekłamań w danych i naprawy tylko uszkodzonego fragmentu, bez konieczności powtarzania całej transmisji. W celu wykrycia błędnych danych nie jest również konieczne przesyłanie całego drzewa wystarczy postępować zgodnie z algorytmem: 1. Komunikacja rozpoczynana jest od wysłania korzenia drzewa (jednoelementowa lista węzłów). 2. Węzeł inicjujący komunikację wysyła listę wartości funkcji haszującej na danym poziomie drzewa. 3. Węzeł docelowy porównuje to z lokalnymi wartościami drzewa i wysyła w odpowiedzi żądanie przesłania poddrzew odpowiadających węzłom w których wykryta została niezgodność. 4. Kroki 2 i 3 powtarzane są do momentu osiągnięcia liści drzewa 5. Węzeł, który zainicjował komunikację wysyła wartości odpowiadające liściom drzewa, w których wykryte zostały niezgodności. Rysunek 3 pokazuje, jak drzewo haszujące pozwala uniknąć wymiany większości bloków danych w celu naprawy uszkodzonych danych. Porównanie struktury obu drzew jednoznacznie określa, że uszkodzony został tylko blok odpowiadający oznaczonemu na czerwono liściowi drzewa. Pozostałe zaznaczone na czerwono węzły drzewa to węzły w których powstała niezgodność, spowodowana uszkodzonym blokiem danych. 9

13 Rysunek 3. Przykład użycia drzewa haszującego do wykrycia i naprawy różnic pomiędzy węzłami 1.5 Postępowanie w sytuacjach awaryjnych Hinted-handoff Hinted-handoff jest mechanizmem pozwalającym zwiększyć tolerancję awarii i utrzymać wysoką dostępność zapisu w systemie bazodanowym. Polega on na wykryciu sytuacji awarii węzłów, w których powinny zostać zapisane dane oraz przekazaniu rodzaju wskazówki dotyczącej danych, które nie mogą zostać zapisane do następnego węzła w pierścieniu. Wskazówka taka zostaje zapisana w oddzielnej tabeli i może zostać wykorzystana w momencie naprawy węzła do którego była dedykowana Read-repair Poza opisanym w rozdziale mechanizmem zegara wektorowego, do rozwiązywania konfliktów po stronie klienta Dynamo stosuje wbudowany mechanizm naprawy niespójności danych podczas odczytu, zanim jeszcze dane dotrą do klienta. Może tak się stać, kiedy mamy do czynienia z różnymi wersjami tych samych danych w różnych węzłach. Jeżeli wektory czasu pozwalają jasno określić przyczynowość pomiędzy wersjami, Dynamo zapisuje najnowszą znalezioną wersję we wszystkich węzłach i tę wersję zwraca klientowi. Taki sposób odczytu jest oczywiście bardziej skomplikowany i przez to wolniejszy. Stosunkowo 10

14 wolne odczyty są więc ceną, jaką użytkownik systemu płaci za możliwość bardzo szybkich zapisów. 1.6 Zastosowanie systemu Amazon Dynamo jest systemem, który od początku projektowany był w celu rozproszenia na wiele maszyn i osiągnięcia łatwej możliwości skalowania horyzontalnego. Zastosowane rozwiązania sprawiają, że skalowanie takie jest znacznie łatwiejsze w porównaniu z bazami oferującymi model relacyjny. Jednocześnie Amazon Dynamo zaniedbuje wiele aspektów oferowanych przez bazy relacyjne nie dostarcza możliwości transakcji oraz oferuje znacznie uboższy model danych i zapytań. Wymienione ograniczenia sprawiają, że wszelkie operacje wykonywane na danych jak i same dane powinny być tak zorganizowane, aby w możliwie najlepszy sposób niwelować ryzyko związane nietransakcyjnością Amazon Dynamo. Warto pamiętać, że nie jest możliwe użycie bazy takiej jak Amazon Dynamo w aplikacjach, w których, ze względu na znaczenie obsługiwanego przypadku biznesowego, niedopuszczalne jest osłabienie spójności danych. Przykładem mogą być aplikacje finansowe odpowiedzialne za transakcje na giełdach czy w bankach. Poza tym uboższy model danych i zapytań zmusza producentów aplikacji do obsłużenia wielu koniecznych operacji na danych po stronie klienta bazy. Najbardziej oczywistym zastosowaniem sytemu Dynamo są aplikacje, w których oczekiwany jest bardzo duży ruch, a jednocześnie możliwa jest osłabienie wymagań dotyczących transakcji. W przypadku systemu takiego jak sklep internetowy, Dynamo wydaje się doskonale pasować zarówno jako baza w systemie odpowiedzialnym za obsługę koszyka, jak i w podsystemach sklepu, takich jak np. moduł odpowiedzialny za logowanie ruchu klientów i sugerującego na podstawie zebranych danych kolejne produkty. Systemy te obsługują ogromną liczbę klientów i nieocenioną zaletą bazy Dynamo jest łatwość dodawania kolejnych maszyn do klastra. Dynamo potwierdziło swoją przydatność pozwalając na spełnienie wymagań skalowalności i dostępności największego sklepu internetowego na świecie. 11

15 2 Apache Cassandra 2.1 Podstawowe informacje Wprowadzenie Apache Cassandra jest rozproszoną bazą danych stworzoną na potrzeby serwisu Facebook i opisaną w pracy [4].Cassandra nie jest bazą przechowującą główne dane biznesowe w serwisie Facebook odpowiada ona jedynie za indeks wyszukiwarki wiadomości przychodzących. W 2008 roku kod Cassandry został otwarty, a projekt dołączył do inkubatora Apache [5]. Założeniem architektów systemu było stworzenie oferującego wydajny zapis, odpornego na awarie, liniowo skalowalnego produktu. Architektura systemu została w dużym stopniu zainspirowana projektami Amazon Dynamo [1] i Google BigTable [6]. Podsumowanie najważniejszych rozwiązań wraz z odnośnikami do odpowiednich rozdziałów pracy zawiera poniższa tabela. Problem Rozwiązanie Model danych Grupy kolumn (ang. Column family) Format zapisu danych na dysku SSTable Partycjonowanie danych Consistent Hashing 4.1 Krótkotrwałe awarie Hinted-handoff Długotrwałyme awariame powodujące Drzewa haszujące niezgodność danych między replikami Wykrywanie awarii - przyrostowe wykrywanie awarii Tabela1 Podsumowanie głównych problemów i ich rozwiązań zastosowanych przez Cassandrę Kolumna, wiersz, grupa kolumn Cassandra jest bazą wprowadzającą (podobnie jak Google BigTable) bogatszy model danych, niż robi to Amazon Dynamo. Poniżej przedstawione zostały podstawowe pojęcia związane z modelem danych zaproponowanym przez Cassandrę. Kolumna: para <nazwa, wartość> wraz ze znacznikiem czasu ustalanym przez klienta. Wiersz: zbiór kolumn, będących atrybutami jednego obiektu, encji, opisywanej przez dany wiersz. 12

16 Grupa kolumn (ang. column family): zbiór semantycznie podobnych wierszy. Nie musi być to zbiór wierszy o dokładnie takich samych kluczach kolumn pozwala to unikać zapisywania wartości null w przypadku kolumn o nieznanej wartości. Opisana struktura grupy kolumn jest właściwie dwuwymiarową mapą przedstawioną na rysunku Rysunek 4 Rysunek 4. Schemat grupy kolumn Za przykład danych ułożonych zgodnie z przedstawioną strukturą mogą posłużyć poniższe dane w formacie JSON [7]. Muzycy: Grupa Kolumn Jan Brzęczyszczykiewicz: Klucz wiersza jan@domena.pl Nazwa kolumny:wartość Instrument: keyboard Nazwa kolumny:wartość Andrzej Jakub: Klucz wiersza andrew@domena.pl Nazwa kolumny:wartość Samochody: Grupa kolumn WF1922: Klucz wiersza Marka: Ford Nazwa kolumny:wartość Model: Fiesta Nazwa kolumny:wartość Rok produkcji: 2008 Nazwa kolumny:wartość Kod 1. Przykład danych zorganizowanych w wiersze i kolumny Dodatkowym, nie przedstawionym powyżej aspektem jest to, że każda kolumna zawiera znacznik czasu (ang. timestamp), oznaczający datę ostatniej jej modyfikacji. Wartość ta nie 13

17 jest automatycznie dostarczana przez bazę danych, przeciwnie, każdy klient powinien dostarczyć tę wartość, wraz z żądaniem zapisu danych. Cassandra nie dostarcza możliwości zapytań według kryterium znacznika czasu, wartość ta jest wykorzystywana jedynie do rozwiązywania konfliktów po stronie serwera Nadkolumny Cassandra pozwala również na grupowanie powiązanych kolumn, tworząc w ten sposób dodatkowy wymiar nadkolumny (ang. Supercolumn). Po uwzględnieniu nadkolumn, wiersz przybierze postać jak na rysunku Rysunek 5 Rysunek 5. Schemat wiersza zawierającego nadkolumny. 2.2 Operacje zapisu i odczytu danych Uogólniony opis zapisu danych Węzeł w klastrze, otrzymując żądanie zapisu danych (insert, update, delete), najpierw zapisuje je sekwencyjnie do przechowywanego lokalnie na dysku dziennika (ang. commit log) Dziennik służy jako kopia bezpieczeństwa na wypadek awarii na jego podstawie dane zostają odzyskane po restarcie uszkodzonego węzła Poprawny zapis do dziennika stanowi minimum konieczne do uznania operacji zapisu za poprawną. 14

18 Zapis sekwencyjny jest szybki (brak operacji szukania pozycji, pod którą dane mają zostać zapisane), przez co zapis do dziennika nie jest dużym obciążeniem. Cassandra może dokonywać synchronizacji pamięci cache, reprezentującej ostatnie zmiany w dzienniku, w dwóch trybach okresowym (ang. periodic) i wsadowym (ang. batch). Okresowy tryb zapisu oznacza natychmiastowe potwierdzenie zapisu i okresowe wymuszanie zapisu dziennika na dysk. Zapis taki następuje w odstępach czasu konfigurowanych przez parametr commitlog_sync_period_in_ms (Domyślnie: ms). Oznacza to teoretyczną możliwość utraty danych jeżeli wszystkie repliki uległy awarii przed zapisem na dysku, w praktyce jest to zależne od zachowania wirtualnej maszyny Javy obsługującej serwer bazy danych. Zapis wsadowy oznacza, że zapis nie zostanie potwierdzony, zanim dane z dziennika nie zostaną zapisane do pliku dziennika na dysku. Aby uniknąć dostępu do dysku po każdym żądaniu, Cassandra oczekuje na kolejne polecenia zapisu i wykonuje je wsadowo. Maksymalny czas oczekiwania określony jest przez wartość parametru commitlog_sync_batch_window_in_ms określoną w milisekundach. Dwa tryby zapisu dziennika na dysk dają możliwość odzwierciedlenia tego, która z cech systemu: pewność zapisu czy szybkość odpowiedzi, jest dla użytkownika priorytetem. Cassandra podczas restartu odtwarza zawartość dziennika aby zapewnić odzyskanie potencjalnie utraconych danych. Po zapisie do dziennika, Cassandra zapisuje dane do przechowywanej w pamięci strukturach zwanej Memtable. Memtable jest pamięcią cache przechowującą wartości kolumn wraz z kluczem. Dane w Memtable są posortowane względem klucza. Każdej grupie kolumn odpowiada osobna struktura Memtable. Struktura Memtable jest zapisywana na dysk, gdy konieczne jest zwolnienie miejsca w pamięci, lub ilość zapisanych kluczy przekroczy konfigurowalny limit, ewentualnie po upływie określonego przez klienta czasu. Struktura Memtable zapisywana jest na dysk jako SSTable (więcej wrozdziale 2.2.4) Cassandra łączy pliki SSTable po przekroczeniu limitu (domyślnie 4) liczby nowo zapisanych plików (ang. Compaction). Zapobiega to nadmiernemu wzrostowi narzutu związanego z przeszukiwaniem wielu plików. 15

19 W skład danych zapisywanych na dysku wchodzą: plik danych, plik indeksu, plik filtru (więcej szczegółów w sekcji 2.2.3). Warto jeszcze raz podkreślić, że w przeciwieństwie do baz relacyjnych, zarówno zapis do dziennika jak i do SSTable nie zmienia istniejących już plików danych, dlatego nie wymaga odczytu danych i losowego dostępu do dysku. Dzięki temu Cassandra może osiągać bardzo dobry czas zapisu Uogólniony opis odczytu danych Pierwszą czynnością wykonywaną przez Cassandrę w odpowiedzi na żądanie odczytu danych jest sprawdzenie, czy oczekiwana wartość nie znajduje się w przechowywanej w pamięci strukturze Memtable. Jeżeli oczekiwana wartość nie została znaleziona w Memtable, oznacza to konieczność dostępu do danych zapisanych w SSTable na dysku.. Następujące operacje służą przyśpieszeniu operacji znalezienia i odczytu odpowiedniego klucza w SSTable: 1. Użycie filtru Blooma do ewentualnego wykluczenia istnienia poszukiwanego klucza w SSTable (patrz 2.2.6). 2. Użycie indeksu w celu szybkiego zlokalizowania pozycji klucza w pliku SSTable (patrz 2.2.5) Struktura katalogów i plików Poniższej przedstawiona została struktura katalogów zastosowana w Cassandrze. data saved_cache commitlog data columnfamily1... columnfamilyn Możemy zatem wyróżnić trzy główne katalogi: danych (data), dziennika (commitlog) oraz cache u (saved_cache). Katalog dziennika zawiera pliki dziennika nazwane w sposób unikalny, oznaczone znacznikiem czasu i usuwane zaraz po tym, gdy dane w nich znajdujące się trafią do docelowych plików danych. Katalog danych zawiera podkatalogi odpowiadające poszczególnym grupom kolumn. Każdy katalog grupy kolumn zawiera trzy podstawowe rodzaje plików: pliki danych, pliki indeksu i pliki filtru Blooma. 16

20 Plik danych zawiera dane ułożone w formacie SSTable (więcej w sekcji 2.2.4), dodatkowo skompresowane (domyślnie używany jest algorytm Snappy [8]). Plik indeksu zawiera posortowane klucze i pozycję w pliku danych, odpowiadającego każdemu kluczowi wiersza. (więcej w sekcji 2.2.5). Plik filtru metadane w postaci filtru Blooma (patrz rozdział 2.2.6) SSTable fizyczny sposób zapisu danych SSTable (Sorted String Table) to struktura danych wprowadzona w projekcie Google BigTable i z tego właśnie projektu zaczerpnęli inspirację twórcy Cassandry, decydując o sposobie zapisu danych na dysku. SSTable jest strukturą, w której dane zapisane są jako kolejne pary (klucz, wartość), posortowane według klucza. Ponieważ Cassandra wprowadza pojęcia wierszy i kolumn, dane zostały posortowane według klucza wiersza, a wewnątrz wiersza według klucza kolumny. Uproszczony model został przedstawiony na rysunku Rysunek 6. Rysunek 6 Model struktury SSTable Decyzja o niemodyfikowaniu danych w SSTable wynika z tego, że operacje dodawania danych do takiej struktury byłyby kosztowne oraz prowadziłyby do dodatkowej fragmentacji dysku. Zamiast modyfikowania SSTable podjęto decyzję o każdorazowym zapisie danych z pamięci lub dziennika do nowego pliku. W związku z tym jednej grupie kolumn może odpowiadać wiele plików SSTable. Pliki te są okresowo łączone w jeden tak, aby uniknąć sprawdzania zbyt wielu plików przy odczycie. Algorytm łączenia plików SSTable jest stosunkowo prosty (jest to analogiczne do łączenia posortowanych list), a sama operacja zapisu jest sekwencyjna, przez co dużo mniej kosztowna Indeksy Plik indeksu zawiera posortowane klucze i pozycję odpowiadającego im wiersza w pliku danych. Przedstawione zostało to na rysunku Rysunek 7. 17

21 Rysunek 7 Schemat pliku indeksu systemu Cassandra Odczyt danych przy użyciu indeksu polega na posłużeniu się indeksem do znalezienia odpowiedniej pozycji w pliku danych. Warto zwrócić uwagę na fakt, że klucze są posortowane, co umożliwia przeszukiwanie binarne, a plik indeksu jest zdecydowanie mniejszy od pliku danych, przez co przeszukiwanie indeksu jest znacznie szybsze. Po odnalezieniu odpowiedniej pozycji w pliku danych, następuje przeczytanie odpowiedniego miejsca w pliku danych, co zostało pokazane na Rysunek 8. Rysunek 8 Przykład mapowania pomiędzy indeksem a plikiem danych w systemie Cassandra Filtry Blooma Filtry Blooma stworzone w 1970 roku przez Burtona H. Blooma używane są do reprezentacji zbioru elementów pozwalającej na szybkie określenie przynależności elementu do zbioru. Poniżej przedstawione zostały podstawowe założenia i algorytm filtru: 18

22 wartość 0. m-bitowy wektor, w którym początkowo wszystkie bity ustawione są na niezależne funkcje haszujące przyjmujące wartości z zakresu zbiór reprezentowany przez filtr Dla każdego elementu wyznaczyć należy wartości, kolejno i ustawić odpowiadające im pozycje wektora na 1 (poszczególne bity mogą zostać ustawione na wartość 1 więcej niż raz). Wartość 0 i-tego bitu wektora oznacza więc, że nie istnieje element taki, że któraś z funkcji haszujących przyjmuje wartość i. Wykorzystując ten fakt możemy stwierdzić, że sprawdzenie przynależności elementu b do zbioru A polega na sprawdzeniu wartości bitów wektora na pozycjach wartość 0 któregokolwiek ze sprawdzanych bitów oznacza, że z całą pewnością element b do zbioru A nie należy. Jeżeli na każdej z pozycji wartość bitów wektora wynosi 1, możemy przypuszczać, że b należy do zbioru, jednak istnieje prawdopodobieństwo, że założenie to jest błędne (sytuacja określana jako false positive ). Wartości parametrów oraz powinny zostać dobrane w taki sposób, aby prawdopodobieństwo błędnego przypuszczenia istnienia elementu w zbiorze (ang. false positive ) było akceptowalnie niskie każde przypuszczenie, że element należy do zbioru, w praktyce powoduje próbę przeczytania takiego elementu. W przypadku błędnego przypuszczenia, oznacza to nadmiarowe i kosztowne wyszukiwanie elementu na dysku. W optymalnym dobraniu parametrów oraz pomóc może Formuła 1 określająca prawdopodobieństwo błędnego przypuszczenia przynależności elementu do zbioru -elementowego. Formuła 1. Prawdopodobieństwo błędnego przypuszczenia istnienia elementu w zbiorze w zależności od parametrów Filtru Blooma Więcej informacji na temat pochodzenia powyższego wzoru oraz tabela pomagająca dobrać konkretne wartości oraz znajduje się w pracy [9]. 19

23 2.3 Organizacja klastra, wymiana informacji pomiędzy węzłami Gossiper Podstawowe pojęcia Gossiper jest komponentem odpowiedzialnym za to, żeby każdy z węzłów, po zmianie stanu któregoś z nich, ostatecznie uzyskał informację o stanie pozostałych węzłów, włącznie z informacją o tych nieosiągalnych. Kluczowym zadaniem Gossipera jest cykliczne uruchamianie zadania (GossiperTask) inicjującego cykl wymiany wiedzy o stanie klastra pomiędzy węzłami. Zanim opisane zostaną rodzaje wiadomości wysyłanych przez GossiperTask i sposób ich wymiany, przedstawione zostaną podstawowe elementy określające stany węzła i klastra. Są one opisane następującymi strukturami danych: HeartBeatState składa się z numeru generacji i numeru wersji (odpowiednie nazwy w kodzie źródłowym to generation i versionnumber). Numer generacji pozostaje niezmieniony podczas normalnej pracy, pozwala na wyróżnienie sytuacji, kiedy mieliśmy do czynienia z restartem węzła właśnie wtedy jest inkrementowany. Numer wersji jest inkrementowany z każdą nową wiadomością. Jest on znacznikiem pozwalającym określić aktualność wiadomości wiadomość z większym numerem wersji jest bardziej aktualna. ApplicationState - Typ wyliczeniowy, określający możliwe rodzaje informacji o stanie węzła. (m.in. LOAD, SCHEMA) EndpointState reprezentuje stan pojedynczego węzła w klastrze. Składa się z numeru wersji (versionnumber) oraz mapy gdzie kluczem jest ApplicationState a wartością para (wartość stanu, numer wersji). EndpointStateMap Struktura przechowywana przez Gossiper, zawierająca stany (wartości typu EndpointState) wszystkich węzłów (włączając siebie samego), o których zdołał uzyskać informację. Mając przybliżoną wiedzę o danych przechowywanych przez Gossiper, możemy przejść do opisu samego cyklu wymiany informacji. Gossiper w celu propagowania informacji o stanie klastra, posługuje się trzema rodzajami wiadomości GOSSIP_DIGEST_SYN, 20

24 GOSSIP_DIGEST_ACK, GOSSIP_DIGEST_ACK2, reprezentowanymi przez klasy, odpowiednio: GossipDigestSyn, GossipDigestAck, GossipDigestAck Cykl wymiany komunikatów Uruchamiane okresowo zadanie GossiperTask inicjuje cykl wymiany komunikatów. Poniżej przedstawiony został przebieg takiego cyklu. Wysyłka wiadomości typu SYN Wiadomością inicjującą wymianę informacji, jest wiadomość typu GOSSIP_DIGEST_SYN. Zawiera ona listę obiektów typu GossipDigest, opisujących wiedzę na temat wszystkich aktualnie znanych przez wysyłającego węzłów w klastrze. Składowymi takiej informacji są: numer generacji, numer wersji oraz identyfikator opisywanego węzła. Dodatkowo wysyłane są informacje o klastrze, takie jak jego identyfikator oraz sposób jego partycjonowania. GossipDigestSyn{ clusterid='awsomecluster ', partioner='org.apache.cassandra.dht.randompartitioner', Digests=[GossipDigest[ :13:/ ]] } Kluczową rolę pełni tu lista gdigest, zawierająca dane typu GossipDigest w formacie : [numergeneracji:numerwersji:idwęzła] Przetwarzanie wiadomości typu SYN Węzeł, do którego kierowana jest wiadomość GOSSIP_DIGEST_SYN, uruchamia odpowiedzialny za jej przetworzenie komponent GossipDigestSynVerbHandler. Komponent ten jest odpowiedzialny za porównanie przychodzących informacji na temat poszczególnych węzłów z posiadanymi aktualnie przez lokalny Gossiper oraz podjęcie decyzji na temat sposobu przygotowania odpowiedzi. Warto zauważyć, że na etapie sprawdzania, wiadomość zwrotna jest tylko częściowo przygotowywana, a sama wysyłka odpowiedzi następuje dopiero po sprawdzeniu i agregacji informacji o wszystkich węzłach. W zależności od rezultatu porównań, zapada decyzja na temat sposobu przygotowania informacji zwrotnej: Jeżeli, dla danego węzła, przychodzący numer generacji jest większy od przechowywanego, oznacza to, że lokalna informacja nie wie nic o stanie węzła od czasu jego restartu. Tworzone zatem jest żądanie przysłania wszystkich znanych informacji na temat tego węzła. 21

25 Żądanie takie będzie miało postać: GossipDigest[ :0:/ ]. Kluczowy jest tu numer wersji równy 0, co oznacza mniej więcej tyle nie mam żadnej wiedzy na temat tej generacji, przyślij mi proszę wszystko co wiesz. W przypadku, gdy przychodzący numer generacji jest mniejszy od przechowywanego lokalnie, oznacza to że wysyłający żądanie węzeł ma nieaktualną informację na temat danego węzła po restarcie. W takiej sytuacji przyjmujący żądanie przygotowuje wiadomość, zawierającą wszystkie posiadane informacje na temat rozpatrywanego węzła. Oprócz numeru wersji i generacji będzie to mapa wartości stanów zapakowana w strukturze EndpointStateMap. W przypadku gdy lokalny numer generacji danego węzła odpowiada numerowi przychodzącemu w wiadomości GOSSIP_DIGEST_SYN porównywane są numery wersji. Gdy lokalny numer wersji jest większy, przygotowywana jest mapa wszystkich stanów oznaczonych numerem wersji większym od przychodzącej w komunikacie (takie stany nie istnieją lub są już nieaktualne w węźle, który wysłał przetwarzaną wiadomość, powinny być zatem uaktualnione). Tak powstała delta zostanie wysłana i pozwoli wyrównać stan wiedzy na temat danego węzła. Gdy lokalny numer jest wersji jest mniejszy, przygotowywane jest żądanie uaktualnienia, wszystkich wartości stanów, zmienionych później niż w maksymalnej znanej lokalnie wersji. Będzie ono wyglądało w następujący sposób: GossipDigest[ :555/ ] zakładając, że maksymalny znany lokalnie numer wersji to 555. Wiadomość typu ACK Ostatecznie, zebrane w opisany wyżej sposób informacje agregowane są w wiadomości typu GOSSIP_DIGEST_ACK, mającej postać: GossipDigestAck{ gdigests=<lista żądań> epstatemap=<lista uaktualnień stanów> } Lista żądań to lista obiektów typu GossipDigest określających, który numer generacji i wersji jest znany wysyłającemu wiadomość żądanie dotyczy prośby o przesłanie wszystkich informacji o stanach węzła oznaczonych wyższym numerem wersji. Lista 22

26 uaktualnień jest listą obiektów typu EndpointStateMap, określających stany, które powinny zostać uaktualnione po stronie odbiorcy powyżej zdefiniowanego komunikatu. Wiadomość typu ACK2 W odpowiedzi na wiadomość typu ACK jest wysyłana wiadomość typu ACK2 zawiera ona listę aktualnych stanów żądanych w liście w komunikacie ACK. GossipDigestAck2{ epstatemap=<lista uaktualnień stanów> } Lista uaktualnień stanów dotyczy stanów żądanych przez komunikat typu GOSSIP_DIGEST_ACK. Wiadomość ACK2 kończy cykl wymiany komunikatów. Po jego zakończeniu, węzły, które wymieniły się komunikatami na temat stanu klastra mają ten sam stan wiedzy Sposób wyboru węzłów do synchronizacji. Każdy węzeł Cassandry jest odpowiedzialny za okresowe inicjowanie komunikatów typu SYN między węzłami. W każdym cyklu węzeł inicjujący wymianę wiadomości, wybiera węzły docelowe kierując się następującymi kryteriami: 1. Wysyłany jest jeden komunikat ACK do losowo wybranego węzła, który zgodnie z aktualną wiedzą jest aktywny. 2. Wysyłany jest jeden komunikat ACK do losowo wybranego węzła, który zgodnie z aktualną wiedzą jest nieosiągalny. Decyzja taka jest podejmowana w celu wykrycia poprawy sytuacji tego węzła w klastrze. 3. Istnieje jeszcze jeden specjalny typ węzła: seed. Węzły tego typu są węzłami otrzymującymi informacje od wszystkich pozostałych węzłów klastra. Jest to sposób na zapewnienie, że w każdej chwili czasu pewna grupa węzłów będzie zawierała kompletne dane powstałe podczas wymiany informacji. W przypadku, gdy wybrany w pierwszym kroku aktywny węzeł nie jest seedem, następuje wysyłka do węzła typu seed. 23

27 2.4 Wykrywanie awarii Wprowadzenie Wykrywanie awarii jest jednym z kluczowych zagadnień w teorii systemów rozproszonych. Jednym z przypadków, kiedy wykrycie awarii jest kluczowe, jest problem uzgadniania wartości (Consensus) pomiędzy elementami systemu rozproszonego. Problem ten nie może być rozwiązany deterministycznie [10] w systemie asynchronicznym, jeżeli dopuścimy możliwość awarii nawet jednego z procesów systemu. Wynika to z niemożności odróżnienia systemu uszkodzonego od odpowiadającego z dużymi opóźnieniami. Wprowadzenie do problemu uzgadniania wartości dodatkowego systemu wykrywającego awarię, działającego jako rodzaj wyroczni określającej, czy dany proces jest uszkodzony, pozwala na znalezienie deterministycznego rozwiązania [11]. Biorąc pod uwagę ogrom czynników występujących w systemach rozproszonych, nie można spodziewać się istnienia w praktyce idealnego systemu wykrywającego awarię. Rozważania na temat akceptowalnych kompromisów doprowadziły do powstania klasy ostatecznie doskonałych (ang. Eventually perfect) systemów wykrywających awarię P. System wykrywający awarię klasy P (ostatecznie doskonałych) to system spełniający własności: Silna kompletność (ang. Strong completness) Po pewnym skończonym czasie, uszkodzony proces jest podejrzany przez wszystkie poprawnie działające procesy. Ostateczna silna spójność (ang. Eventual Strong consistency) Po pewnym skończonym czasie, każdy poprawnie działający proces nie jest podejrzany przez żaden z pozostałych poprawnie działających procesów. System klasy P jest wystarczający do rozwiązania problemu uzgadniania wartości [12] przyrostowe wykrywanie awarii Podejście klasyczne Klasyczny sposób zgłaszania awarii w systemach rozproszonych, polega na ustawianiu zmiennej typu logicznego określającej stan systemu, a więc daje jedynie możliwość określenia dwuwartościowego stanu fragmentu systemu (działa nie działa). Przyrostowe 24

28 wykrywanie awarii idzie krok dalej, określając wartość z ciągłego przedziału, oznaczającą szansę, że monitorowany proces jest uszkodzony Zarys architektury Implementacja systemu wykrywającego awarię po stronie odbiorcy może zostać podzielona na podstawowe moduły: Monitorujący. Zbiera informację o dostępności monitorowanych procesów, zwyczajowo będą to wiadomości kontrolne lub opóźnienia odpowiedzi na żądania. Interpretujący. Interpretuje informację zebraną podczas monitorowania i wykorzystuje ją np. do określenia, czy monitorowany proces powinien być podejrzany o awarię. Podejmujący akcję. Akcje są wyzwalane jako odpowiedź na podejrzenie awarii. Akcje zazwyczaj są implementowane poza modułem wykrywającym awarie. Są one silnie związane z logiką aplikacji. Podejście takie jest o wiele bardziej elastyczne, pozwala odseparować monitorowanie stanu systemu od jego interpretacji i podjęcia akcji w przypadku awarii. Określenie szansy awarii, zamiast jednoznacznego orzekania o jej istnieniu bądź nie, pozwala na różne reakcje na zaistniałą sytuację różnym podsystemom. Wprowadzenie poziomów abstrakcji i jasne określenie zakresu ich odpowiedzialności pozwala, na luźne powiązanie pomiędzy modułami monitorującym a reagującymi na awarię oraz pozwala na łatwiejsze modyfikacje i wprowadzanie nowych modułów do istniejącego systemu Definicja System przyrostowo wykrywający awarie można zdefiniować jako system, który zwraca wartość powiązaną z każdym spośród monitorowanych procesów. Uproszczony model zakłada, że dla dwóch procesów p (monitorowany) i q (monitorujący) system wykrywający zwraca wartość określoną funkcją: Zwracana wartość określa szansę z jaką monitorowany proces jest uszkodzony, czyli w jakim stopniu może być on podejrzewany (ang. suspected). 25

29 Funkcja powinna [12] spełniać własności: 1) Jeżeli proces p jest uszkodzony, to wartość dąży do nieskończoności, gdy czas t z zmierza do nieskończoności 2) Jeżeli proces p jest uszkodzony, to istnieje czas, po upływie którego rośnie monotonicznie. 3) Proces p jest uszkodzony wtedy i tylko wtedy gdy jest ograniczony z góry podczas wykonywania w nieograniczonym czasie. 4) Jeżeli proces p działa poprawnie wtedy dla dowolnego istnieje takie, że. Mając funkcję, spełniającą powyższe warunki możemy określić sposób jej wykorzystania do określenia poprawności monitorowanego procesu. Niech proces monitorujący proces zarządza dwoma dynamicznymi progami: oraz zainicjowanych arbitralnie wybraną wartością większą od 0. Możemy wtedy zdefiniować dwie operacje wyzwalane przez zmieniającą się wartość funkcji S-Przejście: Kiedy wartość przecina w górę wartość górnego progu, proces q zwiększa wartość do wartości +1 i zaczyna lub kontynuuje traktować proces p jako uszkodzony (podejrzewać go, ang. suspect). T-Przejście: Kiedy wartość przecina w dół wartość dolnego progu, proces q uaktualnia wartość do wartości i zaczyna traktować proces p jako działający poprawnie Tak zdefiniowany system jest systemem klasy P [12] przyrostowe wykrywanie awarii Definicja systemu przyrostowo wykrywającego awarię jest generyczna i abstrakcyjna, nie narzuca sposobu wyboru funkcji a jedynie własności jakie funkcja taka powinna spełniać. W tej sekcji przedstawiony zostanie przykład algorytmu -failure detector [12], definiującego funkcję spełniającą wszelkie określone w poprzedniej sekcji kryteria, wraz ze sposobem jej wykorzystania w implementacji systemu wykrywającego awarię. 26

30 Funkcja oznaczana tutaj jako przyjmuje wartość: Formuła 2 Sposób wyznaczania funkcji oznaczającej prawdopodobieństwo awarii gdzie: aktualny czas czas otrzymania ostatniej wiadomości kontrolnej (ang. heartbeat) prawdopodobieństwo, że wiadomość zostanie otrzymana więcej niż jednostek czasu po poprzednim. Zastanawiając się nad znaczeniem powyższego zapisu można dojść do wniosku, że mając daną wartość oraz zakładając, że podejrzewamy proces gdy, wtedy prawdopodobieństwo, że system popełnia błąd w wykrywaniu awarii jest równe 10%, 1%, 0,1% dla wartości odpowiednio: 1, 2, 3. Metoda określania wartości jest stosunkowo prosta, wszystko dzieje się w trzech fazach.: 1. Próbkowanie przychodzących wiadomości kontrolnych. Proces monitorujący zapisuje odebrane wiadomości wraz z czasem ich otrzymania zapisywane są w oknie przesuwnym (ang. Sampling window) o z góry ustalonym rozmiarze. Za każdym razem, kiedy odebrany zostaje kolejna wiadomość, jest ona zapisywana do okna. Jednocześnie dane dotyczące najstarszej próbki są usuwane. Dane zawarte w oknie pozwalają, na łatwe określenie odstępów czasu, pomiędzy kolejnymi próbkami. Dodatkowo, na bieżąco uaktualniane są wartości sumy wszystkich odstępów oraz ich sumy kwadratów. Pozwala to na efektywne wyznaczania wartości średniej oraz wariancji. 2. Następnie, zebrane próbki wykorzystywane są do określenia dystrybucji czasów pomiędzy kolejnymi komunikatami. 3. Ostatnim krokiem jest wykorzystanie otrzymanej dystrybuanty do określenia wartości funkcji zakładając normalny rozkład prawdopodobieństw. Zarys mechanizmu został przedstawiony na rysunku Rysunek 9 powstałym na podstawie pracy [12]. 27

31 Rysunek 9 Mechanizm -przyrostowego wykrywania awarii. Idea zbieranie kolejnych próbek służących do wyznaczania wartości średniej i wariancji jest bardzo prosta i intuicyjna. Kluczowym szczegółem implementacji przedstawionego na rysunku Rysunek 9 mechanizmu jest przyjęcie odpowiednich do danej sytuacji założeń dotyczących rozkładu prawdopodobieństwa. Autorzy [12] proponują przyjąć, że czasy pomiędzy kolejnymi próbkami rozkładają się zgodnie z rozkładem Gaussa. Przy takim założeniu, aby policzyć wartość należy obliczyć wartość formuły Podejście zastosowane w systemie Cassandra Mimo, że [12] sugeruje użycie rozkładu normalnego, do szacowania prawdopodobieństw czasu otrzymania kolejnego komunikatu, twórcy systemu Cassandra zrezygnowali z tego rozkładu na rzecz rozkładu wykładniczego [13]. Uzasadnili to tym, że rozkład taki lepiej odpowiada naturze kanału komunikacyjnego Gossipera. Ostatecznie funkcja prawdopodobieństwa, będąca dystrybuantą rozkładu wykładniczego, przyjęta przez Cassandrę ma postać: 28

32 Łatwo jest zauważyć, że podstawiając tę wartość do wzoru Formuła 2 i dokonując trywialnych przekształceń otrzymujemy: Otrzymana postać wprawdzie nie pokazuje bezpośrednio związku z wybranym rozkładem wykładniczym, jednak upraszczając formułę uzyskano znaczną optymalizację wykonywanych obliczeń. Wykrywanie awarii w Cassandrze polega na sprawdzeniu, czy wartość funkcji sprawdzanego węzła przekracza wartość parametru phi_convict_threshold, którego domyślna wartość wynosi 8, może natomiast być zmieniona przez użytkownika z jednym zastrzeżeniem jej wartość musi się mieścić w granicach przedziału [5,16]. Pozwala to sterować prawdopodobieństwem granicznym, określającym awarię w granicach od do. Rysunek 10 przedstawia główne elementy wchodzące w skład mechanizmu wykrywania awarii w systemie Cassandra. Poniżej opisana została odpowiedzialność każdego z elementów z punktu widzenia wykrywania awarii. 29

33 Rysunek 10 Główne komponenty komunikujące się podczas wykrywania awarii. GossiperTask Po każdym cyklu wysyłania komunikatów, klasa ta wywołuje metodę GossiperadoStatusCheck odpowiedzialną za sprawdzenie stanu węzłów wchodzących w skład pierścienia poprzez interpretacjęjuż zebranych informacji (patrz Samplingwindow poniżej). Gossiper pośredniczy komunikacji między uruchamianym okresowo zadaniem GossiperTask a obiektem klasy FailureDetector. Dostarcza metodę dostatuscheck oraz przechowuje mapę stanów wszystkich znanych elementów systemu - endpointstatemap. FailureDetector Klasa odpowiedzialna za obliczenie wartości na podstawie odpowiedniego okna przesuwnego oraz jej interpretację (metoda interpret wywoływana przez Gossiper). Po podjęciu decyzji, czy wykryto awarię, następuje ewentualne uaktualnienie stanu przechowywanego w endpointstatemap. SamplingWindow (Okno przesuwne) Obiekt klasy ArrivalWindow odpowiedzialny za przechowywanie historii odstępów czasu pomiędzy kolejnymi wiadomościami otrzymanymi od węzła, któremu odpowiada każdemu węzłowi systemu odpowiada 30

34 dedykowany obiekt okna przesuwnego. Klasa ArrivalWindow dostarcza metodę obliczającą wartość. VerbHandler obiekt typu GossipDigestAckVerbHandler lub GossipDigestAck2VerbHandler lub GossipDigestSynVerbHandler odpowiedzialny za podjęcie akcji po odebraniu, od innych węzłów systemu, wiadomości typu odpowiednio: ACK, ACK2, SYN. Pośrednio (deleguje do Gossipera) odpowiada on za bieżące uaktualnianie okna przesuwnego, oraz mapy endpointstatemap, jeżeli zachodzi taka potrzeba. EndpointStateMap mapa zawierająca najbardziej aktualną wiedzę na temat stanów wszystkich znanych węzłów systemu. 2.5 Partycjonowanie i replikacja danych W chwili pisania pracy Cassandra stosuje podstawową wersję algorytmu Consistent Hashing (patrz rozdział 4.1). Oznacza to, że każdy węzeł jest odpowiedzialny za jedną partycję (oprócz ewentualnych kopii bezpieczeństwa). Sposób podziału danych pomiędzy węzły polega na ustawieniu w pliku konfiguracyjnym każdego węzła, wartości tokena (parametr o nazwie initial_token) wyznaczającego punkt podziału pierścienia danych. W ten sposób, każdy węzeł będzie odpowiedzialny za klucze, których hasze są mniejsze od wartości tokena, ale większe od najbliższego, mniejszego tokena innego węzła. W przypadku uruchamiania nowego klastra takie rozwiązanie sprawdza się świetnie pozwala na rozłożenie obłożenia pomiędzy węzły w sposób dokładnie taki, jakiego życzy sobie administrator. W miarę zmian w klastrze uwidaczniają się problemy takiego rozwiązania np. dodanie do zbalansowanego klastra węzła powoduje przejęcie przez niego części odpowiedzialności ale tylko za ruch w jednym węźle. Oznacza to, że wszystkie pozostałe węzły będą stosunkowo znacznie mocniej obciążone. W celu uniknięcia tego typu zagrożeń, producenci bazy danych Cassandra zalecają zwiększać ilość węzłów w klastrze, nie pojedynczo, ale poprzez podwojenie ilości węzłów w klastrze i ustawiając nowe punkty podziału odpowiednio w środku pomiędzy istniejącymi, co pozwoli na utrzymanie zrównoważonego podziału partycji. Podwojenie ilości maszyn z pewnością nie jest rozwiązaniem na które każda firma i instytucja może sobie pozwolić. Mając na uwadze niedogodności związane z zastosowaną, najprostszą wersją algorytmu, osoby odpowiedzialne za rozwój Cassandry zdecydowały się na uruchomienie projektu [14], mającego na celu zmianę aktualnego sposobu partycjonowanie poprzez dodanie 31

35 obsługi wirtualnych węzłów opisanych w rodziale 4.2 stosując losowy wybór punktów podziału (patrz rozdział 4.3.1) 2.6 Zastosowanie systemu Cassandra podobnie jak Amazon Dynamo pozwala na łatwe skalowanie systemu poprzez dodawanie nowych węzłów. Zastosowane rozwiązania sprawiają jednocześnie, że wiele cech dostępnych w relacyjnych bazach danych, takich jak transakcyjność, blokowanie przy zapisie czy relacje między danymi, jest niedostępnych. Cassandra oferuje rozwiązania takie jak read-repair czy drzewa haszujące, które pozwalają w pewnym stopniu niwelować ewentualne niespójności danych. Ważną cechą systemu jest bardzo wysoka w porównaniu z bazami relacyjnymi szybkość zapisu danych. Powyższa charakterystyka, w połączeniu z opisanymi w tym rozdziale rozwiązaniami, sugeruje, że Cassandra najlepiej sprawdzi się w systemach w których przetwarzane są bardzo duże ilości danych, gdzie przeważają operacje zapisu, a jednocześnie brak wsparcia dla transakcji i relacji pomiędzy danymi nie dyskwalifikuje rozwiązania. Przykładem takich systemów będą systemy logujące ruch użytkowników w celu sugerowania reklam. Kolejnym przykładem problemu, do którego rozwiązaniu Cassandra wydaje się pasować idealnie, jest przetwarzanie w czasie rzeczywistym sms-ów w bardzo dużych kampaniach zorganizowanych w krótkim okresie czasu (np. podczas emisji popularnego programu telewizyjnego). 32

36 3 CouchDB CouchDB [15] jest kolejnym przykładem nierelacyjnej bazy danych, odgrywającej znaczącą rolę na rynku. Jest to baza zapewniająca wysoką skalowalność, odporność na awarie oraz brak sztywnego modelu danych. Brak sztywnego modelu danych nie oznacza bynajmniej, że jest to baza typu klucz-wartość. CouchDB jest systemem, zorientowanym na przechowywanie dokumentów (patrz 3.1.1). Spośród możliwości i własności charakteryzujących CouchDB warte wymienienia z pewnością są: Interfejs typu REST [16] co pozwala na prostą integrację w zasadzie z dowolnym językiem programowania. Narzędzie do zarządzania bazą razem z interfejsem użytkownika dostępnym przez przeglądarkę internetową. Możliwość automatycznej przyrostowej replikacji pomiędzy węzłami systemu. Możliwość budowania zapytań typu map/reduce [17]. Łatwość instalacji na różnych platformach od serwerów po urządzenia mobilne Model danych CouchDB jest systemem zorientowanym na przechowywanie dokumentów (ang. Document database, document-oriented database). W systemach tego typu dokument stanowi podstawowe pojęcie i jest on jednostką danych zapisywaną i odczytywaną przez bazę danych. Sposób reprezentacji dokumentu nie jest tu własnością kluczową, najpopularniejsze formaty to JSON [7], XML [18], BSON [19]. Dokumenty są samoopisującymi się (brak tu z góry narzuconej struktury, schematu danych) hierarchicznymi strukturami danych. Mogą one składać się z map, kolekcji oraz wartości typu prostego. Dokumenty jednej tabeli są zazwyczaj są w pewien sposób podobne do siebie wynika to z natury problemów biznesowych, jednak nie muszą one mieć identycznej struktury i nic nie powstrzymuje użytkownika od zapisywania kompletnie różnych dokumentów niejako obok siebie. Każdy dokument jest zapisywany pod unikalnym kluczem, co jest bardzo podobne do rozwiązań typu klucz-wartość. O bazie zorientowanej na przechowywanie dokumentów możemy myśleć jako o bazie typu klucz-wartość, z tą różnicą, że wartość w tym przypadku ma w pewnym sensie przewidywalną strukturę i format. Określony format przechowywanej wartości z jednej strony zmniejsza elastyczność co do sposobu przechowywania danych, z drugiej jednak 33

37 pozwala na wprowadzenie udogodnień takich jak widoki (ang. view) będące w zasadzie rodzajem indeksu ze względu na konkretne pole dokumentu. 3.2 Sposób organizacji danych B-drzewa B-drzewo (ang. B-tree) [20] jest strukturą danych będącą zrównoważonymi posortowanym drzewem. Cechą charakterystyczną jest to, że każdy węzeł może mieć wiele (nawet tysiące) kluczy oraz potomków. Takie podejście pozwala na wydajne wykorzystanie struktury w pracy z dyskami twardymi, które standardowo podczas odczytu dostarczają duży fragment danych stronę. W zależności od rodzaju danych, węzły drzewa przechowują klucze wraz z wartością lub klucze wraz ze wskaźnikiem do danych mu odpowiadających. B- drzewa umożliwiają wyszukiwanie, dostęp sekwencyjny, wstawianie oraz usuwanie w czasie logarytmicznym. Każdy węzeł B-drzewa zawiera b (wartość ograniczana z góry i z dołu w zależności od potrzeb) posortowanych kluczy. Z każdym kluczem K powiązany jest jeden potomek będący korzeniem poddrzewa zawierającego wszystkie klucze o wartościach mniejszych od K. Dodatkowo węzeł posiada potomka, który odpowiada kluczom większym od maksymalnego jego klucza. Daje nam to b+1 potomków przypadających na węzeł drzewa. Schemat przedstawiający przykładowe B-Drzewo przedstawiony został na rysunku. Rysunek 11 Przykładowe B-drzewo B+drzewa B+drzewo jest modyfikacją opisanego powyżej B-drzewa w taki sposób, że dane zapisywane są jedynie w liściach drzewa, liście natomiast znają wskaźnik do kolejnego (zgodnie z kierunkiem sortowania) liścia. Aby to osiągnąć każdy węzeł musi zawierać kopię 34

38 odpowiadającego mu klucza z węzła rodzica. Oznacza to pewną nadmiarowość, jednak zysk z takiego sposobu zapisu danych jest ogromny sekwencyjne czytanie liści oznacza odczyt posortowanych danych bez konieczności powrotów do węzłów rodziców, co znacznie przyspiesza zapytania dotyczące zakresu kluczy. Schemat przedstawiający przykładowe B+drzewo przedstawia Rysunek 12. Kluczowymi różnicami w porównaniu z poprzednim schematem są wskaźniki pomiędzy sąsiednimi liśćmi drzewa oraz fakt, że klucze o wartościach z korzenia drzewa (10,20,30) zostały powtórzone w liściach. Rysunek 12 Przykładowe B+drzewo Modyfikacje zastosowane w CouchDB Ciekawą modyfikacją B+drzewa w stosunku to standardowej formy opisanej w rozdziale jest zastosowany w CouchDB [21], [22] tryb dopisywania do danych bez ich modyfikacji (ang. Append-only). Oznacza to, że zmiany dodawane są na końcu pliku danych, natomiast usuwanie polega na dopisaniu do pliku danych nowych informacji o węźle po usunięciu klucza, zamiast natychmiastowego jego fizycznego usunięcia. Każdy zapis do liścia drzewa powoduje stworzenie uaktualnionej kopii w nowym miejscu na dysku. Dalej następuje kopiowanie wraz z koniecznymi modyfikacjami węzłów wchodzących w skład ścieżki prowadzącej do korzenia oraz ewentualnie węzłów, które w związku z przeprowadzanym zapisem muszą ulec zmianie. W ten sposób zostaje na nowo zbudowany fragment struktury drzewa, który ulegnie modyfikacji. Do tego momentu proces czytający dane ciągle widzi starą strukturę drzewa i nie jest świadomy przeprowadzanego w tle zapisu proces taki nie otrzymuje informacji o wszystkich aktualnie przeprowadzanych zapisach, przez co aktualność odczytu nie jest pełna. Jest to jednak kompromis pozwalający uniknąć blokowania podczas odczytu, przez co zwiększa się dostępność systemu. Ostatnim krokiem podejmowanym przez algorytm zapisu jest uaktualnienie korzenia nowo stworzony 35

39 korzeń staje się aktualnym korzeniem drzewa, przez co zmiany w nowopowstałych węzłach stają się widoczne dla wszystkich procesów. Opisaną powyżej procedurę przedstawioną na przykładzie wstawienia klucza o wartości 8 do drzewa o maksymalnej liczbie kluczy w węźle równej 4, pokazuje Rysunek 13. Rysunek 13 Przykład dodawania nowego klucza (wart. 8) do B+drzewa stosowanego w systemie CouchDB W wyżej przedstawionym opisie modyfikacji danych i ich zatwierdzaniu warto wspomnieć o sposobie, w jaki baza uzyskuje informację o nowym korzeniu drzewa. Informacje takie zapisane są w początkowej części pliku danych nagłówku (ang. header). W momencie, kiedy wszystkie węzły powiązane z daną modyfikacją, zostały przygotowane, może nastąpić nadpisanie nagłówka. Ciekawym rozwiązaniem jest podwójne zapisanie nagłówka, co ma chronić przed sytuacjami awaryjnymi. Ponieważ zapis nagłówka następuje sekwencyjnie, przynajmniej jedna jego część jest prawidłowa, co z jednej strony chroni przed utratą informacji o strukturze drzewa, z drugiej wprowadza pomijalną ze względu na niewielki rozmiar nagłówka nadmiarowość ilości danych na dysku. Uniknięcie konieczności modyfikowania danych pozwala osiągnąć kilka znaczących zalet: 1. Szybkie zapisy ponieważ zapis polega jedynie na dopisaniu do pliku danych bez jego modyfikacji, nie ma konieczności poszukiwania miejsca w którym dane powinny zostać zapisane, wystarczy dopisać nowe dane na końcu pliku. 36

40 2. Plik danych pełni jednocześnie funkcję dziennika (ang. commit log), nie ma konieczności okresowego synchronizowania dziennika z plikiem danych jak ma to miejsce np. w systemie Cassandra. 3. Dane pozostałe na dysku pozwalają w stosunkowo prosty sposób odtworzyć historię zapisów. Jednocześnie tworzenie kopii bezpieczeństwa z danej chwili czasu jest proste proces tworzący taką kopię może zignorować zapisy powstałe w momencie jego tworzenia jako, że nie zmienią one struktury drzewa po której ten proces się porusza. 4. Awaria podczas zapisu nie jest problemem zapis nie zmienia aktualnego stanu bazy, przez co nie może go uszkodzić. 3.3 Zastosowanie systemu CouchDB jest w pewnym sensie kompromisem pomiędzy bazami relacyjnymi, a bazami typu klucz-wartość. Wprawdzie model danych nie jest w pracy z CouchDB sztywno ustalony, jednak sam fakt, że pracujemy z dokumentem, pozwala na bogatszy sposób tworzenia zapytań jak i indeksów. Z drugiej strony brak sztywno ustalonego modelu danych jest znaczącym ułatwieniem w projektach, w których ustalenie takiego modelu byłoby problematyczne i nienaturalne. W projektach takich model oferowany przez bazy relacyjne nie tylko nie pomaga w zarządzaniu danymi, ale jest wręcz utrudnieniem, wymuszając sztuczny sposób organizowania danych. Luźne określenie modelu danych jest również znaczącym ułatwieniem w projektach, które są na etapie początkowym, model danych nie jest z góry znany, a jego zmiany są w dokonywane na bieżąco. Mając na uwadze wymienione powyżej cechy, CouchDB wydaje się doskonałą alternatywą dla baz relacyjnych w systemach zarządzającymi dokumentami o niejednorodnej strukturze. W przypadku takich dokumentów model relacyjny nie zdaje egzaminu. Bardzo wygodnym sposobem zapisu takich dokumentów są formaty xml czy json, do pracy z którymi system CouchDB został stworzony. CouchDB jest również wartą rozważenia alternatywą w projektach typu startup. W projektach takich kierunek rozwoju aplikacji jest często wyznaczany na bieżąco na podstawie reakcji użytkowników na aplikację w obecnym stanie. CouchDB jako baza zorientowana na zapisywanie dokumentów jest bardzo elastyczna w kontekście zmian modelu danych, przez co doskonale nadaje się do tego typu projektów. Jednocześnie wsparcie dla 37

41 przyrostowej replikacji sprawia, że CouchDB może z powodzeniem spełniać wymagania projektu w momencie, kiedy staje się on bardziej dojrzały, a liczba jego użytkowników szybko rośnie. 38

42 4 Consistent Hashing 4.1 Consistent Hashing zarys algorytmu Consistent Hashing jest algorytmem zaproponowanym w pracy [23]. Pozwala on na organizację danych w klastrze, w rodzaj pierścienia i przypisanie odpowiednim węzłom odpowiedzialności, za poszczególne fragmenty tego pierścienia. Prostym sposobem organizacji danych w pierścień jest przypisanie im (ich kluczom) wartości funkcji hashującej z pewnego zakresu [0, MAX]. Niech: - ilość węzłów w klastrze. - identyfikator węzła. Załóżmy, że każdemu węzłowi i przypiszemy wartość tokena: takie, że. Możemy wtedy założyć, że każdy węzeł będzie odpowiedzialny za zakres kluczy, tworzących partycje takie, że: ].. Dla i>1 Najprostszy wariant rozłożenia danych pomiędzy węzłami został przedstawiony na rysunku Rysunek 14. Rysunek pokazuje cztery węzły (A, B, C, D), które dzielą między sobą odpowiedzialność (kolor węzła odpowiada kolorowi części pierścienia, za którą odpowiada), za odpowiednie partycje danych podzielone względem klucza w zależności od jego wartości po haszowaniu. 39

43 Rysunek 14 Pierścień danych i ich podział pomiędzy węzły w algorytmie Consistent Hashing Consistent Hashing przewiduje również wsparcie dla replikacji danych. Najprostszym sposobem replikacji jest ustalenie, że kopie danej partycji będą przechowywane w kolejnych węzłach. Myśląc o przykładzie takiego zjawiska, możemy wyobrazić sobie klaster czterech węzłów jak na rysunku Rysunek 14. Załóżmy, że dane będą posiadały jedną kopię bezpieczeństwa. Aby to zrobić, wystarczy umieścić kopię danej partycji w węźle odpowiedzialnym za kolejną partycję(zgodnie z ruchem wskazówek zegara). Tak więc węzeł A, oprócz przechowywania swojej głównej partycji, będzie zawierał kopię bezpieczeństwa partycji z węzła D, węzeł B kopię bezpieczeństwa partycji z węzła A, itd. Taki sposób rozmieszczenia danych sprawia, że w przypadku awarii węzła, węzeł posiadający kopię danych z uszkodzonego węzła może przejąć jego odpowiedzialność. 4.2 Wirtualne węzły Przydzielenie odpowiedzialności za jedną, dużą partycję poszczególnym węzłom, sprawia, że wszelkie reorganizacje węzła stają się kłopotliwe i znacząco obciążające. Prostym sposobem zmniejszenia tych niedogodności jest podział fizycznie istniejącej maszyny na węzły wirtualne, a tym samym na kilka mniejszych partycji. Mając kilka partycji możemy znacznie łatwiej przekazać tylko daną partycję nowoprzybyłemu do klastra węzłowi. W ten sposób nowy węzeł może łatwo odebrać część zadań pozostałym węzłom, utrzymując równomierne obciążenie węzłów klastra. Zastosowanie wirtualnych węzłów pozwala również na replikację odpowiednich fragmentów danych z jednej maszyny do kilku różnych węzłów. Podzielenie replikowanych danych na kilka maszyn sprawia, że w przypadku awarii obciążenie przypadające na uszkodzony węzeł rozkłada się pomiędzy wiele maszyn. 40

44 4.3 Przegląd modyfikacji algorytmu Consistent Hashing Wariant A: Losowy wybór punktów podziału Jednym z możliwych sposobów podziału klastra na partycje i przydziału odpowiedzialności za poszczególne partycje jest podział w sposób losowy. Aby to zrobić wystarczy przyjąć, że każdemu węzłowi przypisanie zostanie N losowo wybranych tokenów. Dalej, sposób podziału na partycje na podstawie wartości tokenów, pozostaje bez zmian tzn. każdemu tokenowi T, odpowiada partycja. P=[T,T ), gdzie T jest pierwszym, mniejszym od T tokenem w klastrze. Wyjątek stanowi najmniejszy token w klastrze, któremu odpowiada partycja: P=, gdzie jest największym tokenem w klastrze. Hashing Rysunek 15 Przykładowy pierścień danych podzielony używając wariantu A algorytmu Consistent Wariant B: Partycje równej wielkości Podział pierścienia danych na partycje równej wielkości polega na ustaleniu równej długości przedziałów dzielących zakres funkcji haszującej [0, MAX] i przypisaniu każdemu z nich partycji wirtualnego węzła. Mając określony taki podział, można w sposób odpowiedni do wymagań określić zakres odpowiedzialności poszczególnych maszyn za węzły wirtualne. Dysponując przestrzenią danych podzieloną na wiele równej wielkości partycji można manewrować danymi w taki sposób, aby dane zostały rozłożone w oczekiwany sposób. Najczęstszym sposobem rozmieszczania partycji jest równomierny podział pomiędzy wszystkie węzły klastra. Można jednak wyobrazić sobie maszyny o różnych parametrach 41

45 wchodzące w skład jednego klastra intuicyjnym sposobem wykorzystania tych różnic jest przydzielenie mocniejszym maszynom odpowiednio więcej obsługiwanych partycji. Rysunek 16 przedstawia opisaną wyżej sytuację podziału pierścienia danych, na równe partycje. Hashing. Rysunek 16 Przykładowy pierścień danych podzielony używając wariantu B algorytmu Consistent Wariant C: Losowy wybór punktów podziału propozycja usprawnienia Po bliższym przyjrzeniu się wariantowi A algorytmu doszedłem do wniosku, że nie ma powodu dzielić klastra w sposób zupełnie losowy. Zaproponowane przeze mnie usprawnienie polega na wyborze partycji z najbardziej obciążonych węzłów i podziale ich w sposób taki, aby dołączający węzeł zawierał średnią ilość danych przypadającą na węzeł w klastrze. Jednocześnie dołączający węzeł przejmowałby odpowiedzialność od węzłów najbardziej obciążonych, dzieląc ich największe partycje. Poniższy pseudokod przedstawia wersję C algorytmu: wszystkiewęzły.sort();//sortowanie malejące względem całkowitej przechowywanej ilości danych for(węzeł: wszystkiewęzły){ partycjadopodziału = Węzeł.największaPartycja(); partycjadopodziału.podziel(oczekiwanawielkośćnowejpartycji, identyfikatornowegowęzła) } 4.4 Opis programu symulującego różne warianty Aby porównać własności opisanych w poprzednich rozdziałach wariantów rozłożenia danych w pierścieniu stworzyłem program, który symuluje węzły wchodzące w skład systemu 42

46 bazodanowego. Program ten umożliwia decyzję o sposobie podziału pierścienia danych na węzły w jeden z opisanych wyżej sposobów. Interfejs dostarczony przez symulator umożliwia określenie ilości wirtualnych węzłów przypadających na maszynę w przypadku wariantów A oraz C. Pozwala on również parametryzować ilość partycji, na które zostanie podzielony pierścień w przypadku wariantu B. Porównanie wariantów algorytmu Consistent Hashing nie jest zadaniem łatwym, ponieważ ich tuning odbywa się przez modyfikację parametrów, różniących się w zależności od wariantu. Dodatkowo o jakości i przydatności algorytmu decyduje jego użytkownik, który w zależności od potrzeb może oczekiwać na przykład zbalansowanego klastra lub też raczej łatwości w zarządzaniu nim, kiedy może sobie pozwolić na zakup większej ilości maszyn. Problemy związane z jednoznacznym określeniem głównego parametru decydującego o przydatności algorytmu postanowiłem w symulatorze uwzględnić następujące wartości: Zbalansowanie klastra Suma danych przeczytanych z dysku podczas przenoszenia partycji z jednego węzła do drugiego od początku działania systemu. Sumaryczne ilość danych przesłana przez sieć podczas przenoszenia partycji z jednego węzła do drugiego Użyte narzędzia Symulator został napisany w języku Java [24] z wykorzystaniem narzędzi: Maven [25] narzędzie ułatwiające zarządzaniem zależnościami w projekcie. Intellij IDEA [26] zintegrowane środowisko programistyczne JFreeChart [27] biblioteka służąca to tworzenia wykresów. Użyte w pracy wykresy (również diagramy przedstawiające węzły rysunki Rysunek 16 oraz Rysunek 15) zostały stworzone przy użyciu symulatora, używając właśnie tej biblioteki. Junit [28] standardowe narzędzie języka java służące do tworzenia testów jednostkowych. Testy stworzone w programie służą upewnieniu się, że implementacje algorytmów działają poprawnie, a tym samym mierzone wartości są rzeczywiście tym co zmierzyć zamierzałem. 43

47 Mockito [29] biblioteka umożliwiająca tworzenie obiektów typu mock, ułatwiająca testy jednostkowe z wykorzystaniem JUnit Zarys architektury Reprezentacja symulowanych obiektów Kluczową część symulatora stanowią abstrakcyjna klasa Ring definiująca interfejs pierścienia. Jej której kluczowe metody to: add metoda tworząca nowy węzeł o zadanym identyfikatorze i dodająca go do pierścienia w sposób odpowiedni dla danej implementacji pierścienia loadpernodes metoda zwracająca mapę określającą, jaką część danych pierścienia stanowią dane poszczególnych węzłów. Klasy implementujące klasę Ring: RandomlyPartitionedRing, FixedPartitionedRing, UpgradedRandomPartitionedRing odpowiadają, odpowiednio wersjom A, B, C algorytmu Consistent Hashing opisanych w niniejszej pracy. Każdy pierścień składa się z partycji reprezentowanych przez klasę abstrakcyjną Partition, której główne metody to: getnodeid metoda zwracająca identyfikator węzła do którego dana partycja należy gettoken metoda zwracająca token definiujący partycję, zgodnie z opisem z rozdziału 4.1. size metoda zwracająca ilość wartości funkcji haszującej, za które odpowiada partycja. Klasy implementujące klasę abstrakcyjną Partition to: FixedPartition i TokenBasedPartition i reprezentują one partycję w pierścieniu. Różnica pomiędzy nimi polega na tym, że TokenBasedPartition jest używana w wersjach A oraz C algorytmu, dlatego musi ona wspierać podział na dwie partycje do czego służy metoda split. 44

48 Diagram głównych klas domeny symulatora przedstawia poniższy rysunek. Rysunek 17 Diagram głównych klas domeny symulatora Pomiar wartości istotnych dla eksperymentu Ważnym elementem symulatora jest interfejs Metric dostarczający metodę move,której implementacja zakłada, że będzie ona podliczała wszystkie konieczne statystyki związane z przenoszeniem partycji pomiędzy węzłami. Pozostałe metody interfejsu to metody udostępniające dotychczas zebrane statystyki. Obiekt typu Metric jest przekazywany jako parametr konstruktora obiektu typu Ring. Skonstruowany w ten sposób obiekt pierścienia uaktualnia wszystkie statystyki wraz z postępującymi modyfikacjami. 4.5 Wyniki eksperymentów Wszystkie eksperymenty w tej części zostały przeprowadzona poprzez symulowanie klastra którego początkowa ilość węzłów wynosiła 5, a następnie dodano do niego kolejno 35 węzłów Zrównoważenie klastra Zrównoważenie klastra jest jedną z jego najważniejszych charakterystyk, ponieważ pozwala określić jak rozłożone są pomiędzy węzłami dane a tym samym związane z nimi żądania. Oczywiste jest, że węzły mocniej od pozostałych obciążone są potencjalnym wąskim gardłem całego systemu. Zwiększenie opóźnień odpowiedzi do nich kierowanych wpływa na obraz wydajności całego systemu. Wykresy Rysunek 18,..., Rysunek 23 pokazują zależności różnych wersji algorytmu Consistent Hashing od ilości partycji. Wartości przedstawione na osi Y oznaczają ilość 45

49 danych w węźle, w stosunku do wartości średniej. Na przykład wartość 2 oznacza ilość danych dwukrotnie większą od średniej ilości danych przypadających na jeden węzeł. Porównanie wersji A i C z wersją B jest utrudnione ponieważ ilość partycji w dwóch pierwszych jest parametryzowana per węzeł, podczas gdy wersja B algorytmu określa ilość wszystkich partycji klastra. Spróbuję jednak zastanowić się nad sumaryczną ilością partycji klastra, użytą w wersjach A oraz C, w zależności od ilości węzłów i na tej podstawie porównywać wyniki trzech algorytmów. Analizując wykresy rozważmy konfigurację algorytmów A i C używającą 3 partycje na węzeł oraz wersję B algorytmu używającą 90 partycji na klaster. Porównanie takie jest o tyle uczciwe, że stan klastra przedstawiony na wykresach (40 węzłów) używa 120 partycji w całym klastrze w wersji A i C, czyli więcej niż w przypadku wersji B. Liczba partycji w przypadku wersji A i C była jednak zależna od liczby węzłów i przez większą część cyklu życia klastra była mniejsza od 90 (dopóki wielkość klastra nie osiągnęła 30 węzłów). Na wykresach widać, że przy założonej powyżej konfiguracji odchylenie ilości danych po zastosowaniu algorytmu A (około 0.55) znacznie przewyższa wyniki otrzymane w przypadku wersji B i C algorytmu Consistent Hashing (odpowiednio 0.2 i 0.1). Dużo bardziej wyraźne różnice wartości widać na wykresach przedstawiających ilość danych w największych węzłach klastra. Odczyt danych dla ustalonej konfiguracji pokazuje wartości około: 2,5; 1,4; 1,1 dla odpowiednio wersji A, B, C algorytmu. Jeżeli zastanowimy się nad znaczeniem tych liczb, dojdziemy do wniosku że w przypadku A, w przeprowadzonej symulacji największy węzeł przechowywał średnio 2,5 razy danych więcej niż średnia ilość danych w węźle. Taka różnica w stosunku do średniej jest z jednej strony czymś akceptowalnym, co na pewno nie dyskwalifikuje wersji A algorytmu, z drugiej strony takie rozłożenie danych może powodować zaniepokojenie. Administrator systemu używającego wersji A algorytmu Consistent Hashing z pewnością musi być świadomy większego niebezpieczeństwa przeciążenia niektórych węzłów i powinien mieć gotowy plan reakcji na tego typu sytuację. Analizowane wykresy pokazują, że wszystkie trzy wersje algorytmu umożliwiają konfigurację w sposób pozwalający osiągnąć oczekiwane zrównoważenia systemu kosztem zwiększenia liczby partycji. Więcej partycji oznacza zwiększenie rozmiaru ich metadanych. Nie jest to problemem w kontekście ilości zajmowanego na dysku miejsca. Konfigurując system należy mieć jednak na uwadze, że metadane partycji muszą być uaktualniane 46

50 pomiędzy węzłami. Duża liczba partycji w połączeniu z dużą liczbą klastrów wymieniających między sobą informacje o nich może mieć znaczący wpływ na obciążenie sieci. Rysunek 18 Rezultat eksperymentów Rysunek 19 rezultat eksperymentów 47

51 Rysunek 20 Resultat eksperymentów Rysunek 21 Rezultat eksperymentów Rysunek 22 Rezultat eksperymentów 48

52 Rysunek 23 Rezultat eksperymentów Analiza zależności zachowania klastra od konfigurowalnych parametrów Przedstawione w tym podrozdziale wykresy użycia dysku i sieci, przedstawiają je w abstrakcyjnych jednostkach. Przyjęte zostało założenie przedstawienia odczytów z dysku oraz operacji wysyłania danych przez węzły, które przekazują część swoich danych nowo przybyłym do klastra węzłom. Założyłem również, że po dodawaniu kolejnego węzła, średnia ilość danych na węzeł jest taka sama. Założenie to można uzasadnić tym, że decyzja o rozszerzeniu klastra jest zazwyczaj podejmowana wraz ze wzrostem obciążenia. Wersja B Ciekawym ćwiczeniem, pomagającym w zrozumieniu znaczenia konfiguracji poszczególnych algorytmów będzie analiza wykresów użycia dysku, użycia sieci i zbalansowania klastra dla pojedynczych uruchomień symulatora z różnymi wartościami konfigurowalnych parametrów. Rysunek 24 pokazuje zbalansowanie klastra obsługiwanego przez wersję B algorytmu dla różnych liczb partycji w klastrze. Aby zrozumieć kształt wykresu w różnych konfiguracjach należy zastanowić się nad sposobem, w jaki algorytm dzieli partycje pomiędzy węzły stara się on podzielić partycje po równo pomiędzy węzły, tzn. aby liczba partycji między dowolnymi węzłami różniła się co najwyżej o 1. Oznacza to, że im więcej partycji znajduje się w klastrze, tym ewentualna różnica jednej partycji pomiędzy dwoma węzłami gra mniejszą rolę i klaster jest bliższy idealnemu zbalansowaniu. Analogiczne zależności widać w przypadku analizy wykresów użycia sieci oraz dysku (Rysunek 25, Rysunek 26). Zwiększenie liczby partycji, przybliża podział do ciągłego, co powoduje, 49

53 że dane wybrane do przeniesienia pomiędzy węzłami mogą zostać wybrane bardziej równomiernie niezależnie od liczby węzłów. Obrazuje to zdecydowanie gładszy wykres w przypadku konfiguracji z największą liczbą partycji na obu wspomnianych rysunkach. Wartym uwagi jest też identyczny wygląd wykresów użycia sieci i dysku. Wynika to z założenia, że logiczna partycja pierścienia będzie równoznaczna z istniejącym fizycznie plikiem na dysku. Przy takim założeniu przeniesienie partycji będzie równoznaczne ze skopiowaniem odpowiedniego pliku przez sieć. Pozwala to uniknąć przeszukiwania dysku w celu znalezienia odpowiednich kluczy, które należy przenieść. Przyjęte założenie jest możliwe do zrealizowania dzięki temu, że podział klastra na partycje jest z góry ustalony i nie ulega zmianom wraz z dodawaniem węzłów. Jest to znacząca przewaga wersji B algorytmu nad wersjami A oraz C. Rysunek 24 Rezultat eksperymentów Rysunek 25 Rezultat eksperymentów 50

54 Rysunek 26 Rezultat eksperymentów Wersja A Wykresy przedstawione na rysunkach Rysunek 27 oraz Rysunek 28 pokazują użycie odpowiednio dysku i sieci przez poszczególne węzły podczas jednego z uruchomień symulatora. Wykresy są niejako potwierdzeniem obserwacji zależności średniego zbalansowania klastra od ilości partycji przedstawionej w rozdziale Zaobserwowałem tam, że większa liczba partycji w węźle powoduje utrzymanie lepiej zbalansowanego klastra. Operacje przeprowadzane w celu utrzymywania dobrze zbalansowanego klastra to operacje rozłożone równomiernie i przewidywalnie w miarę dodawania kolejnych węzłów. Poniższe wykresy dla większej ilości partycji mają dużo mniejsze skoki, są znacznie bardziej płaskie co oznacza, że węzły klastra poddawane był znacznie bardziej wyrównanym obciążeniom w porównaniu do tych w klastrach skonfigurowanych na małą liczbę partycji w węźle. Interesujące jest porównanie wartości na wykresach użycia sieci oraz dysku. Ilość danych, które musiały być odczytane z dysku okazuje się być znacząco większa od ilości danych przesłanych przez sieć. Jest to spowodowane tym, że partycja nie jest przesyłana w całości, a w celu jej podziału konieczne jest skanowanie całej partycji, często znacznie większej od jej części przeznaczonej do przesłania. 51

55 Rysunek 27 Rezultat eksperymentów Rysunek 28 Rezultat eksperymentów Wersja C Rysunek 29 pokazuje zbalansowanie klastra w jednym z uruchomień symulacji wersji C algorytmu. Widać, że wszystkie trzy konfiguracje pozwoliły osiągnąć równomierne rozłożenie danych w klastrze, co potwierdza obserwacje z rozdziału mówiące o zadowalających charakterystykach wersji C. Wykres ten pozwala jednocześnie jeszcze raz bezpośrednio porównać różne opcje konfiguracji algorytmu C i stwierdzić, że zwiększanie liczbypartycji na węzeł nie wnosi znaczącej poprawy zbalansowania klastra. Jednocześnie rysunki Rysunek 30 i Rysunek 31 pokazują, że ilość danych czytanych z dysku znacząco przewyższa ilość danych przesłanych w sieci podobnie jak w wersji A 52

56 algorytmu, wynika to z konieczności skanowania partycji w celu znalezienia danych do przesłania. ` Rysunek 29 Rezultat eksperymentów Rysunek 30 Rezultat eksperymentów 53

57 Rysunek 31 Rezultat eksperymentów 4.6 Porównanie Powyższa analiza pokazuje, że wszystkie trzy porównywane algorytmy zachowują się w sposób zadowalający. Porównanie tego, jak dobrze równoważą one obciążenie klastra skłania mnie do stwierdzenia, że wersja A znacząco odstaje od wersji B i C. Porównując wersję B i C widać niewielką przewagę wersji C. Decydując się na którąś z opisanych wersji należy zdecydować o liczbie partycji w klastrze w zależności od wielkości klastra, którą przewidujemy osiągnąć wraz z rozwojem systemu. Trzeba pamiętać, że zbyt dużo partycji, których metadane są regularnie wymieniane pomiędzy węzłami, może znacząco obciążyć sieć i wpłynąć na wydajność systemu. W związku z tym, należy mieć na uwadze, że: Liczba partycji w wersjach A oraz C systemu rośnie liniowo wraz ze wzrostem liczby węzłów decydując się na tę wersję niezbędna jest analiza pozwalająca określić optymalną liczbę partycji w węźle. Liczba partycji w wersji B jest stała, trzeba jednak pamiętać, że zbyt mała powoduje duże różnice w obciążeniu węzłów. W skrajnym przypadku, kiedy liczba partycji jest mniejsza od liczby węzłów, niemożliwe może okazać się dodanie kolejnych węzłów. Warto również przypomnieć o przewadze algorytmu B polegającej na możliwości kopiowania partycji w całości bez ich przeszukiwania. Zmniejszenie obciążenia dysku z tego wynikające może okazać się bezcenne w chwilach dużego obciążenia systemu. Modyfikacja zaproponowana w wersji C znacząco poprawia charakterystyki klastra ją implementującego. Oczywiście, algorytm ten nie ma na celu osiągnąć charakterystyk 54