Baza w niedoczasie

Sposobów na poprawę wydajności serwerów baz danych jest bardzo dużo. Najlepsze rezultaty daje zakup dobrze zaprojektowanej aplikacji, ale ten luksus jest, niestety, udziałem zdecydowanej mniejszości firm.

Sposobów na poprawę wydajności serwerów baz danych jest bardzo dużo. Najlepsze rezultaty daje zakup dobrze zaprojektowanej aplikacji, ale ten luksus jest, niestety, udziałem zdecydowanej mniejszości firm.

W CW 21/2005 Tomasz Kopacz pisał, nie bez racji, że z punktu widzenia typowej firmy rozsądne jest utrzymywanie jednego, uniwersalnego motoru baz danych pozwalającego wydajnie obsłużyć wiele różnych aplikacji pracujących z ogromnymi zbiorami danych. Argumentów za utrzymaniem jednolitości jest wiele, m.in. niższe koszty zarządzania, niż w przypadku utrzymywania kilku specjalizowanych rozwiązań, łatwość integracji aplikacji, proste zabezpieczanie i odtwarzanie po awarii serwera itp. Wiodący dostawcy systemów relacyjnych baz danych czynią wiele, by klienci nie mieli powodów do poszukiwania alternatyw.

Mimo to alternatyw wciąż przybywa. Na świecie trwają prace nad nowymi systemami zarządzania informacją, zarówno komercyjnymi, jak i dostępnymi bez żadnych ograniczeń. Sens ich rozwoju tkwi zwykle w specjalizacji w jakimś obszarze aplikacyjnym, np. analizie danych, przetwarzaniu dokumentów XML, przechowywaniu obiektów aplikacji i ich stanów, czy też szybkiej obsłudze prostych operacji odczytu. Wolne od ograniczeń związanych z uniwersalnością, specjalizowane baz danych osiągają zazwyczaj wysoką wydajność.

Wszystkie - czy to uniwersalne, czy specjalizowane - stoją dziś przed tym samym wyzwaniem, polegającym na wzroście wolumenu danych. Jego wpływ na wydajność baz jest bezsporny - większe tabele wymagają większej ilości pamięci i coraz większych, a przez to coraz wolniej działających indeksów itd. Twórcy serwerów baz danych stale poszukują sposobów na to, by ich produkty wciąż pozostały "dostatecznie wydajne". Pojawiają się też firmy oferujące rozwiązania w ten czy inny sposób przyspieszające przetwarzanie dużych wolumenów danych.

Podział i optymalizacja

Jednym ze starszych sposobów przyspieszania baz danych jest ich podział na logiczne partycje i przetwarzanie ich na oddzielnych serwerach. Kiedyś taka funkcjonalność była dostępna tylko najbogatszym klientom z najbardziej wymagających sektorów, jak wojsko, telekomunikacja czy usługi finansowe. Dziś podział serwera na równolegle działające partycje oferuje każdy szanujący się dostawca, w tym oczywiście Oracle, IBM, Microsoft i Sybase.

Alternatywą dla partycjonowania serwera jest równoważenie obciążenia między wieloma serwerami. Równoważenie obciążenia tym różni się od partycjonowania, że jest realizowane poza bazą - zazwyczaj na poziomie sieci, rzadziej na poziomie systemu operacyjnego. Nic nie stoi na przeszkodzie, by obie te formy stosować łącznie.

Inną powszechnie stosowaną formą przyspieszania baz danych jest utrzymywanie w bazie indeksów przyspieszających wyszukiwanie danych. Ponieważ jednak danych jest bardzo dużo, jeden indeks zwykle nie wystarcza. Zamiast jednego indeksu, nawet partycjonowanego, producenci skłaniają się ku architekturom z wieloma indeksami, z których każdy indeksuje np. dane określonego typu.

Powszechnie stosowaną metodą na zwiększanie wydajności baz danych stała się optymalizacja zapytań . W różnych produktach optymalizatory działają według różnych założeń, jednak ich cel jest ten sam. W optymalizacji chodzi o dwie kwestie: poprawę struktury wyrażenia SQL w taki sposób, aby jego wykonanie zajęło możliwie jak najmniej zasobów serwera, a także o optymalizację kolejności i priorytetów wykonania wielu zapytań, by jak najmniej przeszkadzały sobie nawzajem.

Optymalizacja dziś jest dziedziną w zasadzie naukową, stosującą w praktyce bardzo zaawansowane algorytmy, funkcje statystyczne, a także sztuczną inteligencję. Jej przyszłość wciąż jednak wydaje się jasna - praktyka dowodzi, że w dziedzinie koordynacji i harmonogramowania zapytań, a także np. przewidywania obciążenia, postęp wciąż jest możliwy. Optymalizacja dotyczy nie tylko tego, jak formułować i jak wykonywać zapytania, ale także w jaki sposób traktować ich wyniki.

Wydajność z bufora

Metodą na poprawę wydajności bazy danych, zastosowaną jak dotychczas skutecznie jedynie przez IBM w serwerach mainframe i AS/400 (iSeries, i5), jest zintegrowanie bazy danych z systemem operacyjnym. Jeśli zapytanie SQL jest obsługiwane w zasadzie tak, jak wywołania systemowe, wysoka wydajność jest oczywistością. Do tego dochodzi jeszcze akceleracja sprzętowa. Niestety, takie rozwiązanie jest nieprzenośne, co niektórych odstrasza.

