Bazy Wykresów vs sklepy potrójne-kiedy korzystać z których?

Question

Bazy Wykresów vs sklepy potrójne-kiedy korzystać z których?

Wiem, że na Stackoverflow są podobne pytania, ale nie sądzę, aby odpowiadały na następujące pytania.

Bazy Wykresów według mojego zrozumienia przechowują dane według tego schematu:

Table/Collection 1: store nodes with UID
Table/Collection 2: store relations referencing nodes via UID

Pozwala to na przechowywanie dowolnych typów wykresów. Teraz jak rozumiem potrójne sklepy przechowują tylko potrójne:

Triple/Collection 1: store triples (2 nodes, 1 relation)

Teraz widzę następujące rozróżnienie dotyczące przypadków użycia:

bazy danych Wykresów: gdy masz znane, statyczne połączenia
Triple Stores: gdy masz luźno połączone węzły i często szukasz nowych połączeń

Jestem zdezorientowany faktem, że ludzie nie wydają się dyskutować, który z nich użyć zgodnie z tymi kryteriami. Większość artykułów, które znajduję, mówi o takich argumentach, jak szybkość lub kompatybilność. Ale czy nie jest to najistotniejszy punkt?

Odwrotnie:

wyobraź sobie, że masz wyraźnie połączony, zdefiniowany przez użytkownika Wykres. Dlaczego, u licha, chciałbyś przechowywać to tylko jako potrójne, tracąc wszystkie informacje o połączeniach? Lub konieczność implementacji niestandardowego rozwiązania przechowującego identyfikatory w potrójnym subject.
wyobraź sobie, że masz luźno zebrane węzły, które chcesz odpytywać o nieznane relacje za pomocą SPARQL. Bazy danych grafów to obsługują. Ale w tym celu muszą zbudować kolejny indeks, który zakładam i będzie wolniejszy?

Edytuj: Widzę, że "utrata informacji o połączeniach" to zły sposób, aby to ująć. Jeśli zrobisz to, co pokazano w akceptowanym odpowiedz i wstaw kilka trójek dla relacji 2 węzłów + 1, a następnie zachowaj wszystkie informacje, a konkretnie informacje o tym, jakie dokładnie węzły są połączone.

36

graph-databases neo4j sparql orientdb triplestore

Author: B M, 2015-05-11

Source

1 answers

score 54 · Accepted Answer

Główną różnicą między grafowymi bazami danych a potrójnymi magazynami jest sposób modelowania wykresu. W sklepie potrójnym (lub quad store) dane wydają się być bardzo atomowe. Chodzi mi o to, że "węzły" na wykresie są zazwyczaj prymitywnymi typami danych, takimi jak string, integer, date itp. Relacje łączą prymitywy ze sobą, a więc "jednostka dyskursu" w potrójnym sklepie jest potrójną, a nie węzłem lub relacją, zazwyczaj.

Dla kontrastu, inne bazy danych grafów są często nazywane "magazynami właściwości", ponieważ węzły są kontenerami danych, które odpowiadają obiektom w domenie. Węzeł oznacza obiekt i ma właściwości; działają one jako bogate typy danych określone przez modelarzy grafów, więcej niż tylko prymitywne typy danych. W tych grafowych bazach danych węzły i relacje są "jednostką dyskursu".

Powiedzmy, że mam osobę o imieniu "Bob", która zna "Susan". W RDF byłoby to coś takiego:

<http://example.org/person/1> :hasName "Bob".
<http://example.org/person/1> foaf:knows <http://example.org/person/2>.
<http://example.org/person/2> :hasName "Susan".

W bazie grafów takiej jak neo4j, to byłoby tak:

(a:Person {name: "Bob"})-[:KNOWS]->(b:Person {name: "Susan"})

Zauważ, że w RDF są to 3 relacje, ale tylko jedna z tych relacji wyraża semantykę między dwoma bytami. Pozostałe dwie relacje są po prostu śledzeniem właściwości pojedynczej jednostki wyższego poziomu (osoby). W neo4j jest 1 relacja między dwoma węzłami, przy czym każdy węzeł ma właściwość. W RDF masz tendencję do identyfikowania rzeczy po URI, w neo4j jest to obiekt bazy danych, który automatycznie otrzymuje identyfikator bazy danych. That ' s what I oznacza różnicę między bardziej atomowym / prymitywnym sklepem (sklepy potrójne) a bogatszym wykresem właściwości.

[7]}RDF i triple stores są głównie budowane z myślą o wyzwaniach architektonicznych, na które natkniesz się w sieci semantycznej. Na przykład przestrzeń nazw XML jest wbudowana, przy założeniu architektonicznym, że będziesz mieszał i dopasowywał użycie wielu różnych słowników i przestrzeni nazw. (To jest bardzo" semantic web " założenie). Więc w SPARQL i RDF zobaczysz zazwyczaj przynajmniej użyciexsd, rdf, i rdfs przestrzeni nazw jednocześnie, a prawdopodobnie także owl, skos, i wiele innych. SPARQL i RDF/RDFS mają również wiele hooków i funkcji, które są tam jawnie, aby rzeczy takie jak wnioskowanie ontologiczne były łatwiejsze. Będziesz miał tendencję do identyfikowania rzeczy z Uri jako sposób "przepakowywania nazw identyfikatorów", ale także dlatego, że niektórzy ludzie mogą chcieć usunąć odniesienie do URI...ponownie założeniem jest tutaj szeroki układ wymiany danych między wieloma imprezy. Magazyny właściwości są natomiast kierowane do różnych przypadków użycia, takich jak elastyczne modelowanie danych w ramach jednego modelu/przestrzeni nazw , mapowanie między obiektami i wykresy dla trwałości aplikacji korporacyjnych, szybka ewolucja i tak dalej. Będziesz miał tendencję do identyfikowania rzeczy za pomocą własnego schematu (lub wewnętrznego identyfikatora bazy danych). Auto-incrementing integer może nie być najlepszą formą ID dla dowolnego przypadkowego konsumenta w Internecie, (i na pewno nie mogą być de-odwołuje się jak Adresy URL), ale mogą nie być pierwszą myślą o wewnętrznej aplikacji firmy. Więc co jest lepsze? Bardziej atomic triple Store format, czy bogaty Wykres właściwości? Czy musisz mieszać i dopasowywać wiele różnych słowników w jednym zapytaniu lub modelu danych? Trzeba stworzyć ontologię sowy czy wnioskować? Czy musisz serializować kilka obiektów java w pamięci do bazy danych? Czy trzeba zrobić szybkie przemierzanie długich ścieżek? Tego typu pytania kierują Twoją wybór.

Wykresy są wykresami, oba robią wykresy, więc nie sądzę, że jest duża różnica w zakresie tego, co mogą reprezentować, lub jak można myśleć o problemie w "terminach grafowych". Różnice sprowadzają się do architektury pod maską i tego, jakich przypadków użycia potrzebujesz. Nie powiem ci, że jedno jest lepsze od drugiego, ale wybieraj mądrze.