Porównanie wydajnościserwerów baz danych

Piotr Listosz
Na podstawie Oracle White Papers

Wybór serwera bazy danych nie jest sprawą prostą. Użytkownik
postawiony przed taką decyzją powinien wziąć pod uwagę nie tylko koszty związane
z zakupem oprogramowania, ale również – a może przede wszystkim –
wydajność produktu. Sprawa jest tym trudniejsza, że ilość systemów
oferowanych przez rynek jest całkiem spora. Począwszy od dużych i drogich
rozwiązań, po częstokroć bardzo wydajne oprogramowanie darmowe. Mając na
uwadze przyszły rozwój firmy, nie należy kierować się wyłącznie ceną
bazy danych, lecz także jej wydajnością. Należy przy tym pamiętać, że im
większa jest wydajność oprogramowania, tym szybszy będzie zwrot środków
zainwestowanych w jego zakup i wdrożenie. Zasada ta ze względów oczywistych
nie dotyczy rozwiązań darmowych; te jednak – mimo iż pod względem
wydajności dorównują komercyjnym bazom danych – ustępują im pod względem
bezpieczeństwa danych, czy funkcjonalności oprogramowania (na przykład nie
mają przetwarzania transakcyjnego). Mając na uwadze przede wszystkim wydajność
software’u, spróbujemy w niniejszym tekście porównać trzy duże,
komercyjne serwery baz danych, a mianowicie Oracle 9i, Microsoft SQL Server 2000
oraz IBM DB2 UDB V8.1.

Platformy sprzętowe i systemowe

Mimo iż możliwość uruchamiania oprogramowania na różnych
platformach sprzętowych i systemowych nie ma bezpośredniego przełożenia na
jego wydajność, to w znaczny sposób zwiększa funkcjonalność rozwiązania,
a także daje użytkownikowi wolną rękę zarówno w doborze sprzętu jak i
systemu operacyjnego. Baza danych Oracle 9i może pracować na wszystkich
głównych platformach systemowych, spośród których warto wymienić różne
systemy uniksowe (m.in. Linux), systemy Microsoft Windows, czy też systemy
klasy mainframe. Również pod względem doboru sprzętu oprogramowanie Oracle 9i
nie ogranicza użytkownika, gdyż można je instalować zarówno na serwerach
jednoprocesorowych, jak i dużych maszynach wieloprocesorowych, a także
klastrach składających się z wielu węzłów.

SQL Server 2000 pracuje wyłącznie na systemach operacyjnych
firmy Microsoft. W związku z powyższym, dobór sprzętu ograniczony jest
jedynie do tych komputerów, na których można uruchamiać systemy Windows. Jeśli
w przyszłości zaistnieje konieczność zmiany platformy systemowej lub sprzętowej,
na taką, która nie spełnia tych wymogów, będzie się to musiało wiązać
się z całkowitą zmianą oprogramowania serwera bazy danych.

Oracle 9i przy pomocy jednego kodu obsługuje cały
szereg rozwiązań sprzętowych i systemowych. W związku z powyższym,
oprogramowanie narzędziowe udostępniane przez Oracle, działa w każdym
systemie według identycznych zasad, udostępniając ten sam sposób podnoszenia
wydajności bazy danych. System DB2 UDB V8.1 mimo iż pracuje na różnych
platformach, istnieje w postaci całej rodziny produktów, charakteryzującej się
różnymi kodami źródłowymi, a zatem oferującej różne, niekoniecznie spójne,
metody zwiększania funkcjonalności.

Współbieżność

Zachowanie się systemu w środowisku wielodostępnym ma
olbrzymi wpływ zarówno na wydajność oprogramowania jak i na komfort pracy
jego użytkowników. Pod tym względem Oracle stosuje zupełnie inną filozofię
niż Microsoft i IBM.

Zaimplementowany w Oracle 9i mechanizm spójności
odczytu danych sprawia, że użytkownicy czytający dane
i aktualizujący je, nie blokują sobie nawzajem zasobów. Ponadto można mieć
pewność, że uzyskiwane rezultaty zawsze będą zgodne z aktualnym stanem bazy
danych, nawet wówczas, gdy pobierane dane będą przetwarzane przez jeszcze
niezatwierdzoną transakcję. W momencie rozpoczęcia transakcji, procesy działające
w systemie Oracle 9i przepisują oryginalne dane do segmentu wycofania
transakcji, gdzie figurują one w postaci tzw. rekordów wycofania (ang. undo
records
). Do momentu zatwierdzenia transakcji, te właśnie dane będą
udostępniane użytkownikom. Dzięki temu nie jest możliwe doprowadzenie do
niespójności odczytu, polegającej na pobraniu danych przetwarzanych przez
trwającą transakcję, która później zostanie wycofana.

