systemy zarządzania bazami danych

21
Systemy zarządzania bazami danych 18. Strojenie interfejsu

Upload: cid

Post on 12-Jan-2016

53 views

Category:

Documents


0 download

DESCRIPTION

Systemy zarządzania bazami danych. 18. Strojenie interfejsu. Aplikacja. Procesor zapytań. Indeksy. Podsystem składu. Współbieżność. Odtwarzanie. System operacyjny. Sprzęt [ Procesor ( y ), Dysk ( i ), Pamięć ]. Dostęp do bazy danych. 4GL Power++, Visual B asic , Oracle Forms - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Systemy zarządzania bazami danych

Systemy zarządzania bazami danych

18. Strojenie interfejsu

Page 2: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 218. Strojenie interfejsu

Sprzęt[Procesor(y), Dysk(i), Pamięć]

System operacyjny

Współbieżność Odtwarzanie

Podsystem składuIndeksy

Procesor zapytań

Aplikacja

Page 3: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 318. Strojenie interfejsu

Dostęp do bazy danych

• 4GL– Power++, Visual Basic, Oracle Forms

• Język programowania + CLI – ODBC: Open DataBase Connectivity– JDBC: Java API– OCI (C++/Oracle), CLI (C++/ DB2)– Perl/DBI– ... [ to co kochacie, np. ] django, Ruby on Rails,

Python, etc.

Page 4: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 418. Strojenie interfejsu

Lapsusy wokół API

• Koszt przenośności– Dodatkowa warstwa abstrakcji nad

sterownikami ODBC, która ukrywa różnice między sterownikami o różnych poziomach zgodności

– Uwaga na problemy wydajnościowe związane z tą warstwą:

• Użycie meta-danych przy wysyłaniu zapytań i uzyskiwaniu dostępu do wyniku

• Iteracja po wyniku

Page 5: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 518. Strojenie interfejsu

ODBC a OCI• ODBC a OCI w Oracle8iEE

na Windows 2000

• Iteracja po zbiorze wyników po jednym rekordzie x prefetchingiem

• Małe narzuty OCI, gdy liczba rekordów do przesłania jest mała

• ODBC zachowuje się lepiej przy większej liczbie rekordów. Lepiej wykorzystuje prefetching

0

20

40

60

80

0 2000 4000 6000 8000 10000

Number of records transferred

Th

rou

gh

pu

t (r

eco

rds/

sec)

OCI

ODBC

Page 6: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 618. Strojenie interfejsu

Między klientem a serwerem• Pula połączeń i przełączanie, gdy wielu klientów

łączy się z serwerem• Bufor komunikacyjny na serwerze. Jest jeden na

połączenie.– Jeśli klient nie konsumuje wyników wystarczająco

szybko, zasoby serwera są zajęte do czasu wypisania wyniku.

– Dane są wysyłane, gdy bufor komunikacyjny jest pełny lub zapytanie się zakończyło

• Mały bufor – narzuty na częstą komunikację• Duży bufor – dłuższy czas oczekiwania na pierwszy rekord• Nie ma zbyt wielkiego znaczenia w sieci >100Mb. Istotne w

sieciach o niższej przepustowości

Page 7: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 718. Strojenie interfejsu

Ortodoksja obiektowa szkodzi

• authorized(user, type)

• doc(id, type, date)

• Jakie dokumenty może zobaczyć użytkownik?

• SQL:select doc.id, doc.datefrom authorized, docwhere doc.type = authorized.typeand authorized.user = :usr

• Jeśli dokumenty są hermetyzowane w obiekty:– Znajdź typy dokumentów :t

dostępne dla użytkownika :usrselect doc.type as tfrom authorizedwhere user = :usr;

– Dla każdego :t wyślij zapytanie:select id, datefrom docwhere type = :t;

– Aplikacja a nie SZBD realizuje to złączenie!

Page 8: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 818. Strojenie interfejsu

Unikaj interakcji z użytkownikiem w ramach transakcji

• Interakcja z użytkownikiem w transakcji sprawia, że zamki są trzymane przez bardzo długi czas

• Starannie projektuj transakcje (może podziel je na mniejsze?), aby nie wpaść w te sidła

Page 9: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 918. Strojenie interfejsu

Minimalizuj liczbę komunikatów• Unikaj pętli:

– Języki programowania aplikacji oferują pętle (zdanie SQL, przeglądanie kursora, pozycjonowana modyfikacja)

– Ortodoksyjne programowanie obiektowe może wymuszać takie pętle

• Paczkuj kilka zdań SQL w jednym żądaniu do SZBD– Wsady– Programowanie składowane na serwerze w języku

mającym wbudowany SQL i instrukcje sterujące (Transact SQL, PL/SQL, pgPL/SQL, SQL/PL)

Page 10: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 1018. Strojenie interfejsu

Pętle

• Pobierz 2000 rekordów• Pętla: 200 zapytań• Bez pętli: 1 zapytanie• Zbyt częste przekraczanie

interfejsu aplikacji pogarsza wydajność

0

100

200

300

400

500

600

loop no loop

thro

ug

hp

ut

(rec

ord

s/se

c)

Page 11: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 1118. Strojenie interfejsu

Kursory

• Zapytanie pobiera 200000 56-bajtowych rekordów

• Czas odpowiedzi dla SQL wynosi kilka sekund, a iteracja po kursorze trwa więcej niż godzinę

0

1000

2000

3000

4000

5000

cursor SQL

Th

