Nowy, technologicznie zaawansowany serwer XML ma wg IBM zmienić oblicze baz danych. Najnowsza reinkarnacja szacownej bazy danych przełamuje dotychczasowe bariery, wprowadzając możliwość przechowywania danych XML w naturalnej postaci.

W niedawno udostępnionym wydaniu 9.1 bazy danych DB2 (wcześniej znanym pod kryptonimem Viper) usunięto wiele ograniczeń DB2 8, zwiększono wydajność, skalowalność i bezpieczeństwo. Jednak na szczególne wyróżnienie zasługuje jeden mechanizm - hybrydowy motor XML/relacyjny. Dla użytkowników wkraczających w nową erę baz danych XML innowacje zawarte w Viper są rzeczywiście atrakcyjne.

Od jakiegoś czasu są zapowiadane rodzime bazy danych XML, ale wymagają one specjalnych bibliotek i nie są kompatybilne z danymi relacyjnymi. Z drugiej strony, tradycyjne relacyjne bazy danych mają kłopoty z hierarchicznym modelem XML i ograniczoną funkcjonalność w tej dziedzinie. Tak więc główni dostawcy baz danych intensywnie pracują nad wbudowaniem możliwości XML do produktów relacyjnych baz danych.

Choć IBM nie stanowi tu wyjątku, to jednak technologia tej firmy wyprzedza konkurencję, zachowując rodzimy format danych XML. Konstruowany przez pięć lat całkiem nowy motor bazy danych o nawie pureXML to połączenie relacyjnych baz danych i XML. Zamiast przechowywać XML jako BLOB (Binary Large Object) lub rozkładać na relacyjne pary klucz/wartość, pureXML przechowuje same pliki XML wraz z wszystkimi ich właściwościami i zachowaną strukturą hierarchiczną.

IBM charakteryzuje tak przebudowaną DB2 jako całkiem nowy "hybrydowy serwer danych, który może zmienić oblicze baz danych". Szczegóły implementacji są trzymane w tajemnicy. Jest więc kwestią wyboru, czy zdefiniuje się połączenie DB2 z pureXML jako pojedynczy motor bazy danych składający się z dwóch części, czy jako dwa oddzielne motory, które ściśle współpracują ze sobą. Pewne jest natomiast to, że wydanie to zapewnia kilka interesujących możliwości.

Na początek daje ono możliwość dostępu do danych XML za pośrednictwem kwerend SQL, tak jak do zwykłych tablic relacyjnych. Można także używać XQuery do dostępu do tablic relacyjnych, oprócz danych XML. Można nawet używać relacyjnego SQL do ograniczonego zakresu danych wyciąganych z wyrażeń XQuery. DB2 pozwala na niemal ciągłe mieszanie tych dwóch języków.

Motor pureXML zapewnia także bardziej efektywne indeksowanie, ponieważ indywidualne węzły XML nie są przechowywane jedynie jako ciągi znaków. Według informacji IBM użytkownicy, którzy już mają zaadaptowany nowy motor, potwierdzają zwiększenie wydajności o 5 do 7 razy w porównaniu z osiągami uzyskanymi w rozwiązaniach Microsoft i Oracle.

Skupiając się na XML, IBM dostarczył pewną liczbę nowych narzędzi projektowych. Nowy Developer Workbench (który zastąpił Development Center) oferuje nowego konstruktora Xquery, jak również rozszerzenia do Visual Studio 2005.

Czy takie rozwiązania są dzisiaj niezbędne?

Podstawowe pytanie jednak brzmi: jak wielu użytkowników przyciągną hybrydowe możliwości DB2? Opinie analityków są podzielone. Na przykład bazy danych systemów służby zdrowia mogą zawierać tablice relacyjne dotyczące pacjentów, zawierające wszystkie informacje o każdym z nich, plus listę alergii przechowywanych w postaci XML. Taki rodzaj rekordów może być też modelowany relacyjnie, ale zastosowanie XML jest najlepszym sposobem na zmniejszenie liczby relacji i ułatwia projektowanie, ponieważ nie ma potrzeby utrzymywania powiązań relacyjnych pomiędzy pacjentami i listami alergenów. To samo można zrobić z zamówieniami i detalami zamówień, gdzie każde zamówienie przechowuje wiele pozycji w postaci XML zamiast klasycznych tablic pozycji.

