ODBMS vs. RDBMS - czyli wydajność i wygoda vs popularność i dostępność ;)

Przez kilka ostatnich dni zajmuję się tworzeniem aplikacji, której wydajność jest kluczowa - to czy będzie działać kilka procent szybciej ma ogromne znaczenie. Dlatego też staram się na wszystkim oszczędzać - na ilości przesyłanych danych (bo to aplikacja klient-serwer), ilości tworzonych nowych wątków do obsługi żądań, no i na czasie wykonywania operacji na bazie danych.

Przyznam, że dotychczas jeśli chodzi o aplikacje bazodanowe to tworzyłem je tylko w oparciu o relacyjne bazy danych (zarówno w Javie, jak i w PHP). Jakiś czas temu zacząłem też używać frameworków do mapowań O/R (JDO, Hibernate, Propel). Nigdy jednak nie pomyślałem, że zastosowanie tych technologii może być niewłaściwe dla jakiejkolwiek aplikacji. A jednak...

Dziś w tworzeniu web-aplikacji używa się niemal jedynie relacyjnych baz danych (sam nie znam żadnej PHP-owej witryny, która by używała czegoś innego). Rzeczywistość pokazuje jednak, że w przypadku baz danych, do których wysyła się dużą liczbę zapytań takie rozwiązanie wcale nie jest wydajne, a nawet wygodne(!).

Programując systemy z użyciem obiektowych języków prorgamowania chciałoby się używać tylko i wyłącznie tego języka i niczego więcej. Tymczasem programując aplikacje bazodanowe z użyciem RDBMS trzeba mieć na względzie strukturę bazy danych, wiedzieć jak taka baza pracuje, martwić się wieloma niepotrzebnymi rzeczami. Najgorsze jest jednak to, że taka baza nie przechowuje obiektów a jedynie zbiory rekordów, które muszą być mapowane na obiekty (lub na odwrót). Tu z pomocą przychodzą narzędzia O/R - JDO, Hibernate (Hibernate+Spring+Transakcje), Propel - jednak zastanówmy się jakim kosztem ? Im więcej warstw pośrednich, tym mniejsza wydajność aplikacji. Pójdę jeszcze o krok dalej - a czy w ogóle JDBC jest wydajne? Przecież dla każdej kolumny w zapytaniu JDBC tworzone są nowe obiekty - a duża ilość takich operacji może znacznie obciążyć naszą aplikację.

Tu z pomocą przychodzą obiektowe bazy danych - proste, wydajne, łatwe w użyciu, a przede wszystkim "obiektowe" ;) Prevayler to jedna z najpopularniejszych ODBMS dla Javy. Zakłada ona, iż wszystkie dane pochodzące z naszej aplikacji będą trzymane w pamięci operacyjnej RAM. Ktoś mógłby powiedzieć: "No dobrze, to po co w ogóle używać bazy danych skoro wszystko może być w pamięci RAM". Oczywiście można trzymać wszystkie obiekty w RAMie, ale przeszukanie ich może zająć bardzo dużo czasu (o ile nie napisze się jakiegoś własnego wydajnego mechanizmu, ale to już sie mija z celem ;) Aplikacja używająca Prevayler musi więc sama zarządzać tworzeniem zrzutów bazy danych (backup na wypadek awarii lub restartu serwera). Ponadto trzeba się liczyć z tym, że jeśli ilość danych będzie bardzo duża to zajmie dużo miejsca w pamięci operacyjnej - a przecież nie mamy jej w nieskończonych ilościach. Powracając do sedna sprawy, czyli wydajności - ile taka baza jest szybsza od np. bazy MySQL ? Odpowiedź może być zaskakująca - kilkaset-kilka tysięcy razy szybsza (!). Zachęcam do zapoznania się z wynikami testów wydajnościowych na stronie projektu (czytając go trzeba mieć na względzie, że testy te dotyczą tylko prostych zapytań, nie ma np. porównania z testami na SQLu wykorzystującymi złączenia, procedury, widoki itp.).

Nieco "ulepszoną" wersją dla Prevayler jest db4objects - baza, która potrafi już bezpośrednio operować na plikach (oczywiście kosztem wydajności). Projekt ten posiada 2 licencje: GPL i komercyjną. Gorąco zachęcam to zapoznania się z obiema technologiami, bo naprawdę warto. Sam zastanawiam się, którą z nich wybrać - prawdopodnie do prostych systemów, w których nie jest aż tak ważne "bezpieczeństwo danych" (chodzi o możliwość utraty niektórych danych w przypadku awarii) oraz ilość danych nie przekracza kilkudziesięciu MB Ramu - użyję Prevayler. W innych sytuacja db4objects może okazać się dobrym rozwiązaniem.

