Bigtable Rozproszony system pamięci

Transkrypt

1 Bigtable Rozproszony system pamięci Janina Mincer-Daszkiewicz Systemy rozproszone MSUI, II rok

2 Materiały i rysunki zaczerpnięto z następujących źródeł Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, Rebert E. Gruber, Bigtable: A Distributed Storage System for Structured Data, firma Google, OSDI 2006 Artykuł: Prezentacja: slides.pdf 2

3 Inne źródła Kamil Anikiej, prezentacja na seminarium z Systemów Rozproszonych Praca magisterska Tomasza Wekseja, Niezawodność w rozproszonych systemach bazodanowych Apache Hadoop, HDFS, Hbase Gemius, MooseFS, Gemius Bigtable 3

4 Wprowadzenie Rozproszony system pamięci do przechowywania danych o zadanej strukturze, które mogą osiągać bardzo duże rozmiary (petabajty przechowywane na tysiącach serwerów typu off-the-shelf) Cele projektowe: do wielu różnych zastosowań (Google Earth, Google Finance, web indexing), skalowalność, wysoka wydajność, wysoka dostępność Przypomina bazę danych, ale nie wspiera w pełni modelu relacyjnego 4

5 Model danych Bigtable to wielowymiarowy słownik, rzadki, rozproszony, trwały, posortowany Słownik jest indeksowany za pomocą klucza wiersza, klucza kolumny i stempla czasowego; każda wartość w słowniku jest nieinterpretowaną tablicą bajtową. (row: string, column: string, time: int64) string 5

6 Model danych Webtable przechowuje strony webowe (nazwa wiersza to odwrócony URL) Rodzina kolumn contents przechowuje zawartość strony (trzy wersje, ze stemplami t 3, t 5 i t 6 ), anchor teksty odsyłaczy do strony (po jednej wersji) z dwóch serwisów (więc dwie rodziny); inny przykład: language: ID (zawartość to język strony) 6

7 Model danych Webtable Klucze wierszy są dowolnymi napisami (do 64 KB) Każdy odczyt lub zapis z kluczem pojedynczego wiersza jest atomowy Zakres wierszy w tablicy jest dzielony dynamicznie Każdy zakres wierszy nosi nazwę tabletu, jest jednostką 7 rozpraszania i równoważenia obciążenia

8 Model danych Webtable Klucze w kolumnach są grupowane w zbiory zwane rodzinami kolumn, które stanowią podstawową jednostkę kontroli dostępu Trzeba utworzyć rodzinę kolumn nim zacznie się zapisywać dane Klucz kolumny jest tworzony zgodnie ze składnią: family: qualifier Kontrola dostępu oraz liczenie obciążenia dysku i pamięci są wykonywane na poziomie rodzin kolumn 8

9 Model danych Webtable Każda komórka w Bigtable może zawierać wiele wersji tych samych danych Stemple czasowe (64-bitowe liczby całkowite) są przydzielane przez Bigtable lub aplikacje klienta Wspiera dwa zestawy ustawień na rodzinę kolumn, żeby automatycznie odśmiecać wersje, ostatnie n wersji lub najnowsze wersje 9

10 API - Pisanie Kod w C++, operacje w ramach Apply są realizowane atomowo 10

11 API - Czytanie Obiekt scanner umożliwia iterację po wszystkich odsyłaczach w wierszu 11

12 API - inne Wsparcie dla transakcji dotyczących jednego wiersza (czytanie aktualizacja pisanie); aktualnie brak wsparcia dla transakcji obejmujących wiele wierszy Wsparcie dla skryptów dostarczanych przez użytkownika (pisanych w języku Sawzall) wykonywanych w przestrzeni adresowej serwera Wsparcie dla współpracy z MapReduce Bigtable może być używane jako źródło danych wejściowych i jako miejsce na dane wynikowe 12

13 Związek Bigtable z innymi usługami Bigtable korzysta z GoogleFS do przechowywania logów i plików z danymi Dane Bigtable są przechowywane w google owym formacie plików SSTable. SSTable zawiera ciąg bloków (zwykle wielkości 64 KB) oraz blok indeksowy (za ostatnim blokiem danych). Bigtable korzysta z Chubby (rozproszony zarządca blokad) m.in. do zapewnienia, że jest tylko jeden aktywny zarządca, do odszukiwania serwerów tabletów, do przechowywania schematu danych i list kontroli dostępu 13

14 Implementacja Bigtable ma trzy główne składowe: biblioteka dołączana do każdego klienta jeden zarządca wiele serwerów tabletów Serwery tabletów mogą być dynamicznie dodawane lub usuwane z klastra Zadania zarządcy: przydział tabletów do serwerów, monitorowanie dostępności serwerów, równoważenie obciążenia, odśmiecanie plików w GoogleFS Zadania serwera tabletów: zarządzanie zbiorem tabletów (od 10 do tysiąca tabletów), obsługa żądań odczytu i zapisu tabletów, rozbijanie za dużych tabletów na mniejsze (rozmiaru MB) Większość klientów w ogóle nie komunikuje się z zarządcą tabletów (informację o położeniu tabletów dostarcza Chubby) 14

15 Implementacja położenie tabletu Trzy-poziomowa hierarchia analogiczna do tej z B + - drzew do przechowywania informacji o położeniu tabletów 15

