Pred dvajsetimi leti je moja razvojna ekipa zgradila mehanizem za obdelavo naravnega jezika, ki je skeniral oglase o zaposlitvi, avtomobilih in nepremičninah za iskalne kategorije. Vedel sem, da imamo težek izziv upravljanja podatkov. Podatki o nekaterih vrstah oglasov so bili razmeroma enostavni, na primer prepoznavanje znamk avtomobilov in modelov, drugi pa so zahtevali več sklepov, na primer opredelitev kategorije delovnega mesta na podlagi seznama spretnosti.
Razvili smo model metapodatkov, ki je zajel vse iskalne izraze, vendar je mehanizem za obdelavo naravnega jezika zahteval, da model razkrije pomembna razmerja metapodatkov. Vedeli smo, da je bilo načrtovanje modela metapodatkov s poljubnimi povezavami med podatkovnimi točkami v relacijski bazi podatkov zapleteno, zato smo raziskovali uporabo objektnih podatkovnih baz za upravljanje modela.
To, kar smo takrat poskušali doseči z objektnimi bazami podatkov, lahko danes z grafičnimi bazami podatkov naredimo bolje. Grafične zbirke podatkov hranijo podatke kot vozlišča in podatke, ki določajo njihove odnose z drugimi vozlišči. So preverjena arhitektura za shranjevanje podatkov s kompleksnimi odnosi.
Uporaba grafičnih baz podatkov se je v zadnjem desetletju zagotovo povečala, saj so podjetja upoštevala druge tehnologije NoSQL in velike podatkovne baze. Svetovni trg podatkovnih baz grafov je bil leta 2018 ocenjen na 651 milijonov dolarjev, po napovedih pa naj bi do leta 2026 zrasel na 3,73 milijarde dolarjev. Toda številne druge tehnologije za upravljanje velikih podatkov, vključno s Hadoop, Spark in drugimi, so zabeležile veliko pomembnejšo rast priljubljenosti, sprejetja spretnosti in izkušenj, in primeri uporabe v primerjavi s podatkovnimi bazami grafov. Za primerjavo: velikost trga za podatkovne tehnologije je bila leta 2018 ocenjena na 36,8 milijarde USD, po napovedih pa naj bi do leta 2026 narasla na 104,3 milijarde USD.
Želel sem razumeti, zakaj več organizacij ne razmišlja o podatkovnih bazah grafov. Razvijalci razmišljajo v objektih in redno uporabljajo hierarhične predstavitve podatkov v XML in JSON. Tehnologi in poslovne zainteresirane strani po sebi razumejo grafe, saj je internet medsebojno povezan graf prek hiperpovezav in konceptov, kot so prijatelji in prijatelji prijateljev iz družabnih omrežij. Zakaj potem več razvojnih skupin v svojih aplikacijah ne uporablja podatkovnih baz grafov?
Učenje poizvedbenih jezikov grafičnih baz podatkov
Čeprav je lahko relativno enostavno razumeti modeliranje vozlišč in razmerij, ki se uporabljajo v podatkovnih bazah grafov, zahteva poizvedovanje zanje učenje novih praks in veščin.
Oglejmo si ta primer izračunavanja seznama prijateljev in prijateljev prijateljev. Pred petnajstimi leti sem ustanovil potovalno družabno omrežje in se odločil, da bom podatkovni model poenostavil tako, da vse shranim v MySQL. Tabela, v kateri je bil seznam uporabnikov, se je samostojno pridružila za zastopanje prijateljev in bila je razmeroma preprosta poizvedba za izvlečenje seznama prijateljev. Toda dostop do prijatelja s seznama prijateljev je zahteval pošastno zapleteno poizvedbo, ki je delovala, vendar ni bila uspešna, ko so imeli uporabniki razširjena omrežja.
O tem, kako sestaviti poizvedbo prijateljev prijateljev, sem se pogovarjal z Jimom Webberjem, glavnim znanstvenikom pri Neo4j, eni izmed vzpostavljenih zbirk podatkov o grafih. Razvijalci lahko poizvedujejo po podatkovnih bazah grafov Neo4j z uporabo RDF (Resource Description Framework) in Gremlin, toda Webber mi je povedal, da več kot 90 odstotkov strank uporablja Cypher. Evo, kako izgleda poizvedba v programu Cypher za pridobivanje prijateljev in prijateljev prijateljev:
UTEK (jaz: Oseba {ime: 'Rosa'}) - [: PRIJATELJ * 1..2] -> (f: Oseba)
KJE me f
VRNITEV f
To poizvedbo razumemo tako:
- Poiščite mi vzorec, kjer je vozlišče z oznako Oseba in imenom lastnosti: 'Rosa', in ga povežite s spremenljivko "jaz". Poizvedba določa, da ima "jaz" odhodno razmerje PRIJATELJ na globini 1 ali 2 do katerega koli drugega vozlišča z oznako Person, in ta ujemanja veže na spremenljivko "f".
- Prepričajte se, da "jaz" ni enak "f", ker sem prijatelj svojih prijateljev!
- Vrnite vse prijatelje in prijatelje prijateljev
Poizvedba je elegantna in učinkovita, vendar ima krivuljo učenja za tiste, ki se uporabljajo za pisanje poizvedb SQL. V tem je prvi izziv za organizacije, ki se pomikajo proti podatkovnim bazam grafov: SQL je razširjen nabor spretnosti, Cypher in drugi jeziki za poizvedovanje grafov pa so nova veščina za učenje.
Oblikovanje prilagodljivih hierarhij z bazami grafov
Katalogi izdelkov, sistemi za upravljanje vsebin, aplikacije za upravljanje projektov, ERP in CRM uporabljajo hierarhije za razvrščanje in označevanje informacij. Težava je seveda v tem, da nekatere informacije niso resnično hierarhične, tematike pa morajo ustvarjati skladen pristop k strukturiranju informacijske arhitekture. To je lahko boleč postopek, zlasti če obstaja notranja razprava o strukturiranju informacij ali ko končni uporabniki aplikacije ne najdejo iskanih informacij, ker so v drugem delu hierarhije.
Grafične zbirke podatkov ne omogočajo samo poljubnih hierarhij, ampak tudi razvijalcem omogočajo, da ustvarijo različne poglede na hierarhijo za različne potrebe. Na primer, ta članek o podatkovnih bazah grafov se lahko prikaže pod hierarhijami v sistemu za upravljanje vsebin za upravljanje podatkov, nastajajoče tehnologije, panoge, ki bodo verjetno uporabljale podatkovne zbirke grafov, običajne primere uporabe zbirke podatkov grafov ali vloge tehnologije. Stroj za priporočila ima nato veliko bogatejši nabor podatkov, da se vsebina ujema z zanimanjem uporabnikov.
Govoril sem z Markom Kluszo, soustanoviteljem Construxiva, podjetja, ki prodaja tehnologije gradbeni industriji, vključno z Gritom, platformo za načrtovanje gradbenih del. Če pogledate urnik komercialnega gradbenega projekta, boste videli sklice na več obrti, opremo, dele in reference modelov. En sam delovni paket ima lahko na stotine nalog z odvisnostmi v načrtu projekta. Ti načrti morajo vključevati podatke iz ERP-jev, informacijskega modeliranja zgradb in drugih projektnih načrtov ter predstaviti poglede načrtovalcem, vodjem projektov in podizvajalcem. Klusza je pojasnil: »Z uporabo zbirke grafov v Grit-u ustvarimo veliko bogatejše odnose s tem, kdo kaj počne, kdaj, kje, s katero opremo in s katerimi materiali. To nam omogoča prilagajanje pogledov in boljše napovedovanje konfliktov pri razporejanju delovnih mest. «
Če želite izkoristiti prilagodljive hierarhije, pomaga pri načrtovanju aplikacij od temeljev z bazo podatkov grafov. Nato je celotna aplikacija zasnovana na podlagi poizvedovanja grafa in izkoriščanja vozlišč, odnosov, oznak in lastnosti grafa.
Možnosti uvajanja v oblaku zmanjšujejo operativne zapletenosti
Uvajanje rešitev za upravljanje podatkov v podatkovni center ni nepomembno. Infrastruktura in operacije morajo upoštevati varnostne zahteve; pregledati pomisleke glede zmogljivosti za povečanje strežnikov, pomnilnika in omrežij; in tudi operacionalizirati ponovljene sisteme za obnovo po nesrečah.
Organizacije, ki eksperimentirajo z grafičnimi bazami podatkov, imajo zdaj več možnosti v oblaku. Inženirji lahko Neo4j uvedejo v GCP, AWS, Azure ali izkoristijo Neu4jevo Auro, bazo podatkov kot storitev. TigerGraph ponuja ponudbo v oblaku in začetne komplete za primere uporabe, kot so stranka 360, odkrivanje goljufij, priporočilni mehanizmi, analiza socialnih omrežij in analiza dobavne verige. Javni prodajalci v oblaku imajo tudi zmogljivosti zbirke podatkov grafov, vključno z AWS Neptunom, API-jem Gremlin v Azurejevem CosmoDB, odprtokodnim JanusGraphom na GCP ali grafičnimi funkcijami v storitvah Oracle's Cloud Database Services.
Vrnem se k prvotnemu vprašanju. Zakaj z vsemi zanimivimi primeri uporabe, na voljo zrele platforme baz podatkov grafov, priložnosti za učenje razvoja baz podatkov grafov in možnosti uvajanja v oblaku, zakaj več tehnoloških organizacij ne uporablja graf baz podatkov?
