Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Projektowanie wysokowydajnych i skalowalnych serwisów WWW - Warstwa danych

911 views

Published on

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)

Published in: Technology
  • Login to see the comments

Projektowanie wysokowydajnych i skalowalnych serwisów WWW - Warstwa danych

  1. 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. 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. 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. 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. 5. .com Skalowalna warstwa danych Replikacja Partycjonowanie Wydajne przechowywanie danych 5 Skalowanie warstwy danych
  6. 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. 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. 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. 9. .com  W praktyce Skalowanie warstwy danych Replikacja 9
  10. 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. 11. Multi-Tenant Fizyczny rozdział danych klientów Podsystemy Podział wg typu danych 11 Skalowanie warstwy danych Partycjonowanie
  12. 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. 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. 14. .com  VS. ◦ SELECT products_count FROM user WHERE id = 1; 14 Wydajne przechowywanie danych Agregacja
  15. 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. 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. 17. .com  VS. ◦ SELECT * FROM message; 17 Wydajne przechowywanie danych Denormalizacja
  18. 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. 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. 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ę

×