Systemy SQL Server 2000 oraz DB2 UDB V8.1 nie oferują
mechanizmu zapewniającego spójność odczytu. Tutaj programista aplikacji musi
zakładać na czytane rekordy blokady współdzielone (ang. shared lock),
bądź akceptować dane przetwarzane przez jeszcze niezatwierdzone transakcje.
Takie rozwiązanie ma niestety spore ograniczenia. Mimo iż blokada współdzielona,
założona przez jednego użytkownika, pozwala na czytanie danych przez innych użytkowników,
to uniemożliwia ich modyfikację. Podczas modyfikacji danych zakładana jest
blokada wyłączna (ang. exclusive lock), która nie pozwala innym użytkownikom
czytać zmienianych danych. Reasumując: użytkownik czytający dane blokuje użytkownika,
który chce te dane zmodyfikować, natomiast użytkownik zmieniający dane
blokuje tego, który chce dane odczytać. Tego typu zawłaszczanie zasobów nie
występuje w środowisku Oracle.

Programiści tworzący aplikacje dla systemów SQL Server
2000 i DB2 muszą brać pod uwagę nieco inne wytyczne, niż ci piszący
oprogramowanie dla bazy danych Oracle. W tych dwóch pierwszych systemach ważne
jest szybkie zwalnianie blokad. Jest to szczególnie istotne w środowisku, w którym
z bazy korzysta wiele aplikacji i użytkowników. Okrężnym rozwiązaniem tego
problemu jest oddzielenie aplikacji intensywnie czytających dane (na przykład
aplikacji raportujących), od tych, które owe dane modyfikują i wprowadzają
(oprogramowanie OLTP). Tak czy inaczej, programiści (a także użytkownicy)
korzystający z systemów SQL Server i DB2 muszą znaleźć pewien kompromis,
pozwalający na pogodzenie współbieżności ze spójnością danych.

Oczywistym jest, iż podczas zapisu danych musi występować
blokowanie na poziomie rekordów. Ten typ blokady zapewnia duży stopień współbieżności
danych, gdyż pozostawia dostępnymi dla współistniejących transakcji
wszystkie rekordy oprócz aktualizowanego. Mimo iż blokowanie rekordów występuje
we wszystkich trzech prezentowanych bazach, to sama implementacja tego
mechanizmu jest w Oracle 9i inna niż u konkurentów. W systemie Oracle
informacje o istniejących blokadach przechowywane są bezpośrednio w
rekordach, wskutek czego maksymalna ilość blokad, jakie można założyć,
jest równa ilości rekordów w bazie danych.

W systemach SQL Server 2000 oraz DB2 informacje o blokadach
przechowywane są w specjalnym obszarze pamięci. Rozwiązanie takie dopuszcza
założenie tylko tylu blokad, ile można przechować w tej – rzecz jasna
ograniczonej – puli pamięci. Maksymalna pojemność pamięci przeznaczona na
informacje o blokadach stanowi 40% obszaru pamięci zarezerwowanego przez bazę
danych. W związku z powyższym istnieje pewna wartość progowa, której
przekroczenie spowoduje zmniejszenie ilości blokad zakładanych na poziomie
rekordu, na rzecz blokad na poziomie tabeli. Te pierwsze zapewniają większą
współbieżność danych, lecz te drugie zużywają mniej pamięci, dlatego są
preferowane przez serwer w momencie wyczerpywania się zasobów. Ponieważ zarówno
SQL Server 2000 jak i DB2 stosują blokowanie podczas odczytu danych, osiągnięcie
wspomnianej wyżej wartości progowej nie jest czymś nadzwyczajnym. Mamy tu do
czynienia ze swego rodzaju sprzężeniem zwrotnym: im więcej użytkowników ma
dostęp do bazy danych, tym większa jest ilość transakcji i zakładanych
blokad, a tym samym mniejsza ilość pamięci przeznaczonej na przechowywanie
następnych informacji o blokadach. To z kolei skutkuje pojawieniem się tzw.
eskalacji blokad, polegającej na przekształcaniu blokad na poziomie rekordu do
blokad na poziomie tabeli. Eskalacja prowadzi do zmniejszenia stopnia współbieżności
bazy danych, to zaś powoduje oczekiwanie użytkowników na zajęte zasoby.
Ponieważ podczas zwiększania się ilości blokad na poziomie tabeli, całkowita
liczba blokad jest redukowana, może dojść do sytuacji, w której dwóch użytkowników
zablokuje sobie wzajemnie zasoby. Jest to tak zwane zjawisko zakleszczenia (ang.
deadlock), które może być rozwiązane jedynie wskutek wycofania jednej
z oczekujących transakcji. Zakleszczenia zdarzają się w systemie Oracle
stosunkowo rzadko, a ich przyczyną na pewno nie jest eskalacja blokad.

