Przy dostępie do danych i ich analizie za pomocą języka SQL daną sekwencję kwerend często można zapisać na różne sposoby. Efektywność jej wykonania bywa uzależniona od tego, z jaką konkretnie bazą mamy do czynienia.

Metody działania optymalizatorów wyrażeń i zapytań bazodanowych (np. optymalizatory SQL) są jedną z pilnie strzeżonych tajemnic producentów baz danych. A to od tych optymalizatorów zależy, czy dana baza będzie działać "szybko", czy będzie mogła obsłużyć wymaganą liczbę użytkowników przy pracy na danej bazie sprzętowej.

Wiedzieć jak

W przypadku optymalizacji zapytań można wskazać kilka kluczowych elementów, które w największym stopniu wpływają na pracę optymalizatora. Jednym z podstawowych elementów bazy relacyjnej jest mechanizm złączeń kilku tabel. Przy tworzeniu tego typu złączeń zwykle jest wykorzystywany indeks (jeżeli projektant bazy zadbał o jego istnienie), który ma postać drzewa podobnego do B-drzewa czy R-drzewa. Złączeniu towarzyszy jednak pewna liczba warunków, które dodatkowo precyzują zakres zbioru wyjściowego. Dopiero analizując te warunki, można określić optymalny sposób wygenerowania sumy zbiorów, w tym przechodzenia indeksów. Każda rozbudowana kwerenda ma zazwyczaj kilka możliwych planów wykonania, zaś optymalizator musi wybrać tylko jeden z nich do realizacji. Zwykle przy wyborze są wykorzystywane modele statystyczne (np. wiedza o rozkładzie wartości w polach klucza). Ale np. w ramach PostgreSQL eksperymentuje się z algorytmami genetycznymi (w wersji testowej), które określają, w jakiej kolejności należy wyznaczać kolejne złączenia, by było to optymalne. Jednak bazy komercyjne raczej opierają się na algorytmach czysto statystycznych.

Oczywiście optymalizacja zapytań jest tylko jednym z elementów decydujących o wydajności bazy danych. Tak samo (a może nawet bardziej) istotne jest działanie bazy w sytuacji, gdy korzysta z niej wielu użytkowników. Jak duża część tabeli jest blokowana podczas aktualizacji?

Jak zachowuje się interfejs sieciowy? W jaki sposób działa pamięć podręczna? To kluczowe pytania, na które odpowiedzi także mają istotny wpływ na ostateczne wyniki, chociażby w teście TPC/C czy TPC/H.

Warto rozważyć, czy dobrym rozwiązaniem nie byłoby, by projektant bazy danych, tworząc kwerendę, od razu sugerował optymalizatorowi, w jaki sposób dobrać plan wykonania, np. kolejność wyliczania złączeń, sposób tworzenia blokad itp. Równocześnie określałby ważne parametry np. wielkość jednostkowego bloku zapisywanego na dysk czy sposób podziału pamięci. Szczególnie dużo tego typu opcji zawierają bazy Oracle i DB2.

Jednak jednorazowy dobór tych parametrów wcale nie musi okazać się optymalnym rozwiązaniem w każdej sytuacji. W momencie gdy pojawiają się dodatkowe tabele czy równolegle na tym samym serwerze pracują inne bazy danych, może się okazać, że starannie dobrane i przetestowane parametry, ustalone na stałe, są przyczyną wolniejszego działania systemu. Microsoft SQL Server 7.0 był chyba pierwszą samozarządzalną i samooptymalizującą się bazą danych, gdzie można było ustawiać wiele opcji - ale tak naprawdę nie było to niezbędne. Obecnie każdy producent bazy wyposaża ją w mechanizmy samoregulacji.

Jednak są takie operacje, których nie można rozwiązać automatycznie. Na przykład istnienie indeksu przyspiesza wybór elementów z bazy. Ale może się okazać, że jest to tak rzadko wykorzystywany indeks, iż nie równoważy to kosztów związanych z aktualizacją indeksu przy każdej operacji zapisu. Aby to oszacować, konieczne jest niestety monitorowanie obciążenia bazy czy dokładne przeanalizowanie planów, jakie zwykle generuje baza. Każdy motor dysponuje jakimś mechanizmem, który pozwala przeanalizować aktualne obciążenie czy nawet podejrzeć plan. Dostępne są także zewnętrzne narzędzia (np. ZeroImpact), które analizują ruch w sieci i na bieżąco pokazują, co wykonuje baza danych.

Nieobojętne uwarunkowania

