Baza wykresów - Graph database

W obliczeniowej , A bazie wykres ( GDB ) jest bazą danych , która używa wykres struktur na semantyczne zapytań z węzłów , krawędziach i właściwości reprezentowania i przechowywania danych. Kluczową koncepcją systemu jest graf (lub krawędź lub relacja ). Wykres wiąże elementy danych w sklepie z kolekcją węzłów i krawędzi, które reprezentują relacje między węzłami. Relacje umożliwiają bezpośrednie łączenie danych w sklepie i, w wielu przypadkach, pobieranie za pomocą jednej operacji. Grafowe bazy danych mają priorytet relacji między danymi. Wysyłanie zapytań o relacje jest szybkie, ponieważ są one stale przechowywane w bazie danych. Relacje można intuicyjnie wizualizować za pomocą grafowych baz danych, co czyni je przydatnymi w przypadku silnie powiązanych ze sobą danych.

Grafowe bazy danych są powszechnie określane jako baza danych NoSQL - co oznacza, że ​​podejście do przechowywania, odpytywania i opisywania tych struktur danych znacznie różni się od tradycyjnej relacyjnej bazy danych . Podczas gdy model wykresu wyraźnie określa zależności między węzłami danych, model relacyjny i inne modele baz danych NoSQL łączą dane za pomocą niejawnych połączeń. Innymi słowy, relacje są pierwszorzędnymi obywatelami w grafowej bazie danych i można je oznaczyć etykietą, skierować i nadawać im właściwości. Jest to porównywane z podejściami relacyjnymi, w których te relacje są implikowane i muszą być reifikowane w czasie wykonywania. Grafowe bazy danych są podobne do baz danych modeli sieciowych z lat 70. XX wieku, ponieważ obie reprezentują ogólne grafy, ale bazy danych modeli sieciowych działają na niższym poziomie abstrakcji i nie umożliwiają łatwego przechodzenia przez łańcuch krawędzi.

Podstawowy mechanizm przechowywania grafowych baz danych może się różnić. Niektóre zależą od silnika relacyjnego i „przechowują” dane grafowe w tabeli (chociaż tabela jest elementem logicznym, dlatego takie podejście narzuca kolejny poziom abstrakcji pomiędzy grafową bazą danych, systemem zarządzania grafową bazą danych a urządzeniami fizycznymi, na których dane jest faktycznie przechowywany). Inni używają magazynu klucz-wartość lub bazy danych zorientowanej na dokumenty do przechowywania, co czyni je z natury strukturami NoSQL.

Od 2021 roku żaden uniwersalny język zapytań grafowych nie został przyjęty w taki sam sposób, jak SQL w przypadku relacyjnych baz danych, a istnieje wiele różnych systemów, najczęściej ściśle powiązanych z jednym produktem. Niektóre wczesne próby standaryzacji doprowadziły do ​​powstania języków zapytań od wielu dostawców, takich jak Gremlin , SPARQL i Cypher . We wrześniu 2019 r. członkowie Wspólnego Komitetu Technicznego ISO/IEC 1 (ISO/IEC JTC 1) zatwierdzili propozycję projektu stworzenia nowego standardowego języka zapytań grafowych (ISO/IEC 39075 Information Technology — Database Languages ​​— GQL). GQL ma być deklaratywnym językiem zapytań do bazy danych, takim jak SQL. Oprócz posiadania interfejsów języka zapytań, niektóre bazy danych wykresów są dostępne za pośrednictwem interfejsów programowania aplikacji (API).

Grafowe bazy danych różnią się od grafowych silników obliczeniowych. Grafowe bazy danych to technologie będące translacją relacyjnych baz danych przetwarzania transakcji online (OLTP). Z drugiej strony, grafowe silniki obliczeniowe są używane w przetwarzaniu analitycznym online (OLAP) do analizy zbiorczej. Bazy danych grafowych przyciągnęły znaczną uwagę w 2000 roku ze względu na sukcesy dużych korporacji technologicznych w korzystaniu z własnych grafowych baz danych, a także wprowadzenie grafowych baz danych o otwartym kodzie źródłowym .

