Projektowanie wysokowydajnych i skalowalnych serwisów www - Część druga - Warstwa danych
20
Szkolimy team leaderów i zespoły programistyczne Projektowanie wysokowydajnych i skalowalnych serwisów www Część druga - Warstwa danych Antoni Orfin <[email protected]> octivi.com
-
Upload
octivi -
Category
Technology
-
view
540 -
download
2
description
Część druga prezentacji pochodzącej z warsztatów skupiających się na zagadnieniach projektowania i wytwarzania wysokowydajnych i skalowalnych serwisów webowych. Prezentacja opisuje problemy związane z warstwą danych: - Replikacja (master-master, master-slave) - Partycjonowanie (sharding) - Wydajne przechowywanie danych (agregacja, denormalizacja) Zapraszamy również do części pierwszej, poświęconej warstwie aplikacji: http://www.slideshare.net/octivi/projektowanie-wysokowydajnychiskalowalnychserwisowwwwwarstwaaplikacji
Transcript of Projektowanie wysokowydajnych i skalowalnych serwisów www - Część druga - Warstwa danych
Szkolimy team leaderów i zespoły programistyczne
Projektowanie wysokowydajnych
i skalowalnych serwisów www Część druga - Warstwa danych
Antoni Orfin <[email protected]> octivi.com
.com
1. Przypomnienie części pierwszej
2. Skalowanie warstwy danych ◦ Problemy związane z warstwą danych
◦ Replikacja
◦ Partycjonowanie
3. Wydajne przechowywanie danych ◦ Agregacja
◦ Denormalizacja
4. Konkluzje
Agenda
2
.com
1st Tier Cache (np. Varnish)
Rozdzielanie ruchu (np. HAProxy)
Replikacja, Sharding
2nd Tier Cache (np. Redis, Memcache)
3
Stopnie rozwoju architektury serwisów webowych
Skalowanie serwisu
.com
Problemy związane z warstwą danych
◦ Jak zapewnić wysoką wydajność? Statystyki serwera bazodanowego pokazują 90% wykorzystania procesora
◦ Jak zapewnić wysoką dostępność? Nastąpiła awaria serwera bazodanowego – serwis nie był dostępny przez 2 godziny
◦ Jak rozkładać dane na wielu węzłach? Na serwerze bazodanowym kończy się przestrzeń dyskowa/pamięć RAM
4
Skalowanie warstwy danych
.com
Skalowalna
warstwa danych
Replikacja
Partycjonowanie
Wydajne
przechowywanie
danych
5
Skalowanie warstwy danych
.com
Odpowiada na pytania ◦ Jak zapewnić wysoką wydajność?
◦ Jak zapewnić wysoką dostępność?
Rodzaje ◦ Master/Master – oba serwery równoważne
◦ Master/Slave – jeden z serwerów jest „podrzędnym”
Problemy ◦ Każdy z serwerów powinien posiadać identyczne zasoby
pamięciowe
Skalowanie warstwy danych
Replikacja
6
.com
Master/Master ◦ Każdy z serwerów synchronizuje dane z drugim
◦ Odczyty i zapisy możliwe do każdego z serwerów
Zalety ◦ Wysoka wydajność dla zapisów i odczytów
◦ Wysoka dostępność
Problemy ◦ Generowanie identyfikatorów – GUID, Primary Key
◦ Zachowanie spójności danych – DATE()
◦ Gdy jeden serwer ulega awarii drugi dostaje 2x większy ruch
◦ Konieczne mechanizmy do automatycznego przełączania serwerów
Skalowanie warstwy danych
Replikacja
7
.com
Master/Slave ◦ Slave „pobiera” dane z Mastera ◦ Zapisy kierowane wyłącznie do Mastera ◦ Odczyty ze Slave’ów lub Mastera
Zalety ◦ Wysoka wydajność dla odczytów ◦ Wysoka dostępność - slave na „backup danych” ◦ Prostsze w realizacji od Master/Master
Problemy ◦ Nie rozwiązuje problemów z zapisami ◦ Konieczne mechanizmy do automatycznego przełączania
serwerów
Skalowanie warstwy danych
Replikacja
8
.com
Odpowiada na pytania ◦ Jak rozkładać dane na wielu węzłach?
Partycjonowanie (sharding) na podstawie ◦ Położenia geograficznego użytkownika
◦ Klientów
◦ Rodzaju danych
◦ Losowe
Problemy ◦ JOIN przez Shardy
◦ Każda partycja powinna realizować replikację
Skalowanie warstwy danych
Partycjonowanie
10
Multi-Tenant Fizyczny rozdział danych klientów
Podsystemy
Podział wg typu danych
11
Skalowanie warstwy danych
Partycjonowanie
.com
Baza danych jest wąskim gardłem większości aplikacji webowych
Większość ruchu w aplikacjach webowych to odczyty
Warstwa danych powinna być nastawiona na skuteczne pobieranie danych
12
Wydajne przechowywanie danych
.com
Użytkownicy mają dodane produkty:
Jak pobrać liczbę produktów użytkownika? ◦ SELECT COUNT(*) FROM product WHERE user_id = 1;
Wydajne przechowywanie danych
Agregacja
13
.com
VS.
◦ SELECT products_count FROM user WHERE id = 1;
14
Wydajne przechowywanie danych
Agregacja
.com
Cechy ◦ Zakładamy, że liczba wyświetleń, miejsc, w których
wykorzystamy liczbę produktów jest większa od liczby INSERTów produktów
◦ Operacje bazodanowe SUM, COUNT, AVG są wolne
◦ Należy pamiętać o spójności – np. zawsze przy usuwaniu produktu należy zmniejszać licznik przy użytkowniku
15
Wydajne przechowywanie danych
Agregacja
.com
Użytkownicy mają dane osobowe:
Jak pobrać wiadomości wraz z danymi użytkownika? ◦ SELECT * FROM message JOIN user ON user.id = user_id;
16
Wydajne przechowywanie danych
Denormalizacja
.com
VS.
◦ SELECT * FROM message;
17
Wydajne przechowywanie danych
Denormalizacja
.com
Cechy ◦ Optymalizacja bazy tak, aby była nastawiona na prezentację
danych
◦ Projektujemy strukturę bazy z myślą o późniejszym odczycie
◦ JOINy są wolne
◦ Dla danych które nie będą zmieniane - sytuacja w której użytkownik zmienia imię/nazwisko jest rzadka lub może zostać zupełnie zablokowana w serwisie
18
Wydajne przechowywanie danych
Denormalizacja
.com
Baza danych jest przeważnie wąskim gardłem – należy zaplanować jak skutecznie pobierać z niej dane
Projektując strukturę bazy danych należy pomyśleć kiedy i gdzie będą prezentowane dane
Użytkownik nie wie „co stoi” za serwisem – ważne jest dla niego co i jak szybko dostanie
Konkluzje
19
.com
20
Pytania, uwagi?
Zobacz również: ◦ octivi.com
◦ whoisusing.it
Zapraszam na warsztaty
Projektujemy nasz własny, skalowalny serwis
1. Wylosowanie opisu serwisu, określenie budżetu
2. Zaprojektowanie architektury
3. Prezentacja i omówienie pomysłów uczestników
Dziękuję za uwagę
