Aspekty fizyczne baz danych

Niepoprawny projekt bazy danych

Zy projekt logiczny bazy danych prowadzi do kiepskiej wydajnociowo bazy danych. Przy tworzeniu bazy danych od podstaw, warto powici wicej czasu na dobry projekt logiczny. Jest to warunek konieczny do dobrej bazy danych z punktu wydajnociowego. Wszelkie poprawki w schemacie logicznym bazy danych dopiero podczas implementacji s trudne do przeprowadzenia. Straty na wydajnoci wynikajce z nieoptymalnego projektu bazy danych s cikie do nadrobienia nawet przy zastosowaniu drogich rozwiza sprztowych.

Plan wykadu
Wykonywanie zapyta Indeksowanie Partycjonowanie Zalecenia dla twrcw bazy danych (zbir dobrych praktyk)

Wykonywanie zapyta
Kompilacja zapytania Wykonywanie zapytania

Plan wykonania zapytania

Dla kadej paczki instrukcji tworzony jest osobny plan wykonania zapytania Etapy utworzenia planu zapytania:
Parsowanie sprawdzenie czy zapytanie jest poprawne syntaktycznie; Bindowanie sprawdzanie semantyczne (np. czy obiekty, do ktrych odwouj si zapytania znajduj si rzeczywicie w bazie danych) Optymalizacja znalezienie najlepszego planu wykonania zapytania, czyli takiego, ktry wykona zapytanie najszybciej.

Plany wykonania zapyta s zapisywanie w pamici cache i mog by powtrnie uywane.

Zapytanie
SELECT C.CustomerID, COUNT(O.OrderID) AS NumOrders FROM dbo.Customers AS C LEFT OUTER JOIN dbo.Orders AS O ON C.CustomerID = O.CustomerID WHERE C.City = 'London' GROUP BY C.CustomerID HAVING COUNT(O.OrderID) > 5 ORDER BY NumOrders;

Plan zapytania

Drzewa
Drzewo skada si z wzw Kady wze oprcz korzenia ma jednego przodka i moe mie rn liczb potomkw Korze nie ma przodka Wze, ktry nie ma potomkw jest liciem Poziom wza jest zawsze wikszy o 1 ni poziom jego przodka, poziom korzenia = 0

Czym jest B+ drzewo

Cechy charakterystyczne B+ drzewa Jest drzewem zbalansowanym:
Kada cieka z korzenia do lici ma t sam dugo Kady wierzchoek posiada od n/2 do n dzieci, gdzie n jest ustalone dla kadego drzewa (regua 50%) Wskaniki do danych znajduj si tylko na liciach

B+ drzewo przykad (n=4)

Przeszukiwanie B+ drzewa
Przeszukiwanie B+ drzewa polega na porwnywaniu wartoci klucza w drzewie. Przykad: znajd warto 45 i 15 w poniszym drzewie.

Przeszukiwanie
Rezultat: 1. Wartoci 45 nie ma w drzewie. 2. Dla wartoci 15 zwrcona zostanie pozycja wskanika.

Wstawianie
Jeli wstawianie do B+ drzewa spowoduje, e drzewo nie bdzie zbalansowane, wwczas nastpuje przebudowa drzewa. Przykad #1 : wstawianie 28 do drzewa.

25 28 30 Zachowana jest regua 50%

Wstawianie
Rezultat:

Wstawianie
Przykad #2: wstawianie 70 do drzewa

Wstawianie
Reorganizacja drzewa

50

55

60

65

70

50

55

60

65

70

Naruszenie reguy 50%, reorganiza cja drzewa

Wstawianie
Rezultat: wybieranie rodkowego klucza 60, i umieszczenie go w wierzchoku indeksu pomidzy 50 i 75.

Wstawianie
Przykad #3: dodawanie wartoci klucza 95 do drzewa.

75 80 85 90 95
Naruszenie reguy 50%, podzielenie licia

75 80

85 90 95

25 50 60 75 85

Wstawianie
Rezultat: wstawienie wartoci klucza 60 do wza indeksowego i reorganizacja drzewa.

Algorytm wstawiania w B+ drzewie

Strona danych pena Nie Tak Strona indeksu pena Nie Nie Akcja Wstaw rekord w porzdku rosncym do odpowiedniego licia
1. 2. 3. 4. 1. 2. 3. 4. 5. 6. 7. Podziel stron danych . Umie rodkowy klucz danych do strony indeksowej w porzdku rosncym Lewa strona licia zawiera rekordy o kluczu mniejszym ni klucz rodkowy. Prawa strona licia zawiera rekordy o kluczu mniejszym lub rwnym ni klucz rodkowy. Podziel stron danych. Lewa strona licia zawiera rekordy o kluczu mniejszym ni klucz rodkowy. Prawa strona licia zawiera rekordy o kluczu mniejszym lub rwnym ni klucz rodkowy. Podziel stron indeksu. Klucz rodkowy zapisywany jest do strony wyszego poziomu. Klucze mniejsze od rodkowego klucza zapisywane s do lewego licia, wiksze lub rwne do prawego. Jeli nastpny poziom jest peny, nastpuje kolejny podzia.

