R - Technologie Przetwarzania Danych

Transkrypt

Zarządzanie danymi w chmurze
Cloud Databases
Nowe potrzeby przetwarzania danych
• Eksploatacja pojedynczych aplikacji baz danych o
miliardach użytkowników oraz o milionach
(dziesiątkach milionów) równoległych sesji
(Amazon, Google, Facebook)
• Wydajna realizacja zadań przetwarzających
olbrzymie wolumeny danych (petabajty i
eksabajty danych) – Big Data, hurtownie danych
• Ekonomiczna dzierżawa zasobów
obliczeniowych dla milionów klientów
Przetwarzanie w chmurze
Odpowiedzią na te wymagania jest przetwarzanie danych w
chmurze.
Charakterystyka chmur obliczeniowych w stosunku do centrów
obliczeniowych, data gridów, DDBMS, itd.:
• automatyzacja zarządzania infrastrukturą sprzętowo-programową,
• zwiększona odporność na awarie,
• iluzja nieograniczonej mocy obliczeniowej,
• anonimowość lokalizacji obliczeń,
• niższe koszty utrzymania,
• dynamiczna skalowalność dla pojedynczych aplikacji w górę i w
dół,
• model ekonomiczny opłat - opłata za używanie zasobów:
pay-as-you-go (płacisz tylko kiedy korzystasz),
• model dostępu: usługi obliczeniowe *aaS, a nie dzierżawa
infrastruktury IT.
Przetwarzanie jako usługa
Oprogramowanie
jako usługa
użytkownik
Platforma jako
usługa
programista
Infrastruktura
jako usługa
administrator
Wady utrzymywania własnej infrastruktury IT
• Przesłanki przetwarzania w chmurze są głównie natury
ekonomicznej. Posiadanie własnych kompletnych rozwiązań
informatycznych ma szereg wad:
– duże koszty inwestycyjne,
– duże koszty utrzymania,
– duże zużycie energii, przy niewielkim wykorzystaniu
zasobów komputerowych,
– problemy z awariami sprzętowymi i programowymi,
– wysoki poziom nadwyżki mocy przetwarzania.
zasoby
własna infrastruktura IT
brak mocy
posiadana moc
niewykorzystana
moc
usługi obliczeniowe
Wady utrzymywania własnej infrastruktury IT
Przykładowa jednostka organizacyjna zatrudniająca 1700
pracowników korzystających z infrastruktury IT:
• średnie zapotrzebowanie na moc obliczeniową w godzinach
pracy stanowiło 4,2% posiadanej mocy;
• średnie zapotrzebowanie na pamięć operacyjną stanowiło
7,3% zainstalowanej pamięci
• wykorzystanie pamięci dyskowej wynosiło 2,5%
Usługa przetwarzania danych
• Iluzja nieskończonych zasobów komputerowych:
– dostępnych na żądanie,
– nie ma potrzeby planowania zapotrzebowania na
zasoby komputerowe z wyprzedzeniem.
• Nie ma kosztów początkowych:
– firmy mogą rozpoczynać od wykorzystania niewielkich
zasobów,
– zasoby są zwiększane, tylko jeżeli rzeczywiście są
potrzebne.
• Opłaty za faktyczne krótkoterminowe zużycie:
– procesory za godziny, dyski za dni,
– możliwość zwalniania zbędnych zasobów.
Model dojrzałości technologii
• Ogólny kształt "krzywej popularności"
Popularność
Szczyt zawyżonych oczekiwań
Plateau produktywności
Nachylenie prawdziwego zrozumienia
Dno rozczarowania
Pojawienie się nowej technologii
Czas
Dwa rodzaje chmur
• Publiczne –usługi przetwarzania danych (ang.
utility computing) oferowane otwartemu
kręgowi nabywców, płatne w formie pay-asyou-go.
• Prywatne – wewnętrzne centra danych firm
lub organizacji obsługujące setki
tysięcy/miliony użytkowników (Google,
Facebook, Amazon, itd.)
• Hybrydowe
Modele udostępniania
Dostępne są dwa podstawowe modele udostępniania
baz danych w chmurze:
• Na maszynie wirtualnej – obraz maszyny wirtualnej
może dostarczyć jej użytkownik lub dostawca może
oferować gotową do użycia maszynę z zainstalowaną
i skonfigurowaną bazą danych.
• Jako usługa sieciowa (DaaS) – dostawca oferuje
gotowe, potencjalnie skalowalne i rozproszone
rozwiązanie systemu bazy danych.
Dostępne systemy SQL
Maszyny wirtualne
•
•
•
•
•
•
•
Oracle
IBM DB2
Ingres
PostgreSQL
MySQL
NuoDB
Galant
Usługa DaaS
•
•
•
•
•
•
•
•
Amazon Relational Database Service (MySQL)
Microsoft SQL Azure (MS SQL)
Heroku PostgreSQL as a Service
Clusterix Database as a Service
Xeround Cloud Database - MySQL front-end
EnterpriseDB Postgres Plus Cloud Database
GaianDB
ClearDB ACID-compliant MySQL
Dostępne systemy NoSQL
Maszyny wirtualne
•
•
•
•
CouchDB on Amazon EC2
Hadoop on Amazon EC2
Apache Cassandra on Amazon EC2
Neo4J on Amazon EC2 or Microsoft
Azure
• MongoDB on Amazon EC2 or Microsoft
Azure
Usługi DaaS
•
•
•
•
•
•
•
Amazon DynamoDB
Amazon SimpleDB
Cloudant Data Layer (CouchDB)
Database.com by SalesForce
Google App Engine Datastore
MongoDB Database as a Service
Cloudbase.io Cloud Database
Dojrzałość technologii
przetwarzania w chmurze
Dojrzałość technologii
przetwarzania w chmurze
Zarządzanie danymi w chmurze
Integracja trzech technologii informatycznych:
• Rozproszone baz danych: rozproszenie danych, optymalna
fragmentacja, replikacja i alokacja danych; zapewnienie
poprawności przetwarzania w środowisku replikowanym i
rozproszonym, zwiększenie wydajności przetwarzania,
odporność na awarie serwerów baz danych.
• Równoległe bazy danych: równoległe bardziej wydajne wersje
klasycznych algorytmów przetwarzania danych (skan,
grupowanie, sortownie, połączenia); optymalizacja
fragmentacji danych.
• Nowe uproszczone modele danych: proste struktury danych,
prosty zestaw operacji, nowe rozwiązania wydajnościowe
poświęcające poprawność przetwarzania, nowe uproszczone
modele spójności.
Rozproszone bazy danych
Stare i nowe rozwiązania
Rozproszone bazy danych
Dlaczego rozpraszać bazy danych?
• Użytkownicy aplikacji baz danych z natury są
rozproszeni: rozproszone geograficznie filie banków,
sieci sklepów, itp.
• Większa wydajność dzięki alokacji danych blisko
użytkowników
• Skalowalność dla coraz większych zbiorów danych
• Skalowalność dla coraz większej liczby użytkowników
dzięki równoległości inter-operacyjnej
• Odporność na awarie serwerów danych
Własności architektury rozproszonej
• Duża dostępność danych – dane mogą być przechowywane w
miejscu ich przetwarzania
• Krótsze czasy odpowiedzi – dzięki lokalnej dostępności danych
oraz równoległości przetwarzania danych
• Duża skalowalność – teoretycznie nieograniczona możliwość
rozbudowy systemu przez dodawanie nowych serwerów danych
• Duża odporność na awarie – awarie pojedynczych węzłów lub
fragmentów sieci komunikacyjnej nie wykluczają dalszej pracy
systemu (utrata części funkcjonalności lub wydajności systemu)
• Większa złożoność projektu i implementacji systemów
informatycznych - większe koszty budowy i administrowania
systemem
• Większe narzuty systemowe – obsługa dodatkowej
funkcjonalności systemu
Dodatkowa funkcjonalność DDBMS
Czym różni się funkcjonalność rozproszonych DBMS od DBMS?
• Obsługa zdalnego dostępu do danych – przekazywanie żądań i danych
między węzłami systemu rozproszonego.
• Utrzymywanie dodatkowych informacji w schematach danych –
informacje te dotyczą powiązań między rozproszonymi danymi, np.
więzów integralności, fragmentacji danych, replik danych.
• Realizacja rozproszonych operacji i ich optymalizacja – system musi
umieć obsługiwać operacje, które przetwarzają dane znajdujące się na
różnych węzłach systemu rozproszonego oraz uwzględniać w
szacowanych kosztach tych operacji koszty komunikacyjne.
• Obsługa utrzymywania spójności danych dla nowych typów awarii –
dotyczących poprawności działania sieci komunikacyjnej.
• Synchronizacja rozproszonych transakcji – gwarantująca nie tylko
lokalną, ale również globalną uszeregowalność transakcji.
• Utrzymywanie spójności replik danych – istnienie wielu kopii danych
stwarza problem ich wzajemnej spójności.
Nowe własności chmur baz danych
Co nowego chmury baz danych wnoszą do dziedziny
rozproszonych baz danych:
• Różnica skali – chmury baz danych mają zarządzać, nie
dziesiątkami serwerów, ale tysiącami i dziesiątkami tysięcy.
• Publiczna infrastruktura DBMS zamiast prywatnej –
rozproszone zasoby chmury mają być współdzielone przez
wielu dzierżawców (ang. multitenancy).
• Automatyzacja zarządzania strukturą rozproszonych baz
danych – zamiast ręcznego projektowania, automatyczne
dopasowanie struktur danych do zmieniającego się
obciążenia.
• Jeszcze większy nacisk na dostępność danych.
Optymalizacja struktur danych
rozproszonych baz danych
Optymalizacja jest realizowana poprzez stosowanie trzech
podstawowych technik:
• fragmentacji danych – określającej optymalny sposób
podziału większych logicznych struktur danych (tabel)
na mniejsze fizyczne fragmenty;
• replikacji danych – określająca optymalną liczbę replik
tych samych fragmentów rozproszonych na różnych
serwerach;
• alokacji danych – określającej optymalną lokalizację
replik fragmentów danych (na jednym z n serwerów).
Projektowanie schematów
rozproszonych baz danych
Celem optymalnego projektu schematu rozproszonej bazy
danych jest:
• skalowalna przepustowość
• minimalizacja czasu dostępu do danych,
• minimalizacja kosztów przetwarzania danych,
• zwiększenie dostępności danych.
Osiągnięcie powyższych celów wymaga stosowania
fragmentowania, replikowania i właściwej alokacji danych.
• Klasyczne rozproszone bazy danych przyjmowały, że za projekt
rozproszonej bazy danych jest wykonywany ręcznie przez
projektantów i programistów.
• Projekt schematów rozproszonych baz danych w chmurze
powinien być utrzymywany automatycznie.
Fragmentacja danych
Fragmentacja danych jest to podział logicznych tabel na mniejsze
fizyczne fragmenty.
Głównym celem fragmentacji jest zwiększenie wydajności
przetwarzania danych w wyniku:
1) rozproszenia żądań użytkowników (load balancing) między
różne fragmenty alokowane na różnych dyskach lub różnych
serwerach (inter-operacyjność);
2) rozproszenia fragmentów na różne lokalizacje serwerów w celu
zmniejszenia wielkości opóźnienia, ograniczenia ruchu w sieci i
zwiększenie dostępności danych (dane jak najbliżej ich
użytkowników);
3) przetwarzania mniejszych zbiorów danych, fragmentów tabel
zamiast całych tabel;
4) współbieżnego przetwarzanie tabel (intra-operacyjność).
Fragmentacja danych
Ewolucja celów stosowania:
• fragmentacja danych (ang. fragmentation) – (2) pozioma lub
pionowa; termin wprowadzony w klasycznej teorii rozproszonych
baz danych; nie była wspierana systemowo przez DDBMS;
• partycjonowanie (ang. partitioning) – (4) poziomy podział tabel
na mniejsze fragmenty w celu zrównoleglenia przetwarzania
dużych tabel;
• (ang. sharding) – (1) i (3) nazwa poziomej fragmentacji, w bazach
danych w chmurze wspierana systemowo przez systemy klasy
NoSQL, mająca na celu zwiększenie przepustowości żądań
dostępu do pojedynczych danych.
Koszty zdalnego dostępu do danych
Czas transmisji pakietu danych przez sieć komputerową zależy od
dwóch parametrów:
• przepustowości sieci,
• długości sieci – która podzielona przez prędkość światła Cm
określa opóźnienie (ang. latency) transmisji.
Czas transmisji m-bitowego komunikatu jest określony
następującym wzorem:
Czas transmisji=Odległość/Cm + m/przepustowość
Typ sieci
cluster
LAN
MAN
WAN
Średnica
100m
1 km
100 km
10 000 km
Opóźnienie
0,3 s
3,3 s
0,3 ms
33 ms
Przepust.
100 Gbps
10 Gbps
1 Gbps
100 Mbps
Tran. 1 KB
0,076 s
0,76 s
7,6 s
0,08 ms
Dla baz danych połączonych sieciami WAN lokalna alokacja danych
jest ważna.
Optymalna fragmentacja danych
Konkretny cel fragmentacji wpływa na sposób ustalania
optymalnych fragmentów.
• Dobra fragmentacja mająca na celu zmniejszenie opóźnień w
dostępie do danych musi zapewnić, że wszystkie żądania danych
użytkowników zamkną się w zbiorze danych fragmentów.
Nieoptymalna fragmentacja:
Fragment 1
Pojedyncze
żądanie
Fragment
lokalny
Fragment 2
żądania
Fragment 3
Fragment 4
Fragment
zdalny
Typy fragmentacji danych
• Fragmentacja pozioma – podział krotek relacji r na
podzbiory r1, r2, ... , rm. Fragment ri jest wynikiem selekcji
krotek na relacji r według predykatu Pi : ri=Pi(R). Relacja
źródłowa r może być odtworzona przez zsumowanie
wszystkie fragmentów.
r = r1  r2  ...  rm
• Fragmentacja pionowa – podział atrybutów relacji r na
grupy: ri=L(R). Klucz podstawowy relacji musi być częścią
każdego fragmentu. Odtworzenie relacji r uzyskujemy
łącząc wszystkie fragmenty.
r = r1  r2  ...  rm
• Fragmentacja mieszana - równoległe zastosowanie
podziału przez projekcję i selekcję
Warunki poprawnej fragmentacji
• Kompletność
Fragmentacja relacji r na fragmenty r1, r2, ... , rm jest kompletna
wtedy i tylko wtedy, gdy dla każdego elementu danych di r istnieje
fragment ri taki, że di  rj.
• Rozłączność
Fragmentacja relacji r na fragmenty r1, r2, ... , rm jest rozłączna,
wtedy i tylko wtedy, gdy dla każdego fragmentu rj i każdego
elementu danych di  rj, di  rk dla wszystkich k  j.
• Odtwarzalność
Fragmentacja relacji r na fragmenty r1, r2, ... , rm jest odtwarzalna,
jeżeli istnieje operator relacyjny (lub zbiór operatorów)  taki, że:
r = 1  i  m ri.
Przykłady fragmentacji
Dana jest relacja Pracownicy i dane są wzorce dostępów
do tej relacji w poszczególnych lokalizacjach, określające
przetwarzane wiersze i atrybuty tej relacji.
id_prac
Nazwisko Etat
Płaca
Zespół
100
120
150
110
Tarzan
Morzy
Dziubasik
Buła
10 000 zł
1 500 zł
3 500 zł
8 000 zł
Zarząd
Administracja
Administracja
Zarząd
Prezes
Referent
Kierownik
Z-ca prezesa
Fragmentacja pozioma
Dla danego schematu zapytań:
Pracownicy_1: (Pracownicy) Zespół='Zarząd'
Pracownicy_2: (Pracownicy) Zespół='Administracja'
powstaną dwa fragmenty poziome:
id_prac
100
110
Nazwisko Etat
Tarzan
Prezes
Buła
Z-ca prezesa
Płaca
10 000 zł
8 000 zł
Zespół
Zarząd
Zarząd
id_prac
120
150
Nazwisko Etat
Morzy
Referent
Dziubasik Kierownik
Płaca
1 500 zł
3 500 zł
Zespół
Administracja
Administracja
Modyfikacje operacji użytkowników zgodnych ze schematem zapytań:
• zapytania: relacja -> fragment
• wstawianie: relacja -> fragment
• modyfikacja: relacje -> fragment
• usuwanie: relacja -> fragment
Fragmentacja pionowa
Fragmentacja pionowa dla schematu zapytań:
Pracownicy_1: id_prac, Nazwisko, Etat, Zespół (Pracownicy)
Pracownicy_2: id_prac, Płaca (Pracownicy)
31
id_prac
100
120
150
110
Nazwisko
Tarzan
Morzy
Dziubasik
Buła
id_prac
100
120
150
110
Płaca
10 000 zł
1 500 zł
3 500 zł
8 000 zł
Etat
Prezes
Referent
Kierownik
Z-ca prezesa
Zespół
Zarząd
Administracja
Administracja
Zarząd
Modyfikacje operacji użytkowników
• zapytania: relacja -> fragment
• wstawianie: relacja -> fragmenty
• modyfikacja: relacje -> fragment
• usuwanie: relacja -> fragmenty
Algorytmy fragmentacji danych
Znanych jest wiele propozycji fragmentacji danych dla
relacyjnego modelu danych: fragmentacja bazująca na
własnościach: minterm, affinity table lub affinity graph. Część
proponowanych rozwiązań dotyczy tylko jednego typu
fragmentacji: horyzontalnej lub wertykalnej. Inne preferują jeden
z typów fragmentacji: HV lub VH. Nieliczne optymalizują
symetryczną fragmentację mieszaną.
H
V
VH
HV
G
Algorytmy fragmentacji danych
Dane źródłowe niezbędne do przeprowadzenia procesu
fragmentacji mogą być zapisane w postaci macierzy użycia
atrybutów i predykatów przez transakcje:
Transakcje
Atrybuty
Predykaty
Częstość
Serwery
T1
a1, a5, a7
p1, p7
25
s1, s4
T2
a2,a3, a8, a9
p2, p7
50
s2, s4
T3
a4, a3, a10
p3, p7
25
s4
T4
a2, a7, a8
p4, p8
35
s1
T5
a1, a2, a3, a5, a7, a8, a9
p5, p8
25
s1, s2, s3
T6
a1, a5
p6, p8
25
s3, s4
T7
a3, a9
p5, p8
25
s4
T8
a3, a4, a6, a9, a10
p6, p8
15
s1, s2, s3
Macierze pokrewieństwa atrybutów
- fragmentacja pionowa
Siła zależności między poszczególnymi atrybutami może być
określona za pomocą macierzy pokrewieństwa atrybutów (ang.
Atribute Affinity Matrix AAM):
Atrybuty
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10
A1
75
25
25
0
75
0
50
25
25
0
A2
25
110
75
0
25
0
60
110
75
0
A3
25
75
115
15
25
15
25
75
115
15
A4
0
0
15
40
0
40
0
0
0
40
A5
75
25
25
0
75
0
50
25
25
0
A6
0
0
15
40
0
40
0
0
0
40
A7
50
60
25
0
50
0
85
60
60
0
A8
25
110
75
0
25
0
60
110
75
0
A9
25
75
115
15
25
15
25
75
115
15
A10
0
0
15
40
0
40
0
0
15
40
Wartości
pokrewieństwa
są wyznaczane
jako:
affij = kacckij
gdzie acckij jest
częstością
przetwarzania
atrybutów i i j
przez transakcję
k.
Graf pokrewieństwa atrybutów
- fragmentacja pionowa
Dla danej macierzy AAM można
utworzyć graf pokrewieństwa
atrybutów. Podział tego grafu na
silnie powiązane podgrafy
definiuje fragmenty.
atrybuty
siła
pokrewieństwa
atrybutów
Fragmentacja pozioma
Szukanie prostych predykatów logicznych występujących w
zapytaniach różnych aplikacji, które pochodzą z określonych
lokalizacji.
Predykaty = {miasto = 'Poznań' , miasto = 'Wrocław',
obroty >= 1 000 000, obroty < 1 000 000}
Definiowanie mintermów, które łączą proste predykaty logiczne.
m1: miasto = 'Poznań' and obroty >= 1 000 000
m2: miasto = 'Poznań' and obroty < 1 000 000
m3: miasto = 'Wrocław' and obroty >= 1 000 000
m4: miasto = 'Wrocław' and obroty < 1 000 000
m5: miasto not in ('Poznań' ,'Wrocław') and obroty >= 1 000 000
m6: miasto not in ('Poznań' ,'Wrocław') and obroty < 1 000 000
Implementacja fragmentacji
Fragmentacja nie jest bezpośrednio wspierana przez systemową
funkcjonalność RDBMS. Transparentna fragmentacja może by zrealizowana
np. przez zastąpienie fizycznych fragmentów przez logiczne tabele. Dostęp do
sfragmentowanej tabeli może być osiągnięty poprzez zdefiniowanie
perspektywy ze zbiorem utrzymujących ją triggerów typu instead of.
CREATE VIEW tabela AS
SELECT * FROM fragment_1 UNION
SELECT * FROM fragment_1 UNION …
CREATE TRIGGER tab_ins INSTEAD OF INSERT
FOR EACH ROW
BEGIN
IF :new.miasto = 'POZNAŃ' THEN
INSERT INTO fragment_1 VALUES (:new.atr1,…)
…
Partycjonowanie danych
Celem partycjonowania danych jest horyzontalny podział
logicznych tabel na fizyczne fragmenty dla zrównoleglenia
przetwarzania OLAP. Jest wspierana przez funkcjonalność
systemową RDBMS.
CREATE TABLE Sprzedaż (
id_sklepu NUMBER(6),
id_towaru NUMBER(6),
cena NUMBER(6,2))
PARTITION BY HASH(id_sklepu)
(PARTITION p1 TABLESPACE ts1,
PARTITION p2 TABLESPACE ts2,
PARTITION p3 TABLESPACE ts1,
PARTITION p4 TABLESPACE ts3);
Optymalne partycjonowanie danych
• Definicja partycji powinna gwarantować równomierne
rozproszenie danych między partycje, tak żeby koszty
wykonywania operacji na poszczególnych partycjach były takie
same. Czas równoległego przetwarzania danych będzie co
najmniej równy czasowi przetwarzania największej partycji.
Przykładowym mechanizmem gwarantującym równomierne
rozpraszania danych między partycje jest algorytm Round Robin.
Fragment 1
Równoległy
dostęp
Fragment 2
Fragment 3
Fragment 4
Równe czasy
przetwarzania
Sharding danych
Celem shardingu danych jest podział logicznych tabel na fizyczne
fragmenty (shards) dla rozproszenia przetwarzania danych w
trybie OLTP między wiele serwerów DBMS. Mechanizm
shardingu jest realizacją poziomej skalowalności aplikacji baz
danych.
jeden serwer DBMS
dwa serwery DBMS
Sharding danych
• Fragmentacja mająca na celu zwiększenie przepustowości
strumienia dostępów do pojedynczych danych na bazie klucza,
musi równomiernie rozpraszać dane np. za pomocą rozłącznych
przedziałów wartości klucza lub funkcji haszującej, której
wartościami są identyfikatory jednostek obliczeniowych chmury.
• Sharding jest wspierany przez systemową funkcjonalność DBMS.
żądanie
dostępu do
x=27
Dispatcher
x<1;10>
Fragment 1
x<11;20>
Fragment 2
x<21;30>
Fragment 3
x<31;40>
Fragment 4
Optymalny sharding danych
Dobra fragmentacja (sharding) mająca na celu rozproszenie żądań
użytkowników powinna zapewnić, że pojedyncze żądania
użytkowników zamkną się w pojedynczych fragmentach.
• Dla prostych modeli danych SQL, które oferują jedynie dostęp
do pojedynczych danych fragmenty mogą być generowane
przez funkcję haszującą na kluczu danych.
• Dla relacyjnego modelu danych, który dopuszczalne jest
przetwarzanie przez pojedynczą operację całych zbiorów
danych, projekt fragmentów powinien uwzględniać warunki
selekcji danej operacji. Przetwarzane przez pojedyncze operacje
zbiory danych powinny się zamykać w całości w zdefiniowanych
fragmentach, co powinno być łatwe dla modelu OLTP.
• Dostęp do danych przekraczający granice pojedynczych
fragmentów będzie zrównoleglony na węzłach zawierających
przetwarzane dane.
Replikacja danych
Replikacja fragmentów danych pozwala osiągnąć trzy istotne
cele:
1. dla rozległych sieci komputerowych - udostępnianie
lokalnych replik fragmentów danych dla wszystkich
potencjalnych użytkowników, w wypadku współdzielonych
fragmentów danych;
2. dla lokalnych sieci komputerowych – zwiększenie
przepustowości przez zrównoleglenie dostępu dla tych
samych operacji na różnych serwerach RBD (równoległość
inter-operacyjna);
3. zwiększenie dostępności danych – w wyniku odporności na
ewentualne awarie powodujące niedostępność pojedynczych
serwerów RBD. Jeżeli dostępność danych na pojedynczym
serwerze wynosi p, to dostępność dla replik utrzymywanych
na N serwerach wynosi: 1-(1-p)N
Replikacja danych – ciemna strona mocy
Stosowanie replikacji danych ma również trzy istotne wady:
1. Zapewnienie spójności replik – operacje modyfikacji jednej z
replik wymaga propagacji tej modyfikacji na wszystkie pozostałe
repliki. Wiąże się z to dodatkowym istotnym narzutem na
wszelkie operacje modyfikacji.
2. Brak spójności danych – wynikający z asynchronicznego
utrzymania replik. Po modyfikacji jednej z replik, użytkownicy
podłączeni do innych serwerów będą przetwarzali nieaktualne
repliki danej.
3. Brak spójności danych - wynikający z podziału sieci. Wartości
danych w replikach rozłącznych fragmentach sieci nie będą
synchronizowane.
4. Niska dostępność danych dla operacji modyfikacji – dla
dostępności pojedynczej repliki równej p, dostępność N replik
wynosi pN.
Alokacja danych – definicja problemu
Celem procesu alokacji danych jest znalezienie optymalnych
lokalizacji dla replik fragmentów danych. Lokalizacji
optymalnych ze względu na czasy odpowiedzi systemu L lub
jego wysoką dostępność A.
Problem maksymalizacji/minimalizacji wybranej funkcji
zysku/kosztu jest w ogólności NP zupełny.
Dla n fragmentów danych i m serwerów DDBMS, rozmiar
przestrzeni rozwiązań
• dla niereplikowanej bazy danych wynosi: mn
• dla replikowanej bazy danych wynosi: (2m-1)n
Sformułowanie problemu
Dane są:
• zbiór fragmentów danych,
• charakterystyki i rozkłady zapytań,
• charakterystyki i rozkłady operacji DML,
• węzły sieci (serwery baz danych),
• przepustowość połączeń sieci między poszczególnymi
węzłami,
• moc przetwarzania i pojemność węzłów.
Poszukiwany jest:
• schemat rozmieszczenia potencjalnie replikowanych
fragmentów danych w węzłach sieci, tak by pewna funkcja
zysku/kosztu była maksymalna/minimalna.
Algorytmy alokacji i replikacji
Statyczne algorytmy alokacji:
• Best Fit – najlepsze dopasowanie dla danych
niereplikowanych
• All Beneficial Sites (ABS) - dopasowanie dla danych
replikowanych
• Progresywnej alokacji fragmentów (FPA) – z
uwzględnieniem korzyści z odporności na awarie
Dynamiczne algorytmy alokacji:
• Simple Counter, Load Sensitive Counter
Algorytm alokacji: Best Fit
• Homogeniczna sieć węzłów o nieorganicznej pojemności
• Fragment Fi pamiętamy na węźle Sj, na którym liczba referencji
odczytu i modyfikacji Fi jest największa
• Ograniczenie: fragment jest alokowany tylko na jednym węźle - brak
replikacji
Notacja:
• i jest indeksem fragmentu relacji lub relacji
• j jest indeksem stanowiska
• k jest indeksem aplikacji
• fkj jest częstością k-tej aplikacji na j-tym
stanowisku
• rki jest liczbą odczytów i-tego fragmentu danych
przez k-tą aplikację
• uki jest liczbą referencji aktualizacji i-tego
fragmentu danych przez k-tą aplikację
• nki=rki+uki
Aplikacje
…
k
…
2
Stanowiska
1 1 2 3 … j …
1
2
3
…
i
…
10 0 25 …
Fragmenty
1