Proces eskalacji blokad nie ma bezpośredniego wpływu na
wydajność bazy danych, gdyż nie zużywa on ani zbyt wielu zasobów, ani też
nie wykorzystuje w znaczącym stopniu czasu procesora. Tym niemniej skutkiem
eskalacji jest zmniejszenie współbieżności bazy danych (blokady zakładane
na tabele uniemożliwiają modyfikowanie danych w tych tabelach), a to prowadzi
do spadku wydajności.

Mimo iż w systemie DB2 można wyłączyć eskalację blokad,
to opcja ta jest dostępna jedynie na platformie OS/390; systemy Windows i Unix
nie dają takiej możliwości.

Indeksowanie

Indeksy to obiekty bazy danych, których przeznaczeniem jest
zapewnienie szybszego dostępu do danych. Korzystanie z indeksów może
doprowadzić do sporej redukcji liczby dyskowych operacji wejścia/wyjścia, co
z kolei skutkuje zwiększeniem wydajności procesów wyszukiwania i pobierania
danych.

Wszystkie trzy omawiane systemy obsługi baz danych posługują
się tradycyjnymi indeksami o postaci B-drzew, które są uporządkowanymi
listami wartości kluczowych, skojarzonymi z numerami rekordów przechowujących
te wartości. Ponadto w systemie Oracle 9i oraz SQL Server 2000 można
tworzyć tabele o organizacji indeksowej (w terminologii Microsoft zwane
indeksami klastrowymi), które nie są dostępne w bazach danych DB2. Ze względu
na fakt,
iż w tabelach o organizacji indeksowej dane przechowywane są w strukturze
B-drzewa, dostęp do informacji jest dużo szybszy niż w przypadku zwykłych
tabel, co jest szczególnie widoczne podczas uruchamiania zapytań wyszukujących
dane według klucza głównego. Ponadto – w porównaniu z tradycyjnymi,
tabele o organizacji indeksowej wymagają mniejszego obszaru pamięci dyskowej,
gdyż nie ma tu miejsca dublowanie w indeksie wartości kolumn klucza głównego,
a także nie ma konieczności przechowywania adresów rekordów, używanych do
połączenia kluczy indeksowych z odpowiadającymi im rekordami zwykłych tabel.
Ważne również jest to, że tabele o organizacji indeksowej charakteryzują się
pełną funkcjonalnością tabel tradycyjnych.

Jak już wspomnieliśmy, system DB2 UDB V8.1 nie obsługuje
tabel o organizacji indeksowej. Można tu jedynie w pewien sposób symulować
taką strukturę, poprzez dołączenie określonych kolumn do zestawu kolumn
wchodzących w skład klucza indeksowego. Mimo iż taki mechanizm może zwiększyć
wydajność niektórych zapytań (ponieważ nie występuje tu konieczność dostępu
do tabeli, a jedynie do indeksu przechowującego wszystkie potrzebne dane), to
nie wywoła on charakterystycznej dla tabel o organizacji indeksowej oszczędności
miejsca dyskowego, gdyż wartości kolumn powielane są zarówno w tabeli jak i
w indeksie.

W odróżnieniu od systemu SQL Server 2000, Oracle 9i
obsługuje indeksy bitmapowe (statyczne oraz łączone), których użycie
prowadzi do ogromnego wzrostu wydajności, szczególnie zauważalnego w środowiskach
hurtowni danych. Ponadto, w porównaniu z innymi technikami indeksowymi,
zastosowanie indeksów bitmapowych powoduje redukcję zużycia pamięci
dyskowej. System DB2 obsługuje indeksy bitmapowe w sposób dynamiczny, co
jednak nie jest tak wydajne jak mechanizm zastosowany przez Oracle.

Indeks bitmapowy, to dwuwymiarowa tablica bitów, której
jeden wymiar reprezentuje wartość indeksu, drugi zaś pozycję rekordu w
tabeli. Każdy bit w tej tablicy odpowiada jednemu rekordowi tabeli. Bit jest
ustawiony wówczas, gdy rekord zawiera wartość kluczową. Bitowa reprezentacja
indeksu powoduje sporą oszczędność miejsca dyskowego, co jest szczególnie
istotne w przypadku danych o niskim stopniu unikalności (na przykład
informacje o płci). Indeksy bitmapowe pozwalają na wykonywane szybkich
operacji logicznych, polegających na scalaniu różnych warunków klauzuli
WHERE. Rekordy, które nie odpowiadają warunkom zapytania, są odfiltrowywane
przed udostępnieniem tabeli, co znacznie skraca czas odpowiedzi.

