O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Projektowanie wysokowydajnych i skalowalnych serwisów WWW - Warstwa danych

920 visualizações

Publicada em

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)

Publicada em: Tecnologia
  • Entre para ver os comentários

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ę

×