Jedno z badań wykazało, że RDBMS był „porównywalny” pod względem wydajności z istniejącymi silnikami analizy wykresów podczas wykonywania zapytań o wykresy.

Historia

W połowie lat sześćdziesiątych nawigacyjne bazy danych, takie jak IMS IBM , obsługiwały struktury drzewiaste w swoim modelu hierarchicznym , ale ścisłą strukturę drzewa można było obejść za pomocą rekordów wirtualnych.

Struktury grafowe mogły być reprezentowane w bazach danych modeli sieciowych z późnych lat sześćdziesiątych. CODASYL , który zdefiniował COBOL w 1959, zdefiniował Network Database Language w 1969.

Wykresy oznaczone etykietami mogą być reprezentowane w bazach danych wykresów z połowy lat 80., takich jak Logiczny Model Danych.

Bazy danych obiektów komercyjnych (ODBMS) pojawiły się na początku lat dziewięćdziesiątych. W 2000 roku Object Data Management Group opublikowała standardowy język do definiowania struktur obiektów i relacji (grafów) w swojej publikacji ODMG'93.

Kilka ulepszeń w grafowych bazach danych pojawiło się na początku lat 90., a pod koniec lat 90. nastąpiło przyspieszenie wraz z próbami indeksowania stron internetowych.

Od połowy do końca XXI wieku dostępne stały się komercyjne bazy danych grafów z gwarancjami ACID, takie jak Neo4j i Oracle Spatial and Graph .

W 2010 roku dostępne stały się komercyjne bazy danych grafów ACID, które można było skalować w poziomie . Ponadto SAP HANA wprowadził do baz danych wykresów technologie in-memory i kolumny . Również w latach 2010 dostępne stały się wielomodelowe bazy danych obsługujące modele wykresów (oraz inne modele, takie jak relacyjna baza danych lub baza danych zorientowana na dokumenty ), takie jak OrientDB , ArangoDB i MarkLogic (od wersji 7.0). W tym czasie, bazy danych wykres różnych rodzajów stały się szczególnie popularne społecznej analizy sieci wraz z pojawieniem się firm w mediach społecznościowych.

Tło

Bazy danych grafów wykorzystują węzły, właściwości i krawędzie.

Graficzne bazy danych przedstawiają dane tak, jak są one przeglądane koncepcyjnie. Odbywa się to poprzez przesyłanie danych do węzłów i ich relacji do krawędzi.

Baza danych grafów to baza danych oparta na teorii grafów . Składa się ze zbioru obiektów, który może być węzłem lub krawędzią.

• Węzły reprezentują jednostki lub instancje, takie jak ludzie, firmy, konta lub jakikolwiek inny element, który ma być śledzony. Są mniej więcej odpowiednikiem rekordu, relacji lub wiersza w relacyjnej bazie danych lub dokumentu w bazie danych magazynu dokumentów.
• Krawędzie , zwane również grafami lub relacjami , to linie łączące węzły z innymi węzłami; reprezentowanie relacji między nimi. Podczas badania połączeń i wzajemnych połączeń węzłów, właściwości i krawędzi pojawiają się znaczące wzorce. Krawędzie mogą być skierowane lub nieskierowane. W grafie nieskierowanym krawędź łącząca dwa węzły ma jedno znaczenie. W grafie skierowanym krawędzie łączące dwa różne węzły mają różne znaczenia, w zależności od ich kierunku. Krawędzie są kluczowym pojęciem w grafowych bazach danych, reprezentującym abstrakcję, która nie jest bezpośrednio zaimplementowana w modelu relacyjnym lub modelu magazynu dokumentów .
• Właściwości to informacje związane z węzłami. Na przykład, jeśli Wikipedia byłaby jednym z węzłów, może być powiązana z właściwościami takimi jak strona internetowa , materiał referencyjny lub słowa zaczynające się na literę w , w zależności od tego, które aspekty Wikipedii są związane z daną bazą danych.

Modele wykresów

Wykres oznakowanych właściwości

