For tjue år siden bygde utviklingsteamet mitt en naturlig språkbehandlingsmotor som skannet annonser for annonser, biler og eiendommer for søkbare kategorier. Jeg visste at vi hadde en vanskelig datastyringsutfordring. Dataene i noen annonsetyper var relativt enkle, som å identifisere bilmerker og modeller, men andre krevde mer slutning, for eksempel å identifisere en stillingskategori basert på en liste over ferdigheter.
Vi utviklet en metadatamodell som fanget alle søkbare termer, men den naturlige språkbehandlingsmotoren krevde at modellen skulle avsløre betydelige metadataforhold. Vi visste at utformingen av en metadatamodell med vilkårlige forbindelser mellom datapunkter i en relasjonsdatabase var kompleks, så vi utforsket ved hjelp av objektdatabaser for å administrere modellen.
Det vi prøvde å oppnå den gang med objektdatabaser, kan gjøres bedre i dag med grafdatabaser. Grafdatabaser lagrer informasjon som noder og data som spesifiserer deres forhold til andre noder. De er velprøvde arkitekturer for lagring av data med komplekse forhold.
Bruk av grafdatabaser har absolutt vokst det siste tiåret ettersom selskaper vurderte andre NoSQL- og big data-teknologier. Det globale grafdatabasemarkedet ble anslått til $ 651 millioner i 2018 og forventet å vokse til $ 3,73 milliarder dollar innen 2026. Men mange andre store datahåndteringsteknologier, inkludert Hadoop, Spark og andre, har sett mye mer betydelig vekst i popularitet, ferdighetsadopsjon, og produksjonsbrukstilfeller sammenlignet med grafdatabaser. Til sammenligning ble markedsstørrelsen på big data-teknologien estimert til 36,8 milliarder dollar i 2018 og forventet å vokse til 104,3 milliarder dollar innen 2026.
Jeg ønsket å forstå hvorfor flere organisasjoner ikke vurderer grafdatabaser. Utviklere tenker objekter og bruker hierarkiske datarepresentasjoner i XML og JSON regelmessig. Teknologer og forretningsinteressenter forstår iboende grafer siden Internett er en sammenkoblet graf gjennom hyperkoblinger og konsepter som venner og venner av venner fra sosiale nettverk. Så hvorfor har ikke flere utviklingsteam brukt grafdatabaser i applikasjonene sine?
Lære spørringsspråkene til grafdatabaser
Selv om det kan være relativt enkelt å forstå modelleringen av noder og relasjoner som brukes i grafdatabaser, krever det å lære nye metoder og ferdigheter å spørre dem.
La oss se på eksemplet på å beregne en liste over venner og venner av venner. For femten år siden grunnla jeg et sosialt nettverk for reiser og bestemte meg for å holde datamodellen enkel ved å lagre alt i MySQL. Tabellen som lagret en liste over brukere, hadde en egen deltakelse for å representere venner, og det var et relativt greit spørsmål å trekke ut en venneliste. Men for å komme til en venneliste for en venn, var det et uhyre komplekst spørsmål som fungerte, men som ikke fungerte bra når brukerne hadde utvidede nettverk.
Jeg snakket med Jim Webber, sjefforsker ved Neo4j, en av de etablerte grafdatabasene som er tilgjengelige, om hvordan du lager et vennevennspørsmål. Utviklere kan spørre Neo4j-grafdatabaser ved hjelp av RDF (Resource Description Framework) og Gremlin, men Webber fortalte meg at mer enn 90 prosent av kundene bruker Cypher. Slik ser spørringen ut i Cypher for å trekke ut venner og venner av venner:
MATCH (meg: Person {name: 'Rosa'}) - [: VENN * 1..2] -> (f: Person)
HVOR jeg f
RETUR f
Slik forstår du dette spørsmålet:
- Finn meg mønsteret der det er en node med etiketten Person og et eiendomsnavn: 'Rosa', og bind det til variabelen "meg." Spørringen spesifiserer at "meg" har et utgående FRIEND-forhold på dybde 1 eller 2 til en hvilken som helst annen node med en Person-etikett, og binder disse treffene til variabelen "f."
- Forsikre deg om at "meg" ikke er lik "f", fordi jeg er en venn av vennene mine!
- Returner alle vennene og vennene til vennene
Spørringen er elegant og effektiv, men har en læringskurve for de som er vant til å skrive SQL-spørsmål. Der ligger den første utfordringen for organisasjoner som beveger seg mot grafdatabaser: SQL er et omfattende ferdighetssett, og Cypher og andre grafspørsmål er en ny ferdighet å lære.
Designe fleksible hierarkier med grafdatabaser
Produktkataloger, innholdsstyringssystemer, prosjektledelsesapplikasjoner, ERP og CRM bruker alle hierarkier for å kategorisere og merke informasjon. Problemet er selvfølgelig at informasjon ikke er virkelig hierarkisk, og emner må skape en konsekvent tilnærming til strukturering av informasjonsarkitekturen. Det kan være en smertefull prosess, spesielt hvis det er intern debatt om strukturering av informasjonen, eller når sluttbrukere av applikasjoner ikke finner informasjonen de søker, fordi den er i en annen del av hierarkiet.
Ikke bare aktiverer grafdatabaser vilkårlige hierarkier, men de gjør det også mulig for utviklere å lage forskjellige visninger av hierarkiet for forskjellige behov. For eksempel kan denne artikkelen om grafdatabaser vises under hierarkier i et innholdshåndteringssystem for datahåndtering, nye teknologier, bransjer som sannsynligvis vil bruke grafdatabaser, vanlige grafdatabaser eller etter teknologiroller. En anbefalingsmotor har da et mye rikere datasett for å matche innhold med brukerinteressen.
Jeg snakket med Mark Klusza, medstifter av Construxiv, et selskap som selger teknologier til byggebransjen, inkludert Grit, en plattform for byggeplanlegging. Hvis du ser på tidsplanen for et kommersielt byggeprosjekt, vil du se referanser til flere handler, utstyr, deler og modellreferanser. En enkelt arbeidspakke kan lett ha hundrevis av oppgaver med avhengigheter i prosjektplanen. Disse planene må integrere data fra ERP, bygningsinformasjonsmodellering og andre prosjektplaner og presentere visninger til planleggere, prosjektledere og underleverandører. Klusza forklarte: “Ved å bruke en grafdatabase i Grit skaper vi mye rikere forhold til hvem som gjør hva, når, hvor, med hvilket utstyr og med hvilke materialer. Det gjør det mulig for oss å tilpasse synspunkter og forutsi bedre konflikter med jobbplanlegging. ”
For å dra nytte av fleksible hierarkier hjelper det å designe applikasjoner fra grunnen av med en grafdatabase. Hele applikasjonen er deretter designet basert på spørring av grafen og utnyttelse av noder, relasjoner, etiketter og egenskaper til grafen.
Alternativer for distribusjon av skyer reduserer operasjonelle kompleksiteter
Å distribuere datastyringsløsninger i et datasenter er ikke trivielt. Infrastruktur og drift må ta hensyn til sikkerhetskrav; gjennomgå ytelseshensyn for å oppgradere servere, lagring og nettverk; og også operasjonalisere replikerte systemer for katastrofegjenoppretting.
Organisasjoner som eksperimenterer med grafdatabaser har nå flere skyalternativer. Ingeniører kan distribuere Neo4j til GCP, AWS, Azure eller utnytte Neo4j’s Aura, en database som en tjeneste. TigerGraph har et skytilbud og startsett for brukstilfeller som kunde 360, svindeloppdagelse, anbefalingsmotorer, sosiale nettverksanalyser og analyse av forsyningskjeder. De offentlige skyleverandørene har også grafdatabasefunksjoner, inkludert AWS Neptune, Gremlin API i Azure's CosmoDB, åpen kildekode JanusGraph på GCP, eller graffunksjonene i Oracles Cloud Database Services.
Jeg kommer tilbake til det opprinnelige spørsmålet mitt. Med alle de interessante bruksområdene, modne grafdatabaseplattformer tilgjengelig, muligheter for å lære grafdatabaseutvikling og skyutplasseringsalternativer, hvorfor bruker ikke flere teknologiorganisasjoner grafdatabaser?