W systemie Oracle 9i możliwe jest również tworzenie
indeksów bitmapowych na tabelach o organizacji indeksowej, przez co te ostatnie
mogą być używane jako tabele faktów w środowisku hurtowni danych. Ponadto
możliwe jest tu również konstruowanie indeksów bitmapowych odnoszących się
do złączenia dwóch lub więcej tabel, przez co można uniknąć rzeczywistego
łączenia tych tabel. Nie tylko skraca to czas wyszukiwania i pobierania
danych, lecz również oszczędza miejsce w pamięci, jakie musiałoby zostać
przeznaczone na złączone dane. System SQL Server 2000 nie obsługuje ani
indeksów bitmapowych, ani tym bardziej bitmapowych indeksów łączonych. W
systemie DB2 indeksy bitmapowe tworzone są dynamicznie podczas działania
programu. Mechanizm ten polega na pobieraniu adresów rekordów z tradycyjnych
indeksów i tworzeniu na ich podstawie mapy bitowej (poprzez sortowanie lub
zastosowanie funkcji haszujących). Taki sposób tworzenia indeksów bitmapowych
nie gwarantuje osiągnięcia wydajności nawet zbliżonej do tej, jaką oferują
rzeczywiste indeksy bitmapowe systemu Oracle.

W bazie danych Oracle 9i możliwe jest tworzenie
indeksów z kluczem odwróconym, co nie występuje w systemie DB2. Indeks taki
polega na odwróceniu kolejności bitów każdego klucza umieszczanego w
indeksie tak, aby podczas wstawiania do indeksowanej tabeli rekordów o zbliżonych
wartościach atrybutu – klucza, następowało rozproszenie modyfikacji struktury
indeksu. Dzięki temu redukowane jest negatywne zjawisko rywalizacji o dostęp
do indeksu przez współbieżne transakcje, wstawiające do tabeli rekordy o
wartościach kluczy pobieranych z sekwencji.

W systemie Oracle indeksy mogą być tworzone w oparciu o
funkcje działające na jednej lub większej ilości kolumn indeksowanej tabeli.
Indeksy takie wyliczają i przechowują wartość funkcji lub wyrażenia. Mimo iż
podobna funkcjonalność dostępna jest w systemie DB2 (indeks może być
tworzony na kolumnie, wygenerowanej w oparciu o wyrażenie), to zastosowana tam
implementacja jest mniej wydajna niż mechanizm używany przez Oracle (DB2
wymaga miejsca w tabeli na przechowanie wygenerowanej kolumny).

Partycjonowanie

Partycjonowanie polega na dzieleniu na mniejsze części dużych
struktur przechowywanych w bazie danych (tabel, indeksów, itp.). Pomimo iż
mechanizm ten jest postrzegany przede wszystkim jako element decydujący o dostępności
i łatwości zarządzania bazą danych, to ma on również niebagatelny wpływ
na wydajność tej bazy.

System Oracle 9i oferuje kilka metod partycjonowania
tabel, a mianowicie:

  • partycjonowanie według zakresu (ang. range
    partitioning
    ), w wyniku którego podział na partycje dokonywany jest na
    podstawie wartości zakresów danych, znajdujących się w kolumnach, według
    których dzielone są tabele,
  • partycjonowanie według funkcji haszującej, w którym o
    przynależności rekordów do konkretnej partycji decyduje rezultat funkcji
    haszującej, przetwarzającej dane z określonych kolumn dzielonych tabel,
  • partycjonowanie według list, pozwalające użytkownikom
    wpływać na sposób podziału tabel, poprzez dostarczanie list wartości
    decydujących o przynależności danych do określonych partycji.

Ponadto w bazie danych Oracle 9i dostępne są również
trzy typy partycjonowanych indeksów, a mianowicie:

  • indeks lokalny, tj. indeks odnoszący się do
    partycjonowanej tabeli, podzielony według tych samych wytycznych, co
    odpowiadająca mu tabela. Każda partycja indeksu lokalnego odpowiada tylko
    jednej partycji indeksowanej tabeli,
  • partycjonowany indeks globalny, będący indeksem odnoszącym
    się do tabeli jednolitej bądź partycjonowanej, podzielony według innego
    klucza niż indeksowana przez niego tabela,
  • nie partycjonowany indeks globalny, który jest
    zasadniczo identyczny z indeksem tabeli nie podzielonej na partycje.
    Struktura takiego indeksu nie jest partycjonowana.