fkjnki
k
Algorytm alokacji: Best Fit
Fragment Ri pamiętamy na stanowisku Sj, na którym liczba
referencji odczytu i zapisu do Ri jest największa:
Bij =
 fkj * nki
k
Współczynnik Bij jest miarą intensywności dostępu do fragmentu i
w lokalizacji j.
Dla każdego i wyznaczamy: maxj(Bij)
Przykład:
Transakcja Serwer Częstość
T1
T2
T3
S1
S4
S2
S4
S3
S5
25
100
10
50
200
5
Operacje
F1: (5r+2w), F2: (1r)
F1: (2r), F3:(3r+1w)
F2: (10r)
Best Fit - Przykład
Charakterystyka
przetwarzania:
Best Fit
Ostateczna alokacja fragmentów na serwerach S2, S3 i S4:
S5
S1
S2
S4
F3
F1
S3
F2
Własności:
• Algorytm prosty obliczeniowo
• Nie uwzględnia replikacji
• Mała "dokładność"
– uwzględnia tylko częstość
dostępów do fragmentów
– nie uwzględnia parametrów
składników systemu
rozproszonego
Algorytm optymalizacji zysku ABS
All Beneficial Sites
• Algorytm określa wszystkie węzły, na których opłaca się
umieścić danych fragment; jeżeli takich węzłów jest więcej
pojawiają się repliki.
• Fragment jest umieszczany w tych węzłach, dla których zysk z
umieszczenia fragmentu jest większy, niż koszt
przechowywania i aktualizowania tego fragmentu.
• Fragment Fi pamiętamy w węźle Sj, w którym zysk z lokalnego
odczytu jest większy niż koszt modyfikacji Fi z innych węzłów
w systemie.
Algorytm optymalizacji zysku ABS
• Koszt utrzymywania dodatkowej kopii fragmentu Fi w węźle Sj:
– sumaryczny czas wszystkich lokalnych aktualizacji fragmentu
Fi przez transakcje inicjowane w węźle Sj plus sumaryczny
czas wszystkich zdalnych aktualizacji fragmentu Fi przez
transakcje inicjowane w pozostałych węzłach DDBMS i
odwołujące się do tego fragmentu
• Zysk z utworzenia dodatkowej kopii fragmentu Fi w węźle Sj:
– różnica między czasem wykonania zapytania zdalnego, a
czasem wykonania zapytania lokalnego pomnożona przez
częstość zapytania do fragmentu Fi z węzła Sj
Bij =

fkj * rki – C *  
k
k
j’  j
fkj’ * uki
Przykład
Charakterystyki przetwarzania
Koszty modyfikacji dla schematów alokacji fragmentu F1
 F1 alokowany kolejno w S1, S2, ..., S5
Przykład
• Charakterystyki przetwarzania
• Koszty modyfikacji dla schematów alokacji fragmentu F2
Przykład
• Koszty modyfikacji dla schematów alokacji fragmentu F3
Przykład
• Zysk dla schematów alokacji fragmentu F1
Przykład
Przykład
Wynik procesu alokacji ABS
• Uzyskany schemat alokacji
– fragment Fi jest alokowany we wszystkich węzłach dla
których zysk>koszt
S5
S1
F2, F3
F1
S2
S4
F1, F3
F1, F3
S3
F2, F3
Algorytm progresywnej alokacji fragmentów
Algorytm PFA stanowi rozszerzenie algorytmu ABS.
Idea: mierzymy zysk z alokacji nowej kopii fragmentu Ri w
terminach zwiększonej niezawodności i dostępności danych.
Niech di oznacza stopień redundancji fragmentu Ri, i niech Fi
oznacza zysk z pełnej replikacji fragmentu Ri na wszystkich
stanowiskach.
Następująca funkcja (di) jest miarą zysku:
(di) = (1 - 21-di) * Fi
Zauważmy, że (1) = 0, (2) = Fi/2, (3) = 3* Fi/4
Stąd, zysk z wprowadzenia nowej kopii Ri na stanowisku j jest
zdefiniowany następująco:
koszt
Bij =
k fkj * rki – C * k 
j’  j
zysk
fkj’ * uki +  (di)
Simple Counter
• Jeden dedykowany węzeł DDBMS utrzymuje liczniki
dostępów z poszczególnych lokalizacji do każdego
fragmentu danych.
• Proces systemowy okresowo, w regularnych odstępach
czasowych, sprawdza te liczniki.
• Relokacja fragmentów ma miejsce, gdy lokalizacja z
najwyższą wartością licznika dostępów do danego
fragmentu jest inna niż miejsce jego aktualnego
składowania.
Modyfikacja Load Sensitive Counter weryfikuje dodatkowo
poziom obciążenia miejsca docelowego realokacji.
Realokacja na przeciążony węzeł zostanie zablokowana.
Simple Counter
Własności:
• zapewnia zadowalający schemat alokacji, gdy zmiany
obciążenia stabilizują się w czasie;
• jeżeli większość zapytań pochodzi z jednego węzła, to
wszystkie rekordy mogą znaleźć się w tym węźle, co może
doprowadzić do przeciążenia tego węzła;
• nieefektywne, dla źle dobranych częstotliwość sprawdzania
liczników;
• najgorszy przypadek, gdy algorytm próbuje nadążyć za szybko
zmieniającym się obciążeniem - dużo zbędnych realokacji
danych.
Równoważenie obciążenia w
chmurach baz danych
Cele zarządzania
chmurami obliczeniowymi
Zarzadzanie chmurami obliczeniowymi ma na celu równoczesne osiągnięcie
dwóch potencjalnie sprzecznych celów:
• Minimalizacja opóźnień będących efektem kolejkowania zadań z powodu
braku dostępnych zasobów (perspektywa klienta - perspektywa zadań).
• Maksymalizacja poziomu wykorzystania zasobów, poprzez utrzymywanie
działania minimalnej liczby zasobów niezbędnych do obsłużenia bieżącego
strumienia żądań obliczeniowych (perspektywa dostawcy – perspektywa
zasobów).
opóźnienie
poziom
wykorzystania
zasobów
Równoważenie obciążenia
w chmurach obliczeniowych
Dwie perspektywy równoważenia obciążenia w chmurach obliczeniowych:
• Perspektywa użytkownika – użytkownik chmury przedkładający swoje
zadanie do wykonania jest zainteresowany minimalizacją czasu wykonania
zadania
• Perspektywa dostawcy – oferent usług obliczeniowych jest
zainteresowany wysokim poziomem wykorzystania zasobów, co pozwala
ograniczać koszty inwestycji w infrastrukturę chmury i tym samym
zmniejszać koszty eksploatacji. Pozwoli to na realizację zasady ponoszenia
kosztów tylko za eksploatację zasobów obliczeniowych.
posiadana moc
niewykorzystana
moc
obciążenie
Poziom obciążenia chmur obliczeniowych
Typowy poziom obciążenia chmur:
Twitter:
Google:
Średni poziom wykorzystania zasobów oferentów chmur 6-15% Overprovisioning Curse.
Poziom obciążenia chmur obliczeniowych
Typowy poziom obciążenia chmur, Twitter:
80% serwerów jest obciążonych na poziomie < 20%.
Typy chmur ze względu na charakter zadań
Nie istnieją uniwersalne metody równoważenia obciążenia dla
wszystkich typów chmur obliczeniowych. Jedną z własności
rozróżniających sposoby równoważenia obciążenia jest wielkość i
charakter usług obliczeniowych oferowanych w chmurze.
• Proste usługi obliczeniowe o krótkim czasie wykonywania –
ułamki sekund, sekundy, minuty. Dla chmur baz danych będą to
np. operacje właściwe dla przetwarzania OLTP.
• Złożone usługi obliczeniowe o dłuższym czasie wykonywania –
minuty i godziny. Dla chmur baz danych będą to np. operacje
właściwe dla przetwarzania małych i średnich hurtowni danych.
• Bardzo złożone usługi obliczeniowe - długim czasie
wykonywania – godziny i dni. Dla chmur baz danych będą to
np. operacje właściwe dla przetwarzania Big Data i dużych
hurtowni danych.
Proste usługi obliczeniowe
Model równoważenia obciążenia zazwyczaj bazuje na teorii kolejek.
• Dany jest strumień zadań obliczeniowych o potencjalnie różnej wielkości. Strumień jest
opisany przez rozkład czasów między pojawianiem się kolejnych zadań. Średnia częstość
pojawiania się kolejnych zadań jest równa . Czas wykonania zadań (lub ich wielkość)
może być znany w momencie ich przedkładania.
• Dany jest zbiór N węzłów obliczeniowych chmury. Każdy węzeł ma określoną moc
przetwarzania opisaną przez maksymalną częstość obsługi zadań równą . Obciążenie
systemu można wyznaczyć jako:    /   1.
Równoważenie obciążenia polega na takim rozpraszaniu żądań, żeby minimalizować średni
czas odpowiedzi systemu (opóźnienia) lub jego przepustowość. Sprzyja ono również
utrzymaniu wysokiego poziomu wykorzystania zasobów.
Opcje:
• znany/nieznany rozmiar zadań;
• zadania są wywłaszczalne/
niewywłaszczalne;
• serwery są identyczne/
strumień
różne;
zadań 
• serwery pracują w sposób
współbieżny/sekwencyjny.
czas odpowiedzi =
opóźnienie + czas obsługi
kolejka
Load
Balancer
JSQ
FCFS
obsługa 
węzeł
szeregowanie
FCFS
zadań
Teoria kolejek
Model: M 1/G 2/N 3/JSQ 4/PS 5 – bazuje na notacji Kendalla
1.
rozkład czasów przedkładania zadań do wykonania; M – rozkład losowy
Markowa (Poissona), D – deterministyczny, G – rozkład ogólny/nieznany itp.
2. rozkład czasów obsługi;
3. liczba kanałów obsługi – serwerów
4. algorytm przydziału zadań do kolejek; Random, Round Robin RR, Size Based
Splitting , Least Work Left, Join Shortest Queue - JSQ, Join Null Queue – JNQ.
5. algorytm obsługi zadań przydzielonych do kolejek; Processor Sharing PS,
First Come First Serve FCFS, Shortest Remaining Processing Time SRPT,
Shortest Job First JSF, itp.
Efektywność działania poszczególnych algorytmów przydziału i obsługi zadań
zależy od rozkładu wielkości zadań i od rozkładu intensywności strumienia oraz
od modelu obsługi zadań: sekwencyjnego np. FCFS lub z podziałem czasu PS.
Klasy zastosowań teorii kolejek
I.
Szeregowanie zadań
na pojedynczym
serwerze
II. Przetwarzanie offline
Superkomputery
III. Przetwarzanie online
Serwery aplikacji/baz danych
FCFS
Load
Balancer
FCFS
PS
Load
Balancer
PS
Własności systemów kolejkowania
• Dany jest system obsługi masowej o parametrach ,  i ts. W
systemie tym nastąpiło dwukrotne zwiększenie intensywności
zadań w strumieniu wejściowym:  = 2  .
• O ile należy zwiększyć wydajność przetwarzania , żeby
zachować dotychczasową średnią wartość czasów odpowiedzi ts?
a) ' > 2  
ts
FCFS
b) ' = 2  


