Porównanie relacyjnych baz danych i grafowych baz danych

Czy ktoś może mi wyjaśnić zalety i wady bazy danych relacji, takiej jak MySQL, w porównaniu z bazą danych grafów, taką jak Neo4j?

W SQL masz wiele tabel z różnymi identyfikatorami, które je łączą. Następnie musisz dołączyć, aby połączyć stoły. Z punktu widzenia początkującego, dlaczego miałbyś projektować bazę danych tak, aby wymagała łączenia, zamiast mieć połączenia jawne jako krawędzie od początku, jak w przypadku bazy danych grafów. Koncepcyjnie nie miałoby to sensu dla nowicjusza. Przypuszczalnie jest ku temu bardzo techniczny, ale niepojęciowy powód?

W rzeczywistości za obydwoma stylami kryje się rozumowanie koncepcyjne. Wikipedia na temat modelu relacyjnego i baz danych wykresów daje dobry przegląd tego.

Podstawowa różnica polega na tym, że w grafowej bazie danych relacje są przechowywane na poziomie pojedynczego rekordu, podczas gdy w relacyjnej bazie danych struktura jest definiowana na wyższym poziomie (definicje tabel).

Ma to ważne konsekwencje:

• Relacyjna baza danych jest znacznie szybsza, gdy działa na ogromnej liczbie rekordów. W grafowej bazie danych każdy rekord musi zostać zbadany indywidualnie podczas zapytania w celu określenia struktury danych, podczas gdy w relacyjnej bazie danych jest to znane z góry.
• Relacyjne bazy danych zajmują mniej miejsca w pamięci, ponieważ nie muszą przechowywać wszystkich tych relacji.

Przechowywanie wszystkich relacji na poziomie rekordów indywidualnych ma sens tylko wtedy, gdy w relacjach będzie dużo zmienności; w przeciwnym razie po prostu powielasz w kółko te same rzeczy. Oznacza to, że graficzne bazy danych są dobrze dostosowane do nieregularnych, złożonych struktur. Jednak w rzeczywistości większość baz danych wymaga regularnych, stosunkowo prostych struktur. Dlatego przeważają relacyjne bazy danych.

Kluczowa różnica między wykresem a relacyjną bazą danych polega na tym, że relacyjne bazy danych współpracują z zestawami, a grafowe bazy danych ze ścieżkami.

Przejawia się to w nieoczekiwany i niepomocny sposób dla użytkownika RDBMS. Na przykład przy próbie emulacji operacji na ścieżkach (np. Przyjaciół znajomych) poprzez rekursywne dołączanie do relacyjnej bazy danych, opóźnienie zapytań rośnie nieprzewidywalnie i masowo, podobnie jak użycie pamięci, nie wspominając o tym, że utrudnia SQL wyrażanie tego rodzaju operacji. Więcej danych oznacza wolniej w bazie danych opartej na zestawie, nawet jeśli możesz opóźnić ból dzięki rozsądnemu indeksowaniu.

