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)

1. Szkolimy team leaderów i zespoły programistyczne
Projektowanie
wysokowydajnych
i skalowalnych serwisów www
Część druga - Warstwa danych
Antoni Orfin <aorfin@imagin.pl>
octivi.com

2. .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

3. .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

4. .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

5. .com
Skalowalna
warstwa danych
Replikacja
Partycjonowanie
Wydajne
przechowywanie
danych
5
Skalowanie warstwy danych

6. .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

7. .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

8. .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

9. .com
 W praktyce
Skalowanie warstwy danych
Replikacja
9

10. .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

11. Multi-Tenant
Fizyczny rozdział danych klientów
Podsystemy
Podział wg typu danych
11
Skalowanie warstwy danych
Partycjonowanie

12. .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

13. .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

14. .com
 VS.
◦ SELECT products_count FROM user WHERE id = 1;
14
Wydajne przechowywanie danych
Agregacja

15. .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

16. .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

17. .com
 VS.
◦ SELECT * FROM message;
17
Wydajne przechowywanie danych
Denormalizacja

18. .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

19. .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

20. .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ę