210 likes | 370 Views
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
E N D
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ęć] 18. 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. 18. 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 18. Strojenie interfejsu
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 ODBC a OCI 18. 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 18. Strojenie interfejsu
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 :tdostępne dla użytkownika :usr select doc.type as tfrom authorizedwhere user = :usr; Dla każdego:twyślij zapytanie: select id, datefrom docwhere type = :t; Aplikacja a nie SZBD realizuje to złączenie! Ortodoksja obiektowa szkodzi 18. 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 18. 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) 18. Strojenie interfejsu
Pobierz 2000 rekordów Pętla: 200 zapytań Bez pętli: 1 zapytanie Zbyt częste przekraczanie interfejsu aplikacji pogarsza wydajność Pętle 18. Strojenie interfejsu
Zapytanie pobiera 200000 56-bajtowych rekordów Czas odpowiedzi dla SQL wynosi kilka sekund, a iteracja po kursorze trwa więcej niż godzinę Kursory 18. Strojenie interfejsu
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 Funkcje użytkownika 18. Strojenie interfejsu
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 Pobieraj tylko potrzebne kolumny 18. 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 18. Strojenie interfejsu
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 Minimalizuj kompilacje zapytań Eksperyment wykonany na Oracle8iEE na Windows 2000. 18. 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) 18. 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 18. Strojenie interfejsu
Ł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 Ścieżka bezpośrednia Eksperyment wykonany naOracle8iEE na Windows 2000. 18. Strojenie interfejsu
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 Wielkość wsadu Eksperyment wykonany na SQL Server 2000 na Windows 2000. 18. Strojenie interfejsu
Masowe ładowanie 600000 rekordów Zgodnie z oczekiwaniem Wyłączenie dziennika pomaga Zbieranie statystyk szkodzi Przyrostowa aktualizacja indeksów szkodzi bardzo Parametry podsystemu składu Eksperyment wykonany na IBM DB2 UDB V7.1 na Windows 2000. 18. 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 18. Strojenie interfejsu