rou

gh

pu

t (r

eco

rds/

sec)

Page 12: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 1218. Strojenie interfejsu

Funkcje użytkownika

• Funkcja oblicza liczbę dni roboczych między dwiema datami

• Funkcja ta wykonana na serwerze bazy danych (UDF) lub po stronie aplikacji

• Użycie UDF poprawia wydajność, gdy pomaga istotnie zmniejszyć ilość danych wysyłanych do aplikacji

0

1

2

3

4

5

6

20% 80%

Th

rou

gh

pu

t (q

uer

ies/

mse

c)

UDF

applicationfunction

Page 13: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 1318. Strojenie interfejsu

Pobieraj tylko potrzebne kolumny• Nie przesyłaj

niepotrzebnych danych

• Może to uniemożliwić użycie indeksu pokrywającego

• Eksperyment dotyczy przesyłu ¼ atrybutów– Redukcja ilości danych

przekraczających granice interfejsu aplikacji daje sporą poprawę wydajności

0

0.25

0.5

0.75

1

1.25

1.5

1.75

no index index

Th

rou

gh

pu

t (q

uer

ies/

mse

c)

all

covered subset

Page 14: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 1418. Strojenie interfejsu

Pobieraj tylko potrzebne wiersze

• Jeśli użytkownik ogląda tylko niewielki podzbiór dużego zestawu danych, lepiej jest:– Przesyłać tylko ten podzbiór– Obliczać tylko ten podzbiór

• Aplikacje pozwalające na formułowanie zapytań ad-hoc, powinny pozwalać także na ich przerywanie

Page 15: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 1518. Strojenie interfejsu

Minimalizuj kompilacje zapytań

• Prepared statement daje lepszą wydajność, gdy zapytanie jest wykonywane więcej niż jeden raz– Brak kompilacji– Brak dostępu do słownika

danych

• Zachowane plany zapytań stają się nieaktualne, gdy dodano indeksy lub zmieniły się statystyki relacji

0

0.2

0.4

0.6

0 1 2 3 4 5 6

Th

rou

gh

pu

t (q

uer

ies/

sec)

direct

prepared

Eksperyment wykonany naOracle8iEE na Windows 2000.

Page 16: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 1618. Strojenie interfejsu

Strojenie interfejsu aplikacji

• Unikaj interakcji z użytkownikiem w ramach transakcji

• Minimalizuj liczbę komunikatów między aplikacją i bazą danych

• Pobieraj tylko potrzebne kolumny• Pobieraj tylko potrzebne wiersze• Minimalizuj kompilacje zapytań (hard

parse, soft parse, prepared statement)

Page 17: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 1718. Strojenie interfejsu

Masowe ładowanie danych

• W SZBD są narzędzia do masowego ładowania danych

• Parametry ładowania– Ominięcie procesora zapytań– Rezygnacja z wpisów do dziennika– Rezygnacja z aktualizacji indeksów– Rezygnacja z kontroli więzów integralności– Częstotliwość zatwierdzania

Page 18: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 1818. Strojenie interfejsu

Ścieżka bezpośrednia

• Ładowanie 600000 rekordów do tabeli lineitem z zestawu TPCH

• Ścieżka bezpośrednia omija procesor zapytań i menadżera składowania.

• Jest o rzędy wielkości szybsza niż konwencjonalna (z zatwierdzanie co 100 rekordów) i wstawianiem z zatwierdzaniem każdego rekordu

650

10000

20000

30000

40000

50000

conventional direct path insert

Th

rou

gh

pu

t (r

ec/s

ec)

Eksperyment wykonany naOracle8iEE na Windows 2000.

Page 19: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 1918. Strojenie interfejsu

Wielkość wsadu

• Masowe ładowanie 600000 rekordów

• Przepustowość równomiernie rośnie aż do wielkości wsadu 100000 rekordów. Potem pozostaje stała

• Kompromis między wydajnością i ilością danych do przeładowania w przypadku awarii

0

1000

2000

3000

4000

5000

0 100000 200000 300000 400000 500000 600000

Th

rou

gh

pu

t (r

eco

rds/

sec)

Eksperyment wykonany na SQL Server 2000 na Windows 2000.

Page 20: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 2018. Strojenie interfejsu

Parametry podsystemu składu

• Masowe ładowanie 600000 rekordów

• Zgodnie z oczekiwaniem– Wyłączenie dziennika

pomaga

– Zbieranie statystyk szkodzi

– Przyrostowa aktualizacja indeksów szkodzi bardzo

0

2000

4000

6000

8000

rec

ov

era

ble

-n

o s

tati

sti

cs

-re

bu

ild in

de

x

no

nre

co

ve

rab

le

sta

tis

tic

s

inc

rem

en

tal

ind

ex

ma

inte

na

nc

eTH

rou

gh

pu

t (r

ec

/se

c)

Eksperyment wykonany na IBM DB2 UDB V7.1 na Windows 2000.

Page 21: Systemy zarządzania bazami danych

Oryginał: Shasha & Bonnet 2118. Strojenie interfejsu

Łączenie z wieloma bazami danych

• Dzielone połączenia obniżają wysokie koszty inicjacji – Pule połączeń

• Wysyłaj zapytania żywcem, gdy zajętość procesora klienta jest krytyczna– Eliminacja przepisywania zapytania, aby dostosować

się do konkretnego dialektu SQL

• Przesyłaj duże ilości danych, gdy wydajność nie jest ograniczona przepustowością łącza