Techniką stosowaną powszechnie jest przechowywanie wyników najczęściej powtarzających się zapytań w dedykowanym buforze w pamięci RAM. Microsoft przekonuje tymczasem, że najlepszą praktyką jest przechowywanie w pamięci RAM nie tylko wycinków, ale całej bazy danych. Tym tropem idzie ostatnio także Oracle (patrz ramka nt. przejęcia firmy TimesTen).

Pamięci dyskowe pozostają najwolniejszym elementem całej infrastruktury przetwarzania danych i w wielu przypadkach nie da się z nich zrezygnować. W związku z tym serwery baz danych w coraz większym stopniu samodzielnie zarządzają zapisem danych bezpośrednio do pamięci masowych. Oracle w serwerze 10g wymaga wręcz, by baza była instalowana na wolumenach bez własnego systemu plików, stanowiącego dodatkową, a przy tym nieskoordynowaną z serwerem baz danych warstwę logiki.

Wsparciem dla wydajności baz danych jest stosowanie w macierzach buforów pamięci RAM. W niektórych przypadkach dostawcy macierzy umożliwiają serwerom baz danych samodzielne zarządzanie zawartością buforów, jednak wyzwania techniczne z tym związane są podejmowane dosyć rzadko, w wyjątkowych przypadkach.

Znacznie częściej zdarza się, że serwer baz danych może wskazać macierzy, w jaki sposób powinna sterować fizyczną lokalizacją danych na dyskach. Dla podwyższenia wydajności dane są zwykle umieszczane jak najbliżej obrzeża talerzy dysków, by były dostępne z jak największą prędkością liniową. O wydajności podsystemu dyskowego w dużej mierze decyduje liczba dysków, jaką można umieścić w macierzy - oczywiście jest to wskaźnik zgrubny, obarczony warunkami.

Alternatywą dla - będących zwykle niezależnymi od serwera baz danych - algorytmów buforowania danych oraz zarządzania wydajnością dysków, jest zastąpienie pewnej puli dysków twardych pamięciami półprzewodnikowymi (Solid State Disk). Jeśli pamięć tego typu, zwana często RAM-dyskiem, zostanie wskazana serwerowi baz danych jako wolumen, na którym przechowywane są indeksy, wydajność bazy zazwyczaj istotnie wzrasta.

Baza wyrwana z kleszczy

W bazach danych przetwarzających dużą liczbę transakcji generowanych przez wiele działających równolegle modułów aplikacyjnych dosyć często występuje zjawisko zakleszczenia (deadlock). Zakleszczenie powstaje, gdy dwa lub więcej procesów chcą zapisać dane do tego samego obszaru bazy, a jego wykonanie jest warunkiem wykonania dalszych operacji. Częste występowanie zakleszczeń może spowolnić nawet najwydajniejszą bazę dysponującą dużym zapasem mocy i pamięci po stronie sprzętu, dlatego ich unikanie i sprawna eliminacja zwykle przyspieszają przetwarzanie. Producenci baz danych realizują to na wiele sposobów.

Podstawowa metoda polega na blokowaniu na potrzeby transakcji jak najmniejszego obszaru bazy, a najlepiej dostosowywaniu go dynamicznie do zakresu transakcji. Tylko czasem będzie to cała tabela (najczęstszy powód problemów); najczęściej wystarczy strona, a wiele współczesnych baz oferuje blokowanie danych na poziomie rekordu, a nawet pojedynczego pola. Jeśli zakleszczeń nie da się uniknąć, można skorzystać z dostępnego w wielu serwerach mechanizmu hurtowego zatwierdzania transakcji. Z grubsza działa to tak, że zapisy do konkretnej tabeli są buforowane w kolejce, a następnie wykonywane jako jedna operacja commit.

Gdyby tylko programiści chcieli ten fakt wykorzystywać... częściej. Nie można bowiem nie zauważyć, że wiele zagadnień związanych z optymalizacją wydajności baz danych to "poprawianie po programiście".

Oracle razy dziesięć

Oracle ogłosił niedawno przejęcie firmy TimesTen. Założona w 1997 r. TimesTen obsługuje ok. 1,5 tys. klientów, w tym wielu bardzo znamienitych, jak linie lotnicze i banki. TimesTen oferuje trzy produkty. TimesTen/Cache - serwer buforujący, przyspieszający dostęp do danych przechowywanych w bazach Oracle. TimesTen/Data Server to samodzielny serwer bazodanowy przeznaczony do przetwarzania baz danych wyłącznie w pamięci RAM - bez dysków - oraz mechanizmy do replikacji danych do węzłów współpracujących w klastrze. Trzeci produkt to TimesTen/Transact - połączenie serwera baz danych, bufora i mechanizmu do replikacji z zewnętrznymi brokerami komunikatów, tworzący wspólnie z nimi wydajne środowisko integracyjne. Jednym z konkurentów TimesTen jest firma Ants Software.