Tak

Tak

Usuwanie
Zasady podobne do wstawiania, B+ drzewo musi by przebudowane przy zaamaniu reguy 50%. Przykad #1: usunicie 70 z drzewa

To jest OK. 60 65

Usuwanie
Rezultat:

Usuwanie
Przykad #2: usunicie 25 z drzewa, przy czym 25 pojawia si na stronie indeksu.
Ale

28 30 To jest OK.

Usuwanie
Rezultat: zastpienie przez 28 na stronie indeksu.
Dod. 28

Usuwanie
Przykad #3: usuwanie 60 z drzewa

65 50 55 65
Zamanie reguy 50%

Usuwanie
Rezultat: usuniecie 60 ze strony indeksowej i reorganizacja grafu.

Algorytm usuwania dla B+ drzewa

Strona danych poniej wspczynnika wypenienia Nie Strona indeksu poniej wspczynnika wypenienia Nie Akcja

Usu rekord ze strony danych. Jeli klucz pojawia si w stronie indeksu, zamie go przez nastpny klucz. Przenie dane ze strony, z ktrych usunito dane do strony ssiedniej. Zmie stron indeksu tak, aby odzwierciedli zmian w liciach. Przenie dane ze strony, z ktrych usunito dane do strony ssiedniej. Zmie stron indeksu tak, aby odzwierciedli zmian w liciach. Przenie dane indeksowe do strony ssiedniej. Dostosuj stron indeksow poziom wyej do powyszych zmian. Algorytm powinien by kontynuowany do momentu, gdy strona indeksu bdzie poniej wspczynnika wypenienia

Tak

Nie

Tak

Tak

Rodzaje indeksw na przykadzie SQL Server

Indeks klastrowy:
moe by jeden w tabeli; dane znajduj si w liciach; utworzenie klucza gwnego na kolumn w tabeli powoduje dodanie indeksu klastrowego na t kolumn; create clustered index nazwa_indeksu on tabela (kolumna1,)

Indeks nieklastrowy:
moe by wicej ni jeden w tabeli; w liciach nie ma danych tylko s wskaniki do danych; create nonclustered index nazwa_indeksu on tabela (kolumna1,)

Indeks klastrowy

Indeks nieklastrowy

Indeks klastrowy i nieklastrowy

Kiedy stosowa indeksy?

Przyspieszaj dostp do bazy danych. Powinny by projektowane ostronie Zajmuj miejsce na dysku, a wic nie powinno by ich wicej ni potrzeba Przy zmianie danych w bazie (insert, update, delete) indeksy s przebudowywane, to zajmuje czas

Kiedy stosowa indeksy?

Gdy tabela jest czsto zmieniana, naley nie uywa zbyt wielu indeksw na niej oraz indeksw na wielu kolumnach Gdy tabela jest rzadko modyfikowana, mona zakada duo indeksw na niej Mae tabele naley indeksowa rozsdnie, gdy nawigacja po indeksie moe by dusza ni skanowanie tabeli Lepiej implementowa indeks na kolumnie o wartociach unikalnych. Im mniej powtarzajcych si wartoci, tym lepsza wydajno indeksu. Przy indeksach zoonych naley bra pod uwag kolejno. Na pierwszym miejscu powinny by takie kolumny, ktre najczciej s uywane w klauzuli WHERE.

Indeksy a zapytania
Czsto zmian w bazie ma wpyw na wydajno indeksw Lepiej modyfikowa du paczk danych na raz ni robi kilka zapyta. W pierwszym przypadku indeksy bd reorganizowane tylko raz. Naley uywa indeksw nieklastrowych na kolumnach, ktre bd bray udzia w instrukcjach zczenia. Naley uywa indeksw nieklastrowych w przypadku, gdy bdzie czsto wykonywana instrukcja WHERE na tych kolumnach.

Dlaczego baza powinna by znormalizowana?

Redukuje ilo danych w bazie. Zwiksza si wic wydajno bazy. Redukuje ilo wartoci NULL w bazie danych. Uywanie wartoci NULL znacznie obnia wydajno bazy danych, szczeglnie w klauzulach WHERE. Redukuje liczb kolumn w bazie co sprawia, e wicej wierszy mieci si na jednej stronie, co z kolei zwiksza wydajno serwera. Redukuje ilo kodu SQL, ktry musiaby by napisany w przypadku bazy nieznormalizowanej. Im bardziej znormalizowana baza, tym wicej tabel i wicej indeksw klastrowych, ktre zwikszaj wydajno. Brak redundancji powoduje, e nie ma potrzeby obsugi anomalii bazy danych:
dodawania, modyfikacji takich samych danych w kilku miejscach usuwania tych samych danych z kilku tabel