Należy zaznaczyć, iż system Oracle dopuszcza stosowanie
wszystkich możliwych kombinacji partycjonowanych i nie partycjonowanych indeksów
oraz tabel.

Mówiąc o partycjach i związanych z nimi technikach
przetwarzania danych, należy wspomnieć o tzw. przycinaniu partycji (ang. partition
pruning
) – mechanizmie pozwalającym wykonywać operacje jedynie na tych
partycjach, które rzeczywiście zawierają potrzebne dane. Przycinanie partycji
jest ściśle związane z działaniem optymalizatora zapytań, którego zadaniem
jest analiza klauzul FROM oraz WHERE instrukcji SQL, pod kątem wyeliminowania z
procesu wyszukiwania tych partycji, które na pewno nie zawierają żądanych
informacji. Technika ta mocno redukuje ilość danych pobieranych z dysku, a także
skraca czas przetwarzania zapytania SQL, co ma bezpośredni wpływ na zwiększenie
wydajności. Takie przycinanie partycji sprawdza się szczególnie w środowiskach
hurtowni danych, gdzie wyszukiwanie informacji należy do najpowszechniejszych
działań.

Warto zaznaczyć, iż w systemie Oracle 9i mechanizm
przycinania partycji może być łączony z dostępem do indeksu (globalnego lub
lokalnego). Gdy indeks jest podzielony według innych kolumn niż odpowiadająca
mu tabela, wówczas niepotrzebne partycje indeksu zostaną odrzucone, nawet jeśli
partycje odpowiadającej mu tabeli pozostaną

Ponadto w wyniku stosowania partycji można udoskonalić
wydajność złączania wielu tabel, stosując w tym celu technikę
partycjonowania na poziomie złączeń (ang. partition-wise joins).
Technikę tę można stosować wówczas, gdy dwie łączone tabele są
partycjonowane według klucza złączenia. Partycjonowanie na poziomie złączeń
powoduje podział dużych złączeń na mniejsze, pojawiające się w każdej
partycji; dzięki temu całkowite złączenie może być skompletowane w krótszym
czasie. Dzięki równoległemu wykonywaniu instrukcji DML, partycjonowanie
pomaga również zredukować czas odpowiedzi na zapytania intensywnie korzystające
z bazy danych, które występują zazwyczaj w systemach podejmowania decyzji i
hurtowniach danych.

Microsoft SQL Server 2000 nie obsługuje partycjonowania w
sposób zaimplementowany w systemie Oracle, lecz korzysta z tzw. widoków
partycjonowanych. Istotą tego mechanizmu jest łączenie danych pochodzących z
wielu tabel podzielonych na partycje, co daje wrażenie pobierania danych z
jednej tabeli. Kluczem podziału tabel są zakresy wartości występujących w
jednej z kolumn, która określana jest mianem kolumny partycjonowanej. Zakresy,
o których mowa definiuje się przy pomocy ograniczenia CHECK, nałożonego na
kolumnę partycjonowaną. Uzyskanie na podstawie wspomnianych tabel jednego
zestawu danych, możliwe jest dzięki wykorzystaniu instrukcji UNION ALL.

W systemie SQL Server 2000 rozróżnia się lokalne i
rozproszone widoki partycjonowane. Te pierwsze występują wówczas, gdy
wszystkie uczestniczące w procesie widoki i tabele znajdują się na tym samym
serwerze; z drugimi mamy do czynienia w przypadku, gdy przynajmniej jedna
uczestnicząca w złączeniu tabela znajduje się na odległym serwerze.

Ze względu na brak rzeczywistego partycjonowania, wydajność
i możliwości skalowania bazy danych SQL Server 2000 nie dorównują tym,
uzyskiwanym w systemie Oracle 9i.

Widoki partycjonowane systemu firmy Microsoft nie obsługują
indeksów globalnych. Zapytania wyszukujące dane według kolumn innych niż
kolumny partycjonowane, muszą przeszukiwać wszystkie tabele. Ze względu na
fakt, iż indeksy globalne okazują się niezastąpione w środowiskach OLTP,
ich brak w systemie SQL Server 2000 deprecjonuje jego wykorzystanie w tego typu
aplikacjach.