Model wykresu właściwości etykietowanych jest reprezentowany przez zestaw węzłów, relacji, właściwości i etykiet. Oba węzły danych i ich relacje są nazwane i mogą przechowywać właściwości reprezentowane przez pary klucz-wartość . Węzły można oznaczyć etykietami do grupowania. Krawędzie reprezentujące relacje mają dwie cechy: zawsze mają węzeł początkowy i końcowy oraz są skierowane; uczynienie grafu grafem skierowanym . Relacje mogą również mieć właściwości. Jest to przydatne przy dostarczaniu dodatkowych metadanych i semantyki do relacji węzłów. Bezpośrednie przechowywanie relacji umożliwia ciągłe przechodzenie w czasie .

Ramy opisu zasobów (RDF)

Przykładowy wykres RDF

W modelu grafu RDF każda dodana informacja jest reprezentowana przez oddzielny węzeł. Na przykład wyobraźmy sobie scenariusz, w którym użytkownik musi dodać właściwość nazwy dla osoby reprezentowanej na wykresie jako odrębny węzeł. W modelu z grafem własności etykietowanej byłoby to zrobione przez dodanie własności name w węźle osoby. Jednak w RDF użytkownik musi dodać oddzielny węzeł zwany hasNamełączącym go z pierwotnym węzłem osoby. W szczególności model grafu RDF składa się z węzłów i łuków. Notacja grafu RDF lub instrukcja jest reprezentowana przez: węzeł dla podmiotu, węzeł dla obiektu i łuk dla predykatu. Węzeł może być pusty, może być literałem i/lub może być identyfikowany przez identyfikator URI . Łuk może być również identyfikowany przez identyfikator URI. Literał węzła może być dwojakiego rodzaju: zwykły (bez typu) i wpisany. Zwykły literał ma formę leksykalną i opcjonalnie znacznik języka. Literał typowany składa się z ciągu znaków z identyfikatorem URI, który identyfikuje określony typ danych. Pusty węzeł może być użyty do dokładnego zilustrowania stanu danych, gdy dane nie mają identyfikatora URI .

Nieruchomości

Grafowe bazy danych są potężnym narzędziem dla zapytań grafowych. Na przykład obliczanie najkrótszej ścieżki między dwoma węzłami na wykresie. Inne zapytania podobne do wykresów mogą być wykonywane w bazie danych wykresów w naturalny sposób (na przykład obliczenia średnicy wykresu lub wykrywanie społeczności).

Wykresy są elastyczne, co oznacza, że ​​pozwalają użytkownikowi wstawiać nowe dane do istniejącego wykresu bez utraty funkcjonalności aplikacji. Projektant bazy danych nie musi planować obszernych szczegółów dotyczących przyszłych przypadków użycia bazy danych.

Składowanie

Podstawowy mechanizm przechowywania grafowych baz danych może się różnić. Niektóre zależą od silnika relacyjnego i „przechowują” dane grafowe w tabeli (chociaż tabela jest elementem logicznym, dlatego takie podejście narzuca kolejny poziom abstrakcji pomiędzy grafową bazą danych, systemem zarządzania grafową bazą danych a urządzeniami fizycznymi, na których dane jest faktycznie przechowywany). Inni używają magazynu klucz-wartość lub bazy danych zorientowanej na dokumenty do przechowywania, co czyni je z natury strukturami NoSQL . Węzeł byłby reprezentowany jak każdy inny magazyn dokumentów, ale krawędzie łączące dwa różne węzły posiadają specjalne atrybuty wewnątrz dokumentu; atrybuty _from i _to.

Sąsiedztwo bez indeksów

Wydajność wyszukiwania danych zależy od szybkości dostępu z jednego węzła do drugiego. Ponieważ sąsiedztwo bez indeksów wymusza na węzłach bezpośrednie fizyczne adresy pamięci RAM i fizyczne wskazywanie na inne sąsiednie węzły, skutkuje to szybkim pobieraniem. Natywny system grafów z sąsiedztwem bez indeksów nie musi przechodzić przez żaden inny typ struktur danych, aby znaleźć powiązania między węzłami. Bezpośrednio powiązane węzły w grafie są przechowywane w pamięci podręcznej po pobraniu jednego z węzłów, dzięki czemu wyszukiwanie danych jest jeszcze szybsze niż przy pierwszym pobraniu węzła przez użytkownika. Jednak taka przewaga ma swoją cenę. Sąsiedztwo bez indeksu obniża wydajność zapytań, które nie korzystają z przechodzenia przez wykres . Natywne grafowe bazy danych wykorzystują bezindeksowe sąsiedztwo do przetwarzania operacji CRUD na przechowywanych danych.

Typy wykresów

Istnieje wiele rodzajów wykresów, które można podzielić na kategorie. Gartner proponuje pięć szerokich kategorii wykresów:

• Wykres społeczny : dotyczy powiązań między ludźmi; przykłady obejmują Facebook , Twitter i ideę sześciu stopni separacji
• Wykres intencji: dotyczy rozumowania i motywacji.
• Wykres zużycia: znany również jako „wykres płatności”, wykres zużycia jest intensywnie używany w branży detalicznej. Firmy e-commerce, takie jak Amazon, eBay i Walmart, wykorzystują wykresy konsumpcji do śledzenia konsumpcji poszczególnych klientów.
• Wykres zainteresowań : przedstawia zainteresowania danej osoby i często jest uzupełniany wykresem społecznościowym. Ma potencjał, aby podążać za poprzednią rewolucją organizacji sieci, mapując sieć według zainteresowań, a nie indeksując strony internetowe.
• Wykres mobilny: jest zbudowany na podstawie danych mobilnych. Dane mobilne w przyszłości mogą obejmować dane z sieci, aplikacji, portfeli cyfrowych, GPS i urządzeń Internetu rzeczy (IoT).

Porównanie z relacyjnymi bazami danych

Od czasu artykułu Edgara F. Codda z 1970 roku na temat modelu relacyjnego , relacyjne bazy danych są de facto standardem branżowym dla systemów przechowywania danych na dużą skalę. Modele relacyjne wymagają ścisłego schematu i normalizacji danych, które rozdzielają dane na wiele tabel i usuwają zduplikowane dane w bazie danych. Dane są normalizowane w celu zachowania spójności danych i obsługi transakcji ACID . Nakłada to jednak ograniczenia na to, w jaki sposób można odpytywać relacje.

Jedną z motywacji projektowych modelu relacyjnego było uzyskanie szybkiego dostępu wiersz po wierszu. Problemy pojawiają się, gdy istnieje potrzeba tworzenia złożonych relacji między przechowywanymi danymi. Chociaż relacje można analizować za pomocą modelu relacyjnego, wymagane są złożone zapytania wykonujące wiele operacji sprzężenia na wielu różnych atrybutach w kilku tabelach. Podczas pracy z modelami relacyjnymi należy również wziąć pod uwagę ograniczenia klucza obcego podczas pobierania relacji, co powoduje dodatkowe obciążenie.

W porównaniu z relacyjnymi bazami danych grafowe bazy danych są często szybsze w przypadku asocjacyjnych zestawów danych i bardziej bezpośrednio odwzorowują strukturę aplikacji zorientowanych obiektowo . Można je bardziej naturalnie skalować do dużych zestawów danych, ponieważ zazwyczaj nie wymagają operacji łączenia , które często mogą być kosztowne. Ponieważ w mniejszym stopniu zależą od sztywnego schematu, są reklamowane jako bardziej odpowiednie do zarządzania doraźnymi i zmieniającymi się danymi przy zmieniających się schematach.

Z drugiej strony, systemy zarządzania relacyjnymi bazami danych zazwyczaj szybciej wykonują tę samą operację na dużej liczbie elementów danych, co pozwala na manipulowanie danymi w ich naturalnej strukturze. Pomimo zalet grafowych baz danych i niedawnej popularności nad relacyjnymi bazami danych, zaleca się, aby sam model grafowy nie był jedynym powodem zastąpienia istniejącej relacyjnej bazy danych. Wykresowa baza danych może stać się istotna, jeśli istnieją dowody na poprawę wydajności o rzędy wielkości i mniejsze opóźnienie.

Przykłady

Model relacyjny gromadzi dane razem, wykorzystując informacje zawarte w danych. Na przykład można wyszukać wszystkich „użytkowników”, których numer telefonu zawiera numer kierunkowy „311”. Można to zrobić, przeszukując wybrane magazyny danych lub tabele , szukając w wybranych polach numeru telefonu ciągu „311”. W przypadku dużych tabel może to być proces czasochłonny, dlatego relacyjne bazy danych oferują indeksy , które umożliwiają przechowywanie danych w mniejszej podtabeli, zawierającej tylko wybrane dane i unikalny klucz (lub klucz podstawowy) rekordu. Jeśli numery telefonów są indeksowane, to samo wyszukiwanie nastąpi w mniejszej tabeli indeksów, gromadząc klucze pasujących rekordów, a następnie szukając rekordów z tymi kluczami w głównej tabeli danych. Zwykle tabela jest przechowywana w sposób, który umożliwia bardzo szybkie wyszukiwanie za pomocą klucza.

Relacyjne bazy danych z natury nie zawierają idei stałych relacji między rekordami. Zamiast tego powiązane dane są połączone ze sobą poprzez przechowywanie unikatowego klucza jednego rekordu w danych innego rekordu. Na przykład tabela zawierająca adresy e-mail użytkowników może zawierać element danych o nazwie userpk, który zawiera klucz podstawowy rekordu użytkownika, z którym jest powiązany. Aby powiązać użytkowników i ich adresy e-mail, system najpierw wyszukuje wybrane klucze podstawowe rekordów użytkowników, szuka tych kluczy w userpkkolumnie w tabeli e-mail (lub, co bardziej prawdopodobne, ich indeksie), wyodrębnia dane e-mail, a następnie łączy rekordy użytkownika i wiadomości e-mail, aby utworzyć rekordy złożone zawierające wszystkie wybrane dane. Ta operacja, zwana złączeniem , może być kosztowna obliczeniowo. W zależności od złożoności zapytania, liczby złączeń i indeksowania różnych kluczy, system może być zmuszony do przeszukiwania wielu tabel i indeksów, a następnie sortowania ich wszystkich, aby dopasować je do siebie.

W przeciwieństwie do tego, grafowe bazy danych bezpośrednio przechowują relacje między rekordami. Zamiast wyszukiwania adresu e-mail poprzez wyszukanie klucza użytkownika w userpkkolumnie, rekord użytkownika zawiera wskaźnik, który bezpośrednio odwołuje się do rekordu adresu e-mail. Oznacza to, że po wybraniu użytkownika wskaźnik można śledzić bezpośrednio do rekordów wiadomości e-mail, nie ma potrzeby przeszukiwania tabeli wiadomości e-mail w celu znalezienia pasujących rekordów. Może to wyeliminować kosztowne operacje łączenia. Na przykład, jeśli wyszukuje się wszystkie adresy e-mail dla użytkowników z numeru kierunkowego „311”, wyszukiwarka najpierw przeprowadzi konwencjonalne wyszukiwanie, aby znaleźć użytkowników w „311”, a następnie pobierze adresy e-mail, korzystając z linków znalezionych w te zapisy. Relacyjna baza danych najpierw znalazłaby wszystkich użytkowników w „311”, wyodrębniłaby listę kluczy podstawowych, przeprowadziła kolejne wyszukiwanie dowolnych rekordów w tabeli poczty e-mail z tymi kluczami podstawowymi i połączyła pasujące rekordy ze sobą. W przypadku tego typu typowych operacji bazy danych grafów byłyby teoretycznie szybsze.

Prawdziwa wartość podejścia opartego na wykresie staje się oczywista, gdy przeprowadza się wyszukiwania na więcej niż jednym poziomie. Rozważmy na przykład wyszukiwanie użytkowników, którzy mają „subskrybenci” (tabelę łączącą użytkowników z innymi użytkownikami) w numerze kierunkowym „311”. W tym przypadku relacyjna baza danych musi najpierw wyszukać wszystkich użytkowników z numerem kierunkowym „311”, następnie przeszukać tabelę subskrybentów pod kątem któregokolwiek z tych użytkowników, a na końcu przeszukać tabelę użytkowników, aby pobrać pasujących użytkowników. W przeciwieństwie do tego, graficzna baza danych szukałaby wszystkich użytkowników w „311”, a następnie podążałaby za linkami zwrotnymi przez relację subskrybenta, aby znaleźć użytkowników subskrybujących. Pozwala to uniknąć kilku wyszukiwań, wyszukiwań i użycia pamięci związanej z przechowywaniem wszystkich danych tymczasowych z wielu rekordów potrzebnych do skonstruowania danych wyjściowych. Z punktu widzenia notacji duże O to zapytanie byłoby czasowe – tj. proporcjonalne do logarytmu wielkości danych. Natomiast wersja relacyjna to wiele wyszukiwań plus czas potrzebny na połączenie wszystkich rekordów danych. ${\ Displaystyle O (\ log n) + O (1)}$${\ Displaystyle O (\ log n)}$

Względna przewaga wyszukiwania wykresów rośnie wraz ze złożonością zapytania. Na przykład ktoś może chcieć poznać „ten film o łodziach podwodnych z aktorem, który grał w tym filmie z innym aktorem, który grał główną rolę w Przeminęło z wiatrem ”. Wymaga to najpierw od systemu znalezienia aktorów w Przeminęło z wiatrem , wszystkich filmów, w których grali, wszystkich aktorów we wszystkich filmach, którzy nie byli głównymi bohaterami w Przeminęło z wiatrem , a następnie znalezienia wszystkich filmów byli w środku, w końcu przefiltrowali tę listę do tych z opisami zawierającymi „okręt podwodny”. W relacyjnej bazie danych wymagałoby to kilku oddzielnych przeszukań w tabelach filmów i aktorów, ponownego przeszukania filmów o łodziach podwodnych, znalezienia wszystkich aktorów w tych filmach, a następnie porównania (dużych) zebranych wyników. W przeciwieństwie do tego, baza danych wykresów przeszłaby od Przeminęło z wiatrem do Clarka Gable , gromadziłaby linki do filmów, w których grał, zbierałaby linki z tych filmów do innych aktorów, a następnie podążała za linkami tych aktorów z powrotem do lista filmów. Otrzymaną listę filmów można następnie przeszukiwać pod kątem „okręt podwodny”. Wszystko to można zrobić za pomocą jednego wyszukiwania.

Właściwości dodają do tej struktury kolejną warstwę abstrakcji , która poprawia również wiele typowych zapytań. Właściwości to zasadniczo etykiety, które można zastosować do dowolnego rekordu, a w niektórych przypadkach również do krawędzi. Na przykład, można by nazwać Clarka Gable'a „aktorem”, co pozwoliłoby systemowi na szybkie odnalezienie wszystkich nagrań, które są aktorami, a nie reżyserem lub operatorem kamery. Jeśli etykiety na krawędziach są dozwolone, można również oznaczyć związek między Przeminęło z wiatrem i Clarkem Gable jako „główny” i przeprowadzając wyszukiwanie osób, które są „głównym” „aktorem” w filmie Przeminęło z wiatrem , bazę danych stworzyliby Vivien Leigh , Olivia de Havilland i Clark Gable. Równoważne zapytanie SQL musiałoby opierać się na dodanych danych w tabeli łączącej osoby i filmy, zwiększając złożoność składni zapytania. Tego rodzaju etykiety mogą w pewnych okolicznościach poprawić wydajność wyszukiwania, ale ogólnie są bardziej przydatne w dostarczaniu dodatkowych danych semantycznych użytkownikom końcowym.

Relacyjne bazy danych bardzo dobrze nadają się do płaskich układów danych, w których relacje między danymi są głębokie na jeden lub dwa poziomy. Na przykład baza danych księgowości może wymagać wyszukania wszystkich pozycji dla wszystkich faktur dla danego klienta, kwerendy z trzema sprzężeniami. Bazy danych grafów są przeznaczone dla zbiorów danych zawierających znacznie więcej linków. Szczególnie dobrze nadają się do systemów społecznościowych , w których relacja „przyjaciół” jest zasadniczo nieograniczona. Te właściwości sprawiają, że bazy danych wykresów są naturalnie dostosowane do typów wyszukiwań, które są coraz częściej spotykane w systemach online oraz w środowiskach Big Data . Z tego powodu bazy danych wykresów stają się bardzo popularne w dużych systemach internetowych, takich jak Facebook , Google , Twitter , i podobnych systemach z głębokimi powiązaniami między rekordami.

Aby dalej zilustrować, wyobrazić wzór relacyjny z dwóch tabel: do peoplestołu (której person_idi person_namekolumna) i friendstół (z friend_idi person_id, co jest klucz obcy z peopletabeli). W takim przypadku wyszukanie wszystkich znajomych Jacka skutkowałoby następującym zapytaniem SQL.

SELECT p2.person_name 
FROM people p1 
JOIN friend ON (p1.person_id = friend.person_id)
JOIN people p2 ON (p2.person_id = friend.friend_id)
WHERE p1.person_name = 'Jack';

To samo zapytanie może zostać przetłumaczone na --

• Cypher , język zapytań do bazy danych wykresów

  MATCH (p1:person {name: 'Jack'})-[:FRIEND_WITH]-(p2:person)
  RETURN p2.name
  

• SPARQL , język zapytań bazy danych wykresów RDF standaryzowany przez W3C i używany w wielu sklepach RDF Triple i Quad
  • Długa forma

    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    
    SELECT ?name
    WHERE { ?s a          foaf:Person . 
            ?s foaf:name  "Jack" . 
            ?s foaf:knows ?o . 
            ?o foaf:name  ?name . 
          }
    

  • Skrócona forma

    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    
    SELECT ?name
    WHERE { ?s foaf:name     "Jack" ;
               foaf:knows    ?o .
               ?o foaf:name  ?name .
          }
    

• SPASQL, hybrydowy język zapytań do baz danych, który rozszerza SQL o SPARQL

  SELECT people.name
  FROM (
         SPARQL PREFIX foaf: <http://xmlns.com/foaf/0.1/>
                SELECT ?name
                WHERE { ?s foaf:name  "Jack" ; 
                           foaf:knows ?o .
                        ?o foaf:name  ?name .
                      }
      ) AS people ;
  

Powyższe przykłady są prostą ilustracją podstawowego zapytania dotyczącego relacji. Kondensują ideę złożoności zapytań modeli relacyjnych, która rośnie wraz z całkowitą ilością danych. Dla porównania, zapytanie do bazy danych wykresów jest w stanie łatwo posortować wykres relacji w celu przedstawienia wyników.

Są też wyniki, które wskazują, że proste, skondensowane i deklaratywne zapytania grafowych baz danych niekoniecznie zapewniają dobrą wydajność w porównaniu z relacyjnymi bazami danych. Podczas gdy grafowe bazy danych oferują intuicyjną reprezentację danych, relacyjne bazy danych oferują lepsze wyniki, gdy potrzebne są operacje na zestawach.

Lista grafowych baz danych

Poniżej znajduje się lista godnych uwagi grafowych baz danych:

Graficzne języki programowania zapytań

• AQL (ArangoDB Query Language) : język zapytań podobny do SQL używany w ArangoDB zarówno dla dokumentów, jak i wykresów
• Cypher Query Language (Cypher): deklaratywny język zapytań grafowych dla Neo4j, który umożliwia dostęp ad hoc i programistyczny (podobny do SQL) do grafu.
• GQL : proponowany język zapytań grafu w standardzie ISO
• GSQL : kompletny język zapytań grafowych podobny do języka SQL Turing zaprojektowany i oferowany przez TigerGraph
• GraphQL : język zapytań i manipulacji danymi typu open source dla interfejsów API. Dgraph implementuje zmodyfikowany język GraphQL o nazwie DQL (dawniej GraphQL+-)
• Gremlin : język programowania grafów, który jest częścią projektu open-source Apache TinkerPop
• SPARQL : język zapytań dla baz danych RDF, który może pobierać i manipulować danymi przechowywanymi w formacie RDF

Zobacz też

• Transformacja grafu
• Hierarchiczny model bazy danych
• Datalog
• Baza obiektów
• Baza danych RDF
• Przechowywanie zorganizowane
• Wykres tekstowy

Bibliografia