SQL Sztuka programowania.pdf
(
595 KB
)
Pobierz
SQL. Sztuka
programowania
Autorzy: Stéphane Faroult, Peter Robson
T³umaczenie: Marek Pêtlicki
ISBN: 978-83-246-0895-9
Tytu³ orygina³
u:
The Art of SQL
Format: B5, stron: 472
Wypowiedz wojnê niewydajnym bazom danych
Projektowanie wydajnych baz danych
Uwzglêdnianie kontekstu dzia³ania aplikacji bazodanowych
Poprawa szybkoœci dzia³ania Ÿle zaprojektowanych systemów
Twoje bazy danych dzia³aj¹ zbyt wolno? Pora to zmieniæ! Wraz ze wzrostem wielkoœci
korporacyjnych baz danych czas dostêpu do nich ma coraz wiêksze znaczenie. Napisanie
poprawnie dzia³aj¹cego kodu w jêzyku SQL nie jest trudne, jednak tworzenie wydajnych
aplikacji bazodanowych jest prawdziw¹ sztuk¹. Jak mo¿esz zg³êbiæ jej tajniki i staæ siê
lepszym programist¹? Zdaniem autora tej ksi¹¿ki nauka wydajnej pracy z bazami danych
przypomina poznawanie zasad prowadzenia wojny, dlatego wzorem klasycznej pozycji
„Sztuka wojny” autorstwa Sun Tzu prowadzi Ciê on przez poszczególne etapy kampanii
przeciwko nieefektywnie zaprojektowanym i napisanym aplikacjom bazodanowym.
„SQL. Sztuka programowania” to praktyczny podrêcznik, dziêki któremu szybko
poszerzysz sw¹ wiedzê w zakresie efektywnego stosowania jêzyka SQL. Nauczysz siê
dbaæ o wydajnoœæ aplikacji ju¿ na etapie ich projektowania, a tak¿e myœleæ o pracy
z bazami danych w kategoriach procesów, wykraczaj¹c poza same zapytania jêzyka
SQL. Dowiesz siê, jak poprawnie u¿ywaæ indeksów oraz jak monitorowaæ szybkoœæ
dzia³ania bazy. Poznasz standardowe scenariusze zwiêkszania wydajnoœci, które
pozwol¹ Ci zastosowaæ sprawdzone fortele we w³asnych projektach oraz w bazach
zaprojektowanych przez innych programistów.
Projektowanie pod k¹tem wydajnoœci
Efektywne korzystanie z baz danych w programach
Poprawne stosowanie indeksów
Projektowanie optymalnych zapytañ SQL
Praca z du¿ymi zbiorami danych
Korzystanie ze struktur drzewiastych
Monitorowanie wydajnoœci
Obs³uga wspó³bie¿noœci
Radzenie sobie z niewydajnymi projektami
Poznaj praktyczne techniki poprawy wydajnoœci baz danych
Wydawnictwo Helion
ul. Koœciuszki 1c
44-100 Gliwice
tel. 032 230 98 63
e-mail: helion@helion.pl
SPIS TREŚ CI
Wstęp
7
1.
Plany strategiczne
15
Projektowanie baz danych pod kątem wydajności
2.
Prowadzenie wojny
51
Wydajne wykorzystanie baz danych
3.
Działania taktyczne
87
Indeksowanie
4.
Manewrowanie
113
Projektowanie zapytań SQL
5.
Ukształtowanie terenu
151
Zrozumienie implementacji fizycznej
6.
Dziewięć zmiennych
179
Rozpoznawanie klasycznych wzorców SQL
7.
Odmiany taktyki
231
Obsługa danych strategicznych
8.
Strategiczna siła wojskowa
273
Rozpoznawanie trudnych sytuacji i postępowanie w nich
9.
Walka na wielu frontach
307
Wykorzystanie współbieżności
10.
Gromadzenie sił
337
Obsługa dużych ilości danych
11.
Fortele
381
Jak uratować czasy reakcji
12.
Zatrudnianie szpiegów
417
Monitorowanie wydajności
Ilustracje
451
O autorach
453
Skorowidz
455
ROZDZIAŁ DRUGI
Prowadzenie wojny
Wydajne wykorzystanie baz danych
Il existe un petit nombre de principes fondamentaux de la guerre,
dont on ne saurait s’écarter sans danger, et dont l’application au contraire
a été presque en tous temps couronnée par le succès.
Istnieje niewielka liczba fundamentalnych zagadnień związanych z prowadzeniem wojny,
których nie wolno lekceważyć: zaprawdę, stosowanie się do nich prawie niezawodnie
prowadzi do sukcesu.
— Generał Antoine-Henri de Jomini (1779 – 1869)
Zarys sztuki wojennej
52
ROZDZIAŁ DRUGI
K
ażdy
, kto był zaangażowany w proces przejścia projektu z fazy rozwoju
w fazę produkcyjną, przyzna z pewnością, że prawie czuł tumult i wrzawę
bitwy. Bardzo często zdarza się, że na kilka tygodni przed sądnym dniem
przeprowadzone testy wydajności ujawniają smutny fakt: system nie
będzie działał tak płynnie, jak to zakładano. Zaprasza się ekspertów,
optymalizuje zapytania SQL, w kryzysowych burzach mózgów biorą udział
administratorzy baz danych i systemów. W końcowym rozrachunku na
sprzęcie dwukrotnie bardziej kosztownym osiąga się wydajność jedynie
teoretycznie zbliżoną do zakładanej.
Często w zastępstwie działań strategicznych stosuje się działania taktyczne.
Strategia wymaga zastosowania architektury i modelu przystosowanych do
wymagań projektu. Podstawowych zasad stosowanych w czasie wojny jest
zaledwie kilka, ale zadziwiająco często bywają one ignorowane. Błędy
w architekturze okazują się niezwykle kosztowne, a programista SQL-a
musi wkraczać na pole bitwy dobrze przygotowany do walki, musi wiedzieć,
gdzie chce dotrzeć i którą drogą. W tym rozdziale przeanalizujemy
podstawowe cele zwiększające szanse na sukces w pisaniu programów
w sposób efektywny wykorzystujących bazy danych.
Identyfikacja zapytań
Przez stulecia jedynym sposobem, w jaki generał mógł śledzić losy bitwy,
była obserwacja oddziałów na podstawie kolorów umundurowania
i niesionych przez nich proporców. Gdy jakiś proces w środowisku bazy
danych zużywa nadmierną ilość mocy procesora, często istnieje możliwość
zidentyfikowania zapytania SQL odpowiedzialnego za to zadanie.
Nierzadko jednak trudne bywa odkrycie tego, która część aplikacji
wywołała problematyczne zapytanie, szczególnie w środowisku, w którym
wykorzystywane są zapytania budowane w sposób dynamiczny. Mimo tego
że wiele solidnych produktów wyposażonych jest w mechanizmy
monitorujące, często zdumiewająco trudno jest znaleźć odniesienie między
zapytaniem SQL a środowiskiem, w którym ono działa. Z tego powodu
dobrze jest nabrać nawyku oznaczania programów i krytycznych modułów
przez włączanie komentarzy w kodzie SQL w taki sposób, aby łatwo było
zidentyfikować źródło kłopotów. Na przykład:
/* REJESTRACJA KLIENTA */ select ...
PROWADZENIE WOJNY
53
Tego typu komentarze identyfikujące mogą być pomocne w śledzeniu
błędnie działającego kodu. Mogą być również pomocne przy określaniu
obciążenia serwera bazy danych powodowanego przez każdą korzystającą
z niego aplikację, szczególnie w przypadku, gdy spodziewamy się, że
wprowadzane zmiany mogą spowodować zwiększenie obciążenia, i musimy
oszacować, czy posiadany sprzęt ma szansę sprostać większym wymaganiom.
Niektóre produkty posiadają specjalizowane mechanizmy rejestrujące,
które pozwalają uniknąć komentowania każdego wyrażenia. Na przykład
pakiet
dbms_application_info
serwera Oracle pozwala oznakować program
za pomocą 48-znakowej nazwy modułu, 32-znakowej nazwy akcji
i 64-znakowego pola informacji o kliencie. Zawartość tych pól jest
kontrolowana przez twórcę aplikacji. W środowisku Oracle można użyć
tego pakietu do śledzenia tego, jaka aplikacja wykorzystuje bazę danych
w danej chwili, jak również tego, co dana aplikacja robi. Do tego służą
dynamiczne perspektywy
V$
, za pomocą których można śledzić stan
pamięci.
Identyfikowanie wyrażeń ułatwia śledzenie zależności obciążenia.
Trwałe połączenia do bazy danych
Nowe połączenie do bazy danych tworzy się szybko i łatwo, lecz ta
prostota czasem przesłania fakt, że szybkie, cykliczne wywołania połączeń
wiążą się z konkretnym, niemałym kosztem. Dlatego połączenia z bazą
danych warto traktować z rozwagą. Konsekwencje wywoływania wielu
cyklicznych połączeń, być może ukrytych w ramach aplikacji, mogą być
znaczące, co zademonstruje kolejny przykład.
Jakiś czas temu trafiłem na aplikację, która przetwarzała dużą liczbę
niewielkich plików tekstowych o rozmiarach do stu wierszy. Każdy wiersz
zawierał dane oraz identyfikator bazy danych, do której dane te miały być
załadowane. W tym przypadku był wykorzystywany tylko jeden serwer
bazy danych, ale prezentowana zasada obowiązuje również w przypadku
setek baz danych.
Plik z chomika:
Smoke-Wood
Inne pliki z tego folderu:
JavaServer Faces Wydanie III(1).pdf
(596 KB)
Linux Najlepsze przepisy Wydanie II(1).pdf
(596 KB)
Macromedia FreeHand MX Oficjalny podrecznik(1).pdf
(588 KB)
Generator Macromedia Flash nastepny krok(1).pdf
(584 KB)
JavaServer Faces Wydanie III.pdf
(596 KB)
Inne foldery tego chomika:
- ✖ COMPANY OF HEROES 2 OFENSYWA W ARDENACH [PC]
- ✖ EVOLVE [PC]
- ✖ FAHRENHEIT REMASTERED [PC]
- ✖ LEGO BATMAN 3 POZA GOTHAM [PC]
- � ✔ F1 2014 (2014) XBOX360 - PL✔
Zgłoś jeśli
naruszono regulamin