Mechanizm przycinania partycji obsługiwany jest w systemie
SQL Server 2000 jedynie w sposób częściowy, bowiem działa on tylko wówczas,
gdy wszystkie partycjonowane tabele i indeksy znajdują się na tym samym
serwerze. Optymalizator określa, które tabele powinny być przeszukiwane przez
zapytanie, biorąc pod uwagę ograniczenie CHECK nałożone na kolumnę
partycjonowaną. Tym niemniej niemożność wykorzystania indeksów globalnych
znacznie ogranicza wydajność tego rozwiązania.

System DB2 UDB V8.1 obsługuje jedynie partycjonowanie według
funkcji haszującej, co jest sporym mankamentem w porównaniu z możliwościami
partycjonowania dostępnymi w systemie Oracle. W przeciwieństwie do
partycjonowania według list i zakresów, nie pozwala ono typowym zapytaniom
korzystać z mechanizmu przycinania partycji. Udostępniając więcej możliwości
podziału tabel i indeksów na partycje, Oracle może posługiwać się techniką
przycinania w przypadku większości zapytań.

Ze względu na taki a nie inny sposób tworzenia partycji,
system DB2 nie obsługuje w sposób wydajny procesu aktualizowania informacji
zawartych w hurtowniach danych. Aktualizacja ta polega na wczytywaniu do
hurtowni nowych danych i usuwaniu starych. Fakt zastosowania przy
partycjonowaniu funkcji haszującej, powoduje konieczność odświeżania danych
we wszystkich partycjach, co znacznie zwiększa czas wczytywania informacji do
hurtowni danych, a tym samym zmniejsza jej dostępność (podczas dystrybuowania
danych tabele są zablokowane).

Należy również wspomnieć, też w systemie DB2 wymagane
jest zachowanie równowagi podczas partycjonowania tabel i indeksów. Oznacza
to, że nie można tu tworzyć indeksów globalnych, zarówno partycjonowanych
jak i niepartycjonowanych. Jest to sporym problemem w środowiskach OLTP, gdzie
użycie indeksów globalnych jest powszechnie stosowaną techniką, zapewniającą
szybki dostęp do dowolnego rekordu. Projektanci aplikacji korzystającej z bazy
danych DB2 nie mają wielkiego wyboru podczas definiowania strategii
indeksowania w konfiguracjach partycjonowanych.

Technologia klastrowa

Klaster to grupa niezależnych serwerów (węzłów), połączonych
przy pomocy sieci prywatnej. Klastry umożliwiają skalowanie aplikacji na
poziomie nieosiągalnym przy zastosowaniu pojedynczych serwerów. Ponadto taka
technologia podnosi bezpieczeństwo danych, a także diametralnie poprawia
wydajność.

Technika klastrowa zaimplementowana w systemie Oracle oparta
jest na architekturze Real Application Clusters, której podstawową ideą jest
wykorzystanie przez węzły klastra wspólnej pamięci masowej. Podczas odwołań
do pamięci masowej używana jest szybka pamięć podręczna (cache), co
przyczynia się do zminimalizowania ilości operacji wejścia/wyjścia (pamięć
cache jest tu niejako warstwą pośrednią pomiędzy bazą danych, a fizyczną
pamięcią dyskową). Rozwiązanie zaproponowane przez Oracle nie tylko zwiększa
bezpieczeństwo bazy danych (w przypadku awarii węzła jego funkcje przejmowane
są przez inne węzły) oraz pozwala na swobodne skalowanie instalacji (przyłączanie
nowych węzłów), lecz również – dzięki zastosowaniu opatentowanej
przez Oracle technologii Cache Fusion (mechanizmu wykorzystującego wzajemne połączenie
pamięci cache wszystkich węzłów klastra) – w sposób niebagatelny wpływa na
jej wydajność.

W systemie DB2 węzły klastra nie współdzielą pamięci
masowej, lecz każdy węzeł dysponuje własnym jej fragmentem. Rozdzielenie
pracy pomiędzy poszczególnymi węzłami odbywa się drogą partycjonowania
danych. Rozwiązanie zaproponowane przez IBM sprawdza się jedynie w takich środowiskach,
w których rzadko dochodzi do zmiany węzła będącego właścicielem danych
(typowym powodem zmiany węzła jest jego uszkodzenie lub reorganizacja bazy
danych). Ponadto mechanizm wykorzystywany w DB2 nie dorównuje systemowi Oracle
pod względem wydajności i możliwości skalowania. Podstawowe, obniżające
wydajność mankamenty technologii klastrowej DB2, to dwufazowe zatwierdzanie
transakcji, wymuszający komunikację między procesami dostęp do danych
umieszczonych w innej partycji, utrudniony routing transakcji (wymagający
wiedzy na temat lokalizacji danych przetwarzanych przez tę transakcję) oraz
konieczność wyszukiwania danych w wielu partycjach.

