Prieš dvidešimt metų mano kūrėjų komanda sukūrė natūralios kalbos apdorojimo variklį, kuris skenavo įdarbinimo, automobilių ir nekilnojamojo turto skelbimus pagal ieškomas kategorijas. Žinojau, kad mums iškilo sunkus iššūkis duomenų valdymui. Kai kurių skelbimų tipų duomenys buvo palyginti nesudėtingi, pvz., Automobilių markių ir modelių identifikavimas, tačiau kitiems reikėjo daugiau išvadų, pavyzdžiui, nustatant darbo kategoriją pagal įgūdžių sąrašą.
Mes sukūrėme metaduomenų modelį, kuris užfiksavo visus ieškomus terminus, tačiau natūralios kalbos apdorojimo variklis reikalavo, kad modelis atskleistų reikšmingus metaduomenų ryšius. Žinojome, kad sukurti metaduomenų modelį su savavališku ryšiu tarp duomenų taškų reliacinėje duomenų bazėje buvo sudėtinga, todėl mes ištyrėme, kaip valdyti modelį naudodami objektų duomenų bazes.
Tai, ką tada bandėme pasiekti naudodami objektų duomenų bazes, šiandien geriau galima padaryti naudojant grafikų duomenų bazes. Grafikų duomenų bazėse informacija saugoma kaip mazgai ir duomenys, nurodantys jų sąsajas su kitais mazgais. Jie yra patikrintos architektūros, skirtos saugoti duomenis su sudėtingais ryšiais.
Grafikų duomenų bazių naudojimas per pastarąjį dešimtmetį neabejotinai išaugo, kai įmonės svarstė kitas NoSQL ir didžiųjų duomenų technologijas. Apskaičiuota, kad 2018 m. Pasaulinė grafikų duomenų bazių rinka siekė 651 mln. JAV dolerių, ir prognozuojama, kad iki 2026 m. Ji išaugs iki 3,73 mlrd. JAV dolerių. Tačiau daugelyje kitų didžiųjų duomenų valdymo technologijų, įskaitant „Hadoop“, „Spark“ ir kt., Pastebimas žymiai didesnis populiarumas, įgūdžių pritaikymas, ir gamybos naudojimo atvejai, palyginti su grafikų duomenų bazėmis. Palyginimui, apskaičiuota, kad 2018 m. Didžiųjų duomenų technologijų rinkos dydis siekė 36,8 mlrd. USD ir prognozuojama, kad iki 2026 m. Jis išaugs iki 104,3 mlrd. USD.
Norėjau suprasti, kodėl daugiau organizacijų nesvarsto grafikų duomenų bazių. Kūrėjai mąsto objektuose ir reguliariai naudoja hierarchinius duomenų pateikimus XML ir JSON. Technologai ir verslo suinteresuotieji subjektai iš esmės supranta grafikus, nes internetas yra sujungtas grafikas per hipersaitus ir tokias sąvokas kaip draugai ir draugų draugai iš socialinių tinklų. Tada kodėl daugiau kūrėjų komandų nenaudojo grafikų duomenų bazių savo programose?
Mokomės grafikų duomenų bazių užklausų kalbų
Nors gali būti gana lengva suvokti mazgų ir ryšių, naudojamų grafikų duomenų bazėse, modeliavimą, norint atlikti jų užklausą, reikia išmokti naujos praktikos ir įgūdžių.
Pažvelkime į draugų ir draugų draugų sąrašo skaičiavimo pavyzdį. Prieš penkiolika metų įkūriau kelionių socialinį tinklą ir nusprendžiau, kad duomenų modelis būtų paprastas, viską išsaugodamas „MySQL“. Lentelėje, kurioje saugomas vartotojų sąrašas, buvo savaime prisijungta, kad atstovautų draugams, ir buvo gana paprasta užklausa išgauti draugų sąrašą. Bet norint patekti į draugo sąrašo draugą reikėjo siaubingai sudėtingos užklausos, kuri veikė, bet neveikė gerai, kai vartotojai turėjo išplėstinius tinklus.
Apie tai, kaip sukurti draugų draugų užklausą, kalbėjau su „Neo4j“, vienos iš sukurtų grafikų duomenų bazių, vyriausiuoju mokslininku Jimu Webberiu. Kūrėjai gali pateikti užklausas „Neo4j“ grafikų duomenų bazėse naudodami „RDF“ („Resource Description Framework“) ir „Gremlin“, tačiau Webberis man pasakė, kad daugiau nei 90 procentų klientų naudoja „Cypher“. Štai kaip atrodo „Cypher“ užklausa, kaip išgauti draugus ir draugų draugus:
RENGIMAS (aš: Asmuo {vardas: 'Rosa'}) - [: DRAUGAS * 1..2] -> (f: Asmuo)
KUR aš f
GRĄŽINIMAS f
Štai kaip suprasti šią užklausą:
- Suraskite man modelį, kuriame yra mazgas su etikete „Person“ ir nuosavybės pavadinimu „Rosa“, ir susiekite jį su kintamuoju „me“. Užklausoje nurodoma, kad „aš“ turi išeinantį FRIEND ryšį 1 ar 2 gylyje su bet kuriuo kitu mazgu su etikete „Person“ ir susieja tas atitiktis su kintamuoju „f“.
- Įsitikinkite, kad „aš“ nėra lygus „f“, nes aš esu savo draugų draugas!
- Grąžinkite visus draugus ir draugų draugus
Užklausa yra elegantiška ir efektyvi, tačiau turi mokymosi kreivę tiems, kurie įpratę rašyti SQL užklausas. Čia slypi pirmasis iššūkis organizacijoms, judančioms link grafiko duomenų bazių: SQL yra įprastas įgūdžių rinkinys, o „Cypher“ ir kitos grafikų užklausų kalbos yra naujas įgūdis, kurio reikia išmokti.
Lanksčių hierarchijų su grafikų duomenų bazėmis kūrimas
Produktų katalogai, turinio valdymo sistemos, projektų valdymo programos, ERP ir CRM naudoja hierarchijas informacijai suskirstyti ir žymėti. Žinoma, problema yra ta, kad dalis informacijos nėra iš tikrųjų hierarchinė, o dalykai turi sukurti nuoseklų požiūrį į informacijos architektūros struktūrizavimą. Tai gali būti skausmingas procesas, ypač jei vyksta vidinės diskusijos dėl informacijos struktūrizavimo arba kai programos galutiniai vartotojai negali rasti ieškomos informacijos, nes ji yra kitoje hierarchijos dalyje.
Grafikų duomenų bazės ne tik įgalina savavališkas hierarchijas, bet ir leidžia kūrėjams kurti skirtingus hierarchijos vaizdus skirtingiems poreikiams. Pavyzdžiui, šis straipsnis apie grafikų duomenų bazes gali būti rodomas turinio valdymo sistemos hierarchijose, skirtose duomenų valdymui, besikuriančioms technologijoms, pramonės šakoms, kurios greičiausiai naudos grafikų duomenų bazes, įprastiems grafikų duomenų bazių naudojimo atvejams arba pagal technologinius vaidmenis. Tuomet rekomendacijų variklis turi daug turtingesnį duomenų rinkinį, kad turinys atitiktų vartotojo susidomėjimą.
Kalbėjausi su „Construxiv“, įmonės, parduodančios technologijas statybų pramonei, įskaitant statybų planavimo platformą „Grit“, įkūrėju Marku Klusza. Jei pažvelgsite į komercinio statybos projekto tvarkaraštį, pamatysite nuorodas į kelis sandorius, įrangą, dalis ir modelių nuorodas. Viename darbo pakete gali būti šimtai užduočių, kurių projekto plane yra priklausomybių. Šie planai turi apimti duomenis iš ERP, pastatų informacijos modeliavimo ir kitų projekto planų ir pateikti nuomones planuotojams, projektų vadovams ir subrangovams. Klusza paaiškino: „Naudodami grafų duomenų bazę„ Grit “, mes sukuriame daug turtingesnius santykius, kas ką, kada, kur, su kokia įranga ir kokia medžiaga daro. Tai leidžia mums suasmeninti nuomones ir geriau prognozuoti darbo planavimo konfliktus “.
Norint pasinaudoti lanksčiomis hierarchijomis, tai padeda kurti programas nuo pat pradžių naudojant grafikų duomenų bazę. Tada visa programa yra sukurta remiantis užklausomis apie grafiką ir panaudojant grafo mazgus, ryšius, etiketes ir ypatybes.
Debesies diegimo parinktys sumažina operacijų sudėtingumą
Duomenų valdymo sprendimų diegimas į duomenų centrą nėra trivialus. Infrastruktūroje ir operacijose turi būti atsižvelgiama į saugumo reikalavimus; peržiūrėti serverių, saugyklos ir tinklų dydžio didinimo našumą; taip pat eksploatuoti atkartotas sistemas atkūrimo atveju.
Organizacijos, eksperimentuojančios su grafikų duomenų bazėmis, dabar turi keletą debesų parinkčių. Inžinieriai gali įdiegti „Neo4j“ į GCP, AWS, „Azure“ arba panaudoti „Neo4j’s Aura“ - duomenų bazę kaip paslaugą. „TigerGraph“ turi debesies pasiūlymus ir pradinius rinkinius, skirtus naudoti tokiems atvejams kaip „Customer 360“, sukčiavimo nustatymas, rekomendacijų varikliai, socialinių tinklų analizė ir tiekimo grandinės analizė. Be to, viešieji debesų tiekėjai turi grafikų duomenų bazių galimybes, įskaitant „AWS Neptune“, „Gremlin“ API „Azure“ „CosmoDB“, atvirojo kodo „JanusGraph“ GCP arba „Oracle“ „Cloud Database Services“ diagramų funkcijas.
Grįžtu prie savo pirminio klausimo. Atsižvelgiant į visus įdomius naudojimo atvejus, galimas brandžių grafikų duomenų bazių platformas, galimybes mokytis grafikų duomenų bazių kūrimo ir debesies diegimo galimybes, kodėl daugiau technologijų organizacijų nenaudoja grafikų duomenų bazių?