Na forum Java.net można przeczytać mój wątek o porównaniu ODBMS i RDBMS.

Moja recenzja Sothink SWF Decompiler MX 2005b

Na witrynie Software Developers Journal - jednego z najbardziej prestiżowych czasopism w Polsce, no i przede wszystkim jedynego czasopisma o programowaniu zamieszczono recenzję mojego autorstwa. Recenzja dotyczy programu Sothink SWF Decompiler - w skrócie, aplikacji do dekompilacji plików swf. Artykuł można przeczytać tutaj

Marna dola programisty Java cz. 1

Sytuacja w Polsce, jeśli chodzi o hosting dla webaplikacji tworzonych w Javie jest conajmniej nieciekawa. Tak najprawdę istnieje jedyna poważna firma – http://www.jhosting.pl , która jednak za swoje usługi życzy sobie bajońskie sumy (1200 złoty netto rocznie za marne konto z dzieloną wirtualną maszyną Javy!). Reszta to po prostu wielkie nieporozumienie. Co jest tego przyczyną? Zbyt duże wymagania aplikacji javowych co do ilości pamięci operacyjnej czy niedouczenie polskich administratorów? Jeśli chodzi o to ostatnie to rzeczywiście, polscy administratorzy niewiele wiedzą o Tomcacie czy JBossie. Prędzej specjalistami w tych dziedzinach są programiści Java. Sam osobiście znam kilkoro adminów, którzy na pytanie o znajomość javowych serwerów milkną i zmieniają temat. Póki co dla Polaka pozostaje zakup takiego konta zagranicą. Tam ceny są już nieco niższe, jednak nie ma tak naprawdę rozsądnych rozwiązań za sumy poniżej 500-600 złotych rocznie. Najlepszym rozwiązaniem wydawać się więc może kupno wirtualnego serwera o przyzwoitych parametrach (np. Adiungo lub FDCServers) lub ew. serwera dedykowanego.

Tymczasem sytuacja programistów PHP ma się zgoła odmiennie. Ilość firm oferujących hosting dla takich aplikacji jest ogromna - zarówno w Polsce jak i na świecie. Ofert jest tyle, że nie sposób przed zakupem zapoznać się z 1/10 tego co jest dostępne na rynku. Co więc ma zrobić Javowiec? Przenieść się na php ? Wolne żarty;) Nawet PHP 5 ze swoimi możliwościami obiektowymi w niczym nie dorówna Javie. Póki co jednak, aplikacje webowe napisane w Javie będą stosowane w intranecie i hostowane na serwerach firmowych, które tą aplikację stworzyły.

Na JDN można zobaczyć mój post na temat hostingu Java w Polsce: http://jdn.pl/node/182

Moje CV

Imię	Jacek
Nazwisko	Olszak
Telefon	********
Adres	ul. ***** */*, 02-441 Warszawa
E-mail	jacekolszak [at] gmail.com
Data urodzenia	18 august 1983
Stan cywilny	kawaler
Wykształcenie	2004 - do dziś	Wyższa Szkoła Informatyki w Łodzi (wydział zamiejscowy w Bydgoszczy)
	2003	Uniwersytet Mikołaja Kopernika, Wydział Fizyki, Astronomii i Informatyki Stosowanej
	1998 - 2003	Technikum Elektroniczne, Toruń dyplom technika w specjalnoci automatyka przemysłowa
Certyfikaty	sierpień 2006	Sun Certified Java Programmer SCJP 5.0
Doświadczenie	05.2006 - do dziś	ISolution [programista/projektant J2EE, Hibernate, Spring, JSF]
	10.2005 - 05.2006	Ramzes Sp. z o.o. [programista/projektant J2EE, EJB 3, web services, Spring, Hibernate]
	05.2004 - 10.2005	WiedzaNet Sp. z o.o. [programista Java, ActionScript 2(Flash), Toolbook, PHP]
	2003 – 2005	Praca jako freelancer – PHP, Java, SQL, Flash, DHTML
	2002 – obecnie	Praca przy projektach open source – programowanie i zarządzanie projektami
Osiągnięcia	2003	otrzymanie nagrody Dyrektora za Najlepszą Pracę Dyplomową roku 2002/03 w dziedzinie Informatyki
	1998	zajęcie 5 miejsca w wojewódzkim Konkursie Informatycznym (algorytmy)