Baza w niedoczasie
-
- 20.06.2005
Na obrzeżu serwera
Pewną formą buforowania jest zarządzanie dostępem do serwera baz danych. Nawiązanie połączenia z serwerem i jego zamknięcie angażuje zwykle sporo zasobów, dlatego większość systemów biznesowych pisana jest w taki sposób, by pewna pula połączeń była utrzymywana stale przez serwer aplikacji lub dedykowaną bramkę optymalizującą. Ten ostatni sposób zyskuje ostatnio na znaczeniu. Po pierwsze dlatego, że nie wszystkie aplikacje uruchamiane są w środowisku serwera aplikacji, po drugie zaś, ponieważ występuje potrzeba unifikacji dostępu do bazy dla wielu różnych typów klientów (aplikacje klienckie, przeglądarki WWW, systemy integracyjne itp.). Szczególnie przydatne są optymalizatory dla dostępu przeglądarkowego - taka bramka spełnia rolę wstępnego procesora zapytań, ujednolica je, grupuje, jeśli występuje wiele podobnych, buforuje wyniki itp.
To, czym zajmują się specjalizowane bramki, należy niby do podstawowych zadań samych serwerów baz danych, ale w grę wchodzą tu takie kwestie, jak niechęć do rozbudowy serwera i ponoszenia opłat licencyjnych za większą liczbę procesorów (w przypadku Oracle licencja na procesor wynosi ok. 40 tys. USD). Drugim ważnym powodem jest bezpieczeństwo - bramka chroni bazę przed zapytaniami mogącymi zaszkodzić jej stabilności lub spójności oraz przed kradzieżą danych.
Transakcje niepotrzebne
Ostatnio pojawiają się jeszcze bardziej nowatorskie pomysły na przyspieszanie baz danych, niemające nic wspólnego z mocą obliczeniową ani pojemnością pamięci RAM czy bufora. Jedna z propozycji wychodzi ze zdroworozsądkowego założenia, że większość danych zapisywanych do bazy nigdy więcej nie jest odczytywana. Oczywiście, odsetek danych "zapisanych na wieki" jest różny w różnych aplikacjach. Niemniej, zakładając, że w przyszłości wszystkie ważniejsze czynności i transakcje będą rejestrowane na potrzeby audytu w niezmienionej postaci, odsetek ten będzie tylko rosnąć. Ta konstatacja może prowadzić do przewrotnych wniosków.
Mechanizm transakcyjny w bazach danych pełni rolę stróża, który uniemożliwia dwóm procesom jednoczesne pisanie do tego samego rekordu czy pola i w ten sposób zawsze wiadomo, kto wykonał ostatnią transakcję na rekordzie, a dane pozostają spójne. Skoro jednak rekordy nie są aktualizowane, a zapis danych polega na stworzeniu nowego rekordu, transakcyjność - taka jaką znamy - nie ma sensu.
W konsekwencji rola motoru bazodanowego ulega zasadniczej zmianie. Zamiast pilnować spójności danych, co łatwo można osiągnąć innymi metodami, choćby stosując funkcje skrótów kryptograficznych, motor bazy danych optymalizuje procesy zapisu i odczytu danych, zarządza indeksem lub indeksami służącymi do wyszukiwania danych. Dba też o to, aby dane odczytywane częściej spoczywały na nośnikach bardziej wydajnych, zaś te rzadko bądź nigdy nieużywane - na nośnikach archiwalnych.
Sposobem na poprawę wydajności baz danych może być poprawa obsługi wielowątkowości serwera baz danych. Ponieważ najważniejsze produkty bazodanowe są pod tym względem dopracowane, dalsza poprawa jest możliwa jedynie dzięki wprowadzeniu wielowątkowości wspieranej sprzętowo. Serwer zawierający dwa układy CPU, z których każdy ma dwa rdzenie obliczeniowe zgodne z x86, zaś każdy rdzeń obsługuje dwa wątki jednocześnie, będzie z pewnością wydajniejszy, niż serwer zawierający dwa "zwykłe" procesory jednordzeniowe z tej rodziny.
W kierunku zwiększenia liczby wątków wspieranych sprzętowo idą w zasadzie wszyscy producenci sprzętu mogącego stanowić platformę dla serwera baz danych. Najdalej w obietnicach posunął się Sun, który być może jeszcze pod koniec br. zaprezentuje układy umożliwiające przetwarzanie do 32 wątków jednocześnie. Tymczasem firma Azul Systems już teraz oferuje serwery zdolne sprzętowo obsłużyć 384 wątki aplikacji J2EE. Wydajność modułów logiki biznesowej ma znaczenie dla wydajności bazy danych i będzie ono rosło. Propozycja Azul Systems pozwoli pisać procedury składowane w języku Java (wygoda dla programisty) i efektywnie je wykonywać.
Coraz większą popularność w zastosowaniach wymagających dużej wydajności i skalowalności zyskuje baza Berkeley DB rozwijana na zasadach open source przez firmę Sleepycat. W przeciwieństwie do baz relacyjnych, Berkeley DB w ogóle nie wykorzystuje interpretera zapytań SQL - informacje są zapisywane jako "rekordy" w pliku binarnym, a identyfikowane po unikalnym kluczu. Będący fundamentem Berkeley DB moduł Berkeley DB Data Store jest wykorzystywany także przez inne bazy, m.in. popularny w aplikacjach WWW serwer MySQL.
W odróżnieniu od wielu innych rozwiązań plikowych, Berkeley DB spełnia warunki ACID i oferuje "atomową" transakcyjność, więzy integralności, a nawet zaawansowane klastrowanie i automatyczne odtwarzanie. Oferuje dużą skalowalność - teoretycznie do 256 TB, znane są produkcyjne instalacje, w których Berkeley DB zarządza repozytoriami danych o pojemności kilkuset GB. Na liście referencyjnej Berkeley DB dostępnej pod adresem:http://www.sleepycat.com/solutions/customers.shtml można znaleźć duże firmy i poważne zastosowania.
Oprócz bazy danych opartej na plikach binarnych, Sleepycat oferuje również bazę opartą na repozytorium wykorzystującym katalogi z dokumentami XML. Ten relatywnie nowy produkt bardzo dobrze się zapowiada i być może to on właśnie spowoduje zainteresowanie bazami XML, czego do tej pory nie udało się osiągnąć pionierowi w tej dziedzinie - firmie Software AG, oferującej XML-owy motor baz danych o nazwie Tamino.
