CS 245: Database System Principles

Systemy zarządzania bazami
danych
10. Strojenie
Oryginał: Shasha & Bonnet
10. Strojenie
2
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 & Bonnet
10. Strojenie
3
Programista
aplikacyjny
Aplikacja
Zmyślny
programista
aplikacyjny
Procesor zapytań
(np. konsul. SAP)
Podsystem składu
Indeksy
Men. transakcji
Admin BD,
Stroiciel BD
Odtwarzanie
System operacyjny
Sprzęt [procesor(y), dysk(i), pamięć]
Oryginał: Shasha & Bonnet
10. Strojenie
4
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 & Bonnet
10. Strojenie
5
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 & Bonnet
10. Strojenie
6
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 & Bonnet
10. Strojenie
7
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 & Bonnet
10. Strojenie
8
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 & Bonnet
10. Strojenie
9
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 & Bonnet
10. Strojenie
10
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/
Oryginał: Shasha & Bonnet
10. Strojenie
11
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.
Oryginał: Shasha & Bonnet
10. Strojenie
12