Kontrola dostępu z wykorzystaniem etykiet

Oracle ma bardziej zaawansowaną kontrolę dostępu na poziomie wierszy niż wersja 8.1 jego bazy danych. DB2 9.1 także osiągnęła ten poziom kontroli, aczkolwiek trochę inną metodą. (Podobnej funkcjonalności w kontroli dostępu nie zawiera jednak SQL Server i prawdopodobnie nie zostanie ona jeszcze zawarta w przyszłym wydaniu o nazwie kodowej Katmai.) Chociaż tradycyjne metody kontroli dostępu na poziomie wierszy (widoki i procedury składowane) są nadal używane, to zastosowana w DB2 metoda LBAC (Label-Based Access Control) zapewnia dużo większe zabezpieczenie, chroniąc użytkownika przed omijaniem zastosowanych środków ochrony.

I tak, używając tradycyjnej metody kontroli dostępu, można tworzyć filtry (widoki), które określają np. że konkretny użytkownik może z tablicy widzieć jedynie klientów ze swojego regionu. Jednak użytkownik, który zna nazwę tablicy bazowej, może wykonać kwerendę samej tablicy, zamiast używać widoku. Natomiast metoda LBAC pozwala na określenie polityki bezpieczeństwa w odniesieniu do kontroli dostępu do poszczególnych kolumn lub nawet specyficznego zakresu wierszy.

Inne bazy danych mogą osiągać podobne efekty kontroli na tym poziomie, używając metod tradycyjnych. Różnica polega na stopniu angażowania poziomu administracyjnego. W metodach tradycyjnych można np. utworzyć procedurę składowaną (w bazie danych), dającą grupie użytkowników dostęp do tych danych. Jeżeli pojawi się inna grupa użytkowników, można napisać kolejną procedurę składowaną z danymi, dając dostęp do stosownych danych itd. Trzeba jednak panować nad tymi wszystkimi procedurami i nieustannie śledzić, które grupy uzyskują dostęp do poszczególnych danych. Przewaga tego podejścia polega na tym, że jedna procedura składowana nie ma związku z żadną inną, tak więc takie podejście nie wymaga większego planowania.

W przypadku LBAC trzeba w praktyce mieć plan określający, jak ma wyglądać wprowadzana polityka bezpieczeństwa. Jeżeli pojawią się grupy, które potrzebują różnych dostępów, to może okazać się konieczne przeprojektowanie całej polityki. Ale na dłuższą metę podejście LBAC wymaga mniej bieżącego administrowania. Nie trzeba się martwić o utrzymywanie różnych wersji procedur składowanych itp. Każde z tych podejść ma swoje zalety i wady i zapewne większość użytkowników chętnie widziałaby stosowanie kombinacji obu tych metod.

Ściskanie danych

Nowe kompresowanie na poziomie wierszy w DB2 jest jednym z cenniejszych mechanizmów. Jest to właściwie kompresja na poziomie tabeli i może osiągać rezultaty w postaci oszczędności pamięci rzędu 45 do 75%.

Przeprowadzone testy wydajnościowe na tablicach przed i po kompresji pokazały, że wydajność w obu tych przypadkach była podobna, ale tablice skompresowane często w praktyce przetwarzane są szybciej (głównie z powodu mniejszej zajętości pamięci operacyjnej).

Do kolejnego testu użyto serwera z mniejszą pamięcią RAM (1 GB), aby zobaczyć jak mniejsze przedsiębiorstwa mogą wykorzystać zalety kompresji. Test wykazał, że w tym scenariuszu operacje na tablicach skompresowanych nie wykonywały się już tak szybko jak na serwerze z pamięcią 4 GB. Ponieważ DB2 trzyma słowniki kompresji w pamięci, to mniejsza pamięć serwera spowodowała konieczność wyrzucania stron pamięci ze słownikiem na dysk, jeżeli serwer był zajęty.

Niezależnie od rzeczywistej przyczyny spowolnienia, jeżeli zamierza się używać kompresji na poziomie wierszy, należy najpierw wykonać testy wydajnościowe w rzeczywistym środowisku produkcyjnym. Jeżeli nawet dysponujemy rozbudowaną pamięcią RAM, to możemy być zaskoczeni słabą wydajnością, spowodowaną przez wiele różnych czynników, zwłaszcza jeżeli nie mamy dedykowanego serwera bazy danych. Niemniej jednak jeżeli mamy wytypować jakiś mechanizm, który wysuwa DB2 przed inne bazy danych, to zdecydowanie ten - ponieważ jest on użyteczny dla większości użytkowników baz danych.

Czas na decyzje

Nowa DB2 jest technologicznie imponująca. Upakowano w niej mechanizmy, które zapewne zadowolą zarówno administratorów, jak i projektantów. Czy jednak mechanizmy te będą dostatecznie konkurencyjne, aby przekonać zwolenników Oracle DBA do zmiany platformy - ta kwestia nie jest już tak oczywista.

W firmach stosujących szeroko XML na pewno cenny jest motor pureXML, ale jego znaczenie w szerszym kontekście biznesowym to sprawa przyszłości. Mechanizm skalowalności, obejmujący większe tymczasowe obszary robocze i podglądy statystyczne, czyni DB2 bardziej atrakcyjną na rynku bardzo dużych baz danych, ale niekoniecznie musi przemawiać do mniejszych użytkowników.

Wielu użytkowników może upatrywać większych zwrotów z inwestycji dzięki przełomowej kompresji na poziomie wierszy. Jednak chociaż ten mechanizm zdecydowanie zmniejsza TCO w stosunku do dotychczasowych wdrożeń DB2, to po prostu nie jest wystarczającym powodem przejścia na nową platformę. Podobnie inne mechanizmy - od rozszerzeń kwerend XML po ulepszenia w odtwarzaniu po katastrofie - przykuwają uwagę, ale nie są rewolucyjne.

W sumie jest to doskonałe wydanie dla dotychczasowych użytkowników DB2, ale na bardzo konkurencyjnym rynku baz danych niekoniecznie musi zdobyć nowych konwertytów. Nowe mechanizmy DB2 z pewnością pokazują stan wiedzy inżynierskiej IBM i mogą kłaść podwaliny pod nowe rozwiązania. Być może przez kilka następnych wydań, kiedy IBM i jego użytkownicy zaczną w pełni wykorzystywać te technologie, rzeczywista wartość wizji DB2 zacznie rosnąć.