Pagrindinė vertė, orientuota į dokumentą, stulpelių šeima, grafikas, reliacinis ... Šiandien atrodo, kad turime tiek rūšių duomenų bazių, kiek yra duomenų. Nors tai gali apsunkinti duomenų bazės pasirinkimą, tai apsunkinateisingai duomenų bazę lengviau. Žinoma, tam reikia atlikti namų darbus. Jūs susipažinote su savo duomenų bazėmis.
Vienas iš mažiausiai suprantamų duomenų bazių tipų yra grafikų duomenų bazė. Sukurta darbui su labai tarpusavyje susijusiais duomenimis, grafikų duomenų bazė gali būti apibūdinama kaip „reliacinė“ nei reliacinė duomenų bazė. Grafikų duomenų bazės šviečia, kai siekiama užfiksuoti sudėtingus santykius didžiuliuose informacijos tinkluose.
Čia yra atidžiau pažvelgta į tai, kas yra diagramų duomenų bazės, kodėl jos nepanašios į kitas duomenų bazes ir kokio tipo duomenų problemas jos yra sukurtos spręsti.
Grafikų duomenų bazė ir reliacinė duomenų bazė
Tradicinėje reliacinėje arba SQL duomenų bazėje duomenys yra suskirstyti į lenteles. Kiekvienoje lentelėje duomenys įrašomi tam tikru formatu su fiksuotu stulpelių skaičiumi, kiekvienas stulpelis su savo duomenų tipu (sveikasis skaičius, laikas / data, laisvos formos tekstas ir kt.).
Šis modelis geriausiai veikia, kai daugiausia susiduriate su bet kurios lentelės duomenimis. Tai taip pat neveikia labai blogai, kai kaupiate duomenis, saugomus keliose lentelėse. Tačiau toks elgesys turi keletą pastebimų ribų.
Apsvarstykite muzikos duomenų bazę, kurioje yra albumai, grupės, etiketės ir atlikėjai. Jei norite pranešti apie visus atlikėjus, kurie buvo rodomi tai albumą sukūrė kad grupė išleista toliau šie etiketes - keturias skirtingas lenteles - turite aiškiai apibūdinti tuos santykius. Turėdami reliacinę duomenų bazę, tai galite pasiekti naudodami naujus duomenų stulpelius (santykiams „vienas su vienu“ arba „vienas su daugeliu“) arba naujomis lentelėmis (ryšiams nuo daugelio iki daugelio).
Tai praktiška tol, kol valdote kuklų santykių skaičių. Jei turite reikalų su milijonais ar net milijardais santykių, pavyzdžiui, su draugų draugų draugais, šios užklausos nėra menkos.
Trumpai tariant, jeiduomenų ryšius, o ne patys duomenys yra jūsų pagrindinis rūpestis, tada tinka kitokio tipo duomenų bazė - grafikų duomenų bazė.
Grafikų duomenų bazės ypatybės
Terminas „grafikas“ kilęs iš žodžio naudojimo matematikoje. Ten jis naudojamas mazgų rinkiniui apibūdinti (arba viršūnės), kiekvienoje iš jų pateikiama informacija (savybes) ir su paženklintais santykiais (arba kraštai) tarp mazgų.
Socialinis tinklas yra geras grafiko pavyzdys. Tinklo žmonės būtų mazgai, kiekvieno asmens atributai (pvz., Vardas, amžius ir pan.) Būtų savybės, o linijos, jungiančios žmones (su etiketėmis, tokiomis kaip „draugas“ ar „motina“ ar „ vadovas “) nurodytų jų santykius.
Įprastoje duomenų bazėje užklausos apie santykius gali užtrukti ilgai. Taip yra dėl to, kad santykiai įgyvendinami su svetimais raktais ir jų klausiama sujungiant lenteles. Kaip jums gali pasakyti bet kuris SQL DBA, prisijungti yra brangu, ypač kai reikia rūšiuoti per daug objektų arba, dar blogiau, kai turite prisijungti prie kelių lentelių, kad atliktumėte netiesiogines (pvz., „Draugo draugo“) užklausas. kad grafikų duomenų bazės pasižymi.
Grafikų duomenų bazės veikia saugantsantykiai kartu su duomenimis. Kadangi susiję mazgai yra fiziškai susieti duomenų bazėje, prieiga prie tų ryšių yra tokia pat greita, kaip prieiga prie pačių duomenų. Kitaip tariant, vietoj to, kad apskaičiuotų santykį, kaip turi daryti reliacinės duomenų bazės, grafikų duomenų bazės tiesiog perskaito ryšį iš saugyklos. Užklausų tenkinimas yra paprastas ėjimo arba „perėjimo“ klausimas.
Grafikų duomenų bazėje ne tik saugomi santykiai tarp objektų natūraliu būdu, todėl užklausos apie santykius pateikiamos greitai ir lengvai, bet leidžia į grafiką įtraukti įvairių rūšių objektus ir skirtingų rūšių ryšius. Kaip ir kitose „NoSQL“ duomenų bazėse, grafikų duomenų bazėje nėra schemų. Taigi, kalbant apie našumą ir lankstumą, grafikų duomenų bazės priartėja prie dokumentų duomenų bazių ar pagrindinės vertės saugyklų nei reliacinės ar į lentelę orientuotos duomenų bazės.
Grafikų duomenų bazių naudojimo atvejai
Grafikų duomenų bazės geriausiai veikia, kai duomenys, su kuriais dirbate, yra labai susieti ir turėtų būti pavaizduoti pagal juos susieja arba nurodo kitus duomenis, paprastai santykių „daugeliui į daugelį“ būdu.
Vėlgi, socialinis tinklas yra naudingas pavyzdys. Grafikų duomenų bazės sumažina darbo, reikalingo socialiniuose tinkluose rastų ir rodomų duomenų rodinių, pvz., Veiklos sklaidos kanalų, sukūrimui ir nustatymui, ar jūs pažįstate konkretų asmenį dėl jo artumo kitiems jūsų turimiems draugams.
Kita grafikų duomenų bazių paraiška yra rasti ryšio grafikų duomenyse modelius, kuriuos būtų sunku išgauti naudojant kitus duomenų vaizdus. Sukčiavimo nustatymo sistemos naudoja grafikų duomenų bazes, kad atskleistų santykius tarp subjektų, kuriuos kitu atveju būtų buvę sunku pastebėti.
Panašiai grafikų duomenų bazės yra natūralus pritaikymas programoms, kurios valdo santykius ar tarpusavio priklausomybę tarp subjektų. Dažnai rasite rekomendacijų variklių, turinio ir turto valdymo sistemų, tapatybės ir prieigos valdymo sistemų, reguliavimo atitikties ir rizikos valdymo sprendimų grafikų duomenų bazes.
Grafikų duomenų bazių užklausos
Grafikų duomenų bazės, kaip ir kitos „NoSQL“ duomenų bazės, paprastai naudoja savo, o ne „SQL“, savo pasirinktą užklausų metodiką.
Viena dažniausiai naudojama grafiko užklausų kalba yra „Cypher“, iš pradžių sukurta „Neo4j“ grafų duomenų bazei. Nuo 2015 m. Pabaigos „Cypher“ buvo sukurtas kaip atskiras atvirojo kodo projektas, ir daugelis kitų tiekėjų jį priėmė kaip savo produktų užklausų sistemą (pvz., SAP HANA).
Štai „Cypher“ užklausos, kuri pateikia paieškos rezultatus visiems, kurie yra Skoto draugai, pavyzdys:
MATCH (a: Asmuo {vardas: ’Scott’}) - [: FRIENDOF] -> (b) GRĄŽINTI b Rodyklės simbolis (->) naudojamas „Cypher“ užklausose, kad pavaizduotų nukreiptą ryšį grafike.
„Apache TinkerPop“ grafų skaičiavimo sistemai buvo sukurta kita įprasta grafikų užklausų kalba - „Gremlin“. „Gremlin“ sintaksė yra panaši į tą, kurią naudoja kai kurių kalbų ORM prieigos prie duomenų bazių bibliotekos.
Štai „Skoto draugų“ užklausos Gremliuje pavyzdys:
g.V (). has („vardas“, „Scott“). out („friendof“)
Daugelis grafikų duomenų bazių palaiko „Gremlin“ kaip integruotą ar trečiųjų šalių biblioteką.
Dar viena užklausos kalba yra SPARQL. Iš pradžių jį sukūrė W3C, norėdamas pateikti užklausą metaduomenų duomenims, saugomiems išteklių aprašo sistemos (RDF) formate. Kitaip tariant, SPARQL nebuvo sugalvota grafikų duomenų bazių paieškoms, tačiau gali būti naudojamas joms. Apskritai „Cypher“ ir „Gremlin“ buvo priimti plačiau.
SPARQL užklausose yra keletas elementų, primenančių SQL, būtentPASIRINKTI ir KUR išlygų, tačiau likusi sintaksė yra kardinaliai skirtinga. Nemanykite, kad SPARQL apskritai yra susijęs su SQL arba šiuo atveju su kitomis grafikų užklausų kalbomis.
Populiarios grafikų duomenų bazės
Kadangi grafikų duomenų bazės yra gana nišinio naudojimo atvejis, jų nėra beveik tiek, kiek yra reliacinių duomenų bazių. Pliusas yra tai, kad išskirtinius produktus lengviau atpažinti ir aptarti.
Neo4j
„Neo4j“ yra lengvai brandžiausias (11 metų skaičiuojant) ir geriausiai žinomas iš grafinių duomenų bazių, skirtų bendram naudojimui. Skirtingai nei ankstesni grafikų duomenų bazės produktai, jame nenaudojama SQL vidinė sąsaja. „Neo4j“ yra gimtoji grafų duomenų bazė, sukurta iš vidaus ir palaikant dideles grafo struktūras, kaip ir užklausose, kurios pateikia šimtus tūkstančių ryšių ir dar daugiau.
„Neo4j“ yra tiek nemokamų atvirojo kodo, tiek mokamų įmonių leidimų, be kurių pastarieji neturi jokių duomenų rinkinio dydžio apribojimų (be kitų funkcijų). Taip pat galite eksperimentuoti su „Neo4j“ internetu naudodamiesi „Sandbox“, kuriame yra keletas pavyzdinių duomenų rinkinių, su kuriais galite praktikuotis.
Daugiau informacijos rasite „Neo4j“ apžvalgoje.
„Microsoft Azure Cosmos“ DB
Debesų duomenų bazė „Azure Cosmos DB“ yra ambicingas projektas. Jis skirtas imituoti kelių rūšių duomenų bazes - įprastas lenteles, orientuotas į dokumentus, stulpelių šeimą ir diagramas - per vieną, vieningą paslaugą su nuosekliu API rinkiniu.
Tuo tikslu grafikų duomenų bazė yra tik vienas iš įvairių režimų, kuriais gali veikti „Cosmos DB“. Ji naudoja „Gremlin“ užklausų kalbą ir API grafiko tipo užklausoms ir palaiko „Gremlin“ konsolę, sukurtą „Apache TinkerPop“ kaip kitą sąsają.
Kitas didelis „Cosmos DB“ pardavimo taškas yra tai, kad indeksavimas, mastelio keitimas ir geografinis replikavimas yra automatiškai tvarkomi „Azure“ debesyje, be jokio mygtuko kaitinimo jūsų gale. Kol kas nėra aišku, kaip „Microsoft“ viskas viename architektūra našumo požiūriu matuoja vietines diagramų duomenų bazes, tačiau „Cosmos DB“ tikrai siūlo naudingą lankstumo ir masto derinį.
Norėdami gauti daugiau informacijos, žr. „Azure Cosmos DB“ apžvalgą.
JanusGraph
JanusGraph buvo įtrauktas į „TitanDB“ projektą ir dabar jį valdo „Linux Foundation“. Jis naudoja bet kurį iš palaikomų galinių galų - „Apache Cassandra“, „Apache HBase“, „Google Cloud Bigtable“, „Oracle BerkeleyDB“ - grafiko duomenims saugoti, palaiko „Gremlin“ užklausos kalbą (taip pat kitus „Apache TinkerPop“ kamino elementus) ir taip pat gali įtraukti viso teksto paiešką vykdant „Apache Solr“, „Apache Lucene“ ar „Elasticsearch“ projektus.
IBM, viena iš „JanusGraph“ projekto rėmėjų, „IBM Cloud“ siūlo priglobtą „JanusGraph“ versiją, pavadinimu „Compose for JanusGraph“. Kaip ir „Azure Cosmos DB“, „Compos for JanusGraph“ suteikia automatinį mastelį ir aukštą prieinamumą, o kainos nustatomos atsižvelgiant į išteklių naudojimą.
