EnterpriseDB to nakładka na PostgreSQL, pozwalająca podłączać do niej aplikacje pisane dla baz Oracle i SQL Server.

Gdy większość specjalistów mówi o bazie danych klasy enterprise, zazwyczaj myśli o najpopularniejszej z nich - Oracle. Na dalszych miejscach znajdują się produkty, takie jak IBM DB2, Microsoft SQL Server i Sybase Adaptive Server Enterprise. Baza klasy enterprise, ze względu na to, że od jej pracy zależy zwykle funkcjonowanie całego przedsiębiorstwa, musi być rozwiązaniem o wyjątkowej niezawodności i skalowalności, co w oczywisty sposób przekłada się na jej cenę.

Niezawodność i skalowalność serwera bazy danych może już wkrótce przestać być powodem do żądania sporych kwot za licencje. Rozwijany od kilkunastu lat w ramach projektu open source, stabilny i bogaty funkcjonalnie serwer PostgreSQL doczekał się właśnie EnterpriseDB - komercyjnej nakładki, likwidującej jego najpoważniejsze mankamenty, m.in. w dziedzinie skalowalności.

Na tym nie koniec. EnterpriseDB zapewnia warstwę logiczną pozwalającą serwerowi PostgreSQL "udawać" serwer Oracle lub SQL Server. W efekcie aplikacje pisane dla tych serwerów można uruchamiać na EnterpriseDB bez zmian w kodzie (no, prawie). Wraz z atrakcyjną funkcjonalnością idzie atrakcyjny model licencjonowania - koszt zakupu EnterpriseDB to kilka tysięcy USD za procesor na rok. Jest więc mniej więcej o rząd wielkości niższy od kosztu zakupu serwera Oracle.

Udawanie konkurencji

EnterpriseDB działa w dwóch trybach: tryb Redwood to emulacja serwera Oracle (siedziba Oracle mieści się w miejscowości Redwood Shores); tryb Redmond to oczywiście emulacja Microsoft SQL Server. Emulacja obejmuje utworzenie obiektów typu sysusers lub all_tables, typów, np. datetime czy varchar2, a także funkcji wbudowanych, np. convert bądź to_char.

Wraz z serwerem instaluje się prosta, przykładowa baza danych. Połączenie do niej jest możliwe za pomocą modułów wykorzystujących mechanizmy, takie jak ODBC czy JDBC, oraz narzędzia dla platformy .Net i Mono. Ponieważ EnterpriseDB wywodzi się z PostgreSQL, możliwe jest połączenie do niej za pomocą znanych opcji, takich jak obsługa bazy w języku PHP, Perl czy Python.

Generalnie EnterpriseDB bardzo łatwo jest podłączyć do aplikacji WWW (.Net, PHP). Dostęp do bazy możliwy jest przez sterowniki ODBC i JDBC, a w przyszłości także ustandaryzowane moduły PHP. Dzięki temu, że PostgreSQL obsługuje perspektywy, pozwalające posługiwać się uproszczonymi zapytaniami SQL, podłączenie EnterpriseDB do aplikacji jest nawet łatwiejsze niż w przypadku MySQL.

Użycie wyzwalaczy i procedur składowanych znacznie uprości kod interpretowany na serwerze aplikacyjnym, co nie pozostanie bez wpływu na prostotę, bezpieczeństwo oraz wydajność aplikacji (MySQL zapewnia te funkcje w wersji, która jest dopiero rozwijana).

Razem z bazą dostarczane jest także graficzne narzędzie administracyjne (patrz ilustracja). Oprócz możliwości uruchamiania aplikacji pisanych dla baz Oracle, EnterpriseDB niesie ze sobą narzędzia do zarządzania środowiskiem. Tego "zwykły" PostgreSQL nie zapewnia, poza prostymi narzędziami przeglądarkowymi (które jednak w wielu prostych zastosowaniach są wystarczające). Konsola EnterpriseDB przypomina narzędzia administracyjne Oracle.

Łatwo, ale nie całkiem

W przypadku większości aplikacji niewykorzystujących skomplikowanych obiektów przeniesienie programu z bazy Oracle na EnterpriseDB jest stosunkowo proste. W pewnych przypadkach skorzystanie z możliwości EnterpriseDB będzie jednak wymagać zmiany konfiguracji połączenia do bazy, bądź nawet przepisania fragmentów odpowiedzialnych za komunikację z bazą. Pocieszające jest jednak to, że większość kodu Oracle Forms działa bez zmian.

Kłopoty mogą pojawiać się, gdy wykorzystane zostały specyficzne funkcje/narzędzia. Przykładem są aplikacje napisane za pomocą narzędzi Oracle Developer/2000 - ale i tak powinno się udać. Najwięcej kłopotów sprawiają aplikacje, które obchodzą błędy konkretnych wersji Oracle (np. 8.1.6 dla platformy Linux x86).

Problemy mogą też pojawić się w przypadku aplikacji, które wykorzystują specyficzne dla Oracle rozszerzenia, takie jak Oracle Express Server albo OLAP Option. Między innymi dlatego nie uda się przenieść modułów analityki finansowej niektórych programów ERP - wymagają one np. Express Servera (BPSC Impuls) bądź innych obiektów w bazie (aplikacje ERP firmy TETA wymagające komunikacji z SQL Server, na którym pracuje hurtownia danych).