Zdecydowanie najgorzej prezentuje się tutaj SQL Server 2000,
który w ogóle nie obsługuje technologii klastrowej. Niejako namiastką tego
mechanizmu są tu rozproszone widoki partycjonowane, dzięki którym możliwe
jest utworzenie grupy (federacji) niezależnych serwerów. Mimo iż maszyny te
współpracują podczas przetwarzania danych, to każda z nich jest zarządzana
odrębnie. Każdy ze wspomnianych serwerów przechowuje inny fragment danych. Użytkownik
korzystający z takiej federacji, łączy się de facto z pojedynczym serwerem.
Jeśli dane, które są potrzebne znajdują się akurat na innym serwerze, wówczas
czas ich pobierania znacznie się wydłuża. Siłą rzeczy tego typu
architektura nie może być wydajna; nie jest też bezpieczna, a jej skalowanie
wymaga doskonałej wiedzy zarówno na temat logiki działania aplikacji, jak i
struktury bazy danych.

Więcej informacji na temat architektury Real Application
Clusters oraz konkurencyjnych rozwiązań firm IBM i Microsoft można znaleźć
w artykule Sebastiana Wyrwała „Real Application Clusters”, który
ukazał się w numerze 24 miesięcznika ORACLE’owe PLOUG’tki.

Obsługa hurtowni danych

System Oracle 9i wyposażony jest w pewne właściwości,
które okazują się nieocenione w środowisku hurtowni danych, zwłaszcza
podczas realizowania procesu ETL (pobierania, przekształcania i wczytywania
danych), którego fazy powinny być wykonane możliwie jak najszybciej, by nie
blokować dostępności danych.

W systemie Oracle 9i zaimplementowano nową instrukcję
SQL, MERGE, która umożliwia aktualizowanie lub wstawianie rekordów do tabeli
bądź widoku, ograniczając złożoność aplikacji oraz redukując ilość
instrukcji, jakie byłyby wymagane w przypadku zwykłych operacji wstawiania i
aktualizacji danych. Dzięki istnieniu tej instrukcji można w wygodny sposób
połączyć przynajmniej dwie operacje, a tym samym uniknąć konieczności
powtarzania wielu instrukcji DML INSERT oraz UPDATE. Instrukcja MERGE może być
użyta w celu wybierania rekordów z jednej tabeli i wstawiania ich do innej.
Operacje tego typu są stosunkowo często wykonywane w środowiskach hurtowni
danych, gdzie konieczne jest okresowe odświeżanie informacji, rekordami
pochodzącymi z systemów OLTP. W porównaniu z sekwencjami poleceń DML, użycie
instrukcji MERGE skutkuje doskonałym wzrostem wydajności.

Zarówno SQL Server 2000 jak i DB2 nie udostępniają
polecenia równoważnego instrukcji MERGE. W związku z powyższym, operacje odświeżania
hurtowni danych muszą tu być realizowane w wyniku użycia sekwencji instrukcji
INSERT i UPDATE, co wymaga wielokrotnego przeszukiwania tabel bazy danych. Takie
rozwiązanie powoduje zarówno spadek wydajności jak i użyteczności.

System Oracle 9i umożliwia jednoczesne wstawianie
danych do wielu tabel, przy użyciu pojedynczej instrukcji INSERT. Takie rozwiązanie
jest zdecydowanie bardziej efektywne, niż używanie w stosunku do każdej z
tabel odrębnych instrukcji SQL. Podobnie jak instrukcja MERGE, wielotabelowe
operacje INSERT okazują się szczególnie użyteczne w środowisku hurtowni
danych, gdzie (na ogół) dane, którymi zasilana jest hurtownia, pochodzą z
wielu różnych źródeł. Instrukcje wstawiania o których mowa, nie wymagają
wielokrotnego przeszukiwania danych źródłowych, przez co ich wydajność jest
stosunkowo duża.

Wielotabelowe operacje wstawiania nie są obsługiwane ani w
systemie SQL Server 2000, ani też w DB2. Ich oczywistym ekwiwalentem jest
wielokrotne użycie instrukcji INSERT, co jednak wymaga częstego przeszukiwania
danych źródłowych, a tam samym obniża wydajność operacji.

Zestawienie cech

W tabeli 1 znajduje się porównanie najważniejszych cech
prezentowanych systemów obsługi baz danych.

Tabela 1. Porównanie najważniejszych cech
prezentowanych systemów obsługi baz danych.

