Grafowe bazy danych - przegląd technologii

Grafowe bazy danych - przegl¡d technologii
Daniel Sªotwi«ski
01.06.2010
Spis tre±ci
1 Koncepcja grafowych baz danych
2
1.1
Graf jako struktura danych
. . . . . . . . . . . . . . . . . . . . .
1.2
Geneza grafowych baz danych . . . . . . . . . . . . . . . . . . . .
2
1.3
Relacyjne bazy danych (RBD) a grafowe bazy danych (GDB) . .
2
2 Grafowy model danych
2
3
2.1
Struktury danych . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Wi¦zy integralno±ci . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1
2.2.2
2.2.3
2.3
Spójno±¢ schemat-instancja (ang.
sistency )
schema-instance con-
. . . . . . . . . . . . . . . . . . . . . . . . . . .
object identity and referential integrity )
. . . . . . . . . .
4
Zale»no±ci funkcyjne . . . . . . . . . . . . . . . . . . . . .
5
J¦zyki zapyta« i modykacji danych
. . . . . . . . . . . . . . . .
3 Zastosowania
3.1
3.2
4
To»samo±¢ obiektu oraz integralno±¢ referencyjna (ang.
5
6
Obszary i przyczyny u»ycia modelu grafowego . . . . . . . . . . .
6
3.1.1
Zastosowania klasyczne (ang.
. . .
6
3.1.2
Sieci zªo»one (ang.
. . .
7
. . . . . . . . . . . . . . . . . . . . . .
7
Rzeczywiste zastosowania
classical applications )
complex networks ) . . . . . . . .
4 Przegl¡d dost¦pnych technologii
8
4.1
Opis wybranych systemów . . . . . . . . . . . . . . . . . . . . . .
4.2
Porównanie wybranych cech GBD
. . . . . . . . . . . . . . . . .
5 Przykªadowa implementacja bazy danych neo4j
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
11
12
5.1
Instalacja bazy
5.2
Utworzenie grafu
5.3
Wyszukiwanie w grae . . . . . . . . . . . . . . . . . . . . . . . .
15
5.4
Peªny kod przykªadu . . . . . . . . . . . . . . . . . . . . . . . . .
16
. . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Podsumowanie.
13
13
19
1
1
Koncepcja grafowych baz danych
1.1 Graf jako struktura danych
Graf jest jedn¡ z podstawowych abstrakcji w informatyce i posiada wiele zastosowa«. Praktycznie ka»da aplikacja, która operuje na grafach, musi te struktury przechowywa¢ w pami¦ci oraz tworzy¢ do nich zapytania. W ostatnim czasie wzrosªo zainteresowanie grafami jako reprezentacj¡ sieci spoªeczno±ciowych
(ang.
social networks ),
struktur tworz¡cych sie¢ stron internetowych i innych.
W biologii grafy u»ywa si¦ do modelowania sieci metabolicznych, sieci oddziaªywa« mi¦dzybiaªkowych, grafów struktur chemicznych, klastrów genów, map
genetycznych. Grafy to jedne z najbardziej u»ytecznych struktur do modelowania obiektów i oddziaªywa«.
1.2 Geneza grafowych baz danych
Zainteresowanie naukowców grafowymi bazami danych rozwin¦ªo we wczesnych
latach 90', lecz pó¹niej niemal wygasªo. Zainteresowanie przeniosªo si¦ na technologie modelowania danych póªstrukturalnych, m. in. hipertekst oraz XML.
Struktury drzewiaste byªy wystarczaj¡ce do wi¦kszo±ci zastosowa«.
Wraz z upowszechnieniem Internetu jako narz¦dzia dost¦pu do danych, ilo±¢
danych zacz¦ªa rosn¡¢ zarówno pod wzgl¦dem ilo±ci zasobów, jak i poª¡cze«
mi¦dzy tymi zasobami.
Zacz¦to coraz cz¦±ciej u»ywa¢ modelu grafowego do
reprezentacji ogromnych ilo±ci danych. Tradycyjne magazyny danych (relacyjne
bazy danych) s¡ zdolne do przechowywania reprezentacji struktur grafowych,
jednak nie czyni¡ tego w prosty i naturalny sposób, reprezentacja taka nie jest
te» wydajna.
Dlatego znacznie potrzeba stosowania baz danych wyspecjali-
zowanych do przechowywania danych grafowych.
1.3 Relacyjne bazy danych (RBD) a grafowe bazy danych
(GDB)
Relacyjne bazy danych.
Jedn¡ z przyczyn sukcesu relacyjnych baz danych
jest ich zdolno±¢ do modelowania praktycznie dowolnej struktury danych bez
wprowadzania redundancji lub utraty precyzji.
Osi¡gni¦ciu tego pomaga na
etapie projektowania bazy danych proces normalizacji. Po stworzeniu struktury
bazy dane mog¡ by¢ dodawane, modykowane oraz pobierane z u»yciem j¦zyka
SQL (Structured Query Language).
Model relacyjny posiada jednak wady:
•
Problemy z wydajno±ci¡ zapyta« SQL, które obejmuj¡ wiele tabel (zª¡cze«).
•
Niska skalowalno±¢, trudno±ci w zmianie struktury bazy po pewnym czasie, trudno±ci w modelowaniu struktur drzewiastych, danych póªstrukturalnych danych hierarchicznych, sieci i innych.
•
Model relacyjny jest sªabo dopasowany do popularnych obecnie paradygmatów rozwoju oprogramowania, w szczególno±ci technologii i j¦zyków
zorientowanych obiektowo oraz j¦zyków dynamicznych. Problem w literaturze angielskiej nosi nazw¦
object-relational impedance mismatch.
Konieczne jest tworzenie tzw. warstw ORM (Object-Relational Mapping),
2
mapuj¡cych relacje (tabele) na obiekty i odwrotnie. Systemy te (np. Hibernate) dziaªaj¡ z ró»nym skutkiem, cz¦sto maj¡ problemy z wydajno±ci¡.
•
Dane typu semi-structured s¡ cz¦sto modelowane jako du»e tabele z wieloma
kolumnami, które s¡ puste dla wi¦kszo±ci wierszy (macierze rzadkie), co
prowadzi do niskiej wydajno±ci. Alternatywne modelowanie tych struktur
za pomoc¡ wielu poª¡czonych tabel tak»e nie jest wydajne, ze wzgl¦du na
du»y koszt wykonywania zª¡cze« tabel w zapytaniach (joins ).
Wg teorii struktury grafowe zapisane w RBD mo»na podda¢ normalizacji, ma to
jednak powa»ne konsekwencje wydajno±ciowe przy zapytaniach. Konsekwencje
s¡ zwi¡zane z charakterem rekursywnym struktur takich jak np. drzewa plików,
struktury sieciowe, sieci spoªeczne oraz charakterem zapisu danych w postaci
relacji. Ka»da operacja na relacji pomi¦dzy w¦zªami sieci (czyli kraw¦dzi grafu)
skutkuje wykonaniem zª¡czenia mi¦dzy tabelami RBD operacji powolnej i
nieskalowalnej przy rosn¡cej liczbie krotek (ang.
Grafowe bazy danych.
tuples )
w tabelach.
Zapisanie u»ywanych w programach struktur grafowych
w grafowej bazie danych likwiduje powy»sze problemy. Grafowa baza danych
jest bardziej naturaln¡ ni» RBD metod¡ reprezentacji, przechowywania i pobierania danych, których charakter nie przystaje do typowego schematu bazy
relacyjnej.
Dobrym przykªadem s¡ modele sieci spoªeczno±ciowych lub inne
modele zawieraj¡ce zwi¡zki, których nie mo»na ªatwo reprezentowa¢ w postaci
tabeli lub których nie mo»na skalowa¢.
W pozycji bibliogracznej [3] opisano prób¦, podczas której zostaªa utworzona struktura sieci spoªeczno±ciowej skªadaj¡cej si¦ z 1000 u»ytkowników, gdzie
ka»dy z nich posiadaª 50 znajomych. Tradycyjna RBD potrzebowaªa 2000 ms
na wykonanie zapytania o dane ka»dego przyjaciela ka»dego u»ytkownika. Analogiczna grafowa baza danych zaimplementowana w neo4j potrzebowaªa na t¦
operacj¦ tylko 2 ms. W celu zaprezentowania wydajno±ci i skalowalno±ci bazy
neo4j zwi¦kszono liczb¦ u»ytkowników do 1 000 000. Okazaªo si¦, »e caªkowity
czas zapyta« tak»e wyniósª 2 ms!
Jak wida¢, wa»n¡ cech¡ modelu grafowego
jest zdolno±¢ do ªatwego skalowania przy zªo»onych relacjach mi¦dzy encjami w
bazie oraz du»a elastyczno±¢.
2
Grafowy model danych
2.1 Struktury danych
Reprezentacja grafowa opiera si¦ na dwóch poj¦ciach: encji (inaczej obiektu,
w¦zªa) oraz relacji (powi¡zania, kraw¦dzi). Encja reprezentuje pojedynczy byt.
Relacja jest pewn¡ wªasno±ci¡ wyst¦puj¡c¡ (lub nie) pomi¦dzy encjami. Encje
oraz relacje mog¡ by¢ opisane przez atrybuty (wªasno±ci).
Mówi¡c j¦zykiem teorii grafów, model jest etykietowanym i skierowanym
multigrafem z atrybutami. Graf etykietowany posiada etykiet¦ dla ka»dej kraw¦dzi,
b¦d¡c¡ jej typem.
Graf skierowany zawiera kraw¦dzie z okre±lonym kierunk-
iem, od w¦zªa ¹ródªowego do w¦zªa ko«cowego.
Graf z atrybutami umo»li-
wia przypisanie zmiennej listy atrybutów ka»demu w¦zªowi i ka»dej kraw¦dzi.
Atrybut jest warto±ci¡ zwi¡zan¡ z nazw¡. Multigraf mo»e zawiera¢ wielokrotne
3
kraw¦dzie pomi¦dzy dwoma w¦zªami. Oznacza to, »e dwa w¦zªy mog¡ by¢ ª¡czone wiele razy przez ró»ne kraw¦dzie, nawet je±li te kraw¦dzie maj¡ ten sam
w¦zeª ¹ródªowy, docelowy oraz etykiet¦.
Teoria grafów jest bardzo u»yteczna i odpowiednia do rozwi¡zywania wielu
problemów z wielu ró»nych dziedzin, w których dane modelowane s¡ z przy pomocy struktur grafowych. Przykªadem algorytmu pochodz¡cym z teorii grafów
jest znajdowanie najkrótszej ±cie»ki.
2.2 Wi¦zy integralno±ci
Wi¦zy integralno±ci s¡ ogólnymi instrukcjami i reguªami, które deniuj¡ zbiór
spójnych stanów bazy danych i/lub zmian stanów.
W przypadku grafowych baz danych wyró»niamy nast¦puj¡ce wi¦zy integralno±ci:
2.2.1 Spójno±¢ schemat-instancja (ang.
schema-instance consistency )
Grafowe bazy danych cz¦sto (ale nie zawsze) deniuj¡ schemat bazy (ang.
schema ),
który konkretna instancja bazy danych musi speªnia¢.
Spójno±¢ schemat-instancja w ogólno±ci podporz¡dkowuje si¦ poni»szym wytycznym:
1. instancja powinna zawiera¢ tylko encje i relacje o typach zdeniowanych
w schemacie
2. encja w instancji mo»e mie¢ wyª¡cznie te relacje lub wªa±ciwo±ci (proper-
ties ),
które s¡ zdeniowane dla typu tej encji (lub w przypadku dziedz-
iczenia nadtypu encji). Tak»e wszystkie etykiety w¦zªów i kraw¦dzi musz¡
wyst¡pi¢ w schemacie.
Oddzielenie schematu i instancji (ang.
schema-instance separation )
Okre±la stopie«, w jakim schemat i instancja s¡ rozró»niane w bazie danych.
Model danych mo»e by¢ zaklasykowany jako strukturalny (structured ) lub
niestrukturalny (unstructured ) w zale»no±ci od tego, czy pozwala lub nie pozwala
na denicj¦ schematu w celu ograniczenia instancji bazy danych do dobrze
okre±lonych typów danych.
W wi¦kszo±ci baz danych wyst¦puje rozró»nienie
schematu i instancji.
2.2.2 To»samo±¢ obiektu oraz integralno±¢ referencyjna (ang.
identity and referential integrity )
object
W zorientowanych obiektowo bazach danych (jakimi s¡ grafowe bazy danych)
to»samo±¢ obiektu jest niezale»na od warto±ci atrybutów i jest osi¡gni¦ta przez
zapisanie w ka»dym obiekcie w bazie unikalnego identykatora, np. etykiety.
Integralno±¢ encji (entity
integrity)
zapewnia, »e ka»dy w¦zeª grafu jest
unikaln¡ encj¡ identykowan¡ przez jej kontekst. Integralno±¢ referencyjna (ref-
erential integrity )
wymaga istnienie odniesienia tylko do istniej¡cych encji.
Te ograniczenia odpowiadaj¡ wi¦zom integralno±ci klucza podstawowego oraz
klucza obcego (referencyjnego) w relacyjnych bazach danych.
4
2.2.3 Zale»no±ci funkcyjne
Zale»no±ci funkcyjne s¡ zale»no±ciami semantycznymi.
A → B , gdzie A i B s¡ zbiorami atrybutów
B we wszystkich w¦zªach bazy danych.
Zale»no±¢ funkcyjna
wyra»a, »e
A
okre±la warto±¢
Semantyczne wi¦zy integralno±ci na poziomie schematu bazy mog¡ by¢ reprezentowane przez skierowane kraw¦dzie.
2.3 J¦zyki zapyta« i modykacji danych
J¦zyk zapyta« jest zbiorem operatorów lub reguª wnioskowania, które mog¡
by¢ zastosowane do dowolnych instancji typów struktur danych modelu, w celu
akwizycji i manipulowaniu danymi zawartymi w tych strukturach.
Wiele j¦zyków obsªuguje przechodzenie grafów (graph
traversal ).
Przechodze-
nie to wyszukanie pewnych obiektów (w¦zªów) startuj¡c z innych w¦zªów. Na
przykªad, je±li pewien obiekt w grae jest niepoprawny, to ta informacja musi
zosta¢ rozpropagowana do wszystkich potomków tego w¦zªa - konieczno±¢ przej±cia grafu. Innym przykªadem jest wyszukiwanie pewnych informacji w grae.
Zapytania dzilimy na dwa typy: zapytania strukturalne (structural
i zapytania o dane (data
queries ).
queries )
Przykªadowe zapytania strukturalne:
•
znajd¹ w¦zªy-sieroty: znajd¹ wszystkie w¦zªy w grae, które s¡ singletonami - nie maj¡ we±ciowych i wyj±ciowych kraw¦dzi
•
przejd¹ graf do gª¦boko±ci 4 i zlicz liczb¦ dost¦pnych w¦zªów
Przykªadowe zapytania o dane:
•
zlicz liczb¦ w¦zªów, których dane s¡ równe podanej warto±ci
•
zlicz liczb¦ w¦zªów, których dane s¡ mniejsze od podanej warto±ci
•
zlicz liczb¦ w¦zªów, których dane zawieraj¡ podany ªa«cuch tekstowy
Przykªadowe j¦zyki zapyta«:
•
Gremlin - jest to grafowy j¦zyk programowania.
Posiada wbudowane
mechanizmy zapyta« grafowych, analizy i manipulacji grafami. Jego obsªug¦ posiada m.in. Neo4j.
•
SPARQL - umo»liwia wyra»anie zapyta« dotycz¡cych ró»norodnych ¹ródeª
danych, gdzie dane s¡ przechowywane w RDF. Wynikiem zapyta« SPARQL
jest zbiór grafów RDF. Obsªuga np. w AllegroGraph.
•
G, G+, GraphLog - J¦zyki te umo»liwiaj¡ tworzenie tzw.
ta« (query
graph ).
grafów zapy-
Zapytanie grafowe w przypadku j¦zyka G wyra»one
w jest zbiorem etykietowanych skierowanych multigrafów, których w¦zªy
mog¡ by¢ zmiennymi lub staªymi. Wynikiem zapytania jest suma (union )
wszystkich grafów zapyta«, które dopasowano do podgrafów z instancji
grafu (bazy).
•
G-Log - zawiera j¦zyk deklaratywny do zªo»onych obiektów. U»ywa logiczn¡ notacj¦ speªnienia reguª (rule
na zapytanie.
5
satisfaction ) do wyznaczenia odpowiedzi
•
Glide - zapytania s¡ wyra»one z u»yciem liniowej notacji skªadaj¡cej si¦ z
wyra»e« regularnych (etykiet i
3
wild-cards ).
Zastosowania
3.1 Obszary i przyczyny u»ycia modelu grafowego
W artykule [4] podzielono zastosowania grafowych baz danych na dwie ogólne
classical applications )
kategorie: zastosowania klasyczne (ang.
(ang.
complex networks ).
i sieci zªo»one
Sieci zªo»one wyst¦puj¡ w dziedzinach charakteryzu-
j¡cych si¦ ogromn¡ ilo±ci¡ danych oraz struktur¡ sieci. Zastosowania klasyczne
to wszystkie systemy, w których dotychczas stosowano rozwi¡zana klasyczne
(RBD), w których jednak wyst¦puj¡ problemy, z którymi mo»na sobie poradzi¢
poprzez u»ycie grafowego modelu danych.
3.1.1 Zastosowania klasyczne (ang.
•
classical applications )
Jako uogólnienia klasycznego modelu bazodanowego
Model klasyczny jest cz¦sto krytykowany za brak semantyki, pªask¡ struktur¦ danych, trudno±ci w odkryciu przez u»ytkownika relacji mi¦dzy danymi
oraz trudno±ci w modelowaniu zªo»onych obiektów.
•
Gdy zªo»ono±¢ danych przekracza mo»liwo±ci modelu relacyjnego
Taka sytuacja mo»e wyst¡pi¢ w:
zarz¡dzaniu sieciami transportowymi
(kolejowymi, lotniczymi, wodnymi, telekomunikacyjnymi), modelowaniu
systemu drogowego, komunikacji zbiorowej.
Wiele zastosowa« grafowe
bazy danych znajduj¡ w systemach GIS (Systemy Informacji Geogracznej)
oraz przestrzennych bazach danych.
•
W sytuacjach, gdy siªa ekspresji j¦zyków zapyta« modelu relacyjnego
(SQL) jest zbyt ograniczona
Operacje, które s¡ naturalne w modelu grafowym i s¡ implementowane w
wi¦kszo±ci grafowych baz danych, posiadaj¡ szerokie zastosowanie. Przykªady
takich operacji, to ró»ne rodzaje przechodzenia grafów oraz wyszukiwania.
•
W systemach reprezentacji wiedzy
U»ycie grafowych baz danych pozwala na zwi¦kszenie elastyczno±ci bazy
wiedzy oraz technik wnioskowania.
•
W wielu procesach modelowania semantycznych i zorientowanych obiektowo baz danych u»ywa si¦ abstrakcji w postaci grafu. W takich sytuacjach warto rozwa»y¢ u»ycie grafowej bazy danych, gdzie zarówno operacje
CRUD (Create,
Read, Update, Delete ),
jak i reprezentacja danych b¦dzie
bardziej odpowiednia.
•
Jako rozszerzenie funkcjonalno±ci oferowanej przez obiektowe bazy danych,
np. w systemach CASE, CAD, przetwarzania obrazów, analizy danych
naukowych
•
Interfejsy graczne i wizualne, systemy geograczne, obrazkowe i multimedialne.
•
Sie¢ Semantyczna (Semantic
Web )
6
3.1.2 Sieci zªo»one (ang.
•
complex networks )
Sieci spoªeczno±ciowe
W tych sieciach w¦zªy reprezentuj¡ ludzi lub grupy ludzi, a kraw¦dzie
pokazuj¡ zwi¡zki lub przepªywy pomi¦dzy w¦zªami.
Przykªady relacji i
grafów: sie¢ przyjacióª/znajomych, zale»no±ci biznesowych, towarzyskich,
sie¢ osób wspóªpracuj¡cych naukowo, sieci komputerowe.
•
Sieci informacji (information
networks )
W modelu tym relacje reprezentuj¡ przepªywy informacji, np.
cytaty
pomi¦dzy artykuªami akademickimi, sie¢ WWW (hiperª¡cza), sieci peerto-peer, relacje pomi¦dzy klasami sªów w tezaurusie, sieci preferencji.
•
Sieci technologiczne
W tych sieciach dominuj¡ aspekty przestrzenne i geograczne struktury.
Przykªady:
Internet (jako sie¢ komputerowa), sieci energetyczne, drogi
lotnicze, sieci telefoniczne, sieci kurierskie (pocztowe), GIS.
•
Sieci biologiczne
Model grafowy u»ywany jest do reprezentowania informacji biologicznej,
której du»a obj¦to±¢, zarz¡dzanie i analiza staªy si¦ trudno±ci¡, której
przyczyna le»y w zautomatyzowaniu procesu akwizycji danych.
3.2 Rzeczywiste zastosowania
W tym rozdziale przedstawiono kilka rzeczywistych projektów, przy których
wykorzystano grafowe bazy danych.
Amanzi Wireless Explorer - http://www.amanzitel.com/page/AWE
- Neo4j
Amanzi Wireless Explorer (AWE) jest platform¡ open source sªu»¡c¡ do wizualizacji, zarz¡dzania danymi, optymalizacji i analizy danych, a tak»e raportowania w dziedzinie wspomagania decyzji in»ynierskich. Š¡czy koncepcje arkusza
kalkulacyjnego, systemu GIS oraz bazy danych.
Dane dziedziny s¡ przechowywane w bazie Neo4J, która pozwala na korzystanie przez u»ytkowników z przekazanych struktur danych, a tak»e umo»liwia
interaktywn¡ analiz¦ i raportowanie na poziomie niedost¦pnym w przypadku
relacyjnych baz danych.
Twitter - http://github.com/twitter/ockdb - FlockDB
Tweeter jest serwisem spoªeczno±ciowym, umo»liwiaj¡cym wysyªanie i odczytywanie krótkich wiadomo±ci (tweetów ).
Twitter u»ywa bazy danych FlockDB do przechowywania grafu spoªeczno±ci
(zawieraj¡cego informacje kto ±ledzi kogo, kto blokuje kogo) i drugorz¦dne
indeksy (secondary
indices ).
W kwietniu 2010 w bazie FlockDB Twittera byªo
ponad 13 bilionów kraw¦dzi, a ilo±¢ operacji osi¡gaªa 20 tysi¦ci zapisów/sekund¦
i 100 tysi¦cy odczytów/sekund¦.
7
Smewt (Smart Media Manager) - http://www.smewt.com/ - Neo4j
Smewt jest inteligentnym programem zarz¡dzaj¡cym zasobami multimedialnymi. Przeszukuje pliki u»ytkownika, automatycznie rozpoznaje je i zbiera informacje na ich temat z sieci. Przedstawia multimedialn¡ kolekcj¦ nie w postaci
listy plików, ale jako semantycznie powi¡zane informacje.
Smewt przechowuje wszystkie informacje w postaci grafu. Dzi¦ki temu istnieje mo»liwo±¢ ªatwego powi¡zania przechowywanej informacji oraz tworzenia
trudnych zapyta«, co byªoby w przypadku u»ycia innych struktur danych
utrudnione. U»ytkownik mo»e zamiast prostego przeszukiwania tekstu utworzy¢
zapytanie semantyczne w rodzaju: Podaj list¦ wszystkich moich lmów stworzonych przez hiszpa«skiego re»ysera w ci¡gu ostatnich 10 lat.
Na stronie http://wiki.neo4j.org/content/Neo4j_In_The_Wild jest
obszerna lista projektów, w których wykorzystano baz¦ Neo4J.
4
Przegl¡d dost¦pnych technologii
Rozdziaª zawiera informacje o wybranych implementacjach grafowych baz danych.
4.1 Opis wybranych systemów
Neo4j - http://neo4j.org/
Neo4j jest rozwi¡zaniem
open source dla wszystkich niekomercyjnych zastosowa«
i szybko staje si¦ czoªowym systemem grafowych baz danych.
Neo4j jest wbudowanym, dyskowym (disk-based ), w peªni transakcyjnym sil-
nikiem grafowych baz danych. Wg deweloperów jest on wyj¡dkowo skalowalny
- umo»liwia obsªug¦ kilkunastu bilionów w¦zªów na jednej maszynie, posiada
ªatwe w u»yciu API oraz wydajne procedury przechodzenia grafu (graph
sal ).
traver-
Neo4j u»ywa systemu Apache Lucene do indeksowania i przeszukiwania.
Lucene jest silnikiem przeszukiwania tekstów, napisanym w Javie i posiadaj¡cym du»¡ wydajno±¢.
Neo4j posiada API (bindingi) do wielu j¦zyków programowania, w tym
Python, Ruby, Erlang, Clojure, PHP.
Przykªad implementacji prostej sieci spoªeczno±ciowej w Neo4J znajduje si¦
w rozdziale 5.
Sones GraphDB - http://www.sones.com
Sones GraphDB posiada cechy magazynu plikowego oraz systemu zarz¡dzania
baz¡ danych. Nadaje sie do przechowywania du»ych ilo±ci danych póªstrukturalnych o du»ym stopniu powi¡zania. Umo»liwia prac¦ w ±rodowisku rozproszonym.
Baza danych jest komercyjna, udost¦pniona jest jednak tak»e wersja Open
Source. Sones GraphDB pracuje wyª¡cznie na platformie .NET/Mono.
8
InfoGrid - http://infogrid.org/
InfoGrid ª¡czy cechy grafowych i relacyjnych (SQL) baz danych. Aplikacje zbudowane na platformie InfoGrid mog¡ korzysta¢ z ró»nych silników relacyjnych
baz danych lub baz danych NoSQL bez zmiany kodu aplikacji. W przypadku
u»ycia relacyjnej bazy danych InfoGrid zapewnia automatyczne mapowanie
obiektowo-relacyjne (ORM). InfoGrid implementuje wzorzec REST.
InfoGrid wymusza stosowanie strategii kontroli dost¦pu w warstwie danych.
Odbywa si¦ to w sposób podobny do systemu uprawnie« do plików w systemach
operacyjnych.
Implementacja protokoªu XPRISO umo»liwia komunikacj¦ pomi¦dzy instacjami systemu InfoGrid, co umo»liwia rozszerzanie funkcjonalno±ci systemu i zapewnia skalowalno±¢.
InfoGrid uªatwia dost¦p do zewn¦trznych (rozproszonych) danych, w tym
zmiennych danych.
Probe Framework
umo»liwia dost¦p do danych z dowolnego
¹ródªa i w dowolnym formacie tak, jakby zasoby te byªy danymi natywnymi
InfoGrid.
HyperGraphDB - http://www.kobrix.com/hgdb.jsp
Baza danych zaprojektowana do u»ycia w projektach wykorzystuj¡cych sztuczn¡
inteligencj¦ oraz sieci semantyczne. Umo»liwia przechowywanie danych zarówno
w modelu obiektowym, jak i relacyjnym.
Jako grafowa baza danych Hyper-
GraphDB nie narzuca ogranicze« (wi¦zów), zapewnia wi¦ksz¡ ogólno±¢ ni» inne
GBD.
AllegroGraph - http://www.franz.com/agraph/allegrograph/
AllegroGraph jest baz¡ danych opart¡ o RDF (Resource
work ).
Description Frame-
U»ywa dyskowego magazynu danych, umo»liwia uzyskanie du»ej wyda-
jno±ci przy przechowywaniu bilionów trójek RDF. System wspiera SPARQL,
RDFS++, a tak»e wnioskowanie Prolog.
Od wersji 4.0 AllegroGraph posiada transakcje, automatyczne indeksowanie,
100% wspóªbie»no±ci operacji odczytu.
DEX - http://www.dama.upc.edu/technology-transfer/dex
Ten system zarz¡dzania grafow¡ baz¡ danych posiada nast¦puj¡ce cechy:
•
grafowa reprezentacja danych, operacji i wyników zapyta«
•
wi¦zy integralno±ci obejmuj¡: typy w¦zªów i kraw¦dzi, relacje, atrybuty
dziedzinowe
•
darmowa wersja spoªeczno±ciowa umo»liwia utworzenie bazy maksymalnie
do 1 miliona w¦zªów
vertexdb - http://www.dekorte.com/projects/opensource/vertexdb/
VertexDB jest serwerem grafowych baz danych du»ej wydajno±ci, obsªuguj¡cy
automatyczny
garbage collection.
U»ywa protokoªu HTTP do zapyta« i JSON
jako formatu odpowiedzi. API jest wzorowane na systemie FUSE (Filesystem
in USErspace )
oraz kilku dodatkowych metodach zapyta« i kolejek.
9
FlockDB - http://github.com/twitter/ockdb
FlockDB jest rozproszon¡ baz¡ danych przechowuj¡c¡ informacje grafowe w
postaci list s¡siedztwa. Gªówne cechy FlockDB:
•
du»a wydajno±¢ operacji CRUD
•
wyniki zapyta« mog¡ zawiera¢ miliony warto±ci
•
mo»liwo±¢ archiwizacji i odtwarzania zarchiwizowanych kraw¦dzi
•
skalowanie horyzontalne, w tym replikacja
•
migracja danych online
FlockDB nie obsªuguje przechodzenia grafu.
FlockDB jest prostsza od baz danych takich jak Neo4j, poniewa» skupia si¦
na rozwi¡zywaniu mniejszej ilo±ci problemów.
10
4.2 Porównanie wybranych cech GBD
Neo4J
Sones GraphDB
InfoGrid
Transakcyjno±¢
tak
nie
tak
ACID
tak
nie
cz¦±ciowo
Rozproszona
cz¦±ciowo (RMI)
tak
tak
Silnik bazy
wªasny
wªasny
ró»ne
nie
tak
tak
Baza danych
Mapowanie
obiektowe
Wspóªbie»no±¢
Zapytania
wªasny
J¦zyk zapyta«
Gremlin
Przechodzenie grafu
tak
nie
tak
Open Source
tak
tak
tak
Komercyjny
tak
tak
tak
Licencja
AGPLv3
SaaS
AGPLv3
Java embedded /
.NET embedded, REST,
XPRISO, OpenID,
REST
WebServices
RSS, Atom, JSON,
Licencja
(Graph Query Language)
brak
jako API +
API
Java embedded
J¦zyki
programowania
Java
tak
nie
tak
C++
C#
nie
nie
nie
nie
tak
nie
Python
tak
nie
nie
Ruby
tak
nie
nie
Erlang
tak
nie
nie
Clojure
tak
nie
nie
Lisp
nie
nie
nie
Perl
nie
nie
nie
PHP
tak
nie
nie
REST
tak
.NET
JVM
Platforma
systemowa
JVM
11
AllegroGraph
DEX
VertexDB
Transakcyjno±¢
tak
nie
tak
tak
ACID
tak
-
?
cz¦±ciowo (ACI)
Rozproszona
nie
nie
tak
Silnik bazy
wªasny
Baza danych
Mapowanie
nie
obiektowe
Tokyo
Cabinet
HyperGraphDB
Berkeley DB
nie
tak
Wspóªbie»no±¢
tak
tak
J¦zyk zapyta«
SPARQL
brak
JSON
brak
tak
nie
tak
Zapytania
Przechodzenie grafu
Licencja
Open Source
nie
nie
tak
tak
Komercyjny
tak
tak
nie
nie
Licencja
komercyjna
komercyjna
Revised BSD
LGPL
API
REST
Java
HTTP / JSON
-
Java
tak
tak
-
tak
C++
nie
tak
-
nie
J¦zyki
programowania
C#
tak
nie
-
nie
Python
tak
nie
-
nie
Ruby
tak
nie
-
nie
Erlang
nie
nie
-
nie
Clojure
nie
nie
-
nie
Lisp
tak
nie
-
nie
Perl
tsk
nie
-
nie
PHP
nie
nie
-
nie
REST
tak
nie
-
Platforma
Linux / Linux
Linux,
systemowa
Virtual Machine
Windows
Linux / Unix
Szczegóªowe porównanie systemów grafowych baz danych mo»na znale¹¢ w
pozycji [6] w bibliograi.
5
Przykªadowa implementacja bazy danych neo4j
Celem przykªadu b¦dzie utworzenie instancji bazy danych zawieraj¡cej graf
przedstawiony na poni»szym rysunku. Graf reprezentuje niewielk¡ sie¢ spoªeczno±ciow¡. Przykªad jest wzorowany na prezentacji [5].
12
JVM
Rysunek 1: Przykªadowa sie¢ znajomych. Przykªad pochodzi z prezentacji [5].
5.1 Instalacja bazy
Przykªadowa implementacja zostanie wykonana w Javie. Baza danych b¦dzie osadzona (ang.
embedded ), co oznacza, »e b¦dzie istniaªa lokalnie w uruchomionej
Maszynie Wirtualnej Javy (JVM). Aby u»y¢ neo4j, wystarczy w aplikacji doda¢
do classpath pliki JAR pobrane ze strony http://neo4j.org/download/.
5.2 Utworzenie grafu
Graf z rysunku 1 przedstawia pewnien zbiór w¦zªów, zbiór relacji pomi¦dzy
w¦zªami (ró»nych typów), zbiór wªa±ciwo±ci (properties ) dla ka»dego w¦zªa, oraz
zbiór wªa±ciwo±ci tych relacji.
W celu okre±lenia typów relacji tworzymy enumeracj¦, która deniuje te
typy:
1
private
enum
RelTypes
2
KNOWS,
3
CODED_BY,
4
5
implements
RelationshipType
{
LOVES
}
Metoda createDatabaseInstance tworzy instacj¦ bazy neo4j oraz wypeªnia j¡
danymi:
1
2
3
4
5
6
7
8
9
10
private
private
GraphDatabaseService
Node
public void
graphDb ;
mrAnderson ;
createDatabaseInstance (){
// U tw o rz e ni e i n s t a n c j i b a z y danych . Baza j e s t t y p u " embedded " , c z y l i
// z n a j d u j e s i ¦ na maszynie w i r t u a l n e j , na k t ó r e j program j e s t
// uruchamiany
graphDb = new EmbeddedGraphDatabase ( " n e o 4 j − s t o r e " ) ;
// R o z p o c z ¦ c i e t r a n s a k c j i
13
11
12
Transaction
t x = graphDb . b e g i n T x ( ) ;
14
// U tw o rz e ni e w ¦ z ª a g r a f u . Dodanie do w¦zªów k i l k u w ª a s n o ± c i
// (" p r o p e r t i e s " ) .
15
mrAnderson = graphDb . c r e a t e N o d e ( ) ;
16
mrAnderson . s e t P r o p e r t y ( "name" ,
17
mrAnderson . s e t P r o p e r t y ( " a g e " ,
13
"Thomas
Anderson " ) ;
29);
18
19
Node
20
morpheus . s e t P r o p e r t y ( "name" ,
" Morpheus " ) ;
21
morpheus . s e t P r o p e r t y ( " r a n k " ,
" Captain " ) ;
22
morpheus . s e t P r o p e r t y ( " o c c u p a t i o n " ,
23
morpheus = graphDb . c r e a t e N o d e ( ) ;
" Total
bad
ass " ) ;
24
// U tw o rz e ni e k r a w ¦ d z i ( r e l a c j i ) s k i e r o w a n e j mi¦dzy w¦zªami .
25
mrAnderson . c r e a t e R e l a t i o n s h i p T o ( morpheus ,
R e l T y p e s .KNOWS) ;
26
27
Node
28
t r i n i t y . s e t P r o p e r t y ( "name" ,
29
trinity
= graphDb . c r e a t e N o d e ( ) ;
" Trinity " ) ;
31
// Wªasno±ci (" p r o p e r t i e s ") mo»na t a k » e dodawa¢ do k r a w ¦ d z i , co
// i l u s t r u j e p o n i » s z y kod w p r z y p a d k u r e l a c j i " mrAndersonKnowsTrinity " .
32
morpheus . c r e a t e R e l a t i o n s h i p T o ( t r i n i t y ,
33
Relationship
30
34
R e l T y p e s .KNOWS) ;
mrAndersonKnowsTrinity
= mrAnderson . c r e a t e R e l a t i o n s h i p T o ( t r i n i t y ,
35
mrAndersonKnowsTrinity . s e t P r o p e r t y ( " age " ,
36
t r i n i t y . c r e a t e R e l a t i o n s h i p T o ( mrAnderson ,
"3
R e l T y p e s .KNOWS) ;
days " ) ;
R e l T y p e s . LOVES ) ;
37
38
Node
39
r e a g a n . s e t P r o p e r t y ( "name" ,
r e a g a n = graphDb . c r e a t e N o d e ( ) ;
40
reagan . setProperty ( " l a s t
" Cypher " ) ;
name" ,
" Reagan " ) ;
41
42
43
44
Relationship
morpheusKnowsReagan
= morpheus . c r e a t e R e l a t i o n s h i p T o ( r e a g a n ,
R e l T y p e s .KNOWS) ;
morpheusKnowsReagan . s e t P r o p e r t y ( " d i s c l o s u r e " ,
" public " ) ;
45
46
Node
47
a g e n t . s e t P r o p e r t y ( "name" ,
a g e n t = graphDb . c r e a t e N o d e ( ) ;
48
agent . setProperty ( " v e r s i o n " ,
49
agent . setProperty ( " language " ,
" Agent
Smith " ) ;
" 1 . 0 b" ) ;
"C++" ) ;
50
51
52
Relationship
reaganKnowsAgent
= reagan . c r e a t e R e l a t i o n s h i p T o ( agent ,
R e l T y p e s .KNOWS)
53
reaganKnowsAgent . s e t P r o p e r t y ( " d i s c l o s u r e " ,
54
reaganKnowsAgent . s e t P r o p e r t y ( " a g e " ,
"6
" secret " );
months " ) ;
55
56
Node
57
a r c h i t e c t . s e t P r o p e r t y ( "name" ,
58
agent . createRelationshipTo ( a r c h i t e c t ,
59
60
architect
= graphDb . c r e a t e N o d e ( ) ;
" The
Architect " ) ;
R e l T y p e s .CODED_BY) ;
// Oznaczenie t r a n s a k c j i sukcesem i z a k o « c z e n i e j e j spowoduje
14
61
// wykonanie commit ' u do b a z y
62
tx . s u c c e s s ( ) ;
63
64
tx . f i n i s h ( ) ;
}
5.3 Wyszukiwanie w grae
Znalezienie przyjacióª i
tranzytywnych
przyjacióª pana Andersona.
Gdy mamy wypeªnion¡ baz¦, mo»emy wypróbowa¢ metod¦ przej±cia grafu w
celu znalezienia wszystkich znajomych pana Andersona.
Przej±cie polega na
odwiedzeniu wszystkich w¦zªów, do których da si¦ doj±¢ przechodz¡c wyª¡cznie
wyj±ciowymi kraw¦dziami typu KNOWS. Graf b¦dziemy przechodzi¢ wedªug
strategii przeszukiwania wszerz, przeszukiwaj¡c w¦zªy do ko«ca grafu.
Przeszukiwanie grafu ilustruje poni»szy kod:
1
public void
findFriendsOfAnderson (){
3
// U tw o rz e ni e i n s t a n c j i o b i e k t u k l a s y Traverser , k t ó r y z w r ó c i
// p r z y j a c i ó ª Pana Andersona .
4
Traverser
2
f r i e n d s T r a v e r s e r = mrAnderson . t r a v e r s e (
// s t r a t e g i a p r z e s z u k i w a n i a w s z e r z :
5
6
T r a v e r s e r . O r d e r . BREADTH_FIRST,
// p r z e g l ¡ d a n i e do ko«ca g r a f u :
7
8
S t o p E v a l u a t o r .END_OF_GRAPH,
// z w r a c a n i e w s z y s t k i c h p a s u j ¡ c y c h w¦zªów , o p r ó c z o s t a t n i e g o :
9
10
R e t u r n a b l e E v a l u a t o r .ALL_BUT_START_NODE,
// r e l a c j a , j a k a nas i n t e r e s u j e :
11
12
R e l T y p e s .KNOWS,
// k i e r u n e k r e l a c j i :
13
14
D i r e c t i o n .OUTGOING
15
);
16
17
// P r z e j ± c i e po w ¦ z ª a c h i w y p i s a n i e r e z u l t a t ó w
18
System . o u t . p r i n t l n ( "Mr A n d e r s o n ' s
for
19
20
( Node
:
friends : " );
f r i e n d s T r a v e r s e r ){
System . o u t . p r i n t f ( " At
21
d e p t h %d => %s%n " ,
f r i e n d s T r a v e r s e r . c u r r e n t P o s i t i o n ( ) . depth ( ) ,
22
f r i e n d . g e t P r o p e r t y ( "name" )
23
);
24
25
friend
}
}
Rezultat wykonania powy»szej funkcji jest nast¦puj¡cy:
Mr Anderson ' s
friends :
At
depth
1 => Morpheus
At
depth
1 => T r i n i t y
At
depth
2 => Cypher
At
depth
3 => Agent
Smith
15
Znalezienie wszystkich osób, które s¡ w kim± zakochane.
W tym przy-
padku naszym celem jest zwrócenie wszystkich w¦zªów w±ród znajomych pana
Andersona, które posiadaj¡ wyj±ciow¡ relacj¦ typu LOVES. Sªu»y temu metoda
ndFriendsInLove():
1
public void
findFriendsInLove (){
3
// U tw o rz e ni e i n s t a n c j i o b i e k t u k l a s y Traverser , k t ó r y z w r ó c i w ¦ z ª y
// z r e l a c j ¡ w y j ± c i o w ¡ "LOVES"
4
Traverser
2
l o v e T r a v e r s e r = mrAnderson . t r a v e r s e (
// s t r a t e g i a p r z e s z u k i w a n i a
// p r z e s z u k i w a n i e do ko«ca g r a f u
// Z d e f i n i o w a n i e , k t ó r e w ¦ z ª y maj¡ by¢ zwracane :
5
T r a v e r s e r . O r d e r . BREADTH_FIRST,
6
S t o p E v a l u a t o r .END_OF_GRAPH,
7
new
8
9
10
ReturnableEvaluator (){
public boolean i s R e t u r n a b l e N o d e ( T r a v e r s a l P o s i t i o n
return p o s . c u r r e n t N o d e ( ) . h a s R e l a t i o n s h i p (
11
R e l T y p e s . LOVES,
12
D i r e c t i o n .OUTGOING
);
13
}
14
},
16
// p r z e c h o d z e n i e g r a f u n a d a l odbywa s i ¦ po
// wy±ciowych k r a w ¦ d z i a c h t y p u KNOWS
17
R e l T y p e s .KNOWS,
15
18
D i r e c t i o n .OUTGOING
19
);
20
21
// P r z e j ± c i e po w ¦ z ª a c h i w y p i s a n i e r e z u l t a t ó w
22
System . o u t . p r i n t l n (
for
23
( Node
24
:
"Who
is
in
love ?" ) ;
loveTraverser ){
System . o u t . p r i n t f (
25
" At
d e p t h %d => %s%n " ,
l o v e T r a v e r s e r . c u r r e n t P o s i t i o n ( ) . depth ( ) ,
26
p e r s o n . g e t P r o p e r t y ( "name" )
27
);
28
29
person
}
}
Rezultat uruchomienia metody:
Who
At
is
in
depth
love ?
1 => T r i n i t y
5.4 Peªny kod przykªadu
Plik
1
2
3
4
5
6
7
8
9
10
Neo4jExample.java :
package n e o 4 j e x a m p l e ;
import
import
import
import
import
import
import
import
o r g . n e o 4 j . graphdb . D i r e c t i o n ;
o r g . n e o 4 j . graphdb . GraphDatabaseService ;
o r g . n e o 4 j . graphdb . Node ;
o r g . n e o 4 j . graphdb . R e l a t i o n s h i p ;
o r g . n e o 4 j . graphdb . R e l a t i o n s h i p T y p e ;
o r g . n e o 4 j . graphdb . R e t u r n a b l e E v a l u a t o r ;
o r g . n e o 4 j . graphdb . S t o p E v a l u a t o r ;
o r g . n e o 4 j . graphdb . T r a n s a c t i o n ;
16
pos ){
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
import o r g . n e o 4 j . graphdb . T r a v e r s a l P o s i t i o n ;
import o r g . n e o 4 j . graphdb . T r a v e r s e r ;
import o r g . n e o 4 j . k e r n e l . EmbeddedGraphDatabase ;
public c l a s s Neo4jExample {
private enum RelTypes implements R e l a t i o n s h i p T y p e
{
}
KNOWS,
CODED_BY,
LOVES
private GraphDatabaseService graphDb ;
private Node mrAnderson ;
public void c r e a t e D a t a b a s e I n s t a n c e ( ) {
// Utworzenie i n s t a n c j i ba zy danych . Baza j e s t ty pu " embedded " , c z y l i
// z n a j d u j e s i ¦ na maszynie w i r t u a l n e j , na k t ó r e j program j e s t uruchamiany
graphDb = new EmbeddedGraphDatabase ( " neo4j − s t o r e " ) ;
// R o z p o c z ¦ c i e t r a n s a k c j i
T r a n s a c t i o n tx = graphDb . beginTx ( ) ;
// Utworzenie w¦zªa g r a f u . Dodanie do w¦zªów k i l k u w ª a s n o ± c i (" p r o p e r t i e s " ) .
mrAnderson = graphDb . c r e a t e N o d e ( ) ;
mrAnderson . s e t P r o p e r t y ( "name" , "Thomas Anderson " ) ;
mrAnderson . s e t P r o p e r t y ( " age " , 2 9 ) ;
Node morpheus = graphDb . c r e a t e N o d e ( ) ;
morpheus . s e t P r o p e r t y ( "name" , " Morpheus " ) ;
morpheus . s e t P r o p e r t y ( " rank " , " Captain " ) ;
morpheus . s e t P r o p e r t y ( " o c c u p a t i o n " , " T o t a l bad a s s " ) ;
// Utworzenie k r a w ¦ d z i ( r e l a c j i ) s k i e r o w a n e j mi¦dzy w¦zªami .
mrAnderson . c r e a t e R e l a t i o n s h i p T o ( morpheus , RelTypes .KNOWS) ;
Node t r i n i t y = graphDb . c r e a t e N o d e ( ) ;
t r i n i t y . s e t P r o p e r t y ( "name" , " T r i n i t y " ) ;
// Wªasno±ci (" p r o p e r t i e s ") mo»na t a k » e dodawa¢ do kraw¦dzi , co i l u s t r u j e
// p o n i » s z y kod w przypadku r e l a c j i " mrAndersonKnowsTrinity " .
morpheus . c r e a t e R e l a t i o n s h i p T o ( t r i n i t y , RelTypes .KNOWS) ;
R e l a t i o n s h i p mrAndersonKnowsTrinity
= mrAnderson . c r e a t e R e l a t i o n s h i p T o ( t r i n i t y , RelTypes .KNOWS) ;
mrAndersonKnowsTrinity . s e t P r o p e r t y ( " age " , "3 days " ) ;
t r i n i t y . c r e a t e R e l a t i o n s h i p T o ( mrAnderson , RelTypes .LOVES ) ;
Node r e a g a n = graphDb . c r e a t e N o d e ( ) ;
r e a g a n . s e t P r o p e r t y ( "name" , " Cypher " ) ;
r e a g a n . s e t P r o p e r t y ( " l a s t name" , " Reagan " ) ;
R e l a t i o n s h i p morpheusKnowsReagan
= morpheus . c r e a t e R e l a t i o n s h i p T o ( reagan , RelTypes .KNOWS) ;
morpheusKnowsReagan . s e t P r o p e r t y ( " d i s c l o s u r e " , " p u b l i c " ) ;
Node a g e n t = graphDb . c r e a t e N o d e ( ) ;
a g e n t . s e t P r o p e r t y ( "name" , " Agent Smith " ) ;
a g e n t . s e t P r o p e r t y ( " v e r s i o n " , " 1 . 0 b" ) ;
a g e n t . s e t P r o p e r t y ( " l a n g u a g e " , "C++" ) ;
17
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
R e l a t i o n s h i p reaganKnowsAgent
= r e a g a n . c r e a t e R e l a t i o n s h i p T o ( agent , RelTypes .KNOWS) ;
reaganKnowsAgent . s e t P r o p e r t y ( " d i s c l o s u r e " , " s e c r e t " ) ;
reaganKnowsAgent . s e t P r o p e r t y ( " age " , "6 months " ) ;
Node a r c h i t e c t = graphDb . c r e a t e N o d e ( ) ;
a r c h i t e c t . s e t P r o p e r t y ( "name" , "The A r c h i t e c t " ) ;
a g e n t . c r e a t e R e l a t i o n s h i p T o ( a r c h i t e c t , RelTypes .CODED_BY) ;
}
// Oznaczenie t r a n s a k c j i sukcesem i z a k o « c z e n i e j e j spowoduje wykonanie
// commit ' u do ba zy
tx . s u c c e s s ( ) ;
tx . f i n i s h ( ) ;
public void s t o p D a t a b a s e ( ) {
}
graphDb . shutdown ( ) ;
public void f i n d F r i e n d s O f A n d e r s o n ( ) {
// Utworzenie i n s t a n c j i o b i e k t u k l a s y Traverser , k t ó r y z w r ó c i
// p r z y j a c i ó ª Pana Andersona .
T r a v e r s e r f r i e n d s T r a v e r s e r = mrAnderson . t r a v e r s e (
// s t r a t e g i a p r z e s z u k i w a n i a w s z e r z :
T r a v e r s e r . Order .BREADTH_FIRST,
// p r z e g l ¡ d a n i e do ko«ca g r a f u :
S t o p E v a l u a t o r .END_OF_GRAPH,
// z w r a c a n i e w s z y s t k i c h p a s u j ¡ c y c h w¦zªów , o p r ó c z o s t a t n i e g o :
R e t u r n a b l e E v a l u a t o r .ALL_BUT_START_NODE,
// r e l a c j a , j a k a nas i n t e r e s u j e :
RelTypes .KNOWS,
// k i e r u n e k r e l a c j i :
D i r e c t i o n .OUTGOING) ;
}
// P r z e j ± c i e po w ¦ z ª a c h i w y p i s a n i e r e z u l t a t ó w
System . out . p r i n t l n ( "Mr Anderson ' s f r i e n d s : " ) ;
for ( Node f r i e n d : f r i e n d s T r a v e r s e r ) {
System . out . p r i n t f ( "At depth %d => %s%n" ,
f r i e n d s T r a v e r s e r . c u r r e n t P o s i t i o n ( ) . depth ( ) ,
f r i e n d . g e t P r o p e r t y ( "name" ) ) ;
}
public void f i n d F r i e n d s I n L o v e ( ) {
// Utworzenie i n s t a n c j i o b i e k t u k l a s y Traverser , k t ó r y z w r ó c i w ¦ z ª y
// z r e l a c j ¡ w y j ± c i o w ¡ "LOVES"
T r a v e r s e r l o v e T r a v e r s e r = mrAnderson . t r a v e r s e (
T r a v e r s e r . Order .BREADTH_FIRST, // s t r a t e g i a p r z e s z u k i w a n i a
S t o p E v a l u a t o r .END_OF_GRAPH, // p r z e s z u k i w a n i e do ko«ca g r a f u
// Z d e f i n i o w a n i e , k t ó r e w ¦ z ª y maj¡ by¢ zwracane :
new R e t u r n a b l e E v a l u a t o r ( ) {
public boolean i s R e t u r n a b l e N o d e ( T r a v e r s a l P o s i t i o n pos ) {
return pos . currentNode ( ) . h a s R e l a t i o n s h i p (
RelTypes . LOVES, D i r e c t i o n .OUTGOING ) ;
}
},
// p r z e c h o d z e n i e g r a f u n a d a l odbywa s i ¦ po
// wy±ciowych k r a w ¦ d z i a c h t yp u KNOWS
RelTypes .KNOWS,
D i r e c t i o n .OUTGOING
);
18
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
}
// P r z e j ± c i e po w ¦ z ª a c h i w y p i s a n i e r e z u l t a t ó w
System . out . p r i n t l n ( "Who i s i n l o v e ? " ) ;
for ( Node p e r s o n : l o v e T r a v e r s e r ) {
System . out . p r i n t f ( "At depth %d => %s%n" ,
l o v e T r a v e r s e r . c u r r e n t P o s i t i o n ( ) . depth ( ) ,
p e r s o n . g e t P r o p e r t y ( "name" )
);
}
public s t a t i c void main ( S t r i n g [ ] a r g s ) {
Neo4jExample exampleApp = new Neo4jExample ( ) ;
}
exampleApp . c r e a t e D a t a b a s e I n s t a n c e ( ) ;
exampleApp . f i n d F r i e n d s O f A n d e r s o n ( ) ;
System . out . p r i n t l n ( ) ;
exampleApp . f i n d F r i e n d s I n L o v e ( ) ;
exampleApp . s t o p D a t a b a s e ( ) ;
}
6
Podsumowanie.
W przypadku obszernej klasy problemów grafowe bazy danych znacznie bardziej
nadaj¡ si¦ do przechowywania danych ni» relacyjne bazy danych. Elastyczno±¢,
wydajno±¢, prostota i lepsze dopasowanie do obiektowego modelu dziedziny
to najwa»niejsze zalety GBD. Istnieje wiele zastosowa«, przy których model
grafowy jest jedynym dobrym rozwi¡zaniem.
Przy szybkim rozwoju technologii takich, jak sieci spoªeczno±ciowe, bazy
wiedzy, bazy GIS, czy sieci Semantic Web mo»na si¦ spodziewa¢, »e znaczenie
GBD b¦dzie rosªo. Tak»e w wielu zastosowaniach, w których dotychczas korzystano z tradycyjnych, relacyjnych BD, mo»na czerpa¢ znaczne korzy±ci z u»ycia
modelu grafowego.
Na rynku jest wiele dost¦pnych rozwi¡za«, zarówno komercyjnych, jak i open
source (na które warto zwróci¢ szczególn¡ uwag¦). Rozwi¡zania te, cz¦sto wyodr¦bnione z innych projektów s¡ stosunkowo mªode, ale na tyle zaawansowane,
»e nadaj¡ si¦ do zastosowa« profesjonalnych.
Literatura
[1] A Comparison of a Graph Database and a Relational Database. A Data
Provenance Perspective , Chad Vicknair, Michael Macias, Zhendong Zhao,
Xiaofei Nan, Yixin Chen, Dawn Wilkins, 2010 r., Oxford, MS, USA.
[2] http://www.infoq.com/articles/graph-nosql-neo4j
-
Graph
Databases,
NOSQL and Neo4j .
[3] http://www.techcrunchit.com/2009/10/27/neo-technology-commercializesnext-generation-graph-based-database/ - Neo Technology Commercializes
Next Generation Graph Based Database
[4] Survey of Graph Database Models , Renzo Angles, Claudio Gutierrez, Universidad de Chile, luty 2008 r.
19
[5] http://dist.neo4j.org/basic-neo4j-code-examples-2008-05-08.pdf
-
Neo.
Some code snippets, Emil Eifrem, 8.05.2008 r.
[6] http://java.dzone.com/news/nosql-graph-database-feature - NoSQL Graph
Database Comparison, Pere Urbón-bayes, 2010
20