Systemy zarządzania bazami danych
10. Strojenie
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.
Programista aplikacyjny
Zmyślny programista aplikacyjny
(np. konsul. SAP)
Admin BD, Stroiciel BD
Sprzęt [procesor(y), dysk(i), pamięć]
System operacyjny
Men. transakcji Odtwarzanie
Podsystem składu Indeksy
Procesor zapytań Aplikacja
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
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)
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
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ń
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
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ść
Eksperymenty
• Będą wyniki eksperymentów
pozwalających ocenić sensowność porad
• http://www.diku.dk/dbtune/experiments zawiera zapytania SQL, dane i narzędzia do przeprowadzania eksperymentów
• Teraz to jest nawet:
http://www.databasetuning.org/
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 2000.
– Dual Pentium II (450MHz, 512Kb), 512 Mb RAM, 3x18Gb drives (10000RPM), Windows 2000.
– Pentium III (1 GHz, 256 Kb), 1Gb RAM, Adapter 39160 with 2 channels, 3x18Gb drives (10000RPM), Linux Debian 2.4.
