Systemy zarządzania bazami danych

1. Systemy zarządzania bazami danych 18. Strojenie interfejsu

2. Aplikacja Procesor zapytań Indeksy Podsystem składu Współbieżność Odtwarzanie System operacyjny Sprzęt[Procesor(y), Dysk(i), Pamięć] 18. Strojenie interfejsu

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18. Ł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

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

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

21. Łą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