For tyve år siden byggede mit udviklingsteam en naturlig sprogbehandlingsmotor, der scannede beskæftigelses-, bil- og ejendomsannoncer til søgbare kategorier. Jeg vidste, at vi havde en vanskelig datastyringsudfordring. Dataene i nogle annoncetyper var relativt ligetil, som at identificere bilmærker og modeller, men andre krævede mere slutning, såsom at identificere en jobkategori baseret på en liste over færdigheder.
Vi udviklede en metadatamodel, der fangede alle de søgbare udtryk, men den naturlige sprogbehandlingsmotor krævede, at modellen udsatte betydelige metadataforhold. Vi vidste, at design af en metadatamodel med vilkårlige forbindelser mellem datapunkter i en relationsdatabase var kompleks, så vi udforskede ved hjælp af objektdatabaser til at styre modellen.
Det, vi forsøgte at udrette dengang med objektdatabaser, kan gøres bedre i dag med grafdatabaser. Grafdatabaser gemmer oplysninger som noder og data, der specificerer deres forhold til andre noder. De er dokumenterede arkitekturer til lagring af data med komplekse relationer.
Brug af grafdatabaser er bestemt vokset i løbet af det sidste årti, da virksomheder overvejede andre NoSQL- og big data-teknologier. Det globale grafdatabasemarked blev anslået til $ 651 mio. I 2018 og forventes at vokse til $ 3,73 mia. Dollar i 2026. Men mange andre store datastyringsteknologier, herunder Hadoop, Spark og andre, har set meget mere markant vækst i popularitet, vedtagelse af færdigheder og produktionsanvendelsessager sammenlignet med grafdatabaser. Til sammenligning blev markedsstørrelsen på big data-teknologien anslået til $ 36,8 mia. I 2018 og forventes at vokse til $ 104,3 mia. I 2026.
Jeg ville forstå, hvorfor flere organisationer ikke overvejer grafdatabaser. Udviklere tænker i objekter og bruger hierarkiske datarepræsentationer i XML og JSON regelmæssigt. Teknologer og forretningsinteressenter forstår i sig selv grafer, da Internettet er en sammenkoblet graf gennem hyperlinks og koncepter som venner og venner af venner fra sociale netværk. Så hvorfor har ikke flere udviklingsteam brugt grafdatabaser i deres applikationer?
Læring af forespørgselssprog i grafdatabaser
Selvom det kan være relativt let at forstå modelleringen af noder og relationer, der bruges i grafdatabaser, kræver forespørgsel på dem at lære nye metoder og færdigheder.
Lad os se på det eksempel på beregning af en liste over venner og venner af venner. For femten år siden grundlagde jeg et rejsecosialt netværk og besluttede at holde datamodellen enkel ved at gemme alt i MySQL. Tabellen, der lagrede en liste over brugere, havde en selvtilslutning til at repræsentere venner, og det var en relativt ligetil forespørgsel at udtrække en vens liste. Men at komme til en ven på en vens liste krævede en uhyre kompleks forespørgsel, der fungerede, men som ikke fungerede godt, når brugerne havde udvidede netværk.
Jeg talte med Jim Webber, chefforsker hos Neo4j, en af de etablerede grafdatabaser, om hvordan man konstruerer en forespørgsel om venner. Udviklere kan forespørge Neo4j-grafdatabaser ved hjælp af RDF (Resource Description Framework) og Gremlin, men Webber fortalte mig, at mere end 90 procent af kunderne bruger Cypher. Sådan ser forespørgslen i Cypher om udpakning af venner og venners venner ud:
MATCH (mig: Person {name: 'Rosa'}) - [: VEN * 1..2] -> (f: Person)
HVOR jeg f
TILBAGE f
Sådan forstås denne forespørgsel:
- Find mig mønsteret, hvor der er en node med etiketten Person og et egenskabsnavn: 'Rosa', og bind det til variablen "mig." Forespørgslen specificerer, at "mig" har et udgående FRIEND-forhold på dybde 1 eller 2 til en hvilken som helst anden knude med en personetiket og binder disse matches til variablen "f."
- Sørg for, at "mig" ikke er lige "f", fordi jeg er en ven af mine venner!
- Returner alle venner og venner af venner
Forespørgslen er elegant og effektiv, men har en indlæringskurve for dem, der er vant til at skrive SQL-forespørgsler. Deri ligger den første udfordring for organisationer, der bevæger sig mod grafdatabaser: SQL er et gennemgribende færdighedssæt, og Cypher og andre grafforespørgselssprog er en ny færdighed at lære.
Design af fleksible hierarkier med grafdatabaser
Produktkataloger, indholdsstyringssystemer, projektstyringsapplikationer, ERP'er og CRM'er bruger alle hierarkier til at kategorisere og mærke information. Problemet er naturligvis, at nogle oplysninger ikke er virkelig hierarkiske, og emner skal skabe en konsekvent tilgang til strukturering af informationsarkitekturen. Det kan være en smertefuld proces, især hvis der er intern debat om strukturering af informationen, eller når slutbrugere af applikationer ikke kan finde de oplysninger, de søger, fordi de er i en anden del af hierarkiet.
Ikke kun muliggør grafdatabaser vilkårlige hierarkier, men de gør det også muligt for udviklere at oprette forskellige visninger af hierarkiet til forskellige behov. For eksempel kan denne artikel om grafdatabaser vises under hierarkier i et indholdsstyringssystem til datastyring, nye teknologier, industrier, der sandsynligvis bruger grafdatabaser, almindelige grafdatabaseanvendelsessager eller efter teknologiroller. En anbefalingsmotor har derefter et meget rigere sæt data, der matcher indhold med brugernes interesse.
Jeg talte med Mark Klusza, medstifter af Construxiv, et firma, der sælger teknologier til byggebranchen, herunder Grit, en platform til byggeplanlægning. Hvis du ser på et tidsplan for et kommercielt byggeprojekt, vil du se referencer til flere handler, udstyr, dele og modelreferencer. En enkelt arbejdspakke kan let have hundreder af opgaver med afhængigheder i projektplanen. Disse planer skal integrere data fra ERP'er, bygningsinformationsmodellering og andre projektplaner og præsentere visninger til planlæggere, projektledere og underleverandører. Klusza forklarede, ”Ved at bruge en grafdatabase i Grit skaber vi meget rigere forhold til, hvem der laver hvad, hvornår, hvor, med hvilket udstyr og med hvilke materialer. Det gør det muligt for os at personalisere synspunkter og bedre forudsige konflikter mellem jobplanlægning. ”
For at drage fordel af fleksible hierarkier hjælper det med at designe applikationer fra bunden med en grafdatabase. Hele applikationen er derefter designet baseret på forespørgsel på grafen og udnyttelse af noder, relationer, etiketter og egenskaber for grafen.
Indstillinger for skyudrulning reducerer operationelle kompleksiteter
Implementering af datastyringsløsninger i et datacenter er ikke trivielt. Infrastruktur og drift skal overveje sikkerhedskrav; gennemgå ydeevneovervejelser for at opgradere servere, lager og netværk og også operationelle replikerede systemer til katastrofegendannelse.
Organisationer, der eksperimenterer med grafdatabaser, har nu flere skyindstillinger. Ingeniører kan implementere Neo4j til GCP, AWS, Azure eller udnytte Neo4j's Aura, en database som en tjeneste. TigerGraph har et skyudbud og startpakker til brugssager som kund 360, afsløring af svig, anbefalingsmotorer, analyse af sociale netværk og analyse af forsyningskæden. De offentlige cloud-leverandører har også grafdatabasefunktioner, herunder AWS Neptune, Gremlin API i Azure's CosmoDB, open source JanusGraph på GCP eller graffunktionerne i Oracle's Cloud Database Services.
Jeg vender tilbage til mit oprindelige spørgsmål. Med alle de interessante brugstilfælde, modne grafdatabaseplatforme til rådighed, muligheder for at lære grafdatabaseudvikling og skyimplementeringsmuligheder, hvorfor bruger ikke flere teknologiorganisationer grafdatabaser?