Mimo pewnych teoretycznych wyobrażeń, w rzeczywistości baza musi bardzo ściśle współpracować z systemem operacyjnym. Na przykład z całą pewnością asynchroniczne wykonywanie operacji wejścia/wyjścia (w tym odczytu i zapisu na dysk) zdecydowanie przyspieszy działanie bazy. Duży wpływ na to ma również sposób obsługi podsystemu dyskowego, tzn. czy operacje wykonuje odpowiednia karta I/O czy też procesor.

Niektóre bazy (np. starsze wersje Oracle, niektóre wersje Informixa) przechowywały dane na specjalnych partycjach dyskowych, znajdujących się zupełnie poza kontrolą systemu operacyjnego. Taką partycją zarządzał motor bazy, nie zaś system operacyjny. Wtedy (teoretycznie) baza mogła najbardziej efektywnie zarządzać systemem I/O. Jednak takie rozwiązanie było mało elastyczne i obecnie zostało niemal zupełnie zarzucone. Współczesne bazy danych wykorzystują mechanizmy systemu operacyjnego - do operacji na plikach, alokacji pamięci czy tworzenia wątku i podziału czasu pomiędzy działające procesy/wątki.

Bazy relacyjne są stosunkowo dobrze znane - zarówno od teoretycznej, jak i praktycznej strony. Przy okazji wielu różnych implementacji można było poznać wady i zalety każdego z zastosowań. Niestety, tak już nie jest w przypadku baz obiektowych - tam w praktyce nie bardzo wiadomo, jak rozsądnie stworzyć strukturę, która np. będzie rzeczywiście efektywnie obsługiwać dziedziczenie, czy bardziej ogólnie - klasy abstrakcyjne.

Taki sam problem mają bazy XML-owe, które wykorzystują w jakimś stopniu efektywny motor relacyjny. Bo tak naprawdę XML narzuca bazie strukturę hierarchiczną. Tak więc indeksy, dostosowane do prac na zbiorach, nie będą efektywnie wykorzystywane np. przy zapytaniach XQuery czy XPath.

Większość baz danych może efektownie udostępnić dane w formacie XML. Ponadto (np. w SQL Server 2000 z SQLXML3) istnieje możliwość określenia sposobu odwzorowania (mapowania) pomiędzy dokumentami XML a strukturą bazy. Można także wybierać elementy, używając składni XPath. W ten sposób część operacji może być wykonywana przy użyciu składni związanej z XML, by potem łatwo zostało to przekazane do warstwy środkowej lub przeglądarki klienckiej, gdzie odpowiedni arkusz stylów XSLT wygeneruje efektownie wyglądający raport. Pozostaje tylko pytanie, w jaki sposób przyspieszyć operacje związane z XML?

SQL Server 2000 czy IBM DB2 przechowują pewnego rodzaju kopie dokumentów XML, na których są wykonywane operacje. Ciekawie rozwiązał to Oracle - w wersji 9.2 stworzono motor XML DB. Praktycznie można zażądać, by dla danych w bazie zostały stworzone dwa zestawy indeksów - jeden, dostosowany do danych relacyjnych oraz drugi - przeznaczony do przyspieszania operacji wykonywanych na XML-owym widoku danych.

Od takich problemów wolne są oczywiście bazy czysto XML-owe (np. Tamino), gdzie cała architektura (w tym indeksy) jest dostosowana do wymogów pracy bazy hierarchicznej i przetwarzania zapytań XPath.

Idzie nowe

Coraz bardziej popularne stają się różnego typu systemy działające w ramach serwerów aplikacyjnych, których głównym zadaniem jest właściwa obróbka zapytań skierowanych do dokumentów XML. W ten sposób część operacji wykonuje baza (np. przygotowanie wstępnych dokumentów XML na podstawie danych w bazie relacyjnej), zaś resztę (tj. wybór danych) wyspecjalizowany komponent uruchomiony na serwerze aplikacyjnym - odciążając tym samym bazę relacyjną i pozwalając wykonywać jej te operacje, które motor potrafi robić najlepiej.

Warto także pamiętać o jednej z praprzyczyn powstania języka SQL - bodaj najpopularniejszej metody pracy z danymi przechowywanymi na zbiorach. Celem było stworzenie języka, który byłby łatwy do opanowania przez tzw. użytkowników biznesowych, tak by mogli tworzyć zapytania ad hoc i samodzielnie wygenerować potrzebny raport. Pierwsze wersje SQL miały bardzo ograniczone mechanizmy DDL - instrukcji przeznaczonych do tworzenia relacyjnych struktur - tabel, kluczy, relacji itp. Jednak w praktyce SQL stał się później narzędziem programisty - dla laików okazał się zbyt skomplikowany i trudny do opanowania. Niemniej trwają prace nad opracowaniem mechanizmów English Query, które mają pozwalać tworzyć zapytania w języku naturalnym użytkownika biznesowego.