16 Implementacja położenie tabletu 2 Każdy wiersz tabletu METADATA przechowuje ok. 1 KB danych, przy założeniu, że jego rozmiar to 128 MB, mamy 2 17 pozycji w bloku indeksowym,czyli łącznie można zaadresować 2 34 tabletów, czyli łącznie 2 34 *2 7 *2 20 bajtów w 128 MB tabletach Biblioteka po stronie klienta buforuje położenie tabletów. Jeśli brak informacji w schowku, to potrzebne są trzy odczytu po sieci (więcej w sytuacji niepoprawnych danych). Biblioteka czyta pozycje z wyprzedzeniem W tablicach METADATA są także trzymane logi zdarzeń dotyczących tabletów 16

17 Implementacja przypisanie tabletu Każdy tablet jest przypisany w danej chwili do jednego serwera tabletu, informację o nim przechowuje zarządca Serwer tabletu podczas startu pobiera blokadę do unikatowego pliku w katalogu Chubby ego; utrata tej blokady oznacza, że serwer przestał działać. Gdy ten plik ginie, serwer wyłącza się, dopóki jest, serwer próbuje odzyskać blokadę Zarządca jest odpowiedzialny za wykrywanie sytuacji, gdy serwer tabletu przestaje działać; cyklicznie odpytuje serwer o status blokady; jeśli nie może się połączyć lub dowiaduje się o utracie blokady, to sam próbuje założyć blokadę i jeśli się uda, to ją usuwa, a tablety z tego serwera oznacza jako nieprzypisane 17

18 Implementacja przypisanie tabletu 2 Gdy zarządca rozpoczyna pracę, musi rozpoznać bieżące przypisanie tabletu nim może je zmienić: zakłada unikatową blokadę zarządcy przegląda katalog z informacją o serwerach komunikuje się z żyjącymi serwerami, żeby odtworzyć listę przypisanych tabletów przegląda tabelę METADATA by poznać pełną listę tabletów i odtworzyć listę tych nieprzypisanych Zbiór istniejących tabletów z zmienia się tylko wtedy, gdy tabela jest tworzona lub usuwana (to inicjuje zarządca) oraz podczas rozbijania dużego tabletu na mniejsze (to inicjuje serwer tabletu podczas commit informacja trafia do tabeli METADATA, zawiadamiany jest zarządca) 18

19 Reprezentacja tabletu Obsługa tabletu 19

20 Obsługa tabletu 2 Zakomitowane zmiany trafiają do logu (rekordy redo), ostatnie są przechowywane w buforze w pamięci, starsze w kolejnych plikach SSTable. Żeby odtworzyć tablet, serwer czyta metadane (listę plików SSTable i zbiór punktów redo, które są wskaźnikami do logów zawierających dane); czyta indeksy plików SSTable, rekonstruuje bufor w pamięci wykonując wszystkie zakomitowane zmiany od punktów redo Operacja zapisu: sprawdzenie uprawnień (Chubby), zapis do logu, zakomitowany zapis do bufora w pamięci Operacja odczytu: sprawdzenie uprawnień (Chubby), wykonanie na połączonym widoku plików SSTable i bufora w pamięci (tworzenie widoku jest efektywne, bo oba zbiory są posortowane leksykograficznie) 20

21 Scalanie Mniejsze scalanie (ang. minor compaction) gdy bufor w pamięci przekroczy ustalony rozmiar, jest konwertowany do formatu SSTable i zapisywany do GoogleFS cel: zmniejsza zużycie pamięci, zmniejsza ilość danych, które trzeba odczytać z logu podczas odtwarzania po awarii efekt: powstaje nowy plik SSTable Scalanie (ang. merging compaction) odczytuje się zawartość kilku plików SSTable oraz bufora z pamięci i tworzy nowy plik SSTable cel: zmniejszenie liczby plików SSTable Większe scalanie (ang. major compaction) scalanie polegające na tym, że wszystkie SSTablice są przepisywane do jednej dane usunięte ostatecznie znikają z systemu 21

22 Grupy lokalności Ulepszenia Kompresja Buforowanie dla poprawienia wydajności odczytów Filtry Blooma Implementacja logu Przyspieszenie odtwarzania tabletu Zbadanie odporności na zmiany 22

23 Wydajność Klaster Bigtable z N serwerami tabletów Serwery tabletów skonfigurowano do użycia 1 GB pamięci i zapisu do komórek GoogleFS składających się z 1786 maszyn z 400 dyskami GD IDE N maszyn klienckich generowało obciążenie BigTable użyte w tych testach. Każda maszyna ma dwurdzeniowy procesor Opteron 2GH, dość pamięci do przechowania zbioru roboczego wszystkich wykonywanych procesów i jedno połączenie Ethernetowe Zarządca, serwery tabletów, testowi klienci i serwery GoogleFS wykonują się na tym samym zbiorze maszyn R to liczba kluczy wierszy Bigtable biorących udział w teście R dobrano tak, że każdy benchmark odczytywał lub zapisywał około 1 GB danych z serwera tabletu 23

24 Wydajność Rate per tablet server Aggregate rate Liczba 1000-bajtowych wartości czytanych/zapisywanych na sekundę 24

25 Atrybuty tabel stosowanych w praktyce 25

26 Wnioski Dlaczego zawsze relacyjna baza danych? Projekt sprawdził się w praktyce, gdyż Bigtable jest używane przez wiele produktów Google a Opłaca się czasem zbudować własne rozwiązanie problemu przechowywania danych 26