Jak zasugerował Dan1111, większość grafowych baz danych nie cierpi z powodu tego rodzaju bólu złączeń, ponieważ wyrażają one relacje na podstawowym poziomie. Oznacza to, że relacje istnieją fizycznie na dysku i są nazywane, kierowane i same mogą być ozdobione właściwościami (nazywa się to modelem wykresu właściwości, patrz: https://github.com/tinkerpop/blueprints/wiki/Property-Graph -Model ). Oznacza to, że jeśli zdecydujesz się, możesz przyjrzeć się relacjom na dysku i zobaczyć, jak „łączą się” one z jednostkami. Relacje są zatem jednostkami pierwszej klasy w bazie danych wykresów i są semantycznie znacznie silniejsze niż te domniemane relacje reifikowane w czasie wykonywania w magazynie relacyjnym.

Więc dlaczego powinno Cię to obchodzić? Z dwóch powodów:

1. Grafowe bazy danych są znacznie szybsze niż relacyjne bazy danych dla połączonych danych - siła modelu bazowego. Konsekwencją tego jest to, że opóźnienie zapytań w bazie danych wykresów jest proporcjonalne do tego, jaką część wykresu wybierzesz do eksploracji w zapytaniu, a nie jest proporcjonalne do ilości przechowywanych danych, co powoduje rozbrojenie bomby łączenia .
2. Grafowe bazy danych sprawiają, że modelowanie i wykonywanie zapytań jest znacznie przyjemniejsze, co oznacza szybszy rozwój i mniej momentów WTF. Na przykład wyrażanie przyjaciela przyjaciela dla typowej sieci społecznościowej w języku zapytań Cypher Neo4j jest po prostu MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

Dan1111 udzielił już odpowiedzi oznaczonej jako poprawna. Na marginesie warto zwrócić uwagę na kilka dodatkowych punktów.

Po pierwsze, w prawie każdej implementacji grafowych baz danych rekordy są „przypinane”, ponieważ istnieje nieznana liczba wskaźników wskazujących na rekord w jego bieżącej lokalizacji. Oznacza to, że rekordu nie można przetasować do nowej lokalizacji bez pozostawienia adresu do przekazywania dalej w starej lokalizacji lub bez łamania nieznanej liczby wskaźników.

Teoretycznie można by potasować wszystkie rekordy na raz i znaleźć sposób na zlokalizowanie i naprawienie wszystkich wskaźników. W praktyce jest to operacja, która może zająć tygodnie na dużej bazie danych grafów, w tym czasie baza danych musiałaby być wyłączona. To po prostu niewykonalne.

Z kolei w relacyjnej bazie danych rekordy można przetasować na dość dużą skalę, a jedyne, co należy zrobić, to odbudować wszelkie indeksy, na które miało to wpływ. Jest to dość duża operacja, ale nie jest tak duża, jak odpowiednik dla bazy danych wykresów.

Drugą kwestią, na którą warto zwrócić uwagę, jest to, że światową sieć można postrzegać jako gigantyczną bazę danych grafów. Strony internetowe zawierają hiperłącza, a hiperłącza odsyłają między innymi do innych stron internetowych. Odniesienie to adresy URL, które działają jak wskaźniki.

Gdy strona internetowa zostanie przeniesiona do innego adresu URL bez pozostawienia adresu do przekazywania dalej w starym adresie URL, nieznana liczba hiperłączy zostanie uszkodzona. Te zepsute linki powodują następnie przerażający komunikat „Błąd 404: nie znaleziono strony”, który zakłóca przyjemność tak wielu internautów.

Korzystając z relacyjnej bazy danych, możemy modelować i wykonywać zapytania dotyczące wykresów przy użyciu kluczy obcych i łączeń wewnętrznych. Tylko dlatego, że RDBMS zawierają słowo relacyjny, nie oznacza, że ​​dobrze radzą sobie z relacjami. Słowo relacyjny w RDBMS wywodzi się z algebry relacyjnej, a nie z relacji. W RDBMS sam związek nie istnieje jako obiekt sam w sobie. Musi być albo jawnie reprezentowany jako klucz obcy, albo niejawnie jako wartość w tabeli połączeń (w przypadku korzystania z ogólnego / uniwersalnego podejścia do modelowania). Powiązania między zestawami danych są przechowywane w samych danych.

Im bardziej zwiększamy głębokość wyszukiwania w relacyjnej bazie danych, tym więcej łączeń samoistnych musimy wykonać i tym bardziej spada wydajność zapytań. Im głębiej wchodzimy w naszą hierarchię, tym więcej tabel musimy dołączyć i tym wolniejsze jest nasze zapytanie. Matematycznie koszt rośnie wykładniczo w relacyjnej bazie danych. Innymi słowy, im bardziej złożone są nasze zapytania i relacje, tym więcej korzystamy z wykresu w porównaniu z relacyjną bazą danych. Podczas nawigacji po wykresie nie mamy problemów z wydajnością w bazie danych wykresów. Dzieje się tak, ponieważ baza danych wykresów przechowuje relacje jako oddzielne obiekty. Jednak lepsza wydajność odczytu odbywa się kosztem wolniejszych zapisów.

W niektórych sytuacjach łatwiej jest zmienić model danych w grafowej bazie danych niż w RDBMS, np. W RDBMS, jeśli zmienię relację między tabelami z 1: n na m: n Muszę zastosować DDL z potencjalnym przestojem.

RDBMS ma z drugiej strony zalety w innych obszarach, np. Agregowanie danych lub kontrola wersji danych ze znacznikiem czasu.

Omówię niektóre inne zalety i wady w moim wpisie na blogu dotyczącym grafowych baz danych do hurtowni danych

Chociaż model relacyjny może z łatwością reprezentować dane zawarte w modelu grafowym, w praktyce napotykamy dwa istotne problemy:

1. W języku SQL brakuje składni umożliwiającej łatwe przechodzenie przez wykresy, szczególnie w przypadku przemierzania, w przypadku których głębokość jest nieznana lub nieograniczona. Na przykład użycie SQL do określenia znajomych twoich znajomych jest dość łatwe, ale trudno jest rozwiązać problem „stopni separacji”.
2. Wydajność szybko spada, gdy przeglądamy wykres. Każdy poziom przemierzania znacząco wydłuża czas odpowiedzi na zapytanie.

Odniesienie: Bazy danych nowej generacji

Graficzne bazy danych są warte zbadania pod kątem przypadków użycia, w których się wyróżniają, ale miałem powód, aby kwestionować niektóre stwierdzenia w powyższych odpowiedziach. W szczególności:

Relacyjna baza danych jest znacznie szybsza, gdy działa na ogromnej liczbie rekordów (pierwszy punktor dan1111)

Grafowe bazy danych są znacznie szybsze niż relacyjne bazy danych dla połączonych danych - siła modelu bazowego. Konsekwencją tego jest to, że opóźnienie zapytań w bazie danych wykresów jest proporcjonalne do tego, jaką część wykresu wybierzesz do eksploracji w zapytaniu, a nie jest proporcjonalne do ilości przechowywanych danych, co powoduje rozbrojenie bomby łączenia. (Pierwszy wypunkt Jima Webbera)

Innymi słowy, im bardziej złożone są nasze zapytania i relacje, tym więcej korzystamy z wykresu w porównaniu z relacyjną bazą danych. (Drugi akapit Uli Bethke)

Chociaż te twierdzenia mogą mieć wartość, jeszcze nie znalazłem sposobu, aby dostosować mój konkretny przypadek użycia do nich. Odniesienie: Baza danych wykresów lub relacyjna baza danych Rozszerzenia wspólnych tabel: Porównanie wydajności zapytań dotyczących wykresów acyklicznych

Relacyjne bazy danych znacznie wydajniej przechowują dane tabelaryczne. Pomimo słowa „relacyjne” w nazwie, relacyjne bazy danych są znacznie mniej skuteczne w przechowywaniu lub wyrażaniu relacji między przechowywanymi elementami danych. Termin „relacyjny” w relacyjnych bazach danych odnosi się bardziej do powiązanych kolumn w tabeli, a nie do informacji w różnych tabelach. Istnieją relacje między kolumnami w celu obsługi operacji na zbiorach. Ponieważ baza danych rośnie w milionach lub miliardach rekordów, pobieranie danych z relacyjnych baz danych staje się niezwykle powolne.

W przeciwieństwie do relacyjnej bazy danych, baza danych wykresów jest zbudowana całkowicie wokół relacji danych. Grafowe bazy danych traktują relacje nie jako strukturę schematu, ale jako dane, podobnie jak inne wartości. Pobieranie danych z graficznych baz danych jest bardzo szybkie. Z punktu widzenia relacyjnej bazy danych można o tym myśleć jako o wstępnej materializacji JOIN raz w czasie wstawiania, zamiast obliczać je dla każdego zapytania. Ponieważ struktura danych opiera się całkowicie na relacjach między danymi, wydajność zapytań w czasie rzeczywistym może być osiągnięta bez względu na to, jak duży lub połączony jest zbiór danych. Grafowe bazy danych zajmują więcej miejsca w pamięci niż relacyjna baza danych.