Baza danych dokumentów ArangoDB, a także baza danych wykresów? Jak to jest możliwe?

Question

Ktoś może wyjaśnić, jak działa baza danych dokumentów jako baza danych wykresów?

Jaka jest różnica między ArangoDB a Neo4j?

Answer 1

Nota prawna: Jestem Max z ArangoDB, jednego z głównych programistów.

Po pierwsze, dłuższa dyskusja na ten temat i inne powiązane pytania można znaleźć w moim artykule Graphs in data modeling - is the emperor naked?, ale postaram się tutaj krótko odpowiedzieć na oba pytania.

(1) Przechowywanie wykresu w magazynie dokumentów jest stosunkowo łatwe (jak to jest w relacyjnej bazie danych), można na przykład po prostu przechowywać dokument dla każdego wierzchołka w "kolekcji wierzchołków" i dokument dla każdego krawędź w "kolekcji krawędzi". Trzeba tylko upewnić się, że każda krawędź przechowuje, z którego wierzchołka pochodzi i do którego wierzchołka się ono trafia. W ArangoDB używamy atrybutu _from i _to w dokumencie krawędziowym.

Jednak kluczową możliwością dla bazy danych wykresów jest to, że musi skutecznie odpowiadać na zapytania dotyczące wykresów. Typowe zapytania do wykresów to (a) "czym są sąsiedzi wierzchołka na wykresie?" lub (b) "jaka jest najkrótsza droga od wierzchołka A do wierzchołka B na wykresie?" lub (c) "podaj mi wszystkie wierzchołki, które mogę osiągnąć od wierzchołka A, podążając za krawędziami". Podczas gdy (a) po prostu potrzebny jest dobry wskaźnik na zbiorze brzegów, (b) i (c) obejmuje a priori nieznaną liczbę kroków na wykresie. W związku z tym (b) i (c) nie można zrobić wydajnie z tradycyjnymi językami zapytań baz danych, takimi jak SQL, tylko dlatego, że wymagałyby dużej ilości komunikacji między klientem a serwerem, lub co najmniej bardzo skomplikowanego wyrażenia ze zmienną liczbą dołącza. Wzywam kwerendy takie jak (b) i (c), dlatego "graficzne", nie definiując tego rygorystycznie.

Moja krótka odpowiedź brzmi "w jaki sposób magazyn dokumentów może być graficzną bazą danych?". to: Zapisz wykres jak wyżej i zaimplementuj zapytania graficzne na serwerze bazy danych, dostępne z języka zapytań w składnicy danych. Zasadniczo można to zrobić za pomocą relacyjnej bazy danych i pewnych znacznych rozszerzeń SQL.

Dzięki ArangoDB udało nam się połączyć dokument, wykres i funkcje klucz/wartość w jednym, spójnym języku zapytań. Dlatego nazywamy ArangoDB "wielomodelową bazą danych", ponieważ łączy ona te trzy modele danych bezproblemowo. Możesz nawet mieszać modele danych w jednym zapytaniu!

Prowadzi to do mojego odpowiedź na pytanie (2), który jest oczywiście nieco stronniczy:

W porównaniu do ArangoDB, która jest rozproszona baza danych multi-Model w powyższym sensie Neo4j to klasyczny wykres Baza danych. Przechowuje wykresy, umożliwia ich zapytanie za pomocą "zapytań graficznych" i ma silnik pamięci i zapytań, który jest zoptymalizowany pod kątem tego. Neo4j jest szczególnie dobry w dopasowywaniu ścieżek przy użyciu wbudowanego cyphera języka zapytań. Pozwala na dołączanie właściwości do wierzchołków i krawędzi, ale nie jest to pełnowartościowy magazyn dokumentów. Nie jest zoptymalizowany pod kątem obsługi zapytań do dokumentów przy użyciu wielu indeksów dodatkowych i nie robi złączy. Co więcej, Neo4j nie jest dystrybuowany.

Neo4j jest napisany w Javie, ArangoDB jest napisany w C++ i osadza wersję V8 Google'a, by uruchamiać rozszerzenia JavaScript.

Aby porównać wyniki, patrz this post.