Ohjelmointi

Mikä on kaaviotietokanta? Parempi tapa tallentaa yhdistettyjä tietoja

Avainarvo, asiakirjapainotteinen, sarakeperhe, kaavio, relaatio ... Nykyään näyttää siltä, ​​että meillä on niin monenlaisia ​​tietokantoja kuin dataa. Vaikka tämä saattaa vaikeuttaa tietokannan valitsemista, se tekeeoikein tietokanta helpompaa. Tietysti se vaatii kotitehtävien tekemistä. Olet oppinut tuntemaan tietokantasi.

Yksi kaikkein vähiten ymmärretyistä tietokantatyypeistä on kaaviotietokanta. Suunniteltu työskentelemään hyvin toisiinsa kytkettyjen tietojen kanssa, kaaviotietokantaa voidaan kuvata enemmän "relaationa" kuin relaatiotietokantaa. Kuvaajatietokannat loistavat, kun tavoitteena on kaapata monimutkaiset suhteet suuriin tietoverkoihin.

Tässä on tarkempi kuvaus siitä, mitä kaaviotietokannat ovat, miksi ne ovat toisin kuin muut tietokannat ja millaisia ​​dataongelmia ne on rakennettu ratkaisemaan.

Kuvaajatietokanta vs. relaatiotietokanta

Perinteisessä relaatio- tai SQL-tietokannassa tiedot on järjestetty taulukoiksi. Kukin taulukko tallentaa tiedot tietyssä muodossa kiinteällä lukumäärällä sarakkeita, jokaisella sarakkeella on oma tietotyyppinsä (kokonaisluku, aika / päivämäärä, vapaamuotoinen teksti jne.).

Tämä malli toimii parhaiten, kun käsittelet pääasiassa minkä tahansa taulukon tietoja. Se ei myöskään toimi liian huonosti, kun kootaan useita taulukkoja koskevia tietoja. Mutta tällä käyttäytymisellä on joitain merkittäviä rajoja.

Harkitse musiikkitietokantaa, johon kuuluvat albumit, bändit, levy-yhtiöt ja esiintyjät. Jos haluat ilmoittaa kaikista esiintyjistä, jotka olivat esillä Tämä albumin tekijä että bändi julkaistu nämä tunnisteet - neljä erilaista taulukkoa - sinun on nimenomaisesti kuvattava nämä suhteet. Relaatiotietokannan avulla saavutat tämän uusien tietosarakkeiden (yksi-yhteen tai yksi-moni-suhteiden) tai uusien taulukkojen (monta-monelle-suhteiden) avulla.

Tämä on käytännöllistä, kunhan hoidat vaatimaton määrä suhteita. Jos olet tekemisissä miljoonien tai jopa miljardien suhteiden kanssa - esimerkiksi ystävien ystävien ystävien kanssa -, nämä kyselyt eivät ole mittakaavassa.

Lyhyesti sanottuna, jostietojen väliset suhteet, eivät itse tiedot, ovat tärkein huolenaiheenne, niin eräänlainen tietokanta - kaaviotietokanta - on kunnossa.

Kuvaajatietokannan ominaisuudet

Termi "kaavio" tulee sanan käytöstä matematiikassa. Siellä sitä käytetään kuvaamaan solmujen kokoelmaa (tai kärjet), joista jokainen sisältää tietoja (ominaisuudet) ja merkittyjen suhteiden kanssa (tai reunat) solmujen välillä.

