Systemy zarządzania bazami danych 10. Strojenie

Oryginał: Shasha & Bonnet10. Strojenie2

Oryginał: Shasha & Bonnet10. Strojenie3 Strojenie bazy danych Strojenie bazy danych to działalność mająca na celu sprawienie, aby baza danych działała szybciej. Szybciej zwykle oznacza większą przepustowość, ale może też oznaczać krótszy czas reakcji aplikacji, w których jest on ważny.

Oryginał: Shasha & Bonnet10. Strojenie4 Programista aplikacyjny Zmyślny programista aplikacyjny (np. konsul. SAP) Admin BD, Stroiciel BD Sprzęt [procesor(y), dysk(i), pamięć] System operacyjny Men. transakcjiOdtwarzanie Podsystem składu Indeksy Procesor zapytań Aplikacja

Oryginał: Shasha & Bonnet10. Strojenie5 Cel wykładu Pokazać: –Pryncypia strojenia, które są wspólne dla różnych systemów, platform i technologii –Wyniki eksperymentów nada efektywnością proponowanych metod –Techniki radzenia sobie z problemami wydajnościowymi

Oryginał: Shasha & Bonnet10. Strojenie6 Myśl globalnie, działaj lokalnie Zasada taka jak w medycynie (chirurgii) –Osiągnąć jak największy efekt za pomocą jak najmniejszej interwencji –Nie lecz symptomów, lecz przyczyny –Nie zajmuj się drobnymi problemami, bo możesz popsuć całość Strojenie baz danych nie mniej tajemne niż medycyna (mniej wtajemniczonych)

Oryginał: Shasha & Bonnet10. Strojenie7 Partycjonowanie rozpycha wąskie gardła Partycjonowanie w przestrzeni –Rozproszenie danych geograficzne –Hurtownictwo danych, bazy analityczne –Bazy rezerwowe (partycjonowanie dla dostępności) –Rozproszenie danych na wielu dyskach (równoległa praca kontrolerów) Partycjonowanie w czasie –Przeniesienie zadań wsadowych na okresy mniejszego obciążenia (noc, weekend)

Oryginał: Shasha & Bonnet10. Strojenie8 Inicjacja jest droga, używanie tanie Inicjacja operacji dyskowej jest droga, a potem odczyt ciągu sektorów tani Wysłanie komunikatu sieciowego jest drogie, ale każdy dodatkowy bajt wysłany tym samym komunikatem jest bardzo tani Analiza składniowa, kontrola praw dostępu, optymalizacja zapytania jest droga, ale następne wykonanie tego zapytania tanie –używaj prepared statement, soft parse Otwarcie połączenia z bazą danych jest drogie, ale wielokrotne użycie tanie –Używaj puli połączeń

Oryginał: Shasha & Bonnet10. Strojenie9 Wsadź na serwer to, co ma tam być Równoważ obciążenie klienta i serwera Lepszy jest mechanizm wyzwalaczy niż aktywne czekanie aplikacji na zdarzenie (np. poprzez wielokrotne ponawianie zapytania o oczekiwane dane) Interakcja z użytkownikiem GUI powinna odbywać się poza zakresem transakcji, bo trwa długo Obliczenia numeryczne (np. FFT) raczej nie na SZBD Złączenie tabel raczej nie na kliencie

Oryginał: Shasha & Bonnet10. Strojenie10 Bądź gotowy na kompromis Dodanie pamięci RAM przyspiesza system, ale kosztuje $ Dodanie indeksu przyśpiesza zapytania, ale spowalnia modyfikacje danych Robienie dużych zapytań raportujących na kopii głównej bazy danych, obniża jej obciążenie, ale kosztuje $ i sprawia, że odpowiedzi nie są dokładne Obniżenie izolacji transakcji zwiększa szybkość, ale obniża poprawność

Oryginał: Shasha & Bonnet10. Strojenie11 Eksperymenty Będą wyniki eksperymentów pozwalających ocenić sensowność porad zawiera zapytania SQL, dane i narzędzia do przeprowadzania eksperymentów Teraz to jest nawet:

Oryginał: Shasha & Bonnet10. Strojenie12 Sprzęt użyty do eksperymentów SQL Server 7, SQL Server 2000, Oracle 8i, Oracle 9i, DB2 UDB 7.1 Trzy konfiguracje: –Dual Xeon (550MHz,512Kb), 1Gb RAM, Internal RAID controller from Adaptec (80Mb) 2 Ultra 160 channels, 4x18Gb drives (10000RPM), Windows –Dual Pentium II (450MHz, 512Kb), 512 Mb RAM, 3x18Gb drives (10000RPM), Windows –Pentium III (1 GHz, 256 Kb), 1Gb RAM, Adapter with 2 channels, 3x18Gb drives (10000RPM), Linux Debian 2.4.