Det är ofta lättare att förstå användningsfall för grafdatabaser än att förstå hur grafdatabaser fungerar. Till exempel att ställa frågan om vilka de mest kraftfulla tankeledarna i flera sociala nätverk, med den största variationen av anslutningar, är bättre lämpade för grafdatabaser eftersom alternativet att köra frågan i en relationsdatabas skulle kräva ett löjligt antal tabellkopplingar .
Och så, med TigerGraph som höjer produktens FoU från en ny bas i San Diego och utser ett nytt chef för operationen, Dr. Jay Yu, som gav ursäkten att titta på banan för företaget, för att inte tala om vår önskelista för grafdatabaser, som handlar om förenkling.
Ange sammanhang
Grafdatabaser finns runt omkring oss, men gömmer sig oftare i planens syn. Ett bra exempel är Microsoft Graph, som Microsoft karakteriserar som “porten till data och intelligens i Microsoft 365.” Mer till den punkten kan den användas för att organisera flödet av dokument, uppgifter, meddelanden eller andra processer i hela Microsoft 365, vilket naturligtvis omfattar Microsoft Office. Men för utvecklare exponeras Microsoft Graph som ett API att skriva appar mot, inte en databas. I det här fallet modellerar Microsoft all data, utvecklare kan bara köra och spela med den.
Men i allt större utsträckning skjuter grafdatabaser sina förklädningar eftersom användningsfallen bara stirrar oss i ögonen. De kan sträcka sig från att spåra cybersäkerhetshot till riskhantering inom finansiella tjänster, bekämpa penningtvätt, rekommendationsmotorer, stödja undersökande journalistik, leverera rekommendationer för vårdbehandlingar i realtid, till att bygga kunskapsdiagram för utforskning av rymden. Den röda tråden är att utvinning av visdom innebär att kamma igenom flera nätverk av relationer.
Vart ska man gå härifrån? För några veckor sedan hävdade George Anadiotis på dessa sidor att grafdatabaser utgör en logisk startplatta för AI. Vi kommer att titta på det nedifrån och upp: grafdatabaser måste dra en kritisk masskompetensbas och bli mer tillgängliga, både för utvecklare och affärsanalytiker.
Det börjar med frågespråk
Utmaningen med grafdatabaser är att bygga den kompetensbasen. Till skillnad från relationell har den inte 40 års historia i företaget och ett vanligt frågespråk, SQL, för att dra en kompetensbas. Och till skillnad från dokumentdatabaser har grafdatabaser inte utnyttjat en färdighet som redan är vanlig hos utvecklare (t.ex. JavaScript) med deras JSON -datakonstruktioner. Och förresten, grafdatabaser kräver en annan metod för modellering av data; det finns inte precis en rik reservoar av erfarenhet där heller.
Men utvecklingen som hindrade grafdatabaser från att bli en fotnot i db-motorer var uppfinningen av fastighetsgrafen, som blev populär av grundarna av Neo4J. Innan dess var grafer en utväxt av W3C Semantic Web -initiativet, vilket krävde ganska styva RDF -tripplar. Med tripplar måste varje nod bära ett ämne, predikat och diagram. Även om sådana modeller är väl lämpade för väl avgränsade och väldefinierade informationsföremål, såsom klinisk farmaceutisk forskning, fastighetsgrafer (eller mer specifikt “märkta fastighetsgrafer”) som definierade världen som noder (enheter) och länkar (relationer) ) visade sig mycket mer flexibel och lättare att modellera. I sitt stycke talade Anadiotis om RDF **, vilket kan ge den svårfångade logiska länken mellan RDF och fastighetsdiagram.
Nästa hinder är frågespråk. Fram till nyligen hade varje grafdatabasleverantör sitt eget unika språk, vilket innebär att det inte fanns något gemensamt mål för att bygga en bas för kritisk massfärdighet. Några populära dialekter, som började med Gremlin som procedurspråk, som kom från Apache TinkerPop -projektet, gav en syntax för att navigera runt i en grafdatabas. Vissa leverantörer bildar sina egna allianser, till exempel Neo4J och AWS kring OpenCypher, implementering av öppen källkod av Neo4Js Cypher-frågespråk.
GQL: s rötter
Kredit: GQL -manifestet
Men det finns några tecken på framväxande förnuft, eftersom spelare inklusive Neo4J, TigerGraph, Oracle och andra samarbetar om GQL. Nu är det ett officiellt ISO -projekt, GQL utformas som ett deklarativt språk som skulle förena delar av Neo4Js Cypher; Oracles PGQL; och GCore, en referensimplementering. I slutet av dagen förväntar vi oss inte att Neo4J kommer att släppa Cypher, inte heller skulle TigerGraph släppa sin mer SQL-liknande GSQL. Vi räknar med att GQL kommer att vara en referensimplementering mot vilken leverantörsspråken skulle lägga till korskompatibilitet och kommer därför närmare målet att ha ett gemensamt kompetensmål.
Gå dit utvecklare och affärsanalytiker bor
Snitt på jakt – att göra grafen mer tillgänglig för utvecklare och affärsanalytiker var ämnet som vi pratade med Drs. Yu och Xu från TigerGraph om. TigerGraph, som har dragit 171 miljoner dollar i riskkapitalfinansiering, är inte lika välkänd som sin främsta rival Neo4J. Men TigerGraph har differentierat sig med stöd för en distribuerad databasarkitektur som använder ett antal knep, till exempel datakomprimering, automatisk partitionering, förkompilering av frågor för att effektivisera transversaler och aggregering av interimsresultat. För att utföra en liknande uppgift, skulle andra grafdatabaser kräva utplacering av data och bearbetning till flera separata fysiska instanser med resultat sammanslagna. I ett pressmeddelande nyligen citerade företaget en Uber-liknande kund i Sydostasien som bytte i TigerGraph efter att Neo4j inte kunde skala.
Företaget har gjort några åtgärder för att göra data mer tillgängligt. Till exempel erbjuder den ett dra och släpp -verktyg för att utveckla frågor och har anslutningar till Power BI och Tableau, som finns överallt i BI -visualiseringsvärlden. Det är i stort sett bordsspel eftersom de flesta av de populära grafplattformarna har BI -anslutningar. Naturligtvis, om ditt team har färdigheter med relations- eller NoSQL -databaser, erbjuder många av dessa plattformar grafmaterialiserade vyer som gör att du kan köra ganska enkla graffrågor som kan hantera högst 2 – 3 traversals (uppsättningar av relationer). Men för frågor som är mer komplexa, till exempel att upptäcka bedrägerimönster eller identitetsstöld, krävs en databas som representerar data inbyggt i diagramscheman.
Med företagets San Diego FoU -center och ledande chef på plats frågade vi vad som är nästa på deras agenda. Högst upp på listan läggs till stöd för nya språk och API: er, där utvecklare (och inte nödvändigtvis grafdatabasutvecklare) bor. De lägger till stöd för GraphQL, ett kombinerat API och frågespråk som är mycket effektivare än REST när det gäller enkel datahämtning. Även om det har “graf” i sitt namn, har GraphQL inte associerats med grafdatabaser förrän nu. I stället hänvisar grafen i GraphQL till det underliggande kunskapsdiagrammet som kartlägger datakällan, och ger därför genvägar för att komma till rätt data utan att prata om ett RESTful -samtal.
Inte överraskande har GraphQL visat sig vara populärt bland mobilappar och har ristat fotfäste med NoSQL -databaser som MongoDB eller Apache Cassandra. GraphQLs popularitet har blivit viral bland utvecklare till en punkt där ett nytt företag, Hasura, har byggt en molntjänst runt det för att fråga PostgreSQL, som vi granskade för ungefär ett år sedan. Och det är den växande graden av bekantskap bland mobilutvecklare som TigerGraph försöker utnyttja för att sprida sitt fotavtryck.
En annan pusselbit för att möta utvecklare på sin egen gräsmatta är att runda av anslutningar till alla nyckelfärdmotorer och datalagrar, till exempel Apache Spark och Cassandra. Vår uppfattning är att detta kan leda till att vi lägger till datavirtualisering, där TigerGraph kan komma åt data i källor som Cassandra, MySQL, PostgreSQL eller andra i db-Engines topp tio-lista och behandla dem som utökade noder och kanter. När det gäller att projicera grafvyer på data som inte är grafiska, varför skulle Cassandra eller MongoDB göra allt roligt?
Vi har några fler objekt på vår önskelista. Till att börja med verktyg som kan hjälpa utvecklare som är nybörjare att rita med modelleringsverktyg, så att de kan förstå hur man strukturerar relationer som är viktiga för diagram för databasscheman.
Men låt oss inte glömma affärsanvändare. Att tillhandahålla kopplingar till BI-verktyg är uppenbara första steg, men att ta bort visualiseringar baserade på relationella åsikter kommer inte att göra rättvisa för att förklara nyanser av olika nivåer av relationer som ger de verkliga svaren på deras frågor. Ändå bör vi inte kräva att företagets slutanvändare bildar frågor baserade på nätet av anslutningar mellan olika hörn.
Den uppfattningen är att även om företagsanvändare kanske inte har den svagaste uppfattningen om vad en grafdatabas är eller hur man frågar den, är frågorna de ställer ganska enkla: Vem är de viktigaste påverkarna? Vilka är de vanliga patienterna i flera remissnätverk? Hur kan man snabbt skilja säkert från skadliga webbplatser för att skydda cybersäkerhet? Hur kan man förhindra att tittare vänder sig genom att analysera deras mönster för att konsumera strömmande underhållning? Eller hur man identifierar mönster för penningtvätt genom att analysera samband mellan olika utredningar? Det här är lite av ett ambitiöst steg, men när vi redan ser naturliga språkfrågor som dyker upp i analysverktyg är det inte ett begreppssprång att tillämpa detta på den anslutna datan i grafdatabaser.
Big Data
Var är IBM: s hybridlanseringsplatta för moln? Sju sätt att göra realtidsteknik verklig för din organisation Maskininlärning på kanten: TinyML blir stor Vad händer nästa med Cloudera? McDonald's vill 'demokratisera' maskininlärning för alla användare i sin verksamhet
Relaterade ämnen:
Datahantering Digital Transformation Robotics Internet of Things Innovation Enterprise Software 