Projektowanie wysokowydajnych i skalowalnych serwisów WWW - Warstwa danych

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ę