Sosiaalinen verkosto on hyvä esimerkki kaaviosta. Verkon ihmiset olisivat solmut, kunkin henkilön määritteet (kuten nimi, ikä ja niin edelleen) olisivat ominaisuuksia ja linjat, jotka yhdistävät ihmisiä (tunnisteilla kuten "ystävä", "äiti" tai " esimies ”) ilmoittaisi heidän suhteestaan.

Perinteisessä tietokannassa suhteita koskevien kyselyjen käsittely voi kestää kauan. Tämä johtuu siitä, että suhteet toteutetaan ulkomaisilla avaimilla ja kysytään yhdistämällä taulukoita. Kuten mikä tahansa SQL DBA voi kertoa, liittymisten suorittaminen on kallista, varsinkin kun sinun on lajiteltava suuri määrä esineitä - tai mikä vielä pahempaa, kun sinun on liitettävä useita taulukoita suorittaaksesi erilaisia ​​epäsuoria (esim. "Kaverin ystävä") kyselyjä että kaaviotietokannat ovat erinomaisia.

Kuvaajatietokannat toimivat tallentamallasuhteita yhdessä tietojen kanssa. Koska siihen liittyvät solmut ovat fyysisesti linkitettyjä tietokantaan, näiden suhteiden käyttäminen on yhtä nopeaa kuin itse tietojen käyttö. Toisin sanoen sen sijaan, että laskettaisiin suhde relaatiotietokantojen täytyy tehdä, graafitietokannat yksinkertaisesti lukevat suhteen varastosta. Kyselyjen tyydyttäminen on yksinkertainen asia kävelemisestä eli kaavion käymisestä.

Kaaviotietokanta ei vain tallenna esineiden välisiä suhteita natiivilla tavalla, mikä tekee suhdetta koskevista kyselyistä nopeaa ja helppoa, mutta sen avulla voit sisällyttää kaavioon erilaisia ​​objekteja ja erilaisia ​​suhteita. Kuten muutkin NoSQL-tietokannat, kaaviotietokanta on skeematon. Siten suorituskyvyn ja joustavuuden suhteen graafiset tietokannat ovat lähempänä dokumenttitietokantoja tai avainarvovarastoja kuin relaatio- tai taulukko-suuntautuneet tietokannat.

Kuvaajatietokannan käyttötapaukset

Kaaviotietokannat toimivat parhaiten, kun työskentelemäsi data on hyvin yhteydessä toisiinsa, ja niiden tulisi edustaa niiden tapaa linkittää tai viittaa muihin tietoihin, tyypillisesti monista moniin-suhteiden kautta.

Jälleen sosiaalinen verkosto on hyödyllinen esimerkki. Kuvaajatietokannat vähentävät työn määrää, jota tarvitaan sosiaalisten verkostojen datanäkymien, kuten toimintosyötteiden, rakentamiseen ja näyttämiseen tai sen määrittämiseen, tunnetko tietyn henkilön, koska hän on lähellä muita verkossa olevia ystäviäsi.

Toinen kaaviotietokantojen sovellus on löytää yhteysmalleja kaaviotiedoista, joita olisi vaikea kiusata muiden datan esitysten kautta. Petosten havaitsemisjärjestelmät käyttävät graafitietokantoja valaisemaan suhteita entiteettien välillä, joita muuten olisi ollut vaikea huomata.

Vastaavasti kaaviotietokannat sopivat luonnollisesti sovelluksiin, jotka hallitsevat entiteettien välisiä suhteita tai keskinäisiä riippuvuuksia. Löydät usein kaaviotietokantoja suosituskoneiden, sisällön ja omaisuudenhallintajärjestelmien, identiteetin ja käyttöoikeuksien hallintajärjestelmien sekä sääntelyn noudattamisen ja riskienhallinnan ratkaisujen takana.

Kuvaajatietokannan kyselyt

Kuvaajatietokannat - kuten muut NoSQL-tietokannat - käyttävät yleensä omaa kyselymenetelmäänsä SQL: n sijaan.

Yksi yleisesti käytetty graafikyselykieli on Cypher, joka on alun perin kehitetty Neo4j-graafitietokantaan. Vuoden 2015 lopusta lähtien Cypher on kehitetty erillisenä avoimen lähdekoodin projektina, ja monet muut toimittajat ovat ottaneet sen käyttöön kyselyjärjestelmänä tuotteilleen (esim. SAP HANA).

Tässä on esimerkki Cypher-kyselystä, joka palauttaa hakutuloksen kaikille Scottin ystäville:

MATCH (a: Henkilö {nimi: ’Scott’}) - [: FRIENDOF] -> (b) PALAUTUS b 

Nuolisymboli (->) käytetään Cypher-kyselyissä edustamaan suunnattua suhdetta kaaviossa.

Toinen yleinen graafikyselykieli, Gremlin, kehitettiin Apache TinkerPop -graafilaskentakehystä varten. Gremlin-syntakse on samanlainen kuin joidenkin kielten ORM-tietokantakäyttökirjastojen käyttämä.

Tässä on esimerkki "Scottin ystävien" kyselystä Gremlinissä:

g.V (). on ("nimi", "Scott"). out ("ystävä") 

Monet graafitietokannat tukevat Gremliniä joko sisäänrakennetun tai kolmannen osapuolen kirjaston avulla.

Vielä yksi kyselykieli on SPARQL. Alun perin W3C kehitti sen kyselemään metatietojen Resource Description Framework (RDF) -muodossa tallennettuja tietoja. Toisin sanoen SPARQL ei ollut suunniteltu graafitietokantahakuihin, mutta niitä voidaan käyttää niihin. Kaiken kaikkiaan Cypher ja Gremlin on omaksuttu laajemmin.

SPARQL-kyselyissä on joitain elementtejä, jotka muistuttavat SQL: ääVALITSE ja MISSÄ lausekkeita, mutta loppu syntaksista on radikaalisti erilainen. Älä ajattele SPARQL: ää liittyvän lainkaan SQL: ään tai siinä tapauksessa muihin kaaviokyselykieliin.

Suosittuja kaaviotietokantoja

Koska graafitietokannat palvelevat suhteellisen kapealla käyttötapauksella, niitä ei ole läheskään niin paljon kuin relaatiotietokantoja. Plus-puolella tämä helpottaa erottuvien tuotteiden tunnistamista ja keskustelua.

Neo4j

Neo4j on helposti kaikkein kypsin (11 vuotta ja laskeva) ja tunnetuin yleiseen käyttöön tarkoitetuista graafitietokannoista. Toisin kuin aiemmat kaaviotietokantatuotteet, se ei käytä SQL-taustaa. Neo4j on alkuperäinen graafitietokanta, joka on suunniteltu sisältäpäin ulospäin tukemaan suuria kaaviorakenteita, kuten kyselyissä, jotka palauttavat satoja tuhansia suhteita ja paljon muuta.

Neo4j on saatavana sekä ilmaisissa avoimen lähdekoodin että maksullisessa yritysversiossa, jälkimmäisillä ei ole rajoituksia tietojoukon kokoon (muiden ominaisuuksien lisäksi). Voit myös kokeilla Neo4j: tä verkossa sen Sandboxin kautta, joka sisältää joitain näytetiedostoja, joiden kanssa voit harjoitella.

Katso lisätietoja Neo4j: n katsauksesta.

Microsoft Azure Cosmos DB

Azure Cosmos DB -pilvitietokanta on kunnianhimoinen projekti. Sen on tarkoitus jäljitellä monenlaisia ​​tietokantoja - perinteisiä taulukoita, asiakirjapainotteisia, sarakeperheitä ja kaavioita - kaikki yhden, yhtenäisen palvelun kautta, jossa on yhtenäinen sovellusliittymäsarja.

Tätä varten kaaviotietokanta on vain yksi niistä eri tiloista, joissa Cosmos DB voi toimia. Se käyttää Gremlin-kyselykieltä ja -sovellusliittymää kaaviotyyppisiin kyselyihin ja tukee toisena käyttöliittymänä Apache TinkerPopille luotua Gremlin-konsolia.

Toinen suuri Cosmos DB: n myyntipiste on se, että indeksointi, skaalaus ja maantieteellinen replikointi hoidetaan automaattisesti Azure-pilvessä ilman, että päätäsi painetaan. Ei ole vielä selvää, kuinka Microsoftin all-in-one-arkkitehtuuri mittaa suorituskykyä jopa alkuperäisiin graafitietokantoihin, mutta Cosmos DB tarjoaa varmasti hyödyllisen yhdistelmän joustavuutta ja mittakaavaa.

Katso lisätietoja Azure Cosmos DB: n tarkastelusta.

JanusGraph

JanusGraph oli haaroitettu TitanDB-projektista ja on nyt Linux Foundationin hallinnassa. Se käyttää mitä tahansa useista tuetuista takapääistä - Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB - kaaviotietojen tallentamiseen, tukee Gremlin-kyselykieliä (samoin kuin muita Apache TinkerPop -pinoelementtejä) ja voi myös sisällyttää kokotekstihaku Apache Solr-, Apache Lucene- tai Elasticsearch-projektien kautta.

IBM, yksi JanusGraph-projektin tukijoista, tarjoaa IBM Cloudissa isännöidyn version JanusGraphista nimeltä Compose for JanusGraph. Kuten Azure Cosmos DB, Compose for JanusGraph tarjoaa automaattisen skaalauksen ja korkean käytettävyyden, hinnoittelu perustuu resurssien käyttöön.