W przypadku prostszych rozwiązań, nawet przy pracy na bardzo dużym wolumenie danych, EnterpriseDB sprawdzi się bardzo dobrze. Replikacja jest prosta, działa dobrze, także między kopiami EnterpriseDB działającymi na różnych platformach systemowych. Prawidłowo działa partycjonowanie na przestrzenie tablespaces. Bez żadnych problemów odbywa się wykonywanie kopii bezpieczeństwa, a także odtwarzanie danych, działa nawet opcja odzyskiwania do konkretnego punktu w czasie.

Wydajność bez zastrzeżeń

Szybkość bazy jest zastanawiająco dobra. Miałem okazję porównać pracę EnterpriseDB zainstalowanej na platformie Linux z Oracle 9.2.0.4 zainstalowanym na tej samej maszynie (serwer z dwoma procesorami Xeon 2,4 GHz, 2 GB pamięci RAM; system Aurox 10).

Przy domyślnych ustawieniach, bez strojenia baz, bez tworzenia indeksów, zaimportowałem ponad 2 GB danych do czterech tabel i wykonałem kilka prostych zapytań. EnterpriseDB nie ma się czego wstydzić, w większości z nich jest nieznacznie szybsza od Oracle 9.2.0.4. Różnice w wydajności nie przekraczają kilku procent.

Po stosunkowo prostym dostrojeniu zapytań oraz konfiguracji motoru, działający poniżej EnterpriseDB optymalizator zapytań PostgreSQL pokazuje swoje możliwości. Oczywiście, dobrze dostrojona baza Oracle jest szybsza, ale różnica w wydajności nie jest bynajmniej dla EnterpriseDB dyskwalifikująca.

Porównanie wydajności EnterpriseDB w trybie emulacji SQL Server 2000 na platformie Linux z prawdziwym z SQL Server 2000 działającym na platformie Windows Server 2003 na tym samym sprzęcie (bez strojenia baz), wypada zdecydowanie na korzyść EnterpriseDB. Niestety, w dostępnym mi krótkim czasie nie miałem możliwości przetestowania skalowalności EnterpriseDB, która jest ponoć niezła.

Licencje w dobrej cenie

Dla wielu firm kluczową cechą EnterpriseDB jest cena. Różnicę widać szczególnie dobrze przy instalacji w wieloprocesorowym środowisku. W odróżnieniu od Oracle, nie przewiduje się licencji na użytkownika nazwanego. Są dwa kryteria cenowe. Pierwsze to grupa, w której znajduje się wybrany przez użytkownika produkt, drugie zaś to liczba procesorów (gniazd, nie rdzeni) w serwerze.

Jedynym kryterium rozdzielającym grupy jest wsparcie techniczne. Za 1 tys. USD rocznie za procesor (abonament Silver) otrzymuje się prawo do aktualizacji i wsparcia przez e-mail w ciągu 24h oraz telefonicznego w dni powszednie w godzinach biurowych. Za 3 tys. USD rocznie za procesor (abonament Gold) firma oferuje wsparcie z czasem reakcji 4h, a za 5 tys. USD za procesor (abonament Platinum) - reakcję w ciągu 1h, bezterminowość licencji, zabezpieczenie na wypadek roszczeń związanych z kodem open source oraz prawo do zlecania rozwoju specyficznych funkcji (oczywiście nie za darmo).

Nic dziwnego, że EnterpriseDB może się okazać bardzo poważnym konkurentem - nie tylko dla Oracle, ale i dla Microsoftu. Jeśli budowana aplikacja nie wymaga specjalnych możliwości bazy - takich jak motor OLAP, perspektywy utrwalone czy obsługa specjalnych narzędzi - można zaryzykować stwierdzenie, że przeniesienie obsługi danych z Oracle na EnterpriseDB jest całkiem realne, choć prawdopodobnie będzie wymagać pewnych zmian w aplikacji. W przypadku nowych aplikacji nie ma tego ograniczenia - można z dużą dozą prawdopodobieństwa zakładać, że wszystkie typowe zadania bazodanowe dadzą się obsłużyć w EnterpriseDB.

Najciekawsza jest jednak pozycja cennika, która wskazuje na możliwość nieodpłatnego wykorzystywania tej bazy w zastosowaniach o niskim wolumenie danych. Ograniczenia licencyjne darmowej wersji zakładają pracę na jednym procesorze, bazie o rozmiarze mniejszym niż 4 GB oraz maksymalnie 1 GB pamięci RAM. Podobnie jak w przypadku Oracle, wersja deweloperska, przeznaczona do tworzenia i testowania aplikacji, jest darmowa.

Jeśli producent nie zrezygnuje w przyszłości z nieodpłatnego udostępniania swojej bazy dla użytkowników korzystających z małego wolumenu danych, można zakładać, że wokół EnterpriseDB zacznie gromadzić się środowisko producentów aplikacji dla małych i średnich firm. Statystyki pokazują, że lwia część aplikacji dla firm z segmentu MSP z powodzeniem zmieści się w tym limicie.

Dla dużych i małych

Nie można powiedzieć wprost, że EnterpriseDB jest ścisłym zamiennikiem bazy Oracle, widać wyraźnie zastosowania w biznesie dla nowego produktu. Dwie grupy użytkowników zainteresują się nią na pewno. Pierwsza to małe firmy, których aplikacje będą mogły działać stabilnie bez dodatkowych kosztów, a jednocześnie z perspektywą aktualizacji, jeśli potrzeby wzrosną. Druga to firmy, które nie mogą lub nie chcą kupować licencji na bazy Oracle lub SQL Server w cenach proponowanych im przez producentów. Dla nich szczególnie cenne będą rozwiązania, takie jak replikacja na bazę stand-by, partycjonowanie bazy czy szybkie jej odtwarzanie po awarii.