systemy zarządzania bazami danych
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 PresentationTRANSCRIPT
Systemy zarządzania bazami danych
18. Strojenie interfejsu
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
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.
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
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
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
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!
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
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)
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)
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)
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
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
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
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.
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)
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
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.
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.
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.
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