Baza po ewolucji

Co zmienia otwartość

"Proprietary vendors are seeing that the days of making money off database licensing are ending" - pisze Josh Berkus, jeden z kluczowych programistów PostgreSQL. Czy aby na pewno? Bazy open source niewątpliwie gonią systemy komercyjne pod względem funkcjonalności. Patrząc na listę cech PostgreSQL

- trzeba stwierdzić, że zawiera ona wszystkie ważniejsze algorytmy znane w świecie baz danych w ogóle. Jest tam nawet moduł optymalizatora kwerend oparty na algorytmach genetycznych.

Lista nowych możliwości PostgreSQL (w wersji 8) to jednak, tak naprawdę, mechanizmy dobrze znane z komercyjnych baz danych. Możliwość zmiany typu kolumny w tabeli bez kopiowania i tworzenia nowej tabeli czy mechanizm zatwierdzania transakcji w trybie snapshot od dawna istnieją w Oracle, SQL Server, Sybase ASE...

Podstawowy problem z bazami open source jest związany z testami i analizą wydajności. Nieudane wdrożenie linuxowe nie jest, jako eksperyment o ograniczonym zasięgu, specjalnie kosztowne. Trudno jednak wyobrazić sobie szefa IT, który przeniesie 500 GB bazę na MySQL tylko dlatego, że ktoś gdzieś powiedział, że to baza bardzo wydajna i stabilna. Nie ma bowiem niezależnych testów, jak baza się zachowa przy takiej ilości danych. Nikt nie próbuje nawet zadać sobie pytania, czy koszt "ręcznego nadrobienia" brakujących funkcjonalności w motorze MySQL zrównoważy zyski, jakie przyniesie brak opłat licencyjnych. Również skalowalność jest pojmowana przez środowisko open source dosyć osobliwie. Na jednej z prezentacji na konferencji OSCON 2004 jako przykład dużej instalacji PostgreSQL był wymieniany serwer z 2 procesorami Xeon i 4 GB RAM.

MySQL uczciwie reklamuje swoją bazę, mówiąc wprost, że nie zapewnia ona pełnej integralności, ale za to jest bardzo szybka. Tyle że istnieją na rynku serwery baz danych oferujące zarówno wysoką wydajność, jak i integralność. Po drugie, mechanizmy odpowiadające za pilnowanie powiązań referencyjnych i transakcyjność czy wyzwalacze nie są tam jedynie po to, by zaspokoić żądzę posiadania takiej funkcjonalności. Każdy z tych mechanizmów powstał po to, by ułatwić życie programiście, a w końcowym rozrachunku także użytkownikowi serwera, który nie musi martwić się o niezawodność aplikacji czy bezpieczeństwo danych.

Warto też dodać, że obecnie każdy producent oferuje tanie lub wręcz darmowe wersje swojej bazy danych. DB2 Express jest ograniczona do 2 procesorów. Oracle Standard Edition One - nie ma pewnych cech "większego" motoru bazodanowego. Darmowe MSDE ma "tłumik" uniemożliwiający wykonywanie więcej niż 5 równoległych zapytań o średniej złożoności. SQL Server 2005 Express Edition ma mieć ograniczenie do 2 procesorów i 2 GB RAM. Z kolei Sybase zaczął oferować pełną wersję Adaptive Server Enterprise dla Linuxa za darmo. ASE to porządny kawałek bazy danych, brak opłat zapewnia jej niezłą pozycję wyjściową w starciu z dowolną bazą open source.

Zwolennicy open source przekonują, że bazy MySQL i PostgreSQL są "wystarczająco dobre" w swoich zastosowaniach. Pytanie tylko, czy taka argumentacja znajdzie posłuch na tym rynku. W przeszłości przeciętność, nawet przy braku opłat, nie przynosiła produktom wielkiej popularności czy przewagi. Wystarczy spojrzeć na udziały Open Office w rynku pakietów biurowych, czy np. desktopu opartego o Debiana.

W przypadku baz danych "odrobinę" szybsza baza to mniejszy koszt serwera, szybszy czas odpowiedzi aplikacji, co pozwala pracownikom krócej czekać i wydajniej pracować itp. To są bardzo wymierne zyski, które usprawiedliwiają kupno bazy komercyjnej. Jeżeli ktoś lubi uruchamiać bazę na Linuxie, to na razie tylko Microsoft nie oferuje takiej możliwości.

Ciekawymi przypadkami baz jest SAP DB i InterBase (obecnie FireBird).

Jako produkty komercyjne nie odniosły dużych sukcesów (z ciekawszych wdrożeń InterBase można wymienić giełdę w Moskwie). Natomiast po oddaniu ich społeczności open source zyskały "drugie" życie - i znalazły swoją niszę jako bazy "embedded" - osadzone w konkretnych aplikacjach, pełniąc rolę ich podręcznych magazynów danych.

Serwer, klient i baza

Jednym z podstawowych założeń architektury trójwarstwowej jest separacja kodu "klienta" - czyli "przeglądającego", od bazy danych, do czego służy serwer aplikacyjny. To on wykonuje logikę biznesową i odpowiada za zapis danych do bazy itd. W wielu przypadkach model trójwarstwowy nie jest jednak najwygodniejszy, a w każdym razie najwydajniejszy. Czasem logikę warto umieścić tuż obok serwera baz danych lub wręcz uruchomić ją w jego środowisku.

Działający w środowisku serwera język SQL nie nadaje się do opisu złożonej logiki, dlatego w tym celu wykorzystuje się procedury wbudowane, zwykle pisane w C. Ostatnio coraz częściej pojawia się możliwość pisania ich w Javie, ale administratorzy, przeczuwając problemy z wydajnością, rzadko ją stosują - co najwyżej do wykonywania procedur pomocniczych.

W SQL Server 2005 Microsoft wprowadził mechanizm uruchamiania po stronie serwera kodu .Net, dodając jednocześnie możliwość przechowywania obiektów jako pól w tabeli. Zmodyfikował też ADO.Net 2.0, tak że ma specjalne mechanizmy ułatwiające komunikację z motorem. Pojawił się zupełnie inny mechanizm pobierania danych (nie przez specjalny "provider" JDBC, jak w Javie) - a także relatywnie łatwe łączenie kodu T/SQL i kodu .Net. Dodatkowo aplikacja kliencka może pobrać "referencję" do kodu, który jest w bazie danych. Taki mechanizm osadzania logiki powinien zyskać popularność. Również PostgreSQL pozwala tworzyć kod działający "blisko" bazy danych - w tym przypadku chodzi o Perl.