c) ' < 2  
FCFS
2*
t's = ts
' = ?
Losowe rozkłady obciążenia
Rozkłady opisujące zmienność obciążenia systemu będącą wynikiem zadań o
różnym rozmiarze:
• rozkład wykładniczy – Pr{rozmiar zadania > x}  e-x ;
• dla strumieni obciążeń charakteryzujących się dużą zmiennością rozmiaru
zadań – rozkład o własności heavy tailed – Pr{rozmiar zadania > x}  1/x
Strumienie o dużej zmienności obciążenia wymagają odmiennych algorytmów
przydziału zadań do kolejek i szeregowania zadań w kolejkach. Przyczyną są
częstsze konflikty, które powodują opóźnienia. Taki typ obciążenia jest jednym
ze źródeł zjawiska Overprovisioning Curse.
1
Rozkład wykładniczy PDF
½
1% najdłuższych zadań
odpowiada za 5% obciążenia
¼
1
Rozkład Heavy-tailed PDF
½
1% najdłuższych zadań
odpowiada za 50%
obciążenia
¼
Własności systemów kolejkowania
• Dany jest system obsługi masowej o pojedynczym węźle przetwarzania o
parametrach ,  i ts. Czy system taki jest bardziej, czy mniej wydajny niż
system z dwoma węzłami o wydajności :  = 1/2  .
FCFS
FCFS


vs

Load
Balancer
/2
FCFS
/2
• Dla przebiegów obciążeń o dużej zmienności, inteligentne algorytmy
przydziału zadań (np. Least-Work-Left, Size-based, JSQ) umożliwiają
chmurom składającym się z wielu słabszych serwerów osiągać krótsze czasy
obsługi niż pojedynczy serwer o dużej mocy obliczeniowej. Czasy
wykonywania zadań są w takim wypadku dłuższe, ale za to opóźnienia mniejsze.
Porównanie algorytmów przydziału zadań
Dla obciążeń o dużej zmienności ranking metod szeregowania
zadań jest następujący.
Przetwarzanie online
Przetwarzanie offline
używające do szeregowania
używające do szeregowania
zadań algorytmu PS
zadań algorytmu FCFS
1. Join-Shortest-Queue
1. Size-Based
2. Least-Work-Left
2. Least-Work-Left
3. Random = Size-Based
3. Join-Shortest-Queue
4. Random
czas obsługi
czas obsługi
Random
Random
S-B
obciążenie
= 1
JSQ
obciążenie
= 1
Porównanie algorytmów szeregowania
• Dla obciążeń o dużej zmienności ranking metod
szeregowania zadań jest następujący:
1
Rozkład Heavy-tailed PDF
½
1% zadań odpowiada
za 50% obciążenia
¼
małe E[T]
SRPT
duże E[T]
< PS < SJF < RANDOM = FCFS
Złożone usługi obliczeniowe
Usługi o czasie wykonania na tyle długim, że opłacalną strategią przydziału
zasobów jest przesuwania zadań obliczeniowych w trakcie przetwarzania
między różnymi węzłami. Usługi te są obsługiwane tylko w trybie PS Processor Sharing.
Obsługa złożonych zadań obliczeniowych wymaga dynamicznego przydziału
zasobów, to znaczy takiego, który dynamicznie zmienia przydział zasobów do
już obsługiwanych zadań. Sprzyja ono utrzymaniu wysokiego poziomu
wykorzystania zasobów.
Reguły dynamicznego równoważenia obciążenia:
• identyfikacja przeciążonego węzła – skąd realokować zadania,
• wybór zadania do realokacji – co realokować,
• wybór węzła docelowego dla transferowanego zadania – dokąd
realokować.
PS
strumień
zadań
Load
Balancer
PS
PS
Dedykowane maszyny wirtualne
Dwie perspektywy czasowe równoważenia obciążenia:
• Krótkoterminowa - dodawanie nowych maszyn wirtualnych dla obsługi
tego samego typu zadań i statyczne równoważenie krótkoterminowego
obciążenia tych maszynami.
Google Cloud Platform Network load balancing:
• Długoterminowa – realokacja maszyn wirtualnych między różnymi węzłami
chmury typu multitenancy dla dynamicznego równoważenia obciążenia:
VMware Distributed Resource Scheduler (DRS). Globalny Load Manager
wyznacza sumaryczne uprawnienia: reservation (nie mniej niż), limit (nie
więcej niż), share (udział), wszystkich VM do korzystania z zasobów dla
każdego z węzłów chmury. Następnie dokonuje realokacji VM między
węzłami dla minimalizacji odchyłki standardowej sumarycznych obciążeń
węzłów.
Bardzo duże zadania obliczeniowe
Realizacja pojedynczych, bardzo dużych zadań obliczeniowych może być
wielokrotnie przyśpieszona przez zrównoleglenie ich przetwarzania.
Szczególnym rodzajem przetwarzania jest analityczne przetwarzanie bardzo
dużych zbiorów danych, np. hurtowni danych (OLAP) lub Big Data
(MapReduce - OffLAP). W tym wypadku równoważenie obciążenia jest
gwarantowane przez równomierny rozkład danych między wszystkie węzły
chmury – pre-balancing.
tproc(T)= max{tproc(T1),tproc(T2), …,tproc(Tn)}
• W hurtowniach danych ROLAP za równomierne rozproszenie jest
odpowiedzialny programista (partycjonowanie tabel). Dane mogą być
rozproszone specjalnie pod kątem określonych operacji przetwarzania, np.
Fragment-and-Replicate Join dla operacji połączenia nierównościowego.
• W systemach klasy MapReduce dane są rozpraszane automatycznie przez
procesy systemowe w wypadku dodawania nowych danych i wypadku
zmiany liczby węzłów chmury. Dane są rozpraszane w sposób uniwersalny,
nie pod kątem określonych typów analiz.
Specyfika przetwarzania OLTP w chmurze
Dana jest chmura obliczeniowa, której węzły oferują funkcjonalność serwerów
DBMS oraz przechowują bazy danych najemców chmury. Dane w bazach
danych mogą być fragmentowane za pomocą shardów dla zapewnienia
skalowalności aplikacji najemców chmury i replikowane dla minimalizacji
opóźnień dla rozproszonych geograficznie klientów, i dla zwiększenia
dostępności danych.
Dany jest strumień zadań dostępu do danych chmury o charakterystyce OLTP.
Rozkład czasów obsługi zadań jest zgodny z rozkładem normalnym o małej
wariancji. Charakterystyka poszczególnych zadań odpowiada modelowi CRUD
– wstaw, odczytaj, zmodyfikuj lub usuń pojedynczą daną dostępną poprzez
indeks założony na atrybucie, który posiada własność klucza. Częstość zadań w
strumieniu wejściowym podlega silnej zmienności w czasie. Stąd rozkład
obciążenia chmury (i poszczególnych jej węzłów) ma charakterystykę heavy
tailed.
Którą z poznanych metod równoważenia obciążenia można
używać w chmurach baz danych OLTP?
Funkcjonalna homogeniczność chmur
Ze względu na funkcjonalność oferowaną przez węzły chmur obliczeniowych,
można wyróżnić dwa podstawowe rodzaje chmur:
• Chmury homogeniczne funkcjonalnie (Homogeneous Functionality Cloud
HmFC) – funkcjonalność oferowana przez wszystkie węzły jest taka sama, co
oznacza, że przedkładane do wykonania zadania mogą byś wykonywane na
dowolnym węźle chmury, np. IaaS;
• Chmury heterogeniczne funkcjonalnie (Heterogeneous Functionality Cloud
HtFC) – funkcjonalność każdego z węzłów jest inna, co oznacza, że
przedłożone do wykonania zadanie może być wykonane na dokładnie
jednym węźle chmury, np. DaaS bez replikacji danych.
Możliwy jest przypadek pośredni, homogeniczność funkcjonalna ograniczona do
podzbioru węzłów chmury obliczeniowej (PHmFC). Przykładem mogą być klony
maszyn wirtualnych.
Funkcjonalna homogeniczność chmur
• Formalny model dla chmur typu HmFC jest następujący:
Dany jest strumień zadań s i chmura obejmująca zbiór N uniwersalnych węzłów
chmury obliczeniowej. Równoważenie obciążenia polega w tym wypadku na
wyborze odpowiedniego węzła chmury, na którym zostanie wykonane zadanie
ze strumienia.
W HmFC Load Balancer przypisuje węzły chmury
n1
strumień
zadań
Load
Balancer
n3
n2
nN
do zadań w celu zrównoważenia obciążenia
zasobów. W HtFC Dispatcher przesyła zadania do
węzłów o wymaganej funkcjonalności. W HtFC
dla każdego zadania istnieje tylko jeden taki
węzeł.
• Formalny model dla chmur typu HtFC jest następujący: Dany zbiór strumieni S
= {s1, s2, …, sN} adresujących rozłączne podzbiory zasobów i chmura obejmująca
zbiór N dedykowanych węzłów chmury obliczeniowej. Zadania strumienia si,
mogą być wykonywane tylko i wyłącznie na węźle chmury ni . W związku z tym,
równoważenie obciążenia wykonywane w momencie pojawiania się zadań, nie
jest możliwe. strumienie zadań
adresowane do
rozłącznych
podzbiorów
zasobów
s1
s2
s3
sN
Dispatcher
n1
n2
n3
nN
Ograniczenia chmur typu HtFC
Teza:
Chmury klasy HtFC wymagają większej liczby węzłów i większej sumarycznej
mocy obliczeniowej od chmur klasy HmFC dla takich samych przebiegów
sumarycznego obciążenia strumienia wejściowego i tego samego zadanego
czasu odpowiedzi tr, dla dowolnego przebiegu obciążenia.
Przykład:
Przyjmijmy idealistyczny przypadek trzech węzłów i trzech podstrumieni
zadań, dla których przebiegi obciążenia mają kształt sinusoidy i są przesunięte
względem siebie o 120 stopni.

Dla chmury HmFC : 3

3,500
podstrumień 1
3,000

podstrumień 2
2,500
2,000
podstrumień 3
1,500
strumień sumaryczny
1,000
/3
gdzie  reprezentuje
wymaganą sumaryczną /3
moc obliczeniową
/3
0,500
0,000
1 2 3 4 5 6 7 8 9 1011121314151617181920
czas
Load
Balancer
Dla chmury HtFC : 6


