Po dwóch latach prac IBM wprowadza do sprzedaży serwer baz danych DB2 UDB 9, znany dotychczas pod kodową nazwą Viper.

Prace nad nową wersją bazy danych DB2 UDB o kodowej nazwie Viper trwały w IBM ponad 2 lata. Stinger, poprzednia edycja bazy - wersja 8, pojawiła się na rynku w 2004 r. Za najważniejsze udoskonalenie Vipera należy bez wątpienia uznać pureXML - nowy motor hierarchiczny przeznaczony do przechowywania danych w formacie XML. Istotną nowością jest także wprowadzenie automatycznej kompresji danych. Ważnych nowości funkcjonalnych jest jednak znacznie więcej (patrz ramka).

Obsługa XML

Nazwa kodowa pureXML odnosi się do rozwiązania IBM służącego do przechowywania danych hierarchicznych w serwerze baz danych Viper. Tak naprawdę jest to zintegrowany z relacyjnym motorem oddzielny motor hierarchiczny dedykowany do obsługi danych typu XML. Warto tu dodać, że w opcjach DB2 można ustawić zgodność składni z IMS - "starą" hierarchiczną bazą danych autorstwa IBM.

Z punktu widzenia aplikacji dane XML są przypisywane do kolumny. Faktycznie jednak nie są przechowywane w wierszu, lecz oddzielone i umieszczone w specjalnej strukturze binarnej dostosowanej do gromadzenia tego właśnie typu informacji. Dla porównania, w Microsoft SQL Server 2005 dane XML znajdują się bezpośrednio w wierszu, choć także są zakodowane binarnie. Rozwiązanie IBM ma kilka bardzo poważnych zalet.

Zacznijmy od tego, że jeśli chcemy przyspieszyć wyszukiwanie, w rozwiązaniu Microsoft trzeba do kolumny przypisać schemat, po czym stworzyć indeks na wyrażeniach używanych do wyszukiwania. W DB2 UDB 9 do jednej kolumny można przypisać wiele schematów XML, a także - niezależnie od schematu - indeks. Dzięki temu, gdy w kolumnie przechowywane są informacje z czasem ulegające zmianie (np. ankieta, w której kolejnych edycjach przybywają nowe pytania), nie ma konieczności modyfikowania dotychczasowego opisu - dla każdej wersji ankiety można po prostu stworzyć oddzielny schemat. Dokument XSD w DB2 Viper służy w zasadzie tylko do sprawdzania tego, czy dane umieszczane w bazie są zgodne z aktualnie przyjętymi zasadami.

Podobnie jak w przypadku SQL Server, w momencie aktualizacji danych może być, co prawda, uaktualniony tylko jeden element dokumentu XML, ale zablokowany jest cały wiersz danych - tak jak w bazie relacyjnej. Dla porównania jedną z opcji przechowywania XML na serwerze Oracle jest zbudowanie struktury, w której nie ma wyspecjalizowanego mechanizmu bazy hierarchicznej, a dokument XML rozbity jest na kilka tabel relacyjnych. W takim przypadku traci się "hierarchiczność", ale za to korzysta się efektywniej z mechanizmów blokowania na poziomie bazy danych. Wybór motoru zależy więc - jak zwykle - przede wszystkim od specyfiki aplikacji, która ma korzystać z mechanizmów bazy danych.

Viper zawiera mechanizm pozwalający rozszerzyć schemat XML o dodatkowe wskazówki, które określają, w których tabelach i kolumnach zapisany będzie konkretny dokument. Tego typu dekompozycja umożliwia rozbicie dokumentu na zasadzie podobnej do tej, jaka obowiązuje w przypadku rozwiązań Oracle. Można też (ale tylko "ręcznie") rozbić schemat hierarchiczny w taki sposób, by elementy, które muszą być często aktualizowane, znajdowały się poza dokumentem XML, np. jako dodatkowe "zwykłe" kolumny.