Transakcje
Transakcje powinny by krtkie. Im krtsza transakcja tym krtsze s blokady na danych. To z kolei zwiksza wydajno. Nie naley uywa transakcji do odczytywania danych. Tam gdzie to moliwe powinien by niski poziom transakcji. Transakcje nie powinny by otwarte podczas oczekiwania na reakcj uytkownika. Transakcje powinny by rozpoczynane i koczone jawnie.

Transakcje - przykad
Przykad: Tworzenie nowej faktury Scenariusz #1:
1) Rozpoczcie transakcji 2) Dodanie faktury 3) Dodanie elementw faktury 4) Zatwierdzenie faktury 5) Zatwierdzenie transakcji

Scenariusz #2:
1) Dodanie faktury 2) Dodanie elementw faktury 3) Rozpoczcie transakcji 4) Zatwierdzenie faktury 5) Zakoczenie transakcji

Scenariusz #2: krcej s dane blokowane podczas transakcji. Scenariusz #1: Wewntrz transakcji naley czeka na reakcj uytkownika.

Dlaczego warto uywa procedur skadowanych?

Redukcja ruchu sieci. Jeli aplikacja kliencka wysya kod SQL do serwera, to wysya nazw procedury skadowanej, a nie pojedyncze instrukcje SQL. Plan wykonania zapytania procedury skadowanej pozostaje w pamici cache i moe by ponownie uyty Kod w procedurze skadowanej mona zmieni nie zmieniajc kodu aplikacji.

Poprawienie wydajnoci operacji Join

Operacj JOIN przyspieszaj indeksy, ktre s na atrybutach zczenia. Wydajno jest wiksza, gdy atrybuty zcze s numeryczne. Jeli jedna z tabel jest maa, wwczas jest ona pobierana do pamici cache, co zwiksza wydajno operacji Nested Loop.

Partycjonowanie
Partycjonowanie jest fizycznym podziaem danych pomidzy rne pliki bazy danych Partycjonowa mona tabele i indeksy bazy danych Uytkownik bazy danych nie jest wiadomy tego, czy struktura jest podzielona czy te nie jest. Partycjonowanie nie ma wpywu na zapytania SQL.

Korzyci z partycjonowania
Podniesienie skalowalnoci i zarzdzania tabelami o duych rozmiarach (rzdu kilkuset megabajtw) Lepszy dostp do danych Moliwo wykorzystania wieloprocesorowych serwerw (kady procesor moe wwczas obsugiwa rne partycje) Przykad:
Dana jest tabela sprzeda posiadajca rekordy dotyczce sprzeday z wielu miesicy. Zakadamy, e dzielimy tabel po miesicu. Na ostatnim miesicu s wykonywane czste modyfikacje, a z poprzednich tylko odczyt.

Modyfikacje z ostatniego miesica nie maja wic wpywu na wydajno z miesicy poprzednich.

Konfigurowanie partycjonowania tworzenie bazy danych

CREATE DATABASE [Data Partition DB] ON PRIMARY (NAME='Data Partition DB Primary FG', FILENAME= 'C:\Data\Primary\Data Partition DB Primary FG.mdf', SIZE=5, MAXSIZE=500, FILEGROWTH=1 ), FILEGROUP [Data Partition DB FG1] (NAME = 'Data Partition DB FG1', FILENAME = 'C:\Data\FG1\Data Partition DB FG1.ndf', SIZE = 5MB, MAXSIZE=500, FILEGROWTH=1 ), FILEGROUP [Data Partition DB FG2] (NAME = 'Data Partition DB FG2', FILENAME = 'C:\Data\FG2\Data Partition DB FG2.ndf', SIZE = 5MB, MAXSIZE=500, FILEGROWTH=1 ), FILEGROUP [Data Partition DB FG3] (NAME = 'Data Partition DB FG3', FILENAME = 'C:\Data\FG3\Data Partition DB FG3.ndf', SIZE = 5MB, MAXSIZE=500, FILEGROWTH=1 )

Konfigurowanie partycjonowania
Tworzenie funkcji partycji:
CREATE PARTITION FUNCTION [Data Partition Range](int) AS RANGE LEFT FOR VALUES (100000)

Tworzenie schematu partycji:

CREATE PARTITION SCHEME [Data Partition Scheme] AS PARTITION [Data Partition Range] TO ([Data Partition DB FG1], [Data Partition DB FG2]);

Tworzenie tabeli na partycji:

CREATE TABLE MyTable (ID INT NOT NULL, Date DATETIME, Cost money) ON [Data Partition Scheme] (ID);

Dodawanie danych
declare @count int set @count =1 while @count <=100 begin insert into MyTable select @count,getdate(),100.00 set @count=@count+1 end set @count =100002 while @count <=100202 begin insert into MyTable select @count,getdate(),200.00 set @count=@count+1 end

Odczyt danych
Partycjonowanie nie ma wpywu na polecenia SQL:
select * from MyTable

Odczyt danych z uwzgldnieniem partycji:

select $partition.[Data Partition Range](t.ID), * from MyTable as t

Dzikuj