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

Projektowanie wysokowydajnych i skalowalnych serwisów WWW - Warstwa danych

Embed Size (px)

Citation preview

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

W praktyce

Skalowanie warstwy danych

Replikacja

9

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