Podsumowując, mimo dużej elastyczności, nadal widać, że światy hierarchiczny i relacyjny, choć zbliżyły się do siebie, nadal nie są idealnie "zgrane". Dokumentacja IBM informuje, że nowy typ XML będzie dostępny jako oddzielna wersja DB2 9.1 (szczegóły licen-cyjne będą dostępne nahttp://www.ibm.com/db2/udb ). Jeżeli w bazie włączy się mechanizmy obsługi XML, znaki muszą być kodowane w Unicode. Co więcej, nie można wtedy partycjonować tabel. Innym dodatkowym elementem jest DB2 Net Search Extender, który zapewnia mechanizm pewnego rodzaju "wyszukiwania" pełnotekstowego. Obsługuje on także dokumenty XML. Można też połączyć zapytania XQuery i SQL.

Kompresja danych

Wprowadzona w DB2 Viper kompresja nie polega na kompaktowaniu danych w ramach jednego wiersza - jest to raczej inny sposób przechowywania tabeli, polegający na unikaniu powtarzania większych sekwencji danych. Atrybut włączający kompresję może być ustawiony zarówno przy tworzeniu tabeli, jak i potem, przy użyciu operacji ALTER TABLE.

Efektywny stopień kompresji zależy oczywiście od danych zgromadzonych w bazie. Co ważne, dane skompresowane także mogą być indeksowane, w związku z czym spadek wydajności wynikający z kompresji nie powinien być bardzo istotny. Zresztą, obecnie i tak projektuje się indeksy w taki sposób, aby minimalizować skanowanie tabel i by większość zapytań korzystała z odpowiednich wskaźników wynikających z indeksów.

Możliwość kompresji danych na pierwszy rzut oka wydaje się bardzo ciekawa. Warto jednak pamiętać, że np. serwer analityczny Sybase IQ od dawna pozwala na stosowanie kompresji pionowej (w kolumnie), a mimo to nie zyskał dużej popularności. Biorąc pod uwagę, że ceny pamięci masowych jednak spadają. Z drugiej strony, czasami jest tak, że po prostu "miejsce się kończy", gdy tymczasem pewne tabele nie są już wcale aktualizowane. W takich sytuacjach kompresja jest użyteczną opcją, pozwalającą odłożyć w czasie rozbudowę serwera.

Nowe partycjonowanie

Ciekawą nowością są kolejne opcje w dziedzinie partycjonowania tabel. Dotychczas serwer DB2 UDB miał mechanizm partycjonowania widoków (Materialized Query Table) w ramach klastrów typu "share nothing". Dodatkowo w wersji Viper można zdefiniować zakresy wartości w tabeli i przypisać im wydzielone "przestrzenie tabel" (tablespaces). Co ważniejsze - takie partycje mogą być dynamicznie dołączane/odłączane, łączone itp. Jest to funkcjonalność analogiczna do tej, która była dostępna w DB2 dla z/OS czy w serwerach Informix. Obok tego nadal można stosować mechanizm DPF (Database Partitioning Feature) dzielący całą bazę zgodnie z przyjętą strategią (np. wg klucza hash).

W DB2 9.1 wprowadzono także mechanizm uprawnień oparty na etykietach. Funkcjonalnie przypomina to rozwiązania znane z Oracle - prawa dla użytkownika można określić zarówno "pionowo" - do poszczególnych kolumn, jak i "poziomo" - do poszczególnych wierszy. Reguły bezpieczeństwa definiują kto i kiedy może czytać lub aktualizować dane, a następnie przypisuje się do danych odpowiednie etykiety. Dostęp do kolumn i wierszy jest chroniony przez ten sam mechanizm.

Dla programistów

IBM podobnie jak Microsoft uważa, że klientom trzeba przedstawiać kompleksową ofertę, obejmującą także narzędzia programistyczne do tworzenia rozwiązań wykorzystujących bazę. W przypadku IBM mowa oczywiście o platformie narzędziowej Eclipse, w tym szczególnie o narzędziach przeznaczonych do pisania aplikacji Java. Z jednej strony są to różnego rodzaju narzędzia do projektowania, z drugiej zaś - wygodne interfejsy API.

Jeżeli chodzi o obsługę XML, z punktu widzenia JDBC/SQLJ mamy do dyspozycji specjalny obiekt (DB2Xml), który opakowuje dokument XML. Równocześnie w dosyć ładny sposób można połączyć XQuery z SQL, czy otrzymać strumień XML/HTML wprost z bazy. Używając elementów XML Extender, można wykonać transformację XSLT i wygenerować stronę HTML gotową do pokazania przez serwer WWW. Wygodny XQuery Builder pozwala skonstruować wyrażenie filtrujące dane XML. Także używając specjalnej składni SQL i XUpdate (jak nazywa dialekt aktualizacyjny IBM), można aktualizować wybrane węzły w dokumencie XML.

Ciekawym pomysłem jest oparte na Eclipse środowisko dla programistów bazodanowych - IBM DB2 Developer Workbench 9.1. Można w nim zdefiniować projekt, w którym przechowywane są schematy XSD, dane XML, procedury, kwerendy SQL - słowem, wszystko co potrzebne jest do tworzenia kompletnej struktury bazodanowej. Można też tworzyć obiekty bazodanowe, używając narzędzi GUI. Niestety, nie ma jakiegoś modułu do graficznego projektowania zależności, definiowania kluczy obcych itp. Można natomiast porównywać procedury i struktury między lokalnym narzędziem a tymi, które zostały już wgrane na serwer.

Nie ma, niestety, możliwości wersjonowania obiektów serwerowych, ale można np. dodać projekt do CVS i pośrednio porównywać wersje aktualne z tym, co było tworzone w ramach projektu. Istnieje natomiast możliwość obejrzenia topologii obiektów po zdefiniowaniu więzów itp. Szkoda jednak, że brak jest debuggera, ale za to można łatwo wywołać profiler i przeanalizować wydajność zaprojektowanego wyrażenia czy procedury.

Wkrótce ma się pojawić dedykowany dla DB2 UDB 9 dodatek do Microsoft Visual Studio 2005. Serwer DB2 UDB 9 będzie widoczny w Server Explorer (dotychczas IBM oferował "własne" okienko z obiektami DB2). W ramach dodatku dostępne będą narzędzia do projektowania, pozwalające tworzyć procedury przechowywane, widoki, tabele czy ustawiać właściwości kolumn bezpośrednio w DB2 UDB 9.

W krainie samostrojenia

IBM zdecydował się na automatyczną polonizację interfejsu administracyjnego, co na pierwszy rzut oka sprawia dziwne wrażenie, bo język angielski jest bardziej precyzyjny, zwłaszcza w przypadku komunikatów o błędach. Być może, wzorem wcześniejszych działań Microsoftu, chce dotrzeć w ten sposób do mniejszych klientów. To logiczne wytłumaczenie w świetle tego, że IBM intensywnie promuje wersje Express oraz, że inwestuje w funkcje, które znoszą konieczność dogłębnej znajomości zasad strojenia motoru. Skupmy się na tym wątku, ponieważ w Viper ten obszar doczekał się kolejnych udoskonaleń.

Dotychczas DB2 było bazą, która do prawidłowego działania wymagała dużego strojenia. Zdecydowanie więcej mechanizmów strojenia automatycznego pojawiło się w poprzedniej wersji Stinger, a Viper jest rozwinięciem pomysłów zaprezentowanych w "ósemce". Obecnie IBM twierdzi, że motor DB2 UDB jest "w dużym stopniu samostrojący się", choć, jak podkreślają przedstawiciele firmy, wciąż wiele elementów można dostosować ręcznie. Część parametrów jest też dynamiczna i zmieniająca się w czasie działania na podstawie spływających zapytań.

Obok tego powstało (lub zostało rozszerzonych) kilka narzędzi, które ułatwiają pracę administratorowi. Przykładowo, Doradca Konfiguracji automatycznie pozwala dobrać parametry do zadanego obciążenia. Wybór rodzaju obciążenia sprowadza się do określenia, czy więcej jest zapytań, czy też aktualizacji, albo wskazania, że oba typy operacji występują mniej więcej równie często. Można też wprowadzić liczbę transakcji na minutę lub średnią liczbę instrukcji SQL w ramach transakcji. Na podstawie tych informacji programowy Doradca Konfiguracji dobiera wielkości stert, liczbę połączeń itp. i generuje skrypt SQL, który można wysłać do bazy.

Podobną rolę pełni Doradca Programisty, ale w tym przypadku tworzone są dodatkowe struktury bazodanowe, jak indeksy czy widoki MQT. Dla programistów PHP ma powstać także specjalna wersja Zend Core for IBM dostosowana do DB2 9 Viper. Zend zapowiada, że ma to być darmowy upgrade dla klientów komercyjnych. Wersja Zend dla IBM "prosto z pudełka" obsługuje trzy bazy IBM: motor mobilny Cloudscape, serwer Informix IDS 9 oraz DB2 UDB 8. Zend przekonuje, że zapowiadana integracja pozwoli za pomocą PHP budować aplikacje zgodne z SOA korzystające z danych zgromadzonych w DB2 UDB.