Pomimo tych możliwości praktyczne wydawanie mieszanych wyrażeń SQL i XQuery to jednak zupełnie inna kwestia. Przechodzenie tam i z powrotem pomiędzy tymi dwoma stylami kwerendowania staje się nadmiernie skomplikowane i trudne do szybkiego wykonania. Można podejrzewać, że większość projektantów za wszelką cenę będzie unikać pisania tego typu hybrydowych aplikacji.

Odnośnie do optymalizacji IBM związanej z danymi XML (tak jak z każdym zwiększeniem wydajności) należy zadać pytanie, co to oznacza w każdym konkretnym przypadku zastosowania. Dla zadań, takich jak ładowanie milionów wierszy do bazy danych, siedmiokrotne zwiększenie wydajności jest istotnym osiągnięciem, natomiast dla dorywczego dokładania poszczególnych wierszy nie ma to już takiego znaczenia. Użytkownicy prawdopodobnie zauważą te ulepszenia w dwóch scenariuszach: kiedy baza danych jest zasilana tysiącami wsadów XML oraz gdy do bazy danych ładowane są ogromne pliki XML.

Jednym z bardziej interesujących mechanizmów pureXML jest możliwość przechowywania podpisów cyfrowych sygnowanych plików XML. Jeżeli otrzyma się plik XML podpisany cyfrowo, to można go załadować do bazy danych, wyszukać go w dowolnym czasie w przyszłości, a podpis cyfrowy nadal będzie nienaruszony. Rozwiązania Microsoft i Oracle nie mają takich możliwości, ale nie jest to cecha powszechnie poszukiwana.

Tak więc patrząc na to z dystansem, nie można przesądzić, że pureXML znacząco redukuje TCO (całkowite koszty posiadania). Robi wrażenie technologiczna strona rozwiązania, ale nowa funkcjonalność DB2 niekoniecznie musi być kryterium wyboru bazy.

Skalowanie w nowej przestrzeni

Na szczęście możliwości XML w DB2 nie są jedynymi ulepszeniami w tym wydaniu. Innym obszarem, któremu IBM poświęca szczególną uwagę, jest skalowalność.

Na początek DB2 9.1 pozwala administratorowi na tworzenie tymczasowych tablic roboczych, dla kwerend systemowych i użytkownika, z użyciem długich identyfikatorów rekordów, które są dużo większe niż wcześniej dostępne. Rozmiar pojedynczej tablicy został zwiększony do wielkości 1,1 biliona wierszy lub 16 TB - w zależności od tego, która wartość zostanie osiągnięta w pierwszej kolejności. Obie te wielkości są oczywiście dość ryzykowne - tworząc obiekty tej wielkości, trzeba się liczyć z poważnymi problemami wydajnościowymi. Jeżeli jednak jest to wybór pomiędzy wykonaniem czegoś w sposób powolny a niemożnością wykonania w ogóle, to taką szansę wyboru daje właśnie DB2.

Podobnie jest z limitem kwerendy. DB2 dopuszcza kwerendy o długości do 2 MB. Taka wielkość kwerend to w przybliżeniu 64 strony tekstu zapisane w Word. Trudno sobie nawet wyobrazić skonstruowanie tak długiej kwerendy. Może to być przydatne tylko dla niektórych, na takiej samej zasadzie jak tablice zawierające ponad bilion wierszy.

Widoki statystyczne są kolejnym skalowalnym mechanizmem w DB2 9.1. Zazwyczaj optymalizator kwerend używa statystyk do oszacowania znaczenia (wagi) danych przechowywanych w tabeli. I jest to jeden z głównych czynników używanych do nakreślenia planu wykonania danej kwerendy. Widoki statystyczne to rozciągnięcie tej możliwości również na filtrowanie tabel, co oznacza, iż teraz widoki nie są uważane tylko za wyciągi z tablic, ale można je traktować bardziej jak tablice. IBM nie jest jedyną firmą, która rozważała zatarcie granicy pomiędzy widokami (filtrami) a tablicami, ale pierwszą, która tego dokonała.