Zaskakująco dużo problemów z wydajnością systemów bazodanowych wynika z przenoszenia doświadczeń i przyzwyczajeń zdobytych w pracy z jednym produktem na inne, czego spektakularnym przykładem były niedawne problemy z systemem obsługującym wybory samorządowe. "Relacyjne bazy danych tylko pozornie są do siebie podobne. Poszczególne produkty znacznie różnią się pod względem mechanizmów wewnętrznych, czego najlepszym przykładem jest działanie optymalizatorów zapytań SQL" - mówi Krzysztof Kuśnierz, inżynier w firmie Supra sp. z o.o. z Krakowa.

Kolejna ważna sprawa to dobór właściwej metody blokowania dostępu do danych. Niektóre motory blokują dane na poziomie bloku (strony), inne zaś - pojedynczego rekordu, co sprawdza się zwłaszcza przy dużej liczbie równoczesnych użytkowników. Bazy różnią się znacznie pod względem metod realizacji transakcji - zarówno co do sposobu odczytu, jak i zapisu danych do tabel. Nawet w ramach tej samej bazy można zdefiniować różne metody obsługi transakcji dla różnych tabel. Wybór konkretnej metody nie jest oczywisty i zależy od specyfiki aplikacji, liczby użytkowników itp.

Powodem niezadowalającej wydajności systemu może być nie baza, lecz jej "styk" z aplikacją. Problem ten daje znać o sobie szczególnie wtedy, gdy w krótkim czasie z bazy są pobierane duże ilości danych - najczęściej na potrzeby raportowania. Stosowane do tego celu uniwersalne interfejsy ODBC/JDBC, choć proste w konfiguracji i zazwyczaj dostępne bezpłatnie, są znacząco mniej wydajne niż oryginalne sterowniki, które z reguły sporo kosztują.

Skacząc po dyskach

Jeżeli administrator bazy danych nie ma możliwości zmiany jej konstrukcji, szanse poprawy wydajności przez zmianę konfiguracji są bardzo ograniczone i często jedynym sensownym wyjściem pozostają zabiegi sprzętowe. Poprawę wydajności można uzyskać na kilka sposobów, m.in. kupując szybszy serwer czy rozbudowując pamięć RAM w istniejącym. Najskuteczniejsze okazują się jednak działania w obszarze pamięci masowych.

Pierwszym krokiem może być próba zmiany układu RAID z powszechnie stosowanego RAID 5 na RAID 1+0 - droższy, ponieważ wymagający większej liczby dysków przy tej samej pojemności użytkowej, lecz działający wyraźnie szybciej. Jeżeli zmiana poziomu RAID nie jest możliwa, należy w jak największym zakresie wykorzystywać striping, czyli próbować rozmieścić dane na jak największej liczbie dysków fizycznych. Z reguły przyspiesza to zarówno operacje odczytu, jak i zapisu. Striping ma jednak swoje granice.

Jeśli to możliwe technicznie, warto wziąć pod uwagę zastosowanie nowoczesnych dysków twardych pracujących z prędkością 15 tys. obrotów na minutę. Jak twierdzą dostawcy, skraca to przeciętny czas dostępu do danych na dysku poniżej 4 milisekund. Dla porównania, przeciętne dyski o prędkości 10 tys. obrotów na minutę osiągają czas dostępu na poziomie ok. 6-10 milisekund. Stosowanie w macierzach dysków o dużej pojemności w praktyce obniża ich wydajność. Miarą wydajności macierzy jest bowiem liczba megabajtów przypadających na głowicę dysku. Im mniejszy ten współczynnik, tym wydajniejszy układ - przy założeniu tej samej łącznej pojemności.

Prostym zabiegiem, istotnie podnoszącym wydajność baz danych, jest zapisywanie logów transakcyjnych na innych dyskach niż te, na których są przechowywane pliki bazy danych. Wydajność także powinien poprawić podział logów na wiele plików. Jeżeli jest taka możliwość, dla plików log warto wydzielić samodzielny kanał I/O, dzięki czemu logowanie transakcji nie będzie zajmować pasma przeznaczonego dla danych.

W bazach z dużą liczbą transakcji można eksperymentować ze zwiększeniem pamięci cache macierzy. "Duża pamięć podręczna zdecydowanie zwiększa wydajność odczytu danych, zwłaszcza w połączeniu z oprogramowaniem umożliwiającym predykcyjne odczytywanie danych z dysków. Skala zysku na wydajności zależy od wielu czynników, z reguły jednak jest to poprawa o co najmniej kilkadziesiąt procent. Jeżeli dodatkowo macierz będzie potwierdzać bazie zapis do bufora jako zapis na dysk, rezultaty mogą być naprawdę znakomite" - twierdzi Tadeusz Kudła, współzałożyciel firmy S4E.

Poszukując zwiększenia wydajności, warto dokładnie przyjrzeć się strukturze logicznej podsystemu dyskowego. Niektóre bazy danych wykorzystują własny system plików, który wymaga bezpośredniego dostępu do urządzeń blokowych, inne zaś potrafią współpracować z systemem plików wyposażonym w funkcję journalingu. Journaling na poziomie systemu plików podnosi bezpieczeństwo, jednocześnie jednak obniża wydajność. "Journaling opiera się na pojedynczej kolejce FIFO, co może okazać się wąskim gardłem. Rozwiązaniem jest stworzenie w macierzy nie jednego, lecz co najmniej kilku równolegle działających systemów plików. Podobny problem dotyczy liczby dysków logicznych widzianych przez serwer: dopóki liczba ta nie przekracza 100, dopóty systemy operacyjne radzą sobie z obsługą kolejek. Powyżej bywa różnie" - tłumaczy Piotr Nogaś, inżynier w Veritas Polska.