'=2
'=2
'=2
Równoważenie obciążenia OLTP w chmurze
Chmury baz danych wspierające przetwarzanie OLTP bez replikacji danych
należą do klasy HtFC, a replikowane do klasy PHmFC. Własności chmur baz
danych klasy OLTP z punktu widzenia równoważenia obciążenia są następujące:
• Dobra wiadomość – rozpraszanie obciążenia wynika w sposób naturalny z
rozproszenia danych. Nawet w niereplikowanych i niefragmentowanych
bazach danych aplikacje jawnie adresują różne serwery DBMS, które
przechowują określone zbiory danych. We fragmentowanych i
replikowanych bazach danych, żądania dostępu do usług przetwarzania
danych w bazie danych są przekierowywane przez DDBMS do miejsca
składowania odpowiednich replik fragmentów danych.
• Złe wiadomości – ze względu na ich przynależność do klasy HtFB brak jest
mechanizmów systemowych realizujących równoważenie obciążenia dla
zmiennych przebiegów obciążenia.
(1) Poziom niezrównoważenia w czasie jest niekontrolowany i może być
bardzo duży.
(2) Osiągnięcie wyższego poziomu wykorzystania zasobów jest jeszcze
bardziej konfliktowe z minimalizacją opóźnień.
Równoważenie obciążenia OLTP w chmurze
Dany jest strumień żądań dostępu do danych o zadanej charakterystyce
obciążenia: przebieg czasowy obciążenia chmury strumieniem zadań dostępu do
danych – LTS (Load Time Series) oraz rozkład czasów obsługi zadań N (rozkład
normalny o niewielkiej wariancji).
Dany jest oczekiwany czas odpowiedzi tr,, nie mniejszy niż średni czas obsługi
żądań dostępu wynikający z rozkładu N. Dany jest również wymagany poziom
obciążenia węzłów chmury (0;1> oraz poziom tolerancji niezrównoważenia
obciążenia dla poszczególnych węzłów .
Problem do rozwiązania – rozszerzenie definicji równoważenia obciążenia
Znajdź minimalny zbiór N jednostek obliczeniowych o znanej mocy obliczeniowej,
który zapewni równomierne obciążenie wszystkich jednostek obliczeniowych na
zadanym poziomie wartości oczekiwanej równej  i odchyłce standardowej  .
obciążenie
węzła
czas
odpowiedzi


brak dolnego ograniczenia
obciążenie

moc obliczeniowa
czas
Operacje zarządzania chmurą
Zarządzanie chmurą obejmuje następujące operacje:
• Automatyczne dodawanie do chmury nowych jednostek
obliczeniowych, lub informowania o takiej potrzebie, w
wypadku braku sumarycznej mocy obliczeniowej dla zadanego
poziomu obciążenia . Źródłem dla nowych jednostek
obliczeniowych mogą być, np. jednostki zajęte obliczeniami offline data mining, big data, jednostki obliczeniowe innych chmur.
• Automatyczne odłączania od chmury jednostek
obliczeniowych, w wypadku nadmiaru mocy obliczeniowej w
stosunku do zadanego poziomu obciążenia . Obciążenie
odłączonych jednostek do przetwarzania typu off-line lub ich
udostępnianie innym chmurom.
• Automatyczna realokacja danych (resharding), w wypadku
nierównomiernego obciążenia węzłów chmury.
Specyfika chmur baz danych OLTP
• Nie jest możliwe stosowanie metod równoważenia zmiennego w czasie
obciążenia, ponieważ dla każdej danej istnieje tylko jedno miejsce wykonania
dostępu – węzeł chmury, na którym jest przechowywana.
• Ewentualny transfer danej na inną jednostkę obliczeniową w odpowiedzi na
przeciążenie węzła, na którym jest przechowywana, będzie się wiązał ze
znacznie dłuższym czasem odpowiedzi, niż właściwy dostęp.
czasodczytu + czastransferu + czaszapisu + czasredefinicji fragmentów + czas'dostępu >> czasdostępu
żądanie dostępu
do danej x
Load Balancer
żądanie dostępu
do danej x
nie równoważy
obciążenia
Load Balancer
tylko jedna
lokalizacja
host 1
fragment 1
host 2
fragment 2
zawiera x
host 1
fragment 3
host 1
fragment 1
realokacja
host 2
fragment 2(x)
przeciążony
host 1
fragment 3
Przydatność technologii DDBMS
Które z przedstawionych technologii rozproszonych systemów baz danych są
użyteczne dla rozszerzonego równoważenia obciążenia chmur baz danych o
modelu przetwarzania OLTP?
Potencjalne rozwiązania służące do równoważenia obciążenia:
1. Replikacja danych – mocno obciążone dostępami dane są replikowane na
wielu serwerach (nieznane metodyki). Moduł równoważący obciążenie
wybiera jako miejsce przetwarzania danej najmniej obciążoną jednostkę, na
której składowana jest jedna z replik (Oracle LDAP, Postgres).
2. Fragmentacja danych - fragmenty (shards) tabel wielu baz danych wielu
najemców chmury są rozproszone równomiernie między jednostki
obliczeniowe chmury w sposób transparentny dla aplikacji baz danych.
Dzięki temu żądania dostępu są rozpraszane między wiele jednostek
obliczeniowych (MongoDB, Cassandra).
3. Alokacja/realokacja danych – dane (fragmenty logicznych struktur danych)
są alokowane w sposób równoważący obciążenie węzłów chmury.
Pojedynczy węzeł chmury może składować dane różnych najemców
(różnych baz danych) – multitenancy.
Ograniczenia technologii DDBMS
1. Replikacja danych
• Nie jest skalowalna ze względu na rozmiar bazy danych. N replikowanych
baz danych zajmuje N razy więcej przestrzeni dyskowej. Dla dużych chmur, w
których rząd liczby węzłów jest większy niż 104, nie można (10 000 razy
więcej dysków) za pomocą replikacji zapewnić uniwersalności węzłów –
gwarantującej przynależność do klasy HmFC.
• Nie jest opłacalna ze względu na operacje modyfikacji/odczytu dla
przetwarzania OLTP gwarantującego spójność przetwarzania. Operacje
modyfikacji/odczytu obciążają większość węzłów składujących repliki
modyfikowanej danej.
• Wymagania poprawnościowe wymagają dostępu do wybranych
repliki/repliki danych. Dla asynchronicznych metod utrzymania replik
danych, wartości poszczególnych replik w danym momencie mogą być
różne. Niższe poziomy spójności przetwarzania ograniczają wybór repliki do
odczytu lub modyfikacji. Nawet pełna replikacja nie daje przynależności do
klasy HmFC.
2. Fragmentacja danych
• Fragmentacja danych typu sharding jest przydatna dla skalowalności
umieszczanych w chmurze baz danych. Zbiór danych przeciążonego
przetwarzaniem węzła może być podzielony na fragmenty alokowane na
dwóch różnych węzłach dla skrócenia czasu odpowiedzi, w wyniku
redukcji opóźnień. Fragmentacja pozwala zmniejszyć maksymalne lub
średnie wartości czasowych przebiegów obciążeń.
• Mechanizm fragmentacji to nie rozwiązuje w ogóle problemu
równoważenia chwilowych wartości obciążeń.
przebieg zmienności
obciążenia kolekcji danych
moc obliczeniowa
węzła
przebieg zmienności
obciążenia danych po
fragmentacji na dwa shardy
3. Alokacja/realokacja danych
• Nie ma propozycji wykorzystania alokacji/realokacji danych do dynamicznego
równoważenia obciążenia DDBMS.
• Znane są teoretyczne rozwiązania problemu dynamicznej alokacji
fragmentów danych na podstawie utrzymywanych informacji o historii
obciążenia bazy danych (liczników odwołań do fragmentów z różnych
lokalizacji) dla minimalizacji kosztów działania DDBMS (nie równoważenia
obciążenia): metody Simple Counter i Load Sensitive Counter. Jednak zmiana
alokacji fragmentów w tych propozycjach uwzględnia jedynie sumaryczne
wartości obciążenia w zadanych jednostkach czasu, co pozwala jedynie na
odkrycie linii trendu zmian obciążenia. Metoda ta nie adresuje problemu
charakteru zmienności obciążenia w czasie, takiego jak cykliczność,
sezonowość i losowość zmian obciążenia.
realokacja danych
Równoważenie obciążenia OLTP
w chmurach baz danych
Nie ma gotowych rozwiązań dla problemu równoważenia
obciążenia chmur baz danych OLTP.
• Replikowanie danych nie nadaje się na podstawową metodę
równoważenia obciążenia ze względu na jej nieskalowalność i
niedopasowanie do modelu przetwarzania OLTP.
• Fragmentacja danych (sharding) nie rozwiązuje problemu
równoważenia obciążenia dla zmiennych w czasie przebiegów
obciążeń.
Nowe rozwiązanie powinno opierać się na równoważeniu
obciążenia na podstawie prognozowanych przebiegów
zmienności obciążenia.
Równoważenie obciążenia OLTP w chmurach
Idea
Zastosowanie fragmentacji danych (sharding) z równoważeniem
obciążenia węzłów chmury bazującej na predykcji przebiegu
obciążenia. Replikacja może być użyta jako pomocniczy mechanizm
dla danych typu hot-spot z dominującą operacją odczytu.
Definicja nowej klasy metod równoważenia obciążenia:
1. Równoważenie przez alokację zasobów – alokacja fragmentów
danych przewidująca przyszłe obciążenie poszczególnych
fragmentów danych. W momencie pojawienia się żądania
dostępu jest już za późno na korygowanie alokacji, która
wydłuży, a nie skróci czas odpowiedzi.
2. Równoważenie przez alokację zadań – klasyczne metody
równoważenia obciążenia działające w momencie pojawienia
się nowych zadań do wykonania lub realokacji już realizowanych
zadań w wypadku przeciążenia możliwa do zastosowania dla
replik danych.
Równoważenie obciążenia chmury baz danych
• Równoważenie przez alokację zadań – rozwiązuje problem,
gdzie umieścić nowe zadanie przy znanym obciążeniu węzłów
chmury i ewentualnie znanej wielkości zadania. Dodatkowo dla
długich zadań może rozwiązywać problem skąd i dokąd
przenosić wykonywane zadania w wypadku braku równowagi
obciążenia dla już alokowanych zadań.
• Równoważenie przez alokację zasobów – ma rozwiązywać
problem, jak rozmieścić dane uwzględniając czasową
charakterystykę ich obciążenia, aby zrównoważyć przyszłe
obciążenia chmury. Wymaga od węzłów chmury
funkcjonalności umożliwiającej lokowanie na tych samych
węzłach fragmentów danych baz danych różnych najemców
chmury - multi-tenancy.
Przebiegi czasowe obciążenia
Typowe przebiegi obciążenia charakteryzują się sezonową zmiennością o
różnych jednostkach czasu:
• zmienność dobowa,
• zmienność tygodniowa,
• zmienność roczna.
Typowe przebiegi czasowe obciążenia charakteryzują się również dużą
wariancją wartości obciążenia, "heavy tails" oraz skośnością.
Idea równoważenia obciążenia
Fragmenty baz danych różnych najemców chmury powinny być tak wymieszane
żeby na każdym z węzłów osiągnąć zrównoważoną charakterystykę obciążenia.
Fragmenty umieszczane na jednym węźle chmury powinny charakteryzować się
komplementarnymi przebiegami czasowymi obciążenia.
JA3
JA3
Jednostka
obliczeniowa 1
BD23
BD2
BD31
BD1
JA2
BD13
BD11
BD12
JA1
BD3
BD32
BD3
JA2'
BD3
JA2"
JA2
Metryki równoważenia obciążenia
Przykładowe metody zwiększające różnorodność fragmentów przechowywanych
na węzłach chmury.
• Losowe rozmieszczanie fragmentów danych na węzłach chmury.
• Gromadzenie przez poszczególne węzły chmury podzbiorów fragmentów
spełniających wymagany poziom różnorodności charakterystyk obciążenia,
sprzyjający wygładzaniu sumarycznych przebiegów obciążeń, może być
mierzony przez:
– wariancja zmienności obciążenia w czasie - im mniejsza tym lepsza,;
– średni współczynnik korelacji między przebiegami czasowymi obciążenia
fragmentów – im mniejszy tym lepszy;
– iloczyn skalarny wektorów zmienności obciążenia - im mniejszy tym
lepszy;
– wielkość sumarycznego wektora niezrównoważenia będącego wynikiem
porównania zadanego i faktycznego poziomu obciążenia.
• Strumieniowe utrzymywanie grup (bazujących np. na mikro-klastrach)
podobnych charakterystyk obciążenia fragmentów danych. Węzły chmury
powinny zawierać zrównoważony zbiór fragmentów przynależących do jak
największej liczby grup.
Model obciążenia
Każda z jednostek obliczeniowych powinna składować dane - fragmenty tabel
(shards) - o różnorodnych i wzajemnie uzupełniających się przebiegach czasowych
obciążenia.
Przebiegi czasowe obciążenia fragmentów można modelować jako wektory (Load
Time Series Vector), LTS = [l1,…,li ,…,ln], gdzie indeksy wektorów i=1 ,… ,n,
odpowiadają przedziałom czasowym t1,… ,tn, które dzielą ciągły interwał t na
rozłączne i równe pod-interwały. Wartościami wektora li są liczby dostępów do
danych konkretnego fragmentu w danym przedziale czasowym t1.
Poziom różnorodności obciążenia fragmentów tabel może być mierzony np.
iloczynem skalarnym wektorów LTS – im mniejsza wartość iloczynu, tym bardziej
komplementarne dane.
t2
l2
LTS1
t2
l1
LTS1

fragment 1
LTS2
t1
l1
LTS2
fragment 2
l2 t1
l2
LTS3

l1
l2
fragment 1
t1
t2
fragment 2
LTS4
l1
t1
t2
Idea równoważenia obciążenia
Zbiór fragmentów danych składowanych na węźle chmury
obliczeniowej jest zrównoważony jeżeli sumaryczny wektora
obciążenia jest bliski wektorowi pełnego zrównoważenia LTSB, w
którym I1 = I2 = … = In = , gdzie  jest zadanym obciążeniem
chmury.
t2
węzeł zrównoważony
fragment 1
l2
LTS2
LTS1
t2
LTS2
LTS1
LTSB
l1
t1
t2
t1
węzeł niezrównoważony
fragment 1'
l2
LTSB
l1
t1
t1
t2
fragment 2
Razem
l2
l1
t1
t2
t1
fragment 2'
t2
Razem'
l2
l1
t1
t2
t1
t2
Zarządzanie obciążeniem chmury
Zarządzanie równoważeniem obciążenia węzłów chmury jest realizowane
równolegle na dwóch poziomach: dla chmury jako całości i dla każdego z węzłów
z osobna.
1. Zarządzanie chmurą jako całością bazujące na predykcji zmian obciążenia
całej chmury jest realizowane poprzez:
– dodawanie nowych węzłów chmury w wypadku wzrostu globalnego
obciążenia chmury, żeby uniknąć obniżenia jakości obsługi żądań,
– usuwania węzłów chmury w wypadku obniżenia globalnego obciążenia,
dla efektywnego wykorzystania zasobów,
– definiowanie wymaganego poziomu obciążenia dla wszystkich węzłów
chmury, żeby uniknąć niepotrzebnych transferów, w niedociążonych
przedziałach czasu.
2. Zarządzanie pojedynczymi węzłami chmury, jest realizowane przez
odpowiedni dobór fragmentów danych do składowania w danym węźle,
bazujący na predykcji charakterystyki czasowej ich obciążenia w odniesieniu
do prognozy obciążenia całej chmury. Zarządzanie to polega na wymianie
fragmentów danych między poszczególnymi węzłami.
Model procesów utrzymania chmury
Rejestruj
statystyki
obciążenia
Obsłuż
żądanie
Predykcja
obciążenia glob.
przebieg
obciążenia
Generowanie
celów obciążenia
Predykcja
obciążenia lokal.
Pobranie celów
obciążenia
Weryfikacja
obciążenia
N
X
Cykl życia
węzłów
chmury
tablica
zgłoszeń
T
Zgłoś
niezrównoważenie
wektor
niezrównoważenia
odczyt listy wektorów
niezrównoważenia
Cykl życia
serwerów
zarządzania
pusta lista
X
ustal aktualny
transfer
wyznacz najlepszą
parę węzłów
wykonaj transfer
zaplanuj transfer
zmodyfikuj listę
zaplanowane
transfery
Zarządzanie obciążeniem chmury
Rozproszone procesy zarządzania po stronie węzłów chmury:
• zbierają informacje o historii swojego obciążenia,
• na jej podstawie aktualizują prognozy przewidywanego przebiegu obciążenia,
• pobierają aktualne cele równoważenia obciążenia,
• weryfikują przewidywane obciążenie z celami,
• gdy przewidywany przebieg obciążenia nie mieści się w zadanym przedziale od
założonego zrównoważonego obciążenia, zgłaszają to do procesu centralnego,
• po sparowaniu z innym węzłem realizują proces wymiany fragmentów danych.
Scentralizowany proces zarządzania równoważeniem obciążenia:
• cyklicznie zbiera informacje o przebiegu zmian obciążenia chmury jako całości,
• wyznacza i aktualizuje predykcję przewidywanego przebiegu obciążenia,
• ustala aktualne cele równoważenia obciążenia dla wszystkich węzłów,
• szuka optymalnego dopasowania niezrównoważenia węzłów i łączy
przeciwstawne węzły w pary do wymiany fragmentów danych,
• ustala potrzebę dodawania bądź usuwania węzłów z chmury.
Kluczowe algorytmy rozwiązania
• Predykcja przyszłego przebiegu obciążenia na podstawie zebranych w logach
informacji o historii obciążenia (dla całej chmury i dla każdego z węzłów).
Problemem jest predykcja przebiegów o dużej różnorodności poziomu
obciążenia – heavy tailed, odmienna od mniej zmiennych przebiegów
ekonomicznych.
• Wybór pary węzłów chmury ze zbioru wszystkich węzłów o przewidywanym
niezrównoważeniu, dla których zostanie przeprowadzona wymiana
fragmentów danych łącznie z ich przewidywanym obciążeniem.
• Wybór optymalnego zbioru fragmentów z dwóch wybranych węzłów, które
zostaną wymienione. Wybór ma być optymalny ze względu na minimalizację
sumarycznego wektora niezrównoważenia.
• Wybór optymalnego momentu wymiany, który zagwarantuje, że
niezrównoważenia, które pojawią się szybciej powinny być obsłużone
wcześniej oraz, że wymiany danych nie powiększy przeciążenia węzłów.
• Algorytm wymiany fragmentów danych, który będzie mógł przeprowadzony w
tle normalnej pracy systemu – live migration.
Zasady dynamicznego zarządzania obciążeniem
Zarządzanie obciążeniem chmury wymaga predykcji obciążenia
chmury jako całości w celu:
• ustalenia potrzeby dodania lub usunięcia nowych węzłów chmury
• ustalenia procentowego celu obciążenia poszczególnych węzłów
• określenie tolerancji obciążenia dla wszystkich węzłów chmury
przewidywane
obciążenie
chmury
tolerancja LT+ jest stała
prognoza - cel obciążenia LT
ruchome
okno
czasowe

tolerancja LTt
t1
t2
t3
t4
t5
t6
t7
Zasady transferu – skąd i dokąd
Z których węzłów chmury usunąć przewidywane zadania przetwarzania
danych?
• Ze wszystkich węzłów, których przewidywana charakterystyka obciążenia
przekracza zadany zakres - przeciążenie.
Na które węzły chmury należy przesunąć zadania przetwarzania danych z
przeciążonych węzłów?
• Na te węzły, których przewidywana charakterystyka obciążenia zawiera
przedziały danych o obciążeniu mniejszym niż zadane.
Te same węzły chmury mogą być jednocześnie przeciążone i niedociążone w
różnych przedziałach czasowych.
przeciążenie
przewidywane
obciążenie
węzła
cel obciążenia
tolerancja
niedociążenie
t1
t2
t3
t4
t5
t6
t7
t
Zarządzanie obciążeniem węzła chmury
Przeciążone i niedociążone węzły chmury, to jest takie, które nie mieszczą się
w dozwolonych granicą obciążeniach, umieszczają informacje o swoich
wektorach niezrównoważenia UL, w scentralizowanej strukturze danych,
nazwanej tablicą ogłoszeń. Wektory niezrównoważenia są wyznaczane jako
różnica między sumarycznym wektorem obciążenia LTSi, a wektorem celu
obciążenia LT.
Wektor niezrównoważenia ma dwie składowe: przeciążenia UL+ i niedociążenia
UL-.
t2
obszar tolerancji
UL+
LT
UL
UL-
LTSi
t1
Poprawność współbieżnego
dostępu do danych
w chmurze replikowanych
baz danych
Spójność replikowanej bazy danych
W replikowanej bazie danych modyfikacje pojawiają się w różnej
kolejności na różnych replikach tej samej danej, ale dostępne są
mechanizmy, które powodują, że po pewnym czasie repliki
przyjmują ostatecznie tę samą wartość.
W rozwiązaniu idealnym replikowana baza danych zachowuje się
tak samo, jak równoważna jej niereplikowana baz danych.
One Copy Serializability - 1SR
strumień
transakcji
x'
y'
x"
replikowana
z"
baza danych
z'
x"'
y"

strumień
transakcji
x
y
niereplikowana
baza danych
z
Hipoteza Brewera
Założenie:
Trzy cechy własności danych przechowywanych w
rozproszonych bazach danych są pożądane i
oczekiwane:
• C: spójność danych
• A: dostępność danych
• P: odporność na podział sieci
Spójność danych
• W twierdzeniu Brewera przez spójność rozumie się spójny sposób
widzenia pojedynczej zreplikowanej danej, taki że w danym momencie
dana pokazuje wszystkim tę samą wartość. Dana jest spójna, jeżeli
istnieje globalny porządek wszystkich operacji na danej, taki jak gdyby
każda z operacji była wykonywana na pojedynczej danej (mimo
istnienia jej replik).
• Są dziedziny zastosowań, które nie wymagają tak restrykcyjnej
definicji spójności i dopuszczają przejściowe niespójności widzenia
danych. Przykładem mogą być bazy danych Googla, zawierające
najczęściej używane słowa w wyszukiwarkach lub powiązania między
stronami WWW. Chwilowa, nieaktualna kolejność podpowiedzi przy
wyszukiwaniu, zmiany w rankingu stron, nie przesądzają o
użyteczności uzyskanych wyników. Z kolei, np. system sprzedaży
używany przez Amazon, nie może dopuszczać niespójności (nie ta
cena, nie ten klient, nie ten towar).
Dostępność danych
• System informatyczny powinien być ciągle dostępny w ten
sposób, że każde zgłoszone żądanie powinno być obsłużone.
To jest, algorytm realizujący wywołaną usługę powinien się
kiedyś (w zadanym czasie) się zakończyć.
• Potencjalną przyczyną braku odpowiedzi jest niedostępność
serwera przechowującego pożądane dane. Usługi
udostepniające dane powinny być odporne na awarie
serwerów i połączeń komunikacyjnych.
• Ogólną dostępność rozproszonej bazy danych można
zwiększyć przez replikację danych na różnych serwerach.
Wtedy dostępność systemu rozproszonego jako całości będzie
większa niż dostępność poszczególnych komponentów.
Odporność na podział sieci
• Podział sieci jest szczególnym rodzajem awarii sieci,
polegającym na tym, że wszystkie komunikaty przesyłane z
węzłów jednej z podsieci do drugiej podsieci – i na odwrót - są
gubione.
• Usługa przetwarzania danych powinna być odporna również
na ten typ awarii.
• Podział sieci pociąga za sobą potencjalną utratę spójności
danych, ponieważ podzielone podsieci mogą utrzymywać
różne wartości replik tej samej danej.
Hipoteza Brewera
Hipoteza Brewera: W danym momencie, tylko dwie z trzech pożądanych
cech CAP mogą być spełnione przez rozproszony system bazy danych.
W wypadku wystąpienia podziału sieci można zapewnić tylko dwie z
trzech pożądanych cech:
• System klasy CA - spójny i dostępny, w którym nie występuje podział
sieci. Podział sieci oznacza awarię całego systemu lub zmianę klasy na
CP lub AP.
• System klasy CP – spójny mimo podziału sieci, ale o ograniczonej
dostępności. Niedostępność pojedynczych serwerów oznacza
niemożność obsługi pewnych żądań. Podział sieci oznacza
dostępność tylko jednej z podsieci (ograniczenie dostępności).
• System klasy AP – dostępny mimo podziału sieci, ale nie
zapewniający spójności danych. Po podziale sieci repliki tej samej
danej przestają być spójne.
Po pewnej formalizacji, hipoteza Brewera przybrała nazwę twierdzenia
CAP.
Kolejny kompromis: spójność, czy opóźnienie
W systemach klasy CA i CP koszt zapewnienia spójności replik może
być bardzo duży. Narzut na utrzymanie spójności replik może
spowodować, że system o dużej dostępności może "wydawać się"
niedostępny.
Sposób definiowania następnych klas systemów iPACELC.
Jeżeli if wystąpi podział sieci P to system preferuje dostępność A, czy
spójność C? W przeciwnym wypadku Else (nie ma podziału - system
klasy AC), ważniejsze jest ograniczenie opóźnienia L, czy spójność C?
• PA/EL: przed podziałem – dostępność, po – wydajność; Dynamo,
SimpleDB, Cassandra, Riptano, CouchDB, Cloudant
• PC/EC: zawsze spójność - DDBMS o własnościach ACID
• PA/EC: przed podziałem - spójność, po – dostępność; GenieDB
• PC/EL: sens istnienia takich systemów jest kwestionowany
Poziomy spójności replikowanej bazy danych
• Ścisła spójność (strict consistency) - każdy odczyt danej zwraca
jej ostatnią (według globalnego zegara) zapisaną wartość.
a) ściśle spójne
P1: r(x)12, w(x)7
P2:
r(x)7
b) nieściśle spójne
P1:r(x)12, w(x)7
P2:
r(x)12, r(x)7
Zapewnienie ścisłej spójności w środowisku rozproszonym
wymagałoby dostępu do globalnego zegara. Wszystkie zapisy są
natychmiast widoczne we wszystkich replikach.
w(x)7
w(x)13
P1
send
r(x)7
P2
r(x)13
• Sekwencyjna spójność (sequential consistency) – odczyty danych wszystkich
procesów widzą taką samą kolejność modyfikacji danych.
a) sekwencyjne
P1: w(x)21
P2:
? w(x)7
P3:
r(x)7
r(x)21
P4:
r(x)7 r(x)21
b) niesekwencyjne
P1: w(x)7
P2:
w(x)21
P3:
r(x)7
r(x)21
P4:
r(x)21
r(x)7
Dana historia współbieżnego dostępu do zbioru replik danej jest sekwencyjna,
jeżeli jest ona zgodna ze wszystkimi historiami dostępu do poszczególnych
replik i w dodatkowo w tej historii wszystkie odczyty dotyczą ostatnich
poprzedzających je zapisów.
H1: w1(x)21
H: w2(x)7, r3(x)7, r4(x)7, w1(x)21, r3(x)21, r4(x)21
H2: w2(x)7
H3: r3(x)7, r3(x)21
H4: r1(x)7, r1(x)21
• Przyczynowa spójność (causal consistency) – zapisy powiązane związkiem
przyczynowym muszą być widziane przez wszystkie współbieżne procesy w
tym samym porządku. Niezależne współbieżne zapisy mogą być widziane
przez różne procesy w różnej kolejności. Nie ma potrzeby zachowywania
porządku niepowiązanych zdarzeń.
P1: w(x)21
P2:
P3:
P4:
w(x)13
r(x)21
w(x)7
r(x)21
r(x)21
Dany graf zależności między operacjami.
Ulubiony przykład:
1. Usunięcia swojego szefa z listy znajomych.
2.
r(x)7
r(x)13
r(x)13
r(x)7
Powiązane operacje modyfikacji
w(x)21 i w(x)7, są widziane przez
wszystkie procesy w poprawnej
kolejności: przyczyna skutek.
Wysłanie do listy znajomych informacji: "Mój szef jest okropny, szukam
nowej pracy"
• "Ostateczna" spójność (ang. eventual consistency) – jeżeli, odpowiednio
długo nie będą wykonywane żadne operacje modyfikacji, to w końcu
(ostatecznie) wszystkie repliki będą spójne (będą miały tę samą wartość).
Maksymalny rozmiar okna niespójności będzie zależał od opóźnień
komunikacyjnych, obciążenia systemu, liczby replik, używanych protokołów,
itp.
Ostateczna spójność wymaga poprawnego rozwiązywania konfliktów
współbieżnych modyfikacji różnych replik.
P1: w(x)21
w(x)13
P2:
w(x)7