Grupa cech Cecha Oracle 9i Microsoft SQL Server 2000 IBM DB2 UDB V8.1
Platformy sprzętowo – systemowe możliwość uruchamiania na wielu platformach tak nie (wyłącznie platformy frmy Microsoft) tak
funkcjonalność niezależna od platformy tak nie
Współbieżność wzajemne blokowanie użytkowników czytających i modyfikujących dane nie tak tak
miejsce przechowywania informacji o blokadach rekordy pamięć pamięć
występowanie eskalacji blokad nie tak tak
częstość występowania zakleszczeń rzadko często często
możliwość pobrania danych aktualnie modyfikowanych przez transakcję nie (istnieje spójność odczytu) tak tak
Indeksowanie struktura indeksu B-drzewo B-drzewo B-drzewo
możliwość tworzenia tabel o organizacji indeksowej tak tak nie
obsługa indeksów bitmapowych statyczne oraz łączone brak tworzone dynamicznie (mniej wydajne)
możliwość tworzenia indeksów o kluczu odwróconym tak tak nie
Partycjonowanie metody partycjonowania tabel według zakresu, funkcji haszującej i listy według warunku ograniczenia CHECK według funkcji haszującej
typy partycjonowanych indeksów lokalny i globalny (partycjonowany i niepartycjonowany) lokalny lokalny
przycinanie partycji tak nie ograniczone
występowanie partycjonowania na poziomie złączeń tak nie nie
Technologia klastrowa architektura Real Application Clusters węzły jako niezależne serwery węzły z niezależnymi pamięciami masowymi
wykorzystanie szybkiej pamięci podręcznej tak nie nie
skutek awarii węzła obniżenie wydajności brak dostępu do danych węzła brak równoważenia obciążenia
możliwość skalowania duża szybki wzrost liczby partycji
Obsługa hurtowni danych występowanie instrukcji MERGE tak nie nie
możliwość wstawiania danych do wielu tabel jednocześnie tak nie nie

Wnioski

Z powyższego tekstu dość jasno wynika, że pod względem
wydajności Microsoft SQL Server 2000 oraz IBM DB2 UDB V8.1 nie są w stanie
konkurować z rozwiązaniem udostępnionym przez firmę Oracle. Lata doświadczeń
inżynierów Oracle’a poskutkowały utworzeniem produktu spełniającego
wymagania większości środowisk, włączając w to e-business, aplikacje OLTP
oraz hurtownie danych. Badania rynku jedynie potwierdzają hegemonię bazy
danych Oracle – korzysta z niej więcej niż 50% największych przedsiębiorstw,
uruchamiając na tej bazie trzy z czterech firmowych aplikacji. Mimo iż Oracle
9i nie jest rozwiązaniem tanim, to zdecydowanie ważniejszymi czynnikami
decydującymi o wyborze systemu są wydajność, łatwość skalowania i
bezpieczeństwo, a w tych dziedzinach Oracle dominuje.

Literatura:

Technical Comparison of Oracle vs SQL Server 2000: Focus on
performance, Herve Lejeune, maj 2002.
Technical Comparison of Oracle vs IBM DB2 UDB: Focus on
performance, Herve Lejeune, listopad 2002.
Real Application Clusters, Sebastian Wyrwał,
Oracle’owe PLOUG’tki nr 24.
System zarządzania bazą danych Oracle 7 i Oracle 8, R.
Wrembel, J. Jezierski, M. Zakrzewicz, Wydawnictwo Nakom, Poznań 2000.
Oracle w zadaniach, E.Honour, P. Dalberth, A. Kaplan, A.
Mehta, Wydawnictwo Robomatic, Wrocław 2001.

I tyle oficjalnych optymistycznych wieści
propagowanych przez Oracle Corporation. Oczywiście wszyscy praktykujący
oraclowcy wiedzą, że „wskaźniki wskaźnikami a wydajność sobie”. Tak
jak na straganie z zieleniną nie da się kupić nieświeżej pietruszki, mimo, że na
pierwszy rzut oka widać, że ledwo zipie, tak i w przypadku nowych
technologii trudno o obiektywne oceny nie do końca kompatybilnych
architektonicznie produktów. Niestety trudno jest spotkać w przyrodzie
fachowca, który miałby okazję przetestować dokładnie w naturze
wszystkie czołowe serwery bazodanowe. Pozostaje nam jedynie czytać
materiału publikowane przez producentów software’u z dużym
marginesem zdrowego rozsądku, zdając sobie sprawę z uczuciowego zaangażowanie autorów tych tekstów.
A może pokusimy się o własną weryfikację przedstawianych nam
superlatyw? Oczekuję na Państwa głosy w tej dyskusji. Obiecuję brak
cenzury.

Jadwiga Gnybek