Det er ofte lettere at forstå brugstilfælde for grafdatabaser end at forstå, hvordan grafdatabaser fungerer. For eksempel at stille spørgsmålet om, hvem de mest magtfulde tankeledere på tværs af flere sociale netværk, med den største variation af forbindelser, er bedre egnet til grafdatabaser, fordi alternativet til at køre forespørgslen i en relationsdatabase ville kræve et latterligt antal tabelforbindelser .
Og så, med TigerGraph, der øger produkt -FoU fra en ny San Diego -base og udnævner et nyt chef til operationen, Dr. Jay Yu, der gav undskyldning for at se på banen for virksomheden, for slet ikke at tale om vores ønskeliste til grafdatabaser, som handler om forenkling.
Indstilling af kontekst
Grafdatabaser er rundt omkring os, men oftere end ikke gemmer de sig i planens øjne. Et godt eksempel er Microsoft Graph, som Microsoft karakteriserer som “porten til data og intelligens i Microsoft 365.” Mere til det punkt kan det bruges til at orkestrere strømmen af dokumenter, opgaver, meddelelser eller andre processer i hele Microsoft 365, hvilket naturligvis omfatter Microsoft Office. Men for udviklere udsættes Microsoft Graph som en API at skrive apps imod, ikke en database. I dette tilfælde modellerer Microsoft alle data, udviklere kan bare køre og spille med dem.
Men i stigende grad kaster grafdatabaser deres forklædninger, fordi brugssagerne bare stirrer os i øjnene. De kan variere fra sporing af cybersikkerhedstrusler til risikostyring i finansielle tjenester, bekæmpelse af hvidvaskning af penge, anbefalingsmotorer, understøttende undersøgelsesjournalistik, levering af anbefalinger til sundhedsbehandlinger i realtid, til opbygning af videndiagrammer til efterforskning af rummet. Den røde tråd er, at udtrækning af visdom indebærer kæmning gennem flere net af relationer.
Hvor skal man hen herfra? Et par uger tilbage argumenterede George Anadiotis på disse sider for, at grafdatabaser udgør en logisk startplade til AI. Vi kommer til at se det fra bunden: grafdatabaser skal tegne et kritisk massefærdighedsgrundlag og blive mere tilgængelige, både for udviklere og forretningsanalytikere.
Det starter med forespørgselssprog
Udfordringen med grafdatabaser er at opbygge denne færdighedsbase. I modsætning til relationelle har den ikke 40 års historie i virksomheden og et fælles forespørgselssprog, SQL, som man kan trække et færdighedsgrundlag til. Og i modsætning til dokumentdatabaser har grafdatabaser ikke udnyttet en færdighed, der allerede er almindelig hos udviklere (f.eks. JavaScript) med deres JSON -datakonstruktioner. Og i øvrigt kræver grafdatabaser en anden tilgang til modellering af data; der er heller ikke ligefrem et rigt reservoir af erfaring.
Men den udvikling, der forhindrede grafdatabaser i at blive en fodnote i db-motorer, var opfindelsen af ejendomsgrafen, der blev populær af grundlæggerne af Neo4J. Før det var grafer en udvækst af W3C Semantic Web -initiativet, der krævede temmelig stive RDF -tredoblinger. Med tredoblinger skulle hver node bære et emne, prædikat og graf. Selvom sådanne modeller er velegnede til velafgrænsede og veldefinerede informationskorpus, såsom klinisk farmaceutisk forskning, ejendomsgrafer (eller mere specifikt “mærkede ejendomsgrafer”), der definerede verden som noder (enheder) og links (relationer) ) viste sig at være langt mere fleksibel og lettere at modellere. I sit stykke talte Anadiotis om RDF **, hvilket kan give den undvigende logiske forbindelse mellem RDF og ejendomsgrafer.
Den næste hindring er forespørgselssprog. Indtil for nylig bar hver grafdatabaseudbyder sit eget unikke sprog, hvilket betyder, at der ikke var noget fælles mål for opbygning af en kritisk massefærdighedsbase. Et par populære dialekter, der begyndte med Gremlin som procedursprog, der kom ud af Apache TinkerPop -projektet, gav en syntaks til at navigere rundt i en grafdatabase. Nogle udbydere danner deres egne alliancer, såsom Neo4J og AWS omkring OpenCypher, open source-implementeringen af Neo4Js Cypher-forespørgselssprog.
Rødderne til GQL
Credit: The GQL Manifesto
Men der er nogle tegn på ny forstand, da spillere, herunder Neo4J, TigerGraph, Oracle og andre samarbejder om GQL. Nu et officielt ISO -projekt, er GQL designet som et deklarativt sprog, der ville smelte elementer af Neo4J's Cypher; Oracle's PGQL; og GCore, en referenceimplementering. I slutningen af dagen forventer vi ikke, at Neo4J dropper Cypher, TigerGraph ville heller ikke droppe sin mere SQL-lignende GSQL. Vi forventer, at GQL vil være en referenceimplementering, som leverandørsprogene ville tilføje krydskompatibilitet mod og derfor rykke tættere på målet om at have et fælles færdighedsmål.
Gå til hvor udviklere og forretningsanalytikere bor
Skær på jagt – at gøre grafen mere tilgængelig for udviklere og forretningsanalytikere var det emne, vi talte med Dr. Yu og Xu fra TigerGraph om. TigerGraph, der har trukket 171 millioner dollars i venturefinansiering, er ikke så kendt som sin primære rival Neo4J. Men TigerGraph har differentieret sig med understøttelse af en distribueret databasearkitektur, der anvender en række tricks, såsom datakomprimering, automatisk partitionering, præ-kompilering af forespørgsler for at strømline transversaler og sammenlægning af midlertidige resultater. For at udføre en lignende opgave, ville andre grafdatabaser kræve udskiftning af data og behandling til flere separate fysiske forekomster med fusionerede resultater. I en nylig pressemeddelelse citerede virksomheden en Uber-lignende kunde i Sydøstasien, der byttede i TigerGraph, efter at Neo4j ikke kunne skalere.
Virksomheden har foretaget nogle skridt for at gøre data mere tilgængelige. For eksempel tilbyder den et træk og slip -værktøj til udvikling af forespørgsler og har stik til Power BI og Tableau, som er allestedsnærværende i BI -visualiseringsverdenen. Det er stort set bordindsatser, da de fleste af de populære grafplatforme har BI -stik. Selvfølgelig, hvis dit team har færdigheder med relationelle eller NoSQL -databaser, tilbyder mange af disse platforme grafmaterialiserede visninger, der giver dig mulighed for at køre ret simple grafiske forespørgsler, der højst kunne håndtere 2 – 3 traversals (sæt af relationer). Men for forespørgsler, der er mere komplekse, såsom at opdage svindelmønstre eller identitetstyveri, kræves en database, der repræsenterer data indbygget i grafskema.
Med virksomhedens San Diego R & amp; D -center og ledende direktør på plads, spurgte vi, hvad der er næste på deres dagsorden. Øverst på listen tilføjes understøttelse af nye sprog og API'er, hvor udviklere (og ikke nødvendigvis grafdatabaseudviklere) bor. De tilføjer understøttelse af GraphQL, et kombineret API og forespørgselssprog, der er langt mere effektivt end REST, når det kommer til simple datahentagelser. Selvom den har “graf” i sit navn, har GraphQL ikke været tilknyttet grafdatabaser før nu. I stedet refererer grafen i GraphQL til den underliggende videngraf, der kortlægger datakilden, og giver derfor genveje til at komme til de rigtige data uden alt snakket om et RESTful -opkald.
Ikke overraskende har GraphQL vist sig at være populær blandt mobilapps og har skåret fodfæste med NoSQL -databaser som MongoDB eller Apache Cassandra. GraphQLs popularitet er blevet viral blandt udviklere til det punkt, hvor et nyt firma, Hasura, har bygget en cloud -service omkring det til forespørgsel på PostgreSQL, som vi gennemgik for cirka et år siden. Og det er den stigende grad af fortrolighed blandt mobiludviklere, som TigerGraph søger at benytte sig af for at sprede sit fodaftryk.
En anden brik i puslespillet for at møde udviklere på deres egen græsbane er afrunding af forbindelser til alle de vigtigste computermotorer og datalagre, såsom Apache Spark og Cassandra. Vores antagelse er, at dette kan føre til tilføjelse af datavirtualisering, hvor TigerGraph kunne få adgang til data i kilder som Cassandra, MySQL, PostgreSQL eller andre i db-Engines top ti-liste og behandle dem som udvidede noder og kanter. Når det kommer til at projicere grafvisninger på ikke-grafiske data, hvorfor skulle Cassandra eller MongoDB svine alt det sjove?
Vi har et par flere ting på vores ønskeliste. Til at begynde med værktøjer, der kan hjælpe udviklere, der er nybegyndere, til at tegne med modelleringsværktøjer, så de kan forstå, hvordan de strukturerer de net af relationer, der er nøglen til grafdatabaseskema.
Men lad os ikke glemme forretningsbrugere. Tilvejebringelse af bindinger til BI-værktøjer er indlysende første skridt, men at fjerne visualiseringer baseret på relationelle synspunkter vil ikke gøre retfærdighed for at forklare nuancerne i forskellige niveauer af relationer, der giver de virkelige svar på deres spørgsmål. Alligevel bør vi ikke kræve, at virksomhedens slutbrugere danner forespørgsler baseret på nettet af forbindelser mellem forskellige hjørner.
Den forestående idé er, at selvom forretningsbrugere måske ikke har den svageste idé om, hvad en grafdatabase er, eller hvordan de skal forespørge på den, er de spørgsmål, de stiller, ganske ligetil: Hvem er de vigtigste påvirkere? Hvem er de almindelige patienter på tværs af flere henvisningsnetværk? Hvordan skelner man hurtigt sikkert fra ondsindede websteder for at beskytte cybersikkerhed? Hvordan forhindrer man seerne ved at analysere deres mønstre for forbrugende streamingunderholdning? Eller, hvordan man identificerer mønstre for hvidvaskning af penge ved at analysere forbindelser på tværs af forskellige undersøgelser? Dette er lidt af et ambitiøst trin, men når vi allerede ser naturlig sprogforespørgsel dukke op i analyseværktøjer, er det ikke et begrebsspring at anvende dette på de tilsluttede data inde i grafdatabaser.
Big Data
Hvor er IBMs hybride cloud -lanceringsplade? Syv måder at gøre realtidsteknologi til virkelighed for din organisation Maskinlæring på kanten: TinyML bliver stor Hvad sker der for Cloudera? McDonald's ønsker at 'demokratisere' maskinlæring for alle brugere på tværs af sine aktiviteter
Relaterede emner:
Datahåndtering Digital Transformation Robotics Internet of Things Innovation Enterprise Software 