eventual 
P3:
r(x)7
r(x)21
r(x)13
P4:
r(x)13
r(x)21
r(x)13
Kolejne żądania odczytu tego samego procesu mogą trafiać do różnych
replik, ze względu na ich dostępność lub równoważenie obciążenia.
Utrzymanie spójności replik danych
Klasy protokołów:
• Synchroniczne - 1SR – wszystkie repliki są uspójniane
w ramach tej samej transakcji, która modyfikuje
replikowaną daną. Ta klasa protokołów gwarantuje
silną spójność danych.
• Asynchroniczne – proces uspójniania replik działa
niezależnie od transakcji modyfikujących dane. Ta
klasa protokołów może być stosowana zarówno dla
silnej, jak i słabej spójności.
Proces utrzymywania replik
• Przekaż nową wartość/poinformuj inne repliki o zmianie
wartości (push)
• Sprawdź i pobierz wartość innej repliki (pull)
Algorytmy epidemiczne:
• Modyfikacje są początkowo wykonywane na jednej lub
niewielkim podzbiorze replik
• Repliki przesyłają swoje aktualne stany do ograniczonego
zbioru sąsiadów (push)
• Propagacja modyfikacji nie jest natychmiastowa
• Ostatecznie modyfikacje trafiają do wszystkich replik
Algorytmy epidemiczne
• Anty-entropia: Każda replika periodycznie
wybiera losowo inną replikę dla dwustronnej
wymiany stanów (push&pull), po której są
identyczne.
• Rumor mongering – Uaktualniona replika
periodycznie wybiera losowo inne repliki dla
przekazania modyfikacji (push)
• Gossiping: Uaktualniona replika informuje z
określonym prawdopodobieństwem pewną
liczbę innych replik o tej modyfikacji.
Asynchroniczne utrzymywanie replik
Trzy podstawowe rozwiązania:
• Primary Copy – wszystkie modyfikacje są adresowane do wybranej
pojedynczej repliki, a następnie asynchronicznie propagowane do
pozostałych replik. Operacje odczytu zwracają wartość jednej z replik.
• Multi-Master Copies – modyfikacje są adresowane do jednej z wielu
replik, a następnie są propagowane do pozostałych replik. W wypadku
wystąpienia konfliktu modyfikacji na replice, konfliktowe modyfikacje są
łączone (merge). Operacje odczytu zwracają wartość jednej z replik.
• Kworum - modyfikacje są adresowane do podzbioru replik o określonej
wielkości, a następnie asynchronicznie propagowane do pozostałych
replik. Wartość danej zwracanej przez operacje odczytu jest odczytywana z
podzbioru replik i wybierana poprzez konsensus między wartościami
odczytanych replik. Gwarantuje to odczyt najnowszej modyfikacji kworum do synchronizacji odczytów i modyfikacji. Równoległe
modyfikacje są synchronizowane przez kworum operacji modyfikacji.
Metoda Primary Copy
Gwarantuje globalny porządek modyfikacji danych – ostateczna spójność.
W wypadku podziału sieci klienci nie mający dostępu do węzła z główną
kopią danej:
• nie będą mogli jej modyfikować,
• nie będą mieli dostępu do najświeższych wartości danych.
modyfikacje
Primary
Copy propagacja
modyfikacje
modyfikacji
Najprostsza w implementacji i
wiążąca się z najmniejszymi
narzutami systemowymi.
odczyt
odczyt
odczyt
Secondary
Copies
Protokół zdalnej modyfikacji – Primary Copy
• Modyfikacje są realizowane jako operacje blokujące
Metoda Multi-Master Copies
W ogólności modyfikacje różnych replik mogą być konfliktowe.
Zapewnienie ostatecznej spójności wymaga:
• komutatywnych operacji modyfikacji, np. przyrostowych,
• mechanizmów detekcji konfliktowych modyfikacji i ich
odczyt i
integracji (mergeable).
W wypadku podziału sieci
niezależnie utrzymywane
repliki będą mogły być
uspójnione po połączeniu
podzielonych podsieci.
uspójnianie
modyfikacja
odczyt i
modyfikacja
odczyt i
modyfikacja
propagacja
modyfikacji
uspójnianie
Metoda kworum
Poprawność operacji odczytu i modyfikacji jest kontrolowana przez
mechanizm kworum wymagający zgody na określone rozwiązanie
danego konfliktu poprzez decyzję większości węzłów.
Modyfikacja i odczyt będą dotyczyć najświeższej wersji danej.
W wypadku podziału sieci
część użytkowników
write quorum = 3
połączona z mniejszym
fragmentem sieci, nie będzie
mogła czytać lub
modyfikować danych.
modyfikacja
odczyt
read quorum = 3
Realizacja metody kworum
Realizacja operacji odczytu:
• zdobądź odpowiednią liczbę replik, które będą stanowiły
kworum dla operacji odczytu,
• wybierz spośród wybranych replik tę o najwyższym
identyfikatorze wersji,
• odczytaj wartość tej replikę.
Realizacja operacji zapisu:
• zdobądź odpowiednią liczbę replik (kworum do zapisu),
• wybierz replikę z największym numerem wersji,
• zwiększ numer wersji,
• zapisz nową wartość do wszystkich replik wchodzących w
skład kworum oraz przypisz im nowy numer wersji.
Modele spójności replik – perspektywa serwera
Niech:
• N = liczba węzłów, które przechowują repliki danych,
• W = ilość replik, które muszą potwierdzić modyfikację, dla
skompletowania operacji zapisu,
• R = liczba replik, do których jest wykonywany dostęp podczas
operacji odczytu.
Modele spójności:
• W + R > N – czytane i zapisywane zbiory replik pokrywają się,
co przy stosowaniu protokołów klasy quorum gwarantuje silną,
tj. sekwencyjną spójność rozproszonej bazy danych. Dla N=2,
W=2 i R=1. Modyfikowane są wszystkie (dwie) repliki, odczyt
dotyczy dowolnej z nich.
Modele spójności replik
• R = 1, W = N – optymalizacja pod kątem wydajności operacji
odczytu; wystarcza odczyt pojedynczej wersji. Operacje zapisu
dotyczą wszystkich replik, co zmniejsza ich wydajność i
dostępność operacji modyfikacji.
• R = N, W = 1 – optymalizacja pod kątem wydajności operacji
zapisu; bezpośredni zapis dotyczy pojedynczej kopii danej.
Kolejne repliki są modyfikowane w oknie niespójności.
Operacja odczytu wymaga dostępu do wszystkich replik, by
wybrać najświeższą wartość danej. Mniejsza wydajność i
dostępność operacji odczytu.
• R > 0.5*N, W > 0.5*N – symetria w traktowaniu operacji
odczytu i zapisu.
• W > 0.5*N – synchronizacja operacji zapis-zapis.
• W+R<=N – słaba, ostateczna spójność.
Spójność replik – co można ulepszyć
Model Primary Copy – W=1 i R=1.
praca systemu
rozproszonego
Tak
Podział?
Nie
Odczyt?
Tak
dostęp do
Primary Copy?
Nie
C'AP
komutatywne
lub łączne
operacje?
Tak
Tak
C'A
niegwarantowany dostęp
do aktualnej wersji
- ostateczna spójność
Nie
niezależne
Primary Copy w
podsieciach
niedostępność dla
modyfikacji
AP
Nie
Niespójność danych w metodzie Primary Copy
• Z definicji brak dostępu do najświeższej zatwierdzonej
wartości danej (brak ścisłej spójności) – repliki do odczytu są
utrzymywane asynchronicznie.
• Różna kolejność odczytu modyfikacji danych (brak
sekwencyjnej spójności) – ze względu na algorytm wyboru
repliki do odczytu: czasowa niedostępność replik,
równoważenie obciążenia.
• Modyfikacja wersji danej inna niż odczytana (no causal) –
odczyt najbliższej repliki i na jej podstawie modyfikacja
primary copy.
• Brak dostępu do zmodyfikowanej danej (no causal) –
modyfikacja danej (primary copy) i następnie odczyt tej danej,
który jest wykonany na innej replice.
Niezależnie od występowania podziału sieci najwyższy osiągalny
poziom spójności to ostateczna spójność.
Model MultiMaster Copies – W=1 i R=1.
praca systemu
rozproszonego
Podział?
Nie
Odczyt?
Tak
Tak
C'A
Nie
komutatywne
lub łączne
operacje?
Nie
Tak
po połączeniu rozdzielonych
podsieci, będzie można
uspójnić dane
C'AP
AP
ostateczna spójność
brak spójności
Niespójność danych w metodzie MultiMaster
• Brak dostępu do najświeższej zatwierdzonej wartości danej
(no strict) – repliki są utrzymywane asynchronicznie.
• Różna kolejność odczytu modyfikacji danych (brak
sekwencyjnej spójności) – ze względu na algorytm wyboru
repliki do odczytu: czasowa niedostępność replik,
równoważenie obciążenia.
• Konfliktowe modyfikacje – (no causal)
Niezależnie od występowania podziału sieci najwyższy osiągalny
poziom spójności to ostateczna spójność. Metoda odporna na
podział sieci, w tym znaczeniu, że podział nie pogarsza
wyjściowego poziomu spójności dla operacji odczytu i dla
komutatywnych lub łącznych modyfikacji.
Protokół quorum R+W>N
praca systemu
rozproszonego
Podział?
Tak
Nie
CA
Tak
Quorum?
Nie
dostępność i spójność
C'P
po połączeniu rozdzielonych
podsieci, będzie można
przywrócić spójność
Tak
komutatywne
lub łączne
operacje?
Nie
brak spójności
AP
Niespójność danych w metodzie Kworum
• W systemie pracującym bez podziału sieci gwarantowana
sekwencyjna spójność.
• Po podziale sieci, dla mniejszej z podsieci wybór między
spójnością, a dostępnością. Albo dostęp do mniejszej podsieci
zostanie zablokowany przez brak kworum CP, albo naruszona
zostanie spójność danych. Dla komutatywnych lub łącznych
operacji możliwa będzie poprawna integracja replik po
ponownym połączeniu sieci – ostateczna spójność.
Niespójność współbieżnych modyfikacji
Współbieżny dostęp do różnych replik tej samej danej może być
przyczyną niespójności przetwarzania danych.
• Metoda Multi Master Copies – wymaga bezustannego
uspójniania równolegle utrzymywanych replik.
• Metoda Primary Copy – mogłyby pozwolić na modyfikacje po
podziale sieci w tych podsieciach, które nie zawierają Primary
Copy, by po odtworzeniu połączenia uspójnić niezależnie
modyfikowane wartości Primary Copy.
• Metoda Kworum - mogłyby pozwolić na modyfikacje po
podziale sieci w tych podsieciach, które nie mają kworum, by
po odtworzeniu połączenia uspójnić wartości replik.
Komutatywność lub łączność operacji
Niezależnie modyfikowane repliki danych mogą być uspójniane
jeżeli operacje modyfikacji są:
• komutatywne: o1(o2(replikai) = o2(o1(replikaj));
Przykładem operacji komutatywnych może być przyrostowa
modyfikacja danych.
(x+=2)+=4  (x+=4)+=2
• możliwe do scalenia (mergeable): M(o2,o1) umieść wynik
przetwarzania o2 w o1, to znaczy na podstawie dwóch
równolegle modyfikowanych wersji, utwórz trzecią.
Przykładem może być równoległa modyfikacja różnych
atrybutów tej samej danej (Cassandra).
x'.a=7 || x".b=13  x'.b=13, x".a=7
Thomas' Write rule
• Przydziel znacznik czasowy każdej operacji modyfikacji.
• Każda replika pamięta znacznik czasowy ostatniej wykonanej na niej
modyfikacji.
• Zaaplikuj modyfikacje trafiające do repliki x, tylko wtedy, gdy spełniony jest
warunek:
operacja.timestamp > x.timestamp
• Stąd na każdej z replik aplikowane są tylko najświeższe modyfikacje.
Przykładowy strumień modyfikacji jest następujący:
<W(X=40), TS:1>, <W(X=70), TS:5>, <W(X=30), TS:3>
Ostateczna wartość repliki:
<X=70, TS:5>
Inne metody uspójniania: wybór wartości mniejszej, większej, o
większym priorytecie, itd.
Zegar wektorowy
Zegary realizowane w systemach asynchronicznych mają stanowić
aproksymację czasu rzeczywistego. Aproksymacja taka uwzględnia
jedynie zdarzenia zachodzące w systemie i dlatego czas ten jest
nazywany czasem wirtualnym (logicznym). Czas wirtualny
wyznacza się za pomocą tzw. zegarów logicznych. Zegarem
logicznym nazywamy abstrakcyjny mechanizm, który
przyporządkowuje wybranym zdarzeniom czas wirtualny.
Zegary logiczne posiadają następujące własności:
• jeżeli w pewnym procesie zdarzenie e1 zachodzi przed
zdarzeniem e2, to czas wirtualny przypisany zdarzeniu e1 jest
mniejszy niż czas przypisany zdarzeniu e2,
• w wypadku wysyłania wiadomości czas wysłania wiadomości
jest mniejszy niż czas odebrania tej wiadomości.
Zegar wektorowy
Zegar wektorowy rozproszonego systemu n procesów jest
wektorem n logicznych zegarów – jeden zegar na jeden proces.
I-ty zegar logiczny wektora reprezentuje czas wirtualny procesu i.
Każdy proces przechowuje swoją wersję całego zegara
wektorowego.
Procesy modyfikują swój zegar logiczny w swoim zegarze
wektorowym w wypadku wysyłania i odbierania komunikatów.
Do komunikatów przesyłanych między poszczególnymi procesami
dołączany jest, jako etykieta czasowa, zegar wektorowy procesu
wysyłającego.
Po odebraniu komunikatu procesu i przez proces j, proces
odbierający modyfikuje swój zegar wektorowy:
1kn, VClockj[k] = max{VClocki[k], VClockj[k]}
Relacje między zegarami wektorowymi
Dane są dwa zegary wektorowe Vclocki i VClockj. Mogą między nimi
zachodzić następujące relacje:
Vclocki = VClockj  k VClocki[k] = VClockj[k]
Vclocki  VClockj  k VClocki[k]  VClockj[k]
Vclocki  VClockj   k VClocki[k]  VClockj[k]
Vclocki  VClockj  k VClocki[k] > VClockj[k]
Vclocki < VClockj  VClocki  VClockj  VClocki  VClockj
Vclocki < VClockj  (VClocki  VClockj  VClocki  VClockj)
Vclocki || VClockj  VClocki < VClockj  VClockj < VClocki
Zegar wektorowy
Zegar wektorowy generując częściowy porządek zdarzeń w
systemie rozproszonym umożliwia detekcję naruszenia zależności
przyczynowo skutkowych, w szczególności kolejności zmian replik
danej.
W każdym momencie:
i,j: VClockj[i]  VClocki[i]
Wektory wersji
Wektory wersji są wyspecjalizowanym typem zegarów wektorowych służącym
do wykrywania konfliktów równolegle modyfikowanych replik.
Każda z replik danej x przechowuje swój wektor wersji (V 𝑘𝑖) . Rozmiar każdego
wektora jest równy liczbie replik. Indeksy wektora odwołują się do
poszczególnych replik, a wartości składowych odpowiadają liczbie modyfikacji
danej repliki. Pozycja i-ta i-tego wektora reprezentuje lokalną wersję danej.
Na wektorach wersji wykonywane są trzy typy operacji:
∀
1. Jednorazowa inicjacja wektora: (V 𝑘𝑖) =0
𝑘
{
ri: (V 𝑘𝑖) =
V 𝑘𝑖+1; 𝑖𝑓 𝑖 = 𝑘
V 𝑘𝑖
2.
Modyfikacja repliki
3.
Synchronizacja replik ri i rj: (V 𝑘𝑖) = (V 𝑘𝑗) = max(V 𝑘𝑖 , V 𝑘𝑗 )
W porównaniu z zegarami wektorowymi, operacja synchronizacji jest
pojedynczą operacją dwustronnej komunikacji replik.
Wektory wersji
Przykładowa historia utrzymania wektorów wersji dla replik r1 i r2.
r1: (0,0)U(1,0)S(1,0)
S(1,2)
r2: (0,0)
S(1,0)U (1,1)U (1,2)S(1,2)
Operacja synchronizacji porównuje wszystkie składowe
synchronizowanych wektorów. Wynik porównania może być
trojaki:
1. (V 𝑘𝑖) = (V 𝑘𝑗) - replika ri jest taka sama jak replika rj ,
2. (V 𝑘𝑖) (V 𝑘𝑗) - replika ri jest starsza od repliki rj i musi być
odświeżona wartością repliki rj,
3. (V 𝑘𝑖) ||(V 𝑘𝑗) - wartości replik ri i rj były współbieżnie
modyfikowane i repliki te muszą być scalone.
Wzmocnienie ostatecznej spójności –
perspektywa klientów
W pewnych zastosowaniach model ostatecznej spójności jest zbyt
słaby. Propozycje silniejszych modeli spójności:
• Spójność historii (consistent prefix) – dla danego globalnego
porządku modyfikacji dostępne są tylko spójne wersje replik
wynikające z uporządkowanej historii zmian.
Dla danego porządku modyfikacji: x=0, y=0, x=1, x=2, y=1
dostępne są następujące odczyty: (x=0, y=0), (x=1, y=0),
(x=2, y=0), (x=2, y=1),
niedostępne są np. odczyty: (x=0, y=1), (x=1, y=1).
• Gwarantowana świeżość (bounded staleness) – gwarantuje, że
dane nie są przeterminowane ze względu na określony czas
ważności.
Dla terminu ważności 5 minut, odczytana wartość repliki została
zapisana nie wcześniej niż 5 minut temu, lub jest najświeższa.
Wzmocnienie ostatecznej spójności –
perspektywa klientów
• Czytaj swoje zapisy (read-your-writes) – dany proces po
modyfikacji danej x, będzie przy kolejnych odczytach widział
swoją modyfikację, a nie starsze wartości x.
• Spójność sesji (session consistency) – gwarantuje spójność RYW
w ramach danej sesji. Po przerwaniu danej sesji, nowa sesja nie
ma gwarancji RYW.
• Monotoniczność odczytów (ang. monotonic read consistency) –
jeżeli proces zobaczył wartość danej, to kolejne dostępy nigdy nie
zwrócą starszych wartości tej danej.
• Monotoniczność zapisów (ang. monotonic write consistency) –
system rozproszony gwarantuje zachowanie lokalnych
porządków modyfikacji wszystkich procesów. Globalny porządek
zapisów honoruje wszystkie porządki lokalne.
Własności wybranych poziomów spójności
Kompromis między poziomem spójności, wydajnością i
dostępnością danych.
Poziom spójności
Spójność
Wydajność
Dostępność
Strict consistency
excellent
poor
poor
Consistent prefix
okay
good
excellent
Bounded staleness
good
okay
poor
Read my writes
okay
okay
okay
Monotonic reads
okay
good
good
Eventual consistency
poor
excellent
excellent
Użyteczność poziomów spójności
Replicated Data Consistency Explained Through Baseball Doug
Terry, Microsoft Research Silicon Valley.
Dwie dane w bazie danych:
• punkty gospodarzy
• punkty gości
Statystycy dodatkowo przetwarzają sumę punktów w sezonie
Official scorekeeper Read my writes
Umpire
Strong Consistency
Radio reporter
Consistent Prefix & Monotonic Reads
Sportswriter
Bounded Staleness
Statistician
Strong Consistency, Read My Writes
Stat watcher
Eventual Consistency
Przykładowy protokół kworum - Paxos
Protokół Paxos zakłada istnienie trzech ról, w których mogą
występować procesy:
• proposers (proponujących),
• acceptors (akceptujących),
• learners (poznających).
Pojedynczy proces może występować w kilku rolach.
Procesy mogą kontaktować się ze sobą za pomocą przesyłania
komunikatów (w modelu asynchronicznym, niebizantyjskim).
• Procesy działają z dowolnymi prędkościami, mogą doznać awarii
skutkującej zatrzymaniem ich pracy i mogą być restartowane.
Agenci muszą pamiętać poznane wartości również po awarii.
• Komunikaty mogą być dowolnie długo przetwarzane,
duplikowane i gubione, ale nie mogą być niepoprawne.
Protokół Paxos – ustalanie wartości
Protokół przewiduje przesyłanie między procesami czterech
rodzajów komunikatów:
• żądanie prepare
• odpowiedź promise
• żądanie accept
• informacja accepted
Aceptors
Learner
Proposer
Aceptors
Komunikat żądania "prepare"
W pierwszym kroku, każdy z procesów proponujących wysyła
żądanie prepare do wszystkich procesów akceptujących
zawierający proponowaną wartość v i numer propozycji n.
Numer propozycji n musi być liczbą naturalną, unikalną i
zwiększaną w sposób monotoniczny.
W podanym przykładzie dwa
procesy A i B przesyłają swoje
propozycje wartości: proces A
proponuje wartość 8, a B
wartość 5, do trzech procesów
akceptujących X, Y i Z. Strzałki
ilustrują kolejność odbierania
komunikatów przez procesy
akceptujące.
* przykład Agnus Mac Donald
Komunikat odpowiedzi "promise"
Proces akceptujący odbierając pierwsze żądanie prepare,
odpowiada komunikatem promise, którym zobowiązuje się nie
zaakceptować wartości o numerze propozycji niższym niż
odebrany.
W przykładzie procesy wszystkie procesy akceptujące X, Y i Z
odpowiadają na pierwsze żądania prepare.
Komunikat odpowiedzi "promise"
Proces akceptujący ignoruje kolejne żądania prepare o mniejszych
numerach niż już odebrane. Jeżeli kolejne żądanie prepare ma
większy numer, proces akceptujący odpowie na nie komunikatem
promise, w którym dodatkowo przekaże informacje o największym
numerze i wartości poprzednich propozycji.
W analizowanym przykładzie procesy akceptujące X i Y przesyłają
odpowiedź procesowi B, przekazując jednocześnie informacje o
poprzednich przyjętych
propozycjach. Proces Z
ignoruje żądanie procesu A.
Komunikat żądania "accept"
Proces proponujący, który odbierze potwierdzenie promise od
większości procesów akceptujących do których wysłał swoje
żądanie prepare, wysyła do nich wszystkich żądanie accept,
ponownie przekazując informacje o numerze i wartości propozycji.
Procesy akceptujące ignorują żądania accept od procesów o
wartościach propozycji mniejszych niż już przez nie przyjęte.
accept request
W analizowanym przykładzie proces A
[n=2, v=4]
przesyła żądania accept do procesów
X i Y. Te żądania są ignorowane, ponieważ procesy te odebrały już propozycje
o wyższych numerach. Z kolei
żądania accept procesu B, zostaną
przyjęte.
Komunikat potwierdzenia "accept"
Procesy akceptujące po odebraniu żądania accept o najwyższym
numerze odebranego żądania prepare, wysyłają komunikat
accepted do wszystkich procesów poznających wartości.
W analizowanym przykładzie, procesy akceptujące X, Y i Z
przesyłają komunikaty accepted do procesu poznającego.
Protokół Paxos – zasady działania
Liczba serwerów akceptujących.
Pojedynczy serwer akceptujący powodowałby dużą wrażliwość
systemu na awarie. Duża liczba serwerów akceptujących
gwarantuje wysoką dostępność systemu. Proponowane wartości
są przesyłane do zbioru wszystkich węzłów akceptujących.
Sposób wyboru
Wybór jednej wartości jest gwarantowany w wyniku tego, że
wybrana wartość musi być zaakceptowana przez większość
serwerów akceptujących (konsensus).
Akceptowanie wartości
Protokół ma działać również w sytuacji, gdy tylko jedna wartość
zostanie zaproponowana przez pojedynczy serwer proponujący.
Protokół Paxos – zasady działania
Akceptowanie wartości cd
Gdyby serwery akceptujące mogły akceptować tylko jedną
wartość (pierwszą otrzymaną), to prawdopodobieństwo przyjęcia
przez większość serwerów tej samej wartości, byłoby bardzo mała.
Dlatego pojedynczy serwer akceptujący może akceptować wiele
wartości.
Dla porównywania różnych propozycji muszą one być
jednoznacznie identyfikowane przez numer propozycji. Propozycje
danej wartości wysyłane przez serwer proponujący do różnych
serwerów akceptujących muszą mieć ten sam numer.
Zastosowanie protokołu Paxos
• Wszystkie węzły odgrywają wszystkie role.
• Jeden z węzłów proponujących pełni rolę
lidera, który rozpoczyna proces wyboru
wartości, w wyniku żądania klienta chcącego
ustalić wartość.
• Protokół Paxos może być stosowany do
zatwierdzania rozproszonych transakcji,
ustalaną wartością jest sposób zakończenia
transakcji, lub do ustalania wartości danej ze
zbioru różnych replik.
Własności protokołu Paxos
• Nieblokujący – w przeciwieństwie do wielu
innych protokołów, np. 2PC
• Odporny na podział sieci – mniejsza podsieć
nie może wyłonić większości
• Wymaga przesyłania dużej liczby komunikatów
Model BASE
BASE – Basically Available, Soft state, Eventually Consistent
Nowy, mniej restrykcyjny model niż ACID, kładący nacisk na
dostępność.
Spójność jest osiągana "w końcu", po jakimś czasie, w związku z
tym niezbędne może się okazać rozwiązywanie logicznych
konfliktów:
• naprawa niespójnego odczytu,
• naprawa niespójnej modyfikacji,
• naprawy są wykonywane asynchronicznie do operacji odczytu i
zapisu.
Rozwiązywanie konfliktów bazuje na globalnym/częściowym
porządku operacji i ma zapewnić, że wszystkie repliki rozwiązują
ewentualne konflikty w taki sam sposób: zegary wektorowe.
Równoległe bazy danych
Równoległość przetwarzania w bazach danych
Cel
Skracanie czasu odpowiedzi w wyniku zrównoleglania algorytmów
realizujących operacje na stanie bazy danych.
Miarą skrócenia czasu odpowiedzi jest współczynnik speedup:
𝑠𝑒𝑞𝑢𝑒𝑛𝑐𝑒 𝑒𝑙𝑎𝑝𝑠𝑒𝑑 𝑡𝑖𝑚𝑒
𝑠𝑝𝑒𝑒𝑑𝑢𝑝 =
𝑝𝑎𝑟𝑎𝑙𝑙𝑒𝑙 𝑒𝑙𝑎𝑝𝑠𝑒𝑑 𝑡𝑖𝑚𝑒
Miarą skalowalności złożonych zapytań jest współczynnik scaleup:
𝑠𝑚𝑎𝑙𝑙 𝑝𝑟𝑜𝑏𝑙𝑒𝑚 𝑒𝑙𝑎𝑝𝑠𝑒𝑑 𝑡𝑖𝑚𝑒
𝑠𝑐𝑎𝑙𝑒𝑢𝑝 =
𝑏𝑖𝑔 𝑝𝑟𝑜𝑏𝑙𝑒𝑚 𝑒𝑙𝑎𝑝𝑠𝑒𝑑 𝑡𝑖𝑚𝑒
Wydajna równoległa realizacja zapytań wymaga zwiększenia
dostępnych zasobów: dysków, pamięci operacyjnej i procesorów.
Architektury równoległych baz danych
• Shared disc – duże wymagania na wydajność sieci komputerowej
• Shared memory - ułatwia synchronizację procesów (blokady, logi)
• Shared nothing – najbardziej skalowalna, najmniej interferencji w
przetwarzaniu ze względu na całkowitą rozdzielność zasobów,
najtrudniejsza do oprogramowania (systemowego) i zarządzania
M
M
M
Memory
P
P
P
Network
Network
D
D
D
Network
P
P
P
P
P
P
M
M
M
D
D
D
D
D
D
Równoległość w relacyjnych bazach danych
Relacyjny model pozwala na definiowanie złożonych zapytań (połączenia,
sortowanie, grupowanie, dedukcja), których wykonywanie na dużych zbiorach
danych wymaga długich czasów realizacji.
Plany zapytań dla RDBMS mogą być w naturalny sposób zrównoleglone, na
jeden z trzech sposobów:
a) interoperation pipelined parallelism,
b) interoperation horizontal parallelism,
c) intra-operation parallelism.
a)
sort
b)
join
merge
c)
scan
selekcja
selekcja
scan
scan
źródło
danych A
źródło
danych A
źródło
danych B
partycja A'
partycja A"
• Krytycznym zasobem w przetwarzaniu złożonych zapytań w
bazach danych są dyski. Stąd kluczowym typem operacji do
zrównoleglenia są operacje dyskowe. Zrównoleglenie
operacji dyskowych wymaga podziału danych (ang.
partitioned) na wiele dysków.
• Dzięki temu pojedyncze operacje relacyjne, takie jak:
skanowanie, sortowanie, łączenie, agregacja danych mogą być
wykonywane równolegle, przez osobne procesy.
• Zapytania wyrażane w języku SQL mogą być realizowane
równolegle w sposób transparentny dla programisty. Stąd
równoległość jest naturalnym rozszerzeniem relacyjnych baz
danych.
Partycjonowanie tabel
W relacyjnych bazach danych krotki relacji są
partycjonowane horyzontalnie na wielu dyskach w taki
sposób, że każda krotka jest ulokowana na dokładnie
jednym dysku.
Znanych jest kilka technik partycjonowania bazujących
na różnych sposobach redystrybucji danych między
różne partycje:
• partycjonowanie sekwencyjne Round Robin,
• partycjonowanie ze względu na przedziały wartości
danych,
• partycjonowanie z funkcją haszującą.
Partycjonowanie Round Robin
Dana tabela R i N dysków numerowanych od 0 do N-1.
Algorytm partycjonowania działa na zasadzie: wyślij i-tą
krotkę wstawianą do relacji R na dysk o numerze
równym i mod N.
0
1
2
N-1
…
Partycjonowanie Round Robin
Zalety:
• Dobrze zbalansowane wypełnienie poszczególnych dysków.
• Wydajna realizacja operacji wymagających skanowania całego
dysku.
• Niezależna od skośności rozkładu wartości danych
Wady:
• Nie wspiera punktowego i przedziałowego wyszukiwania
danych. Operacje te wymagają przeskanowania wszystkich
partycji danych.
• Nieprzydatne dla zwiększenia skalowalności strumienia
odwołań do niewielkich podzbiorów danych
(partycjonowanie, ale nie sharding).
Partycjonowanie zakresowe
• Jeden z atrybutów A relacji R jest wybierany, jako atrybut,
którego wartości będą decydowały o alokacji danej na
określonym dysku.
• Na podstawie znajomości rozkładu wartości atrybutu A, tworzony
jest wektor o liczbie elementów równej liczbie dysków:
[v0, v1, v2, …, vn-2].
• Krotki o wartościach atrybutu A równej v zostają umieszczone na:
– dysku o nr 0, jeżeli v < v0,
– dysku o nr N-1, jeżeli v  vN-2,
– dysku o nr i+1, jeżeli vi v < vi+1.
a-c
d-f
g-k
w-z
…
Partycjonowanie zakresowe
Zalety:
dysku.
• Wydajna realizacja operacji wymagających dostępu do
pojedynczych danych; wystarczy dostęp do pojedynczego dysku.
Pozwala uzyskać skalowalność dla prostych operacji.
• Wydajna dla zapytań zakresowych, o ile definicja zakresu
odwołuje się do atrybutu będącego podstawą partycjonowania.
Dla małego zakresu wartości operacja może się zamknąć na
pojedynczym dysku, dla dużego zakresu może być zrównoleglona.
Wady:
• Jakość zbalansowania danych jest zależna od znajomości rozkładu
danych.
• Jest wrażliwe na skośność rozkładu wartości atrybutu.
Partycjonowanie haszowe
• Jeden lub więcej atrybutów relacji R jest wybieranych jako
argumenty funkcji haszującej h, która generuje wartości z
przedziału od 0 do N-1. Krotka o wartości atrybutu
haszującego równej v zostanie umieszczona na dysku o
numerze i = h(v).
0
1
2
N-1
…
Partycjonowanie haszowe
Zalety:
dysku, przy wykorzystaniu równoległości.
• Wydajna realizacja operacji wymagających dostępu do
pojedynczych danych; wystarczy dostęp do pojedynczego dysku.
• Jeżeli atrybutem haszującym jest klucz, to dla dobrej funkcji
haszującej gwarantuje zbalansowany rozkład danych.
Wady:
• Nie wspiera punktowego i przedziałowego wyszukiwania
danych. Operacje te wymagają przeskanowania wszystkich
partycji danych.
• Jeżeli atrybut haszujący nie ma własności klucza, jakość
dystrybucji danych jest wrażliwa na skośność rozkładu wartości
atrybutu.
Skośność dystrybucji danych
Wynikiem partycjonowania może być nierównomierna (skośna)
dystrybucja danych na poszczególnych dyskach. Jedne dyski
mogą zawierać więcej, inne mniej krotek. Skośność
partycjonowania zmniejsza wydajność równoległych algorytmów
przetwarzania. Źródłami skośności mogą być:
• Skośność wartości atrybutów, polegająca na wielokrotnym
powtarzaniu się pewnych wartości atrybutu. Ogranicza ona
jakość partycjonowania haszowego i bazującego przedziałach
wartości.
• Skośność partycjonowania, występująca w partycjonowaniu
bazującym na przedziałach wartości. Polega na nieprawidłowym doborze wartości granicznych przedziałów.
• Ze względu na prostotę obliczeń oraz na własności pewnych
operacji relacyjnych - zrównoleglanie przetwarzania operacji
relacyjnego modelu danych jest stosunkowo proste – w
porównaniu tradycyjnymi obliczeniami równoległymi.
• Przyjmijmy następujące założenia:
– architektura shared-nothing
– rozproszony system składa się z n serwerów, każdy z
pojedynczym dyskiem i procesorem.
• Operacje będą wykonywane na relacjach R i S, których
rozmiary wyrażone w blokach dyskowych wynoszą
odpowiednio b(R) i b(S).
Czas równoległego wykonania operacji
Jeżeli pominiemy dodatkowy narzut związany z równoległą
realizacją operacji i założymy brak skośności partycjonowania
danych, to oczekiwany czas wykonywania operacji na n
równoległych serwerach będzie równy 1/n czasu realizacji
sekwencyjnej.
Bardziej realistyczne oszacowanie czasu równoległej realizacji
wynosi:
Tpatrycjonowania + Tintegracji_wyników + max(T1, T2, …, Tn)
gdzie Ti jest czasem przetwarzania danych pojedynczej partycji
na węźle i.
Równoległe realizacje metod dostępu
Dla większości znanych algorytmów implementujących operacje
relacyjne można podać ich wydajne równoległe realizacje o
współczynniku speedup równym n:
• selekcja krotek relacji
• skanowanie całej relacji
• połączenia relacji
• sortowanie krotek relacji
• wyznaczanie wartości dla funkcji statystycznych o
własnościach rozłączności i przemienności – sum, min, max
oraz takich, które da się zastąpić funkcjami o takich
własnościach (distributive, algebraic – count, avg, stddev,
variance)
Równoległy algorytm selekcji
Dana operacja selekcji na relacji R: A=v(R) lub v1Av2(R)
R=R1R2…Rn  C(R) = C(R1) C(R2)…C(Rn)
• Czas sekwencyjnego wykonania tej operacji, przy założeniu
braku indeksu na atrybucie A, jest równy czasowi odczytu b(R)
bloków dyskowych.
• Czas równoległego wykonania tej operacji, jest niewiele
większy od czasu odczytu b(R)/n operacji dyskowych.
Jednakże obciążenia poszczególnych procesorów zależy od
przyjętego sposobu partycjonowania.
– Partycjonowanie Round robin – wymaga równoległego wykonania
b(R)/n operacji dyskowych, przez każdy z serwerów.
– Partycjonowanie zakresowe – dokładnie jeden serwer dla warunku
A=v i co najmniej jeden dla warunku v1  A  v2.
– Partycjonowanie haszowe - dokładnie jeden serwer dla warunku A=v i
wszystkie serwery dla warunku v1  A  v2.
Równoległy algorytm agregacji
Dana operacja wyznaczania sumy wartości wybranego atrybutu
relacji R: sum(R.A)
R=R1R2…Rn 
sum(R) = sum(sum(R1.A), sum(R2.A),…, sum(Rn.A))
• Czas sekwencyjnego wykonania tej operacji, przy założeniu braku
indeksu na atrybucie A, jest równy czasowi odczytu b(R) bloków
dyskowych.
• Czas równoległego wykonania tej operacji, jest równy czasowi
odczytu b(R)/n operacji dyskowych, niezależnie od przyjętego
sposobu partycjonowania.
Partitioned join
Dla równościowych warunków połączeniowych (equi-join) jest możliwy podział
łączonych relacji R i S na partycje, bazujący na wartościach atrybutów
połączeniowych. Dla warunku połączeniowego R.A = S.B, węzeł Pi będzie
zawierał wszystkie krotki relacji R i wszystkie krotki relacji S, których wartości
atrybutów połączeniowych należą do tego samego przedziału (partycjonowanie
zakresowe takie samo dla atrybutów R.A i S.B) lub mają te same wartości
(partycjonowanie haszowe, ta sama funkcja haszowa dla R.A i S.B). Gwarantuje
to, że wszystkie krotki które da się ze sobą połączyć znajdą się na tym samym
serwerze.
Krok 1:
• Każdy z serwerów wykonuje równolegle operację połączenia wszystkich
przechowywanych na nim krotek jedną z klasycznych metod łączenia.
Krok 2:
• Wszystkie serwery wysyłają połączone krotki do pojedynczego serwera, który
sumuje (union) odebrane wyniki.
Koszt operacji połączenia jest zmniejszony dzięki równoległemu łączeniu
mniejszych relacji. Należy oczekiwać prawie n-krotnego zmniejszenia kosztu
wykonania operacji.
Równoległy algorytm hash-join
Partycjonowanie bazuje na funkcji haszowej.
Wykonaj operację połączenia tabel R i S z warunkiem
połączeniowym R.A = S.B. Kolejne kroki algorytmu są następujące:
• Pierwsza z relacji, niech będzie nią relacja S, jest rozpraszana
między wszystkie serwery za pomocą funkcji haszującej h1(t.B),
mającej n różnych wartości, gdzie n jest liczbą serwerów. Funkcja
haszująca h1 służy do zrównoleglania operacji join.
• Serwery odbierające krotki relacji S składują je lokalnie na
dyskach w pliku haszowym korzystając z docelowej funkcji
haszującej h2(t.B) (faza build).
• Następnie relacja R jest redystrybuowana na wszystkich
serwerach bazując na funkcji haszującej h1 między wszystkie
serwery.
• Serwery odbierające krotki relacji R umieszczają ją w pliku
haszowym (faza probe), korzystając z funkcji haszującej h2.
Asymmetric fragment-and-replicate join
Dla nierównościowych warunków połączeniowych (nonequi-join) zastosowanie
algorytmu partitioned join nie jest możliwe. Jednym ze sposobów równoległej
realizacji takich połączeń jest metoda asymmetric fragment-and-replicate join.
Metoda jest stosowalna tylko dla przypadków, gdy jedna z relacji mieści się na
pojedynczym węźle. Wymaga ona specjalnego partycjonowania łączonych relacji.
Większa z relacji jest dzielona na partycje według jednej z metod
partycjonowania i rozpraszana na wszystkich serwerach. Mniejsza relacja jest
replikowana na wszystkich serwerach.
Krok 1:
• Każdy z serwerów wykonuje równolegle operację połączenia wszystkich
przechowywanych na nim krotek metodą nested-loop.
Krok 2:
• Wszystkie serwery wysyłają połączone krotki do pojedynczego serwera, który
sumuje (union) odebrane wyniki.
Koszt operacji połączenia jest zmniejszony dzięki równoległemu łączeniu
mniejszych relacji. Należy oczekiwać n-krotnego zmniejszenia kosztu wykonania
operacji mierzonego liczbą operacji porównania wierszy łączonych relacji. Na
każdym z serwerów równolegle będzie przetwarzanych: (1/n|R|)  |S| krotek.
Symmetric fragment-and-replicate join
Modyfikacja poprzedniej metody polegająca na partycjonowaniu i replikacji
obydwu łączonych relacji. Relacja R dzielona jest na m partycji, a relacja S na n
partycji. Zreplikowane partycje są rozpraszane na m*n serwerach.
Krok 1: Każdy z serwerów wykonuje równolegle operację połączenia wszystkich
przechowywanych na nim krotek jedną z klasycznych metod łączenia.
Krok 2: Wszystkie serwery wysyłają połączone krotki do pojedynczego serwera,
który sumuje (union) odebrane wyniki.
Koszt: (1/n|R|)(1/m|S|) operacji porównania.
R1
R3
S2
S3
R1
P11
P12
P12
R2
P21
P22
P22
R3
P31
P32
P32
P1
fragmenty R
R2
S1
P2
S
repliki S
P3
Asymmetric
fragment-and-replicate
Fragment-and-replicate
MapReduce
Model programowania
dla przetwarzania dużych zbiorów danych
MapReduce - motywacje
Specyfika wymagań:
• Przetwarzanie bardzo dużych zbiorów danych – Big Data.
• Przetwarzanie danych niestrukturalnych i semistrukturalnych,
utrzymywanych w logach i plikach – Big Data.
• Realizacja dużych zbiorów prostych operacji przetwarzania
bardzo dużych zbiorów danych wejściowych o prostej
strukturze <klucz, wartość>, które są rozproszone na tysiącach
serwerów.
• Potrzeby model obliczeniowy oferujący abstrakcję dla
przedstawiania prostych obliczeń, i który ukrywałby przed
programistą złożoność implementacji przetwarzania
równoległego, rozproszenia danych, balansowania obciążenia i
odporności na awarie
Przełamanie ograniczeń dotychczasowych technologii:
• rozproszonych i równoległych systemów baz danych, co do
skalowalności na tysiące serwerów.
105
104
rozmiar
klastrów
MapReduce
103
102
RDBMS
rozmiar
zbiorów danych
101
GB
TB
PB
EB
• klasycznego protokołu obliczeń równoległych opartego na MPI
(ang. Message Passing Interface): możliwości występowania
zakleszczeń, narzutów na zarządzanie komunikacją,
nieoptymalnej redystrybucji obciążeń, itp.
Różnice w stosunku do równoległych baz danych
• przetwarzanie danych niestrukturalnych i meta-strukturalnych
np. logów poprzez tworzenie ad hoc kodu dostępu do danych,
zamiast korzystania z relacyjnego modelu danych;
• silniejsza integracja węzłów z rozproszonymi zbiorami danych,
w porównaniu autonomicznych RDBMS o jawnie
zdefiniowanych związkach między danymi;
• automatyzm partycjonowania i rozpraszania danych;
• uproszczona funkcjonalność, prosty model danych (brak
schematów danych), brak transakcyjności, itp.;
• kilka prostych uniwersalnych operacji, zamiast dużego zbioru
operacji o wyspecjalizowanej semantyce.
Porównanie MapReduce i RDBMS
RDBMS
Hurtownie danych
MapReduce
Rozmiar danych Gigabajty
Terabajty
Petabajty
Typ dostępu
Interakcyjny - OLTP
Interakcyjny - OLAP
Wsadowy - OffLAP
Dostęp do
dysku
Pojedyncze rekordy
(operacja seek)
Całe bloki rekordów –
(operacja transferu)
Całe bloki rekordów –
(operacja transferu)
Typ operacji na
danych
Wielokrotne zapisy i Jednokrotny zapis i
odczyty
wielokrotny odczyt
Jednokrotny zapis i
wielokrotny odczyt
Struktura
danych
Dane strukturalne 1NF
Dane strukturalne 1NF
Niestrukturalne i
semistrukturalne
Spójność
Wysoka
Średnia
Niska
Metody
dostępu
Indeks, plik haszowy Materializacja wyników Przetwarzanie
analiz, query rewriting równoległe
Przetwarzanie
rozproszone
Fragmenty, shardy,
repliki, 2PC
Partycje
Rozproszony system
plików
Skalowalność
Nieliniowa
Nieliniowa
Liniowa
Zarządzanie
rozproszeniem
Realizowane przez
programistów
Realizowane przez
programistów
Zautomatyzowane
MapReduce – inspiracje modelu obliczeń
Programowanie funkcjonalne:
• Lambda Calculus (lata 30) – założenia teoretyczne dla
programowania funkcjonalnego, polegającego na
wykonywaniu obliczeń poprzez wywoływanie funkcji
• Funkcjonalne języki programowania: Lisp, Scheme, Haskell,
ML (Matelanguage)
• Funkcjonalne programowanie w językach niefunkcjonalnych:
Fortran, Python
Lisp - funkcyjny język programowania
• Podstawowym typem danych są listy:
'(1 2 3 4 5)
'((a 1) (b 2) (c 3))
• Definiowanie funkcji w języku Lisp polega na powiązaniu
wyrażenia lambda ze zmiennymi:
(define (foo x y)
(sqrt (+ (* x x) (* y y)))))
(foo 3 4)  5
• Funkcje wyższego rzędu, są to funkcje, których argumentami
są inne funkcje:
(define (bar f x) (f (f x)))
(define (baz x) (* x x))
(bar baz 2)  16
Lisp – operacje map i fold
Przetwarzanie list za pomocą funkcji wyższego rzędu: map i fold
• Funkcja map - zastosuj funkcję, która jest argumentem funkcji
map do poszczególnych elementów listy.
(map x) (* x x))
x2
x2
x2
x2
x2
'(1 2 3 4 5))
 '(1 4 9 16 25)
