Implementacja – przypisanie tabletu

Bigtable
Rozproszony system pamięci
Janina Mincer-Daszkiewicz
Systemy rozproszone
MSUI, II rok
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ł:
http://students.mimuw.edu.pl/SR-MSUI/04-bigtable/bigtable-osdi06.pdf
Prezentacja:
http://students.mimuw.edu.pl/SR-MSUI/04-bigtable/bigtable-osdi06slides.pdf
2
Inne źródła
•
Kamil Anikiej, prezentacja na seminarium z Systemów
Rozproszonych
http://students.mimuw.edu.pl/SR/SR-MONO/BigTable.pdf
•
Praca magisterska Tomasza Wekseja, Niezawodność w
rozproszonych systemach bazodanowych
•
Apache Hadoop, HDFS, Hbase
•
Gemius, MooseFS, Gemius Bigtable
3
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
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
Model danych
• Webtable – przechowuje strony webowe (nazwa wiersza to
odwrócony URL)
• Rodzina kolumn contents przechowuje zawartość strony (trzy
wersje, ze stemplami t3, t5 i t6), 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
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
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ą
8
wykonywane na poziomie rodzin kolumn
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
API - Pisanie
Kod w C++, operacje w ramach Apply są
realizowane atomowo
10
API - Czytanie
Obiekt scanner umożliwia iterację po
wszystkich odsyłaczach w wierszu
11
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
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
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 100 – 200
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
Implementacja – położenie tabletu
• Trzy-poziomowa hierarchia analogiczna do tej z B+drzew do przechowywania informacji o położeniu
tabletów
15
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 217 pozycji w bloku indeksowym,czyli
łącznie można zaadresować 234 tabletów, czyli łącznie
234*27*220 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
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
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
Obsługa tabletu
• Reprezentacja tabletu
19
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
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
21
• dane usunięte ostatecznie znikają z systemu
Ulepszenia
•
•
•
•
•
•
•
Grupy lokalności
Kompresja
Buforowanie dla poprawienia wydajności odczytów
Filtry Blooma
Implementacja logu
Przyspieszenie odtwarzania tabletu
Zbadanie odporności na zmiany
22
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
Wydajność
Rate per tablet server
Aggregate rate
Liczba 1000-bajtowych wartości czytanych/zapisywanych
na sekundę
24
Atrybuty tabel stosowanych w praktyce
25
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