Det er ofte lettere å forstå brukstilfellene for grafdatabaser enn å forstå hvordan grafdatabaser fungerer. For eksempel å stille spørsmålet om hvem de mektigste tankelederne på tvers av flere sosiale nettverk, med det største antallet tilkoblinger, er bedre egnet for grafdatabaser fordi alternativet å kjøre spørringen i en relasjonsdatabase ville kreve et latterlig antall tabellforbindelser .
Og så, med TigerGraph som økte produkt -FoU fra en ny San Diego -base, og utnevnte et nytt leder for operasjonen, Dr. Jay Yu, som ga unnskyldning til å se på banen for selskapet, for ikke å snakke om ønskelisten vår for grafdatabaser, som handler om forenkling. Vi fikk sjansen til å snakke med ham og konsernsjef Dr. Yu Xu, og nedenfor er tankene våre.
Angi kontekst
Grafdatabaser er rundt oss, men oftere enn ikke gjemmer seg i planutsikt. Et godt eksempel er Microsoft Graph, som Microsoft karakteriserer som “inngangsporten til data og intelligens i Microsoft 365.” Mer til poenget, det kan brukes til å organisere flyten av dokumenter, oppgaver, meldinger eller andre prosesser i hele Microsoft 365, som selvfølgelig omfatter Microsoft Office. Men for utviklere blir Microsoft Graph avslørt som et API å skrive apper mot, ikke en database. I dette tilfellet modellerer Microsoft alle dataene, utviklere kan bare kjøre og spille med dem.
Men i økende grad slipper grafdatabaser sine forkledninger fordi brukstilfellene bare stirrer oss i øynene. De kan variere fra sporing av cybersikkerhetstrusler til risikostyring i finansielle tjenester, bekjempelse av hvitvasking, anbefalingsmotorer, støtte etterforskende journalistikk, levering av anbefalinger for helsebehandlinger i sanntid, til å bygge kunnskapsgrafer for leting etter rom. Den røde tråden er at å trekke ut visdom innebærer å gre gjennom flere nett av relasjoner.
Hvor skal du gå herfra? For noen uker siden argumenterte George Anadiotis på disse sidene for at grafdatabaser utgjør en logisk startplate for AI. Vi skal se på det nedenfra og opp: grafdatabaser må tegne et kritisk masseferdighetsgrunnlag og bli mer tilgjengelig, både for utviklere og forretningsanalytikere.
Det starter med spørrespråk
Utfordringen med grafdatabaser er å bygge den ferdighetsbasen. I motsetning til relasjonelle, har den ikke 40 års historie i virksomheten og et vanlig spørrespråk, SQL, for å trekke et ferdighetsgrunnlag. Og i motsetning til dokumentdatabaser, har ikke grafdatabaser utnyttet en ferdighet som allerede er vanlig hos utviklere (f.eks. JavaScript) med sine JSON -datakonstruksjoner. Og forresten, grafdatabaser krever en annen tilnærming til modellering av data; det er ikke akkurat et rikt reservoar av erfaring der heller.
Men utviklingen som forhindret at grafdatabaser ble en fotnote i db-motorer, var oppfinnelsen av eiendomsgrafen, som ble populær av grunnleggerne av Neo4J. Før det var grafer en utvekst av W3C Semantic Web -initiativet, som krevde ganske stive RDF -trippler. Med tripler måtte hver node bære et emne, predikat og graf. Selv om slike modeller er godt egnet for velbegrensede og veldefinerte informasjonsforekomster, for eksempel klinisk farmasøytisk forskning, eiendomsgrafer (eller mer spesifikt “merkede eiendomsgrafer”) som definerte verden som noder (enheter) og lenker (relasjoner) ) viste seg langt mer fleksibel og lettere å modellere. I sitt stykke snakket Anadiotis om RDF **, som kan gi den unnvikende logiske koblingen mellom RDF og eiendomsgrafer.
Den neste hindringen er spørrespråk. Inntil nylig hadde hver grafdatabaseleverandør sitt eget unike språk, noe som betyr at det ikke var noe felles mål for å bygge en kritisk masseferdighetsbase. Noen få populære dialekter, som begynte med Gremlin som prosedyrespråk, som kom ut av Apache TinkerPop -prosjektet, ga en syntaks for å navigere rundt i en grafdatabase. Noen tilbydere inngår sine egne allianser, for eksempel Neo4J og AWS rundt OpenCypher, åpen kildekode-implementering av Neo4Js Cypher-spørrespråk.
Røttene til GQL
Credit: The GQL Manifesto
Men det er noen tegn på fremvoksende fornuft, ettersom spillere inkludert Neo4J, TigerGraph, Oracle og andre samarbeider om GQL. Nå som et offisielt ISO -prosjekt, blir GQL designet som et deklarativt språk som vil smelte sammen deler av Neo4Js Cypher; Oracle's PGQL; og GCore, en referanseimplementering. På slutten av dagen vil vi ikke forvente at Neo4J dropper Cypher, ikke TigerGraph vil slippe sin mer SQL-lignende GSQL. Vi regner med at GQL vil være en referanseimplementering som leverandørspråkene vil legge til krysskompatibilitet mot, og derfor komme nærmere målet om å ha et felles ferdighetsmål.
Gå dit hvor utviklere og forretningsanalytikere bor
Snitt på jakt – å gjøre grafen mer tilgjengelig for utviklere og forretningsanalytikere var temaet vi snakket med Dr. Yu og Xu fra TigerGraph om. TigerGraph, som har trukket inn 171 millioner dollar i risikofinansiering, er ikke like kjent som sin primære rival Neo4J. Men TigerGraph har differensiert seg med støtte for en distribuert databasearkitektur som bruker en rekke triks, for eksempel datakomprimering, automatisk partisjonering, forhåndskompilering av forespørsler for å effektivisere kryss og aggregering av midlertidige resultater. For å utføre en lignende oppgave, ville andre grafdatabaser kreve utdeling av data og behandling til flere separate fysiske forekomster med resultatene slått sammen. I en nylig pressemelding siterte selskapet en Uber-lignende kunde i Sørøst-Asia som byttet inn TigerGraph etter at Neo4j ikke klarte å skalere.
Selskapet har gjort noen grep for å gjøre data mer tilgjengelig. For eksempel tilbyr den et dra og slipp -verktøy for utvikling av spørringer og har koblinger til Power BI og Tableau, som er allestedsnærværende i BI -visualiseringsverdenen. Det er ganske mye bordinnsatser ettersom de fleste av de populære grafplattformene har BI -kontakter. Selvfølgelig, hvis teamet ditt har ferdigheter med relasjons- eller NoSQL -databaser, tilbyr mange av disse plattformene grafmaterialiserte visninger som lar deg kjøre ganske enkle grafspørringer som maksimalt kan håndtere 2 – 3 traversals (sett med relasjoner). Men for spørsmål som er mer komplekse, for eksempel å oppdage svindelmønstre eller identitetstyveri, vil det være nødvendig med en database som representerer data opprinnelig i grafskjema.
Med selskapets San Diego FoU -senter og ledende direktør på plass spurte vi hva som er neste på agendaen deres. På toppen av listen er det å legge til støtte for nye språk og APIer, der utviklere (og ikke nødvendigvis grafdatabaseutviklere) bor. De legger til støtte for GraphQL, et kombinert API og spørrespråk som er langt mer effektivt enn REST når det gjelder enkel datahenting. Selv om den har “graf” i navnet, har GraphQL ikke blitt assosiert med grafdatabaser før nå. I stedet refererer grafen i GraphQL til den underliggende kunnskapsgrafen som kartlegger datakilden, og gir derfor snarveier for å komme til de riktige dataene uten all skravling av et RESTful -anrop.
Ikke overraskende har GraphQL vist seg populær blant mobilapper, og har skåret fotfeste med NoSQL -databaser som MongoDB eller Apache Cassandra. GraphQLs popularitet har blitt viral blant utviklere til det punktet hvor et nytt selskap, Hasura, har bygget en skytjeneste rundt det for å spørre PostgreSQL, slik vi gjennomgikk for omtrent et år siden. Og det er den økende grad av kjennskap blant mobilutviklere som TigerGraph søker å benytte seg av for å spre fotavtrykket.
En annen del av puslespillet for å møte utviklere på sitt eget gress, er å avrunde tilkoblinger til alle de viktigste databehandlingsmotorene og datalagrene, for eksempel Apache Spark og Cassandra. Vår oppfatning er at dette kan føre til å legge til datavirtualisering, der TigerGraph kan få tilgang til data i kilder som Cassandra, MySQL, PostgreSQL eller andre i db-Engines topp ti-liste, og behandle dem som utvidede noder og kanter. Når det gjelder å projisere grafvisninger på ikke-grafiske data, hvorfor skulle Cassandra eller MongoDB svine alt moroa?
Vi har noen flere ting på ønskelisten vår. Til å begynne med, verktøy som kan hjelpe utviklere som er nybegynnere med å tegne graf med modelleringsverktøy, slik at de kan forstå hvordan de skal strukturere nettene til relasjoner som er viktige for diagramdatabaseskjema.
Men la oss ikke glemme forretningsbrukere. Å gi tilknytninger til BI-verktøy er åpenbare første skritt, men å fjerne visualiseringer basert på relasjonelle synspunkter vil ikke gjøre rettferdighet for å forklare nyansene til forskjellige relasjonsnivåer som gir de virkelige svarene på spørsmålene deres. Likevel bør vi ikke kreve at sluttbrukerne i virksomheten danner spørsmål basert på forbindelsesnettet mellom forskjellige hjørner.
Den forestående tanken er at selv om forretningsbrukere kanskje ikke har den svakeste anelse om hva en grafdatabase er eller hvordan de kan stille spørsmål, er spørsmålene de stiller ganske enkle: Hvem er de viktigste påvirkerne? Hvem er de vanlige pasientene på tvers av flere henvisningsnettverk? Hvordan skille raskt mellom trygge og ondsinnede nettsteder for å ivareta cybersikkerhet? Hvordan forhindre seerturnering ved å analysere mønstrene deres for å konsumere streamingunderholdning? Eller, hvordan identifisere mønstre for hvitvasking av penger ved å analysere forbindelser på tvers av forskjellige undersøkelser? Dette er litt av et ambisiøst skritt, men når vi allerede ser en naturlig språkforespørsel dukke opp i analyseverktøy, er det ikke et begrepssprang å bruke dette på de tilkoblede dataene inne i grafdatabaser.
Big Data
Hvor er IBMs hybridsky -lanseringsflate? Syv måter å gjøre sanntidsteknologi reell for organisasjonen Maskinlæring på kanten: TinyML blir stor Hva skjer videre med Cloudera? McDonald's ønsker å 'demokratisere' maskinlæring for alle brukere på tvers av operasjonene
Relaterte emner:
Datahåndtering Digital Transformation Robotics Internet of Things Innovation Enterprise Software 