• Funkcja fold – przetwarza wszystkie elementy listy dla uzyskania
sumarycznego wyniku
(fold + 0 '(1 2 3 4 5))  15
(fold * 1 '(1 2 3 4 5))  120
final value
+
Initial value
+
+
+
+
Funkcje map i fold
Wyznaczenie sumy kwadratów elementów listy wejściowej za
pomocą funkcji map i fold, wygląda następująco:
(define (sum-of-squares v)
(fold + 0 (map (lambda (x) (* x x)) v)))
(sum-of-squares '(1 2 3 4 5))  55
x2
+
Initial value
x2
+
x2
+
x2
+
x2
+
final value
MapReduce
Zastosowanie paradygmatu programowania funkcjonalnego
poprzez użycie funkcji wyższego rzędu: map i reduce oraz
systemowej funkcji shuffle.
• Funkcje te działają listach rekordów o strukturze: klucz i wartość:
map(k1, v1)  (k2, v2)
shuffle {(k2, v2)}  (k2,list(v2))
reudce(k2,list(v2)) (k2,v3)
• Działanie funkcji map jest rozproszone na wszystkie węzły
zawierające przetwarzany plik.
• Domyślnym sposobem przetwarzania funkcji map i reduce jest
przetwarzanie równoległe.
• Jeżeli funkcja reduce jest przemienna i łączna, to jest możliwe
dodatkowe zrównoleglenie przetwarzania funkcji reduce.
MapReduce
Proces przetwarzania danych w modelu MapReduce obejmuje pięć faz:
• odczyt danych wejściowych,
• przetwarzanie zbioru elementów wejściowych przez funkcję map ,
• przetasowanie (shuffle) (sortowanie i grupowanie) przetworzonych danych
według wartości kluczy wygenerowanych przez funkcję map,
• wyznaczanie wynikowego zbioru wartości za pomocą funkcji reduce,
• konkatenacja i zapis zbioru danych wyjściowych
Równoległość przetwarzania MapReduce
Operacje map i operacje reduce są rozpraszane między węzłami
chmury, w celu zrównoleglenia ich wykonywania.
rozproszony plik źródłowy
M
M
M
M
k1:v, k1:v
k2:v, k1:v
k3:v, k1:v
k4:v
współbieżność
sekwencyjność
sortowanie i grupowanie
k1:v,v,v k2:v
k3:v k4:v
R
R
rozproszony plik wynikowy
współbieżność
Przykład przetwarzania MapReduce
Dla zbioru dokumentów wejściowych, wyznacz częstość
występowania wszystkich słów.
map(String fileName, String fileContents):
// key: fileName
// value: fileContents
for each word in fileContents:
EmitIntermediate(word, "1");
reduce(String word, Iterator values):
// key: word
// value: "1",...,"1"
int result = 0;
for each v in values:
result += ParseInt(values);
Emit(word, AsString(result));
// key: word
// value: result – liczba wystąpień
Przykład przetwarzania MapReduce
Dla danego wejściowego zbioru dokumentów d1 i d2, wyznacz
częstość występowania wszystkich słów.
<d1,"Ala ma kota">
<d2,"Kot ma mysz">
map
<ala,1>
<mieć,1> reduce
<kot,1>
<kot,1>
<mieć,1>
<mysz,1>
<ala,1>
<mieć,2>
<kot,2>
<mysz,1>
Modelowanie rozwiązań problemów za
pomocą paradygmatu MapReduce
Problemy obliczeniowe do współbieżnej realizacji muszą być
przekształcone do postaci MapReduce.
Znanych jest wiele takich rozwiązań dla wielu złożonych
problemów obliczeniowych:
• prosta analiza danych, np. przez wyznaczanie agregatów dla
dużych zbiorów wejściowych;
• równoległa realizacja klasycznych algorytmów eksploracji
danych, np. PageRank, apriori, klasyfikator Bayesa;
• przetwarzanie obrazów.
Realizacja operacji join
Bazując na algorytmie hash-join:
• funkcja map M przetwarza pojedyncze krotki obydwu relacji, w pary
<wartość funkcji haszującej na atrybucie połączeniowym, krotka>
M(<null,tuple>) <hash key,tuple>
• funkcja reduce R łączy krotki różnych relacji o tej samej wartości klucza
haszowego:
R(<key, list(tuple)>  list(tuple)
M
M
R
R
M
M
Relacja R
R
M
M
Relacja S
M
Implementacje MapReduce
Dostępne są wydajne implementacje funkcjonalności
MapReduce.
• Google MapReduce, oferuje specjalny język
programowania Sawzall, wspierający abstrakcje map i
reduce
• Apache Hadoop, jest oprogramowaniem klasy open
source, w którym funkcjonalność MapReduce jest
oferowana jako w postaci bibliotek języka Java.
Hadoop – konstrukcja aplikacji
Definicja trzech klas: klasa z implementacją zadania map, klasa z implementacją
zadania reduce i klasa z implementacją pracy mapreduce.
static class MyMapper
extends Mapper<LongWritable, Text, Text, IntWritable> {
-- typy parametrów: KeyIn
ValueIn KeyOut ValueOut
…
public void map(LongWritable key, Text value, Context context)
-KeyIn
ValueIn {(KeyOut,ValueOut)}
throws IOException, InterruptedException {
String line = value.toString();
String year = line.substring(15, 19);
int airTemp;
if (line.charAt(87) == '+') {
airTemp = Integer.parseInt(line.substring(88, 92));
} else {
airTemp = Integer.parseInt(line.substring(87, 92));
}
…
context.write(new Text(year),new IntWritable(airTemp));
} -KeyOut
ValueOut
}
Klasa z implementacją zadania reduce
static class MyReducer
extends Reducer<Text, IntWritable, Text, IntWritable> {
-- typy parametrów: KeyIn
ValueIn
KeyOut
ValueOut
public void reduce(Text key, Iterable<IntWritable> values,
-KeyIn
ValueIn
Context context) throws IOException, InterruptedException {
int maxValue = Integer.MIN_VALUE;
for (IntWritable value : values) {
maxValue = Math.max(maxValue, value.get());
}
context.write(key, new IntWritable(maxValue));
-KeyOut
ValueOut
}
}
Klasa z implementacją pracy mapreduce
public class MaxTemperature {
public static void main(String[] args) throws Exception {
if (args.length != 2) {
System.err.println(
"Usage: MaxTemperature <input path> <output path>");
System.exit(-1);
}
Job job = new Job();
job.setJarByClass(MaxTemperature.class);
FileInputFormat.addInputPath(job, new Path(args[0]));
FileOutputFormat.setOutputPath(job, new Path(args[1]));
job.setMapperClass(MyMapper.class);
job.setReducerClass(MyReducer.class);
job.setOutputKeyClass(Text.class);
job.setOutputValueClass(IntWritable.class);
System.exit(job.waitForCompletion(true) ? 0 : 1);
}
}
Organizacja klastrów Hadoop
Zbiór wszystkich zasobów obliczeniowych – węzłów - danej
instalacji Hadoop tworzy klaster. Węzły klastra mogą być
pogrupowane w szafy (rack) i centra danych.
klaster
Rozproszony system plików HDFS
• Dane przetwarzane przez środowisko Hadopp (wejściowe,
pośrednie i wyjściowe) są składowane w dwóch systemach
plików: rozproszonym HDFS (Hadoop Distributed File System) i
lokalnym.
• System plików HDFS posiada szereg istotnych rozwiązań
implementujących funkcjonalność środowiska obliczeniowego
Hadoop:
– automatyczna replikacja danych składowanych w HDFS
(domyślnie trzy repliki każdego bloku danych);
– automatyczne rozpraszanie danych na węzły platformy
sprzętowej w partycje o takich samych wielkościach;
– blokowy dostęp do danych – dane są odczytywane w
dużych blokach (domyślnie 64 MB).
Węzły klastra HDFS pełnią jedną z dwóch ról:
• węzły metadanych – NameNode, przechowują informacje o
strukturze katalogów, własnościach plików danych i katalogów
oraz lokalizacji bloków plików danych na węzłach DataNode,
• węzły danych – DataNode, przechowują właściwe bloki
danych plików.
Węzły NameNode i DataNode współpracują w trybie master –
worker.
Operacja odczytu
Odczyt bloków plików
przechowywanych w HDFS
jest realizowany na
najbliższym węźle spośród
zawierających repliki danego
bloku.
*)
Funkcja odległości:
• distance(/d1/r1/n1, /d1/r1/n1) = 0 (procesy na tym samym węźle)
• distance(/d1/r1/n1, /d1/r1/n2) = 2 (różne węzły w tej samej szafie - rack)
• distance(/d1/r1/n1, /d1/r2/n3) = 4 (węzły w różnych szafach tego samego centrum
danych)
• distance(/d1/r1/n1, /d2/r3/n4) = 6 (węzły w różnych centrach danych)
*) Hadoop The Definitive Guide
Równoważenie rozproszenia danych
Bloki danych plików są rozpraszane równomiernie
między wszystkie węzły klastra Hadoop. Różne centra
danych klastra mogą stosować różne strategie
rozpraszania.
Jako proces systemowy platformy Hadoop działa proces
równoważenia obciążenia, który interweniuje w
wypadku braku zrównoważenia wielkości partycji
plików na poszczególnych węzłach, np. po rozszerzeniu
partycji o nowe węzły lub dodaniu nowych danych do
pliku.
Tworzenie replik
Domyślnie dla każdego nowego bloku danych są tworzone jego
trzy repliki. Repliki są tworzone w różnych szafach, tego samego
centrum danych.
Operacja zapisu
tworzenie replik
Realizacja pracy MapReduce
• Praca do wykonania jest dzielona przez Hadoop na dwa rodzaje zadań:
zadania map i zadania reduce.
• Zarządzanie procesem MapReduce jest realizowane przez dwa rodzaje
węzłów: jobtracker i tasktracker. Węzły jobtracker koordynują realizację prac
w systemie przez przedkładanie zadań do wykonania węzłom tasktracker.
• Węzły tasktracker wysyłają cyklicznie informacje o swojej żywotności
heartbeat do węzłów jobtracker. Brak tego potwierdzenia przez odpowiednio
długi czas, powoduje usunięcie węzła tasktracker w metadanych.
• Hadoop dzieli plik wejściowy (składowany w HDFS) na kawałki danych (splits)
o stałym rozmiarze dla danej pracy. Rozmiar splits jest konfigurowalny
(domyślnie równy rozmiarowi bloku – 64 MB). Małe kawałki danych ułatwiają
równoważenie obciążenia chmury, ale zwiększają narzuty systemowe.
• Hadoop tworzy osobne zadanie map dla każdego kawałka danych. Dane są
przetwarzane w miejscu ich składowania. Wyniki zadań map są składowane
na lokalnych systemach plików (w miejscu przetwarzania - nie w HDFS).
Implementacja Hadoop
Przepływ danych dla pojedynczego zadania reduce
node1
node2
node3
node4
Implementacja Hadoop
Przepływ danych dla wielu zadań reduce. Liczba zadań reduce
jest konfigurowalna. Każde z zadań map dzieli plik wynikowy na
partycje. W jednej partycji umieszczane są dane dla jednego
zadania reduce, na podstawie wartości kluczy generowanych
przez zadania map.
Znane wdrożenia Hadoop
• Last.fm – do generowania rankingów i
statystyk
• Facebook – różnego rodzaju statystyki
cykliczne i ad hoc dla pracowników firmy
generowane w celu utrzymania i rozwoju
produktu
• Apache Nutch search engine – ranking stron,
itp..
Implementacja Google MapReduce
Bazuje na systemie plików GFS (Google File System)
Architektura klastrów obejmuje:
• jeden węzeł typu master i wiele węzłów typu workers,
• użytkownicy przedkładają pracę składającą się z wielu zadań do
modułu planisty,
• zadania są przypisywane dostępnym węzłom typu workers w
klastrze, który zawiera węzeł master.
Schemat działania:
• wywołania funkcji map są rozpraszane między wiele węzłów
bazując na automatycznie tworzonych M partycjach,
• rozproszone dane wejściowe są przetwarzane w sposób
współbieżny,
• wywołania funkcji reduce są rozpraszane między R partycji
tworzonych na podstawie przejściowego klucza np. za pomocą
funkcji haszowej: "key mod R".
Implementacja Google MapReduce
Wydajność rozwiązania MapReduce
Czas ładowania danych źródłowych dla implementacji funkcji
GREP:
Czas realizacji funkcji GREP:
Agregacja danych 2 500 000 grup:
SELECT sourceIP, SUM(adRevenue)
FROM UserVisits GROUP BY sourceIP
Operacja połączenia:
SELECT sourceIP, avgPageRank, totalRevenue FROM (
SELECT sourceIP, AVG(pageRank), SUM(UadRevenue)
FROM Rankings, UserVisits WHERE pageURL = destURL
AND UV.visitDate BETWEEN DATE(‘2000-01-15’) AND
DATE(‘2000-01-22’) GROUP BY sourceIP)
ORDER BY totalRevenue DESC LIMIT 1
Scenariusz programu MapReduce był trzy-fazowy:
Faza 1: odfiltrowanie rekordów niespełniających warunków
selekcji i połączenie z plikiem rankingów
Faza 2: wyliczenie agregatów średniego rankingu stron i
sumarycznych dochodów bazując na numerze IP
Faza 3: wytworzenie rekordu o największej sumie dochodów
Języki dostępu do MapReduce
• Dla zwiększenia atrakcyjności rozwiązań MapReduce
zaprojektowano deklaratywne języki zapytań, których
implementacja wykorzystuje model MapReduce
• Dwa popularne rozwiązania:
– Hive oferujący bazujący na SQL język HQL, rozwijany
początkowo przez Facebooka, teraz Open Source
– Pig oferujący podobny do Perl język Pig Latin stosowany
przez Yahoo
Modele danych NoSQL
Bazy danych NoSQL
Brak jednoznacznej definicji baz danych NoSQL
• Not only SQL
• Nierelacyjny model danych
Inspiracją była baza danych BigTable
Ogólną ideą jest - maksymalnie uprościć model danych
dla umożliwienia osiągnięcia wyższego poziomu
skalowalności.
Postulowane własności baz danych NoSQL
• Horyzontalna skalowalność przepustowości strumienia
prostych operacji na wielu serwerach danych
• Zdolność do replikowania i rozpraszania fragmentów
danych na wielu serwerach
• Prosty interfejs w porównaniu z SQL binding
• Słabszy model spójności niż ACID
• Wydajne użycie rozproszonych indeksów i pamięci RAM
do przechowywania danych
• Zdolność do dynamicznego dodawania atrybutów do
rekordów danych
Redukcja funkcjonalności w modelu NoSQL
Oryginalna propozycja systemu BigTable zwierała wiele ograniczeń
funkcjonalnych w stosunku do klasycznych relacyjnych baz danych:
• operacje modelu danych uproszczone do operacji
C(reate)R(etrive)U(pdate)D(elete);
• brak więzów integralności, weryfikacji poprawności typów i
dziedzin danych;
• brak wsparcia dla złożonych struktur danych;
• rezygnacja z cechy trwałości zapisów danych (D z ACID);
• rezygnacja przetwarzania transakcyjnego; jednostkami pracy są
pojedyncze operacje CRUD;
Modele danych NoSQL
Od czasu premiery systemu BigTable pojawiło się wiele
propozycji nowych modeli NoSQL, które wzbogacają
model danych BigTable dla zwiększenia uniwersalności i
zakresu zastosowania modeli NoSQL:
• model klucz-wartość
• model rodzin kolumn (column family)
• model dokumentowy
• model grafowy
• model tablicowy
Model danych klucz-wartość
klucz1 "John Fitzgerald, 22 old, single"
• Interfejs obejmuje dwie
klucz2 "Alice, music lover"
podstawowe operacje:
klucz3 "James, Enthusiast gaming"
– put(key, value)
..
.
– get(key): value
kluczN "Ford Mondeo mileage: 22000 miles"
• Idea składowania danych
– wartości (dane) są składowane bazując na kluczach
zdefiniowanych przez użytkowników
– system nie zna struktury i semantyki przechowywanych
wartości danych
• Zapytania odwołują się do pojedynczych wartości kluczy
• Indeksy przyśpieszające dostęp do danych są definiowane na
kluczach
• Znane implementacje: MemcacheDB, Voldemort
Model danych rodziny kolumn
Public
klucz1
"name":"John"
Private
Interfejs obejmuje operacje: klucz2 "name":"Mary"
"age":"22"
• define (family)
klucz3 "manufacturer":"Ford" "mileage":"1000"
..
• insert(family, key,columns)
.
• get(family, key):columns
"sex":"Female"
kluczN "name":" Alice"
Składowanie danych
• kolumny są składowane jako trójki: nazwa, wartość i znacznik
czasowy;
• system jest świadomy arbitralnej struktury rodzin kolumn;
• system używa rodzin kolumn jako jednostek fragmentacji i
replikacji;
Zapytania odwołują się do kluczy i nazw rodzi kolumn
Dostępne są indeksy pomocnicze na rodzinach kolumn
Znane implementacje: Cassandra, Hbase, Hypertable
Dokumentowy model danych
Interfejs obejmuje operacje:
•
•
•
•
set(key, document)
get(key): document
set(key, name, value)
get(key, name):value
klucz1
"name":"John", "has":"klucz3"
klucz2
"name":"Mary", "age":"22"
klucz3
"manufacturer":"Ford"
kluczN
"name":" Alice", "sex":"F"
..
.
Składowanie danych
• dokumenty (dane) są składowane bazując na wartościach kluczy;
• system jest świadomy wewnętrznej arbitralnej struktury dokumentów;
• wsparcie dla list, wskaźników i zagnieżdżonych dokumentów
Zapytania odwołują się do wartości kluczy lub innych atrybutów,
o ile zdefiniowano indeksy pomocnicze
Obligatoryjne indeksy na kluczach i opcjonalne na innych
atrybutach
Znane implementacje: CoachDB, MongoDB, Cloudant
Grafowy model danych
"name":"John"
• Interfejs zawiera operacje
–
–
–
–
–
create: id
get(id)
connect(id1, id2): id
addAttribute(id, name, value)
getAttribute(id, neme): value
n1
"name":"Mary", "age":"25"
likes
n2
likes
lives at
"weight":"1"
n3
"name":"Boston"
• Składowanie danych
– dane są składowane jako węzły i typowane krawędzie;
– węzły i krawędzie mo;gą mieć przypisane arbitralnie atrybuty
• Zapytania odwołują się do systemowych identyfikatorów lub
do atrybutów, jeżeli utworzono na nich indeksy
• Indeksy pomocnicze są dostępne dla indeksowania atrybutów
i typów węzłów i krawędzi
• Znane implementacje: Neo4J, Oracle Spatial and Graph,
Oracle NoSQL
BigTable – baza danych Google
• Projekt Google rozpoczęty w 2004 roku, ciągle
rozwijany
• Używany w wielu aplikacjach Googla: Page Rank,
Google Maps, Google Earth, YouTube, Gmail, itd.
• Model danych BigTable należy do klasy rodziny
kolumn
• Skalowalność i dostępność systemu jest osiągana
dzięki własnościom rozproszonego systemu plików:
GFS (Google File System)
Model danych BigTable
Model danych BigTable można widzieć jako strukturę
czterowymiarową:
• Klucze – definiowane przez użytkowników, do 64 KB
• Rodziny kolumn – jednostka kontroli dostępu
• Identyfikator kolumny w rodzinie
• Znacznik czasowy – używany w procesie odśmiecania, nie
więcej niż 8 wersji nie starszych niż trzy dni
Odwołanie do wartości danych wymaga określenia:
(row: string, columnFamily: string,
columnQualifier: string, timestamp: int64)  string
Model transakcji
• Transakcje są ograniczone do operacji
wykonywanych na pojedynczych danych.
Transakcje o własnościach atomowości i
izolacji mogą składać się z kilku operacji
przetwarzających wartości w danych o tym
samym kluczu
• Odczyt danych o różnych wartościach kluczy i
kolumn odbywa się w sposób iteracyjny.
Implementacja struktur danych
• Dane w tabelach są posortowane według leksykograficznego
porządku kluczy
• Tabele są dzielone na tablety, z których każdy zawiera dane
przynależące do określonego przedziału wartości kluczy
• Rozmiar tabletów mieści się w przedziale 100 do 200 MB
a
...
f
g
...
k
...
v
...
z
tabela
a
...
f
tablet
g
...
k
tablet
v
...
z
tablet
Implementacja struktur danych
• Tablety są składowane jako zbiór tzw. SSTable,
• Pojedyncze SSTable jest zbiorem 64 kB bloków z danymi oraz
jeden blok indeksu na blokach
• Każda SSTable jest plikiem systemu operacyjnego GFS
g
...
k
tablet
SSTable
...
SSTable
SSTable
64K
Block
64K
Block
...
64K
Block
index
SSTable
Metadane
• Struktura tablic oraz lokalizacje elementów składowych
(tabletów, SSTable i logach) są przechowywane w tablicach
metadanych.
• Root tablet składuje informacje o pozostałych tabletach
składających się na tablicę metadanych
tablica metadanych
Operacje na tabletach
• Odczyty danych mogą być adresowane do SSTables
składowanych na dysku, lub do struktur danych utrzymywanych
w pamięci operacyjnej
• Zapisy trafiają najpierw do logu, a następnie do struktury
MemTable. Przepełnione MemTable są zapisywane jako SSTable
zapis
MemTable
odczyt
PAO
Dysk
tablet commit log
SSTable
SSTable
SSTable
Implementacja rozproszenia
• Serwery tabletów
– Tablice są przechowywane na dedykowanych serwerach tabletów
– Serwery tabletów są dynamicznie dodawane i odejmowane
– Każdy z tych serwerów przechowuje i zarządza zbiorem tabletów,
typowo od 10-1000 tabletów na serwer
– Serwery tabletów obsługują żądania zapisów i odczytów
– Serwery dzielą zbyt duże tablety
• Serwery typu master
–
–
–
–
Przydziela tablety serwerom tabletów
Balansuje obciążeniem serwerów tabletów
Usuwanie zbędnych plików GFS (garbage collection)
Zarządzanie zmianami w schemacie tablic – tworzenie rodzin kolumn
• Biblioteki dla aplikacji klienckich
– Podczas dostępu do danych klienci kontaktują się bezpośrednio z
serwerami tabletów, wskazanymi przez serwer typu master.
Udoskonalenia
• Pionowa fragmentacja danych (lokalizacja grup)
– Użytkownicy mogą definiować grupy rodzin kolumn przetwarzanych typowo
przez te same operacje
– Grupy te będą przechowywane w odrębnych SSTable
– Operacje przetwarzania będą dzięki temu przetwarzać fragmenty danych o
mniejszych rozmiarach (lepsze upakowanie danych i mniejszy transfer)
• Stosowanie kompresji danych
– Stosowane opcjonalnie na grupach kolumn
– 10-krotna redukcja wolumenu danych, przy prędkości kodowania równej 100200 MB/s i dekodowania 400-1000 MB/s
• Buforowanie danych
– Bufory skanowania – przyśpieszenia powtórnego odczytu danych
– Bufory SSTable – dla przyśpieszenia odczytu kolejnych danych
• Filtry Blooma
– dla efektywności procesu określenia danych, które zawiera dana SSTable
• Replikacja danych
– utrzymywanie 5 replik, wartości są wyznaczane za pomocą protokołu Paxos,
dostępność mniej niż 3 replik oznacza zatrzymanie dostępu do danych.
Testy wydajności BigTable
• Sekwencyjne odczyty są szybsze niż losowe ze względu na
bufory SSTable
• Zapisy są krótsze ze względu na zapisywaniu danych do
MemTable

R - Technologie Przetwarzania Danych

Transkrypt

Podobne dokumenty