Karol Bieńkowski

Wrażenia z użytkowania Objectivity/DB

Instalacja

Instalacja Objectivity/DB przebiega bez większych problemów. Cały program instalacyjny zajmuje tylko 6.5 MB. Po zainstalowaniu (wersja tylko dla Windows NT) Objectivity instaluje demona (Lock Server), Apache'a (na porcie 6781), kilka programów binarnych do zarządzania bazami danych oraz bibliotekę oojava.jar konieczną do kompilacji własnych programów w Javie. Kompercyjna dystrybucja Objectivity zawiera interfejsy do różnych języków programowania (Java/C++/Smalltalk) oraz interakcyjny interpreter zapytań. Darmowa wersja testowa posiada wiązania wyłącznie do Javy - tylko tę część udało się przetestować.

Programowanie

Objectivity nie zapewnia przezroczystej trwałości. Dla uzyskania trwałości własnego obiektu należy utworzyć go jako podklasę klasy com.objy.db.app.ooObj. Zapisywanie obiektu odbywa się przez ręczne wywołanie metody markModified(), a odczytywanie stanu obiektu z bazy danych przez wołanie metody fetch(). Obie metody są zdefiniowane w klasie ooObj. Związki między obiektami można zaprogramować samemu albo skorzystać z wbudowanych klas: com.objy.db.app.ToManyRelationship oraz ToOneRelatioship. Te klasy spełniają dwie role: zarządzają utrwalaniem obiektów oraz ułatwiają używanie powiązań. Weźmy dla przykładu klasę pl.prv.karolb.obdobjy.Ekspres, która ma pole ToManyRelationship rezerwacje. Wtedy dodawanie nowych rezerwacji jest proste: rezerwacje.add(nowaRezerwacja) powoduje związanie odpowiednich obiektów. Ponadto, jeżeli Ekspres był trwały to rezerwacja też zostaje zapisana do bazy danych.

Sztandarowe zastosowanie SQLa to złączenia. Przykładowe zadanie to znalezienie wszystkich rezerwacji dla danego Ekspresu. W Objectivity robi się to to pobierając iterator z obiektu reprezentującego związek (Iterator = rezerwacje.scan()) i pobierając z niego kolejne obiekty. O ilez to prostsze i bardziej oczywiste w użyciu niż złączenia SQLowe.

Wady i zalety nieprzezroczystości

Brak przezroczystości ma oczywiste wady. Zamiast myśleć wyłącznie nad logiką programu trzeba zająć się też składowaniem danych. Ale przecierz od problemów składowania i tak nie uda się uciec. Przezroczysta trwałość pozwala od razu zacząć pisać poprawne programy, ale przy bardziej zaawansowanych zadaniach okazuje się, że chcemy mieć dostęp do "wnętrzności" mechanizmu składującego. Taki model jak w Objectivity wymaga trochę wysiłku na początku - trzeba poznać pewne schematy programowania. Trzeba się np. dowiedzieć do czego służą obiekty ToManyRelationship. Gdy już się zna schematy wszystko idzie z górki. To trochę tak jak z PHP i Javą. W PHP można zacząć pisać od razu, a w Javie nawet wypisanie daty wymaga przeczytania dokumentacji do paru klas. Program Hello World w Javie też jest dłuższy niż w PHP. Jednak większość ludzi woli Javę.

Język zapytań

W Objectivity jest dość ograniczony. Nie uważam tego za wadę. SQL był potrzebny, bo to był jedyny sposób na dostęp do danych w tabelach. W bazach obiektowych korzysta się z paradygmatu programowania obiektowego: hermetyzacji. Każdy obiekt używa wartości które są albo jego atrybutami albo atrybutami obiektów do których ma wskaźnik. Sztandarowym wykorzystaniem SQLa są złączenia, np. Pracowników z Działami. W obiektowej bazie danych obiekt klasy Dział ma tablicę wskaźników do obiektów klasy Pracownik. Dla szybkiego dostępu ta tablica może być haszująca. Funkcjonalność taka jak przy indeksów, tyle że rodzaj indeksu wybiera się używając obpowiedniej klasy (np. Hashtable) z języka programowania, a nie przez specyficzne instrukcje "SQLowe" Oracle'a.

Wyniki testów z opisem

Jedna duża transakcja
InsertUpdateSelect/MetodyKońcowy Commit
50*40.5/1.5/11/1/00/3.5/1.50/0/0
250*43.5/5/2.55/5/01/100/130/0/0.5
500*47.5/17.5/414.5/15.5/0-/-/-0/0/0
COMMIT po każdym zapytaniu
InsertUpdateSelect/MetodyKońcowy Commit
50*41.5/0.5/10.5/1/00/5/1.50/0/0
250*45.5/7/2394.5/6/1501/89/1060/0/0

Klucz

Sposób przeprowadzenia

Sprzęt

Testy Oraclowe przeprowadziłem na systemie uczelnianym. Myślę, że były wiarygodne niż gdybym przeprowadził go na swoim komputerze. Po pierwsze mój komputer jest słabiutki jak na Oracla, po drugie nie znam się zupełnie na dostrajaniu tego SZBD.

Za to Objectivity działał u mnie. Niska moc mojego procesora nie przeszkodziła mu w testach, poniważ w testach nie wymagających częstego korzystania z dysku okazał się szybszy od Oracle'a. To dysk był wąskim gardłem dla Objectivity. Na szybszym dysku wynik Objectivity byłby lepszy, ale nie sądze by dogonił Oracla. Sprzęt: CPU AMD K6-2 400MHz, RAM 320MB, HDD Seagate Barracuda IV 7200 rpm (EIDE, ATA-100).

Sieć nie miała w wypadku Oracla znaczenia, gdyż wszystkie testy i pomiar czasu przeprowadziłem jedną skąadowaną procedurą PL/SQLową.

Oprogramowanie

Testy Oraclowe przeprowadziłem za pomocą procedur PL/SQLowych. Wersja obiektowa procedury jest tu, a perspektywowa tu. Opis wszystkich skryptów SQL znajduje się tu.

Testy na Objectivity/DB trzeba było zaprogramować w Javie. Plik tworzący bazę danych i przeprowadzający testy to UtworzBaze.java (funkcja testujBaze). Przed uruchomieniem testów na Objectivity trzeba utworzyć federację skryptem makeFD.bat.

Procedury testujące, zarówno te PL/SQLowe jak i Javove mają parametry, które określają wielkość bazy i to czy robić COMMIT po każdej transakcji:

Diagram encji

Uwagi nt. testów:

Podsumowanie testów

Oracle jest zdecydowanie szybszy przy krótkich transakcjach. Różnica jest bardzo duża - Oracle jest szybszy kilkadziesiąt razy. W zastosowaniach wymagających krótkich transkacji (np. baza na potrzeby WWW) Objectivity nie ma szans.

Jeżeli transakcje obejmują wieleset operacji to baza Objectivity/DB jest równie wydajna. Podobna wydajność obu baz występuje także przy wołaniu metod na obiektach bazy, z tym że w przypadku Oracla wołane są metody składowane, a Objectivity wykonuje metody lokalnie. Stąd wniosek, że w zastosowaniach wymagających dużej liczby obliczeń, przy skomplikowanej logice programu i niezbyt częstym utrwalaniu danych górą jest Objectivity. Jest lepszy nie tylko pod względem wydajności, ale też pod względem łatwości programowania, bo cały kod powstaje w jednym języku.



©2002 Karol Bieńkowski
Wersja offline