Språk for grafspørsmål - Graph Query Language

Ikke forveksles med GraphQL .

GQL ( Graph Query Language ) er et foreslått standard språk for språk . I september 2019 ble et forslag til et prosjekt for å lage et nytt standard grafforespørselsspråk (ISO / IEC 39075 Information Technology - Database Languages ​​- GQL) godkjent av avstemming av nasjonale standardiseringsorganer som er medlemmer av ISO / IEC Joint Technical Committee 1 ( ISO / IEC JTC 1 ). JTC 1 er ansvarlig for internasjonale standarder for informasjonsteknologi. GQL er ment å være et deklarativt spørrespråk for databaser, som SQL .

Prosjekt for et nytt internasjonalt standard grafisk spørrespråk

I GQL-prosjektforslaget heter det:

"Å bruke graf som en grunnleggende fremstilling for datamodellering er en fremvoksende tilnærming i datastyring. I denne tilnærmingen er datasettet modellert som en graf, som representerer hver dataenhet som et toppunkt (også kalt en node) av grafen og hvert forhold mellom to enheter som en kant mellom tilsvarende hjørner. Grafdatamodellen har trukket oppmerksomhet for sine unike fordeler. For det første kan grafmodellen være naturlig egnet for datasett som har hierarkiske, komplekse eller til og med vilkårlige strukturer. Slike strukturer kan enkelt kodes inn i grafmodellen som kanter. Dette kan være mer praktisk enn relasjonsmodellen, som krever normalisering av datasettet til et sett med tabeller med faste radtyper. For det andre muliggjør grafmodellen effektiv utføring av dyre spørsmål eller dataanalysefunksjoner som trenger å observere multi-hop-forhold mellom dataenheter, som for eksempel tilgjengelighetsforespørsler, korteste eller billigste veispørsmål eller sentralitetsanalyse. er to grafmodeller i nåværende bruk: Resource Description Framework (RDF) -modellen og Property Graph-modellen. RDF-modellen er standardisert av W3C i en rekke spesifikasjoner. Property Graph-modellen har derimot en rekke implementeringer i grafdatabaser, grafalgoritmer og grafbehandlingsanlegg. Imidlertid mangler et vanlig, standardisert spørrespråk for eiendomsgrafer (som SQL for relasjonelle databasesystemer). GQL foreslås å fylle dette tomrommet. "

GQL-prosjektet er kulminasjonen av konvergerende tiltak som dateres tilbake til 2016, spesielt et privat forslag fra Neo4j til andre databaseleverandører i juli 2016, og et forslag fra Oracles tekniske personale innen ISO / IEC JTC 1-standardprosessen senere det året.

GQL-prosjektet ledes av Stefan Plantikow (som var den første ledende ingeniøren i Neo4j 's Cypher for Apache Spark- prosjekt) og Stephen Cannan (Technical Corrigenda-redaktør for SQL). De er også redaktører for de første tidlige arbeidsutkastene til GQL-spesifikasjonen.

Som opprinnelig motivert, har GQL-prosjektet som mål å utfylle arbeidet med å lage en implementerbar normativ naturspråksspesifikasjon med støttende samfunnstiltak som muliggjør bidrag fra de som ikke er i stand til eller ikke er interessert i å delta i den formelle prosessen med å definere en JTC 1 International Standard. I juli 2019 gikk Linked Data Benchmark Council (LDBC) med på å bli paraplyorganisasjon for innsatsen til fellestekniske arbeidsgrupper. Arbeidsgruppene Eksisterende språk og eiendomsgrafskjemaet ble dannet i henholdsvis slutten av 2018 og begynnelsen av 2019. En arbeidsgruppe for å definere formell denotasjonell semantikk for GQL ble foreslått ved den tredje GQL Community Update i oktober 2019.

GQL-datagrammedatamodellen

GQL er et spørrespråk spesielt for eiendomsgrafer. En eiendomsgraf ligner nøye på en konseptuell datamodell, uttrykt i en enhets-relasjonsmodell eller i et UML- klassediagram (selv om den ikke inkluderer n-ary-relasjoner som knytter mer enn to enheter). Enheter eller konsepter er modellert som noder, og relasjoner som kanter, i en graf. Eiendomsdiagrammer er multigrafier : det kan være mange kanter mellom samme par noder. GQL-grafer kan blandes : de kan inneholde dirigerte kanter, der en av endepunktnodene til en kant er halen (eller kilden) og den andre noden er hodet (eller målet eller målet), men de kan også inneholde ikke-rettet (toveis eller refleksive) kanter.

Noder og kanter, samlet kjent som elementer, har attributter. Disse attributtene kan være dataverdier eller etiketter (tags). Verdier av egenskaper kan ikke være elementer i grafer, og de kan heller ikke være helgrafer: disse begrensningene tvinger med vilje et rent skille mellom topologien til en graf, og attributtene som bærer dataværdier i sammenheng med en graftopologi. Eiendomsgrafdatamodellen forhindrer derfor bevisst hekking av grafer, eller behandling av noder i en graf som kanter i en annen. Hver eiendomsgraf kan ha et sett med etiketter og et sett med egenskaper som er knyttet til grafen som helhet.

Nåværende produkter og prosjekter for grafdatabaser støtter ofte en begrenset versjon av modellen som er beskrevet her. For eksempel tvinger Apache Tinkerpop hver node og hver kant til å ha en enkelt etikett; Cypher lar noder ha null til mange etiketter, men relasjoner har bare en enkelt etikett (kalt reltype). Neo4js database støtter udokumenterte grafomfattende egenskaper, Tinkerpop har grafverdier som spiller den samme rollen, og støtter også "metaproperties" eller egenskaper på egenskaper. Oracle's PGQL støtter null til mange etiketter på noder og på kanter, mens SQL / PGQ støtter en til mange etiketter for hver type element. Den NGSI-LD informasjonsmodell som er spesifisert av ETSI er et forsøk på formelt spesifiserer eiendom grafer, med node og forholdet (kant) typene som kan spille rollen som etiketter i tidligere nevnte modeller og støtter semantisk henvisninger ved å arve klasser som er definert i delte ontologier .

GQL-prosjektet vil definere en standard datamodell, som sannsynligvis vil være overmengden av disse variantene, og i det minste vil den første versjonen av GQL sannsynligvis tillate leverandører å bestemme kardinaliteten til etiketter i hver implementering, det samme gjør SQL / PGQ , og å velge om du vil støtte ikke-rettet forhold.

Ytterligere aspekter av ERM- eller UML-modellene (som generalisering eller undertyping, eller enhets- eller forholdskardinaliteter) kan fanges opp av GQL-skjemaer eller typer som beskriver mulige forekomster av den generelle datamodellen.

WG3: utvide SQL og opprette GQL

GQL-prosjektet har en fire års tidsperiode. Syv nasjonale standardiseringsorganer (de fra USA, Kina, Korea, Nederland, Storbritannia, Danmark og Sverige) har nominert nasjonale fageksperter til å jobbe med prosjektet, som gjennomføres av arbeidsgruppe 3 (databasespråk) av ISO / IEC JTC 1s underutvalg 32 (Data Management and Interchange), vanligvis forkortet som ISO / IEC JTC 1 / SC 32 WG3 , eller bare WG3 for kort. WG3 (og dets direkte forgjengerkomiteer innen JTC 1) har vært ansvarlig for SQL-standarden siden 1987.

Utvide eksisterende språk for språk

GQL-prosjektet trekker på flere kilder eller innganger, særlig eksisterende industrispråk og en ny del av SQL-standarden. I forberedende diskusjoner innen WG3 ble det presentert undersøkelser om historien og det komparative innholdet til noen av disse innspillene. GQL vil være et deklarativt språk med sin egen distinkte syntaks, og spiller en lignende rolle som SQL i byggingen av en databaseapplikasjon. Andre grafspørsmål er definert som tilbyr direkte prosessuelle funksjoner som forgrening og looping (Apache Tinkerpop's Gremlin,) og GSQL, noe som gjør det mulig å krysse en graf iterativt for å utføre en klasse grafalgoritmer, men GQL vil ikke direkte innlemme slike funksjoner. Imidlertid er GQL tenkt som et spesifikt tilfelle av en mer generell klasse med grafspråk, som vil dele et graftypesystem og et anropsgrensesnitt for prosedyrer som behandler grafer.

SQL / PGQ Eiendomsgraf-spørring

Før arbeidet med WG3 og SC32 speil organer, særlig i INCITS DM32, har bidratt til å definere en ny planlagt Del 16 av SQL Standard, som gjør en skrivebeskyttet graf spørring for å bli kalt inne i en SQL SELECT-setning, matchende en graf mønster ved hjelp syntaks som er veldig nær Cypher, PGQL og G-CORE, og returnerer en tabell med dataverdier som resultat. SQL / PGQ inneholder også DDL for å tillate at SQL-tabeller blir kartlagt til et diagramvisningsskjemaobjekt med noder og kanter tilknyttet sett med etiketter og datasettegenskaper. GQL-prosjektet koordinerer tett med SQL / PGQ "project split" av (utvidelse til) ISO 9075 SQL, og de tekniske arbeidsgruppene i USA (INCITS DM32) og på internasjonalt nivå (SC32 / WG3) har flere ekspertbidragere som jobbe med begge prosjektene. GQL-prosjektforslaget krever tett justering av SQL / PGQ og GQL, noe som indikerer at GQL generelt vil være et supersett av SQL / PGQ.

Cypher

Cypher er et språk som opprinnelig ble designet av Andrés Taylor og kollegaer i Neo4j Inc., og først implementert av selskapet i 2011. Siden 2015 har det blitt gjort tilgjengelig som en åpen kildekildespråkbeskrivelse med grammatikkverktøy, en JVM- frontend som analyserer Cypher spørsmål og et teknologikompatibilitetssett (TCK) med over 2000 testscenarier, ved bruk av agurk for implementeringsspråkbarhet. TCK gjenspeiler språkbeskrivelsen og en forbedring for tidsmessige datatyper og funksjoner dokumentert i et Cypher Improvement Proposal.

Cypher tillater oppretting, lesing, oppdatering og sletting av grafelementer, og er et språk som derfor kan brukes til analysemotorer og transaksjonsdatabaser.

Spørring med visuelle banemønstre

Cypher bruker kompakte mønstre med fast og variabel lengde som kombinerer visuelle representasjoner av node- og forhold (kant) topologier, med etiketteksistens og eiendomsverdi predikater. (Disse mønstrene blir vanligvis referert til som " ASCII art " -mønstre, og oppsto opprinnelig som en måte å kommentere programmer som brukte et grafisk API på lavere nivå.) Ved å matche et slikt mønster mot grafdataelementene, kan et spørsmål trekke ut referanser til noder , relasjoner og stier av interesse. Disse referansene sendes ut som en "bindingstabell" der kolonnenavn er bundet til et flersett av grafelementer. Navnet på en kolonne blir navnet på en "bindingsvariabel", hvis verdi er en spesifikk grafelementreferanse for hver rad i tabellen.

For eksempel vil et mønster   MATCH (p:Person)-[:LIVES_IN]->(c:City)   generere en to-kolonne utgangstabell. Den første kolonnen med navn   p   vil inneholde referanser til noder med en etikett   Person  . Den andre kolonnen med navn   c   vil inneholde referanser til noder med en etikett   City  , som betegner byen der personen bor.

Bindingsvariablene   p   og   c   kan deretter henvises for å få tilgang til eiendomsverdier knyttet til elementene det er referert til av en variabel. Eksemplets spørring kan bli avsluttet med a   RETURN , noe som resulterer i en fullstendig spørring som denne: 

MATCH (p:Person)-[:LIVES_IN]->(c:City)
RETURN p.first_name, p.last_name, c.name, c.state

Dette vil resultere i en endelig firekolonnetabell med navn på innbyggerne i byene som er lagret i grafen.

Mønsterbaserte spørsmål er i stand til å uttrykke sammenføyninger ved å kombinere flere mønstre som bruker den samme bindingsvariabelen for å uttrykke en naturlig sammenføyning ved bruk av   MATCH   paragrafen: 

MATCH (p:Person)-[:LIVES_IN]->(c:City), (p:Person)-[:NATIONAL_OF]->(EUCountry)
RETURN p.first_name, p.last_name, c.name, c.state

Dette spørsmålet vil bare returnere boligstedet til EU-borgere.

En ytre sammenføyning kan uttrykkes ved   MATCH ... OPTIONAL MATCH  : 

MATCH (p:Person)-[:LIVES_IN]->(c:City) OPTIONAL MATCH (p:Person)-[:NATIONAL_OF]->(ec:EUCountry)
RETURN p.first_name, p.last_name, c.name, c.state, ec.name

Dette spørsmålet vil returnere bostedsbyen til hver person i grafen med boliginformasjon, og, hvis en EU-borger, hvilket land de kommer fra.

Spørringer er derfor i stand til å først projisere en undergraf av grafen som er lagt inn i spørringen, og deretter trekke ut dataverdiene som er knyttet til den undergrafen. Dataverdier kan også behandles av funksjoner, inkludert aggregeringsfunksjoner, som fører til projeksjon av beregnede verdier som gjengir informasjonen som holdes i den projiserte grafen på forskjellige måter. Etter ledelsen av G-CORE og Morpheus, har GQL som mål å projisere undergrafene definert av samsvarende mønstre (og grafer som deretter blir beregnet over disse undergrafene) som nye grafer som skal returneres av et spørsmål.

Mønstre av denne typen har blitt gjennomgripende i språket for eiendomsgraf, og er grunnlaget for at det avanserte mønsterets underspråk er definert i SQL / PGQ, som sannsynligvis blir en delmengde av GQL-språket. Cypher bruker også mønstre for innsetting og modifikasjonsklausuler (  CREATE   og   MERGE  ), og det er kommet forslag i GQL-prosjektet for å samle node- og kantmønstre for å beskrive graftyper.

Cypher-implementeringer

Cypher er implementert i Neo4j-databasen, i SAPs HANA- graf, av Redis Graph., Av Cambridge Semantics 'Anzograph, av Bitnine's AgensGraph, av Memgraph, og i åpen kildekode-prosjekter Cypher for Gremlin vedlikeholdt av Neueda Labs i Riga, og Cypher for Apache Spark (nå omdøpt til Morpheus), så vel som i forskningsprosjekter som Cypher.PL og Ingraph. Cypher som språk styres som openCypher-prosjektet av et uformelt samfunn som har holdt fem openCypher Implementers 'Meetings ansikt til ansikt siden februar 2017.

Cypher 9 og Cypher 10

Den nåværende versjonen av Cypher (inkludert den tidsmessige utvidelsen) blir referert til som Cypher 9. Før GQL-prosjektet var det planlagt å lage en ny versjon, Cypher 10 [ REF HEADING NEDER ], som ville inneholde funksjoner som skjema og komponerbare grafspørsmål og utsikt. De første designene for Cypher 10, inkludert grafkonstruksjon og projeksjon, ble implementert i Cypher for Apache Spark-prosjektet fra 2016.

PGQL

PGQL er et språk designet og implementert av Oracle Inc., men gjort tilgjengelig som en åpen kildekode-spesifikasjon, sammen med JVM-parsingsprogramvare. PGQL kombinerer kjent SQL SELECT-syntaks inkludert SQL-uttrykk og resultatbestilling og aggregering med et mønster som samsvarer med språket som ligner på Cypher. Det gjør det mulig å spørre om spesifikasjonen av grafen, og inkluderer et anlegg for makroer for å fange "mønstervisninger", eller navngitte undermønstre. Den støtter ikke innsettings- eller oppdateringsoperasjoner, og er først og fremst designet for et analysemiljø, for eksempel Oracles PGX-produkt. PGQL er også implementert i Oracle Big Data Spatial and Graph, og i et forskningsprosjekt, PGX.D / Async.

G-CORE

G-CORE er et forskningsspråk designet av en gruppe akademiske og industrielle forskere og språkdesignere som trekker på funksjonene til Cypher, PGQL og SPARQL . Prosjektet ble gjennomført i regi av Linked Data Benchmark Council (LDBC), startende med dannelsen av en Graph Query Language task force i slutten av 2015, med mesteparten av arbeidet med papirskriving som skjedde i 2017. G-CORE er en sammensettbart språk som er lukket over grafer: grafinnganger blir behandlet for å lage en grafutgang, ved hjelp av grafprojeksjoner og grafsettoperasjoner for å konstruere den nye grafen. G-CORE-spørsmål er rene funksjoner over grafer, uten bivirkninger, noe som betyr at språket ikke definerer operasjoner som muterer (oppdaterer eller sletter) lagrede data. G-CORE introduserer visninger (navngitte spørsmål). Den inneholder også baner som elementer i en graf ("baner som førsteklasses borgere"), som kan spørres uavhengig av projiserte baner (som beregnes ved spørringstid over node- og kantelementer). G-CORE er delvis implementert i forskningsprosjekter med åpen kildekode i LDBC GitHub-organisasjonen.

GSQL

GSQL er et språk designet for TigerGraph Inc.s eiendomsgrafdatabase. Siden oktober 2018 har TigerGraph-språkdesignere promotert og jobbet med GQL-prosjektet. GSQL er et komplett Turing-språk som inkluderer prosessuell strømningskontroll og iterasjon, og et anlegg for å samle og modifisere beregnede verdier knyttet til en programutførelse for hele grafen eller for elementer i en graf som kalles akkumulatorer. Disse funksjonene er designet for å gjøre det mulig å kombinere iterative grafberegninger med datautforskning og gjenfinning. GSQL-grafer må beskrives med et skjema med toppunkt og kanter, som begrenser alle innsettinger og oppdateringer. Dette skjemaet har derfor den lukkede verdensegenskapen til et SQL-skjema, og dette aspektet av GSQL (også reflektert i designforslag som kommer fra Morpheus-prosjektet) foreslås som en viktig valgfri funksjon av GQL.

Vertexer og kanter kalles skjemaobjekter som inneholder data, men som også definerer en tilregnet type, akkurat som SQL-tabeller er databeholdere, med tilhørende implisitt radtype. GSQL-grafer er deretter sammensatt fra disse toppunkt- og kantsett, og flere navngitte grafer kan inkludere samme toppunkt eller kantsett. GSQL har utviklet nye funksjoner siden lanseringen i september 2017, og introduserte spesielt kantmønster med variabel lengde ved hjelp av en syntaks relatert til den som er sett i Cypher, PGQL og SQL / PGQ, men også i stil med mønstrene med fast lengde som tilbys av Microsoft SQL / Server-graf

GSQL støtter også begrepet Multigraphs som lar delmengder av en graf ha rollebasert tilgangskontroll. Multigrafier er viktige for grafer i bedriftsskala som trenger tilgang til finkornsadgang for forskjellige brukere.

Morpheus: flere grafer og sammensettbare grafspørsmål i Apache Spark

Opencypher Morpheus-prosjektet implementerer Cypher for Apache Spark-brukere. Fra og med 2016 startet dette prosjektet opprinnelig sammen med tre relaterte anstrengelser, hvor Morpheus-designere også deltok: SQL / PGQ, G-CORE og design av Cypher-utvidelser for spørring og konstruering av flere grafer. Morpheus-prosjektet fungerte som en testbed for utvidelser av Cypher (kjent som "Cypher 10") i de to områdene av grafen DDL og utvidelser av spørrespråk.

Graf DDL-funksjoner inkluderer

  1. definisjon av eiendomsgrafvisninger over JDBC- tilkoblede SQL-tabeller og Spark DataFrames
  2. definisjon av grafskjemaer eller typer definert ved å samle nodetype og kanttypemønstre, med subtyping
  3. begrense innholdet i en graf med et lukket eller fast skjema
  4. lage katalogoppføringer for flere navngitte grafer i en hierarkisk organisert katalog
  5. tegne datakilder for å danne en forent, heterogen katalog
  6. lage katalogoppføringer for navngitte spørsmål (visninger)

Språkutvidelser for grafspørsmål inkluderer

  1. grafforening
  2. projeksjon av grafer beregnet fra resultatene av mønsterkamper på flere inngangsgrafer
  3. støtte for tabeller (Spark DataFrames) som innganger til spørsmål ("kjørebord")
  4. visninger som godtar navngitte eller projiserte grafer som parametere.

Disse funksjonene er blitt foreslått som input til standardiseringen av eiendomsdiagrammerspråk i GQL-prosjektet.

Se også

Referanser