Relaatiotietokannat ovat hallinneet tiedonhallintaa vuosikymmenien ajan, mutta ne ovat viime aikoina menettäneet pohjan NoSQL-vaihtoehdoille. Vaikka NoSQL-tietovarastot eivät ole sopivia kaikkiin käyttötapauksiin, ne ovat yleensä parempia Suuri data, joka on lyhyt tietojärjestelmille, jotka käsittelevät valtavia määriä dataa. Suurille tiedoille käytetään neljää tietovarastotyyppiä:
- Avain- / arvomyymälät, kuten Memcached ja Redis
- Asiakirjapainotteiset tietokannat, kuten MongoDB, CouchDB ja DynamoDB
- Sarakekohtaiset tietovarastot, kuten Cassandra ja HBase
- Kuvaa tietokantoja, kuten Neo4j ja OrientDB
Tämä opetusohjelma esittelee Neo4j: n, joka on graafinen tietokanta, jota käytetään vuorovaikutuksessa hyvin liittyvät tiedot. Vaikka relaatiotietokannat hallitsevat hyvin suhteita välillä tiedot, graafitietokannat hallitsevat paremmin n tutkinto-suhteet. Otetaan esimerkiksi sosiaalinen verkosto, jossa haluat analysoida malleja, joissa on mukana ystäviä, ystävien ystäviä ja niin edelleen. Kuvaajatietokannan avulla olisi helppo vastata esimerkiksi seuraaviin kysymyksiin: "Viisi erottelutasoa huomioon ottaen, mitkä ovat viisi sosiaalisen verkostoni suosittua elokuvaa, joita en ole vielä nähnyt?" Tällaiset kysymykset ovat yleisiä suositusohjelmistoille, ja graafitietokannat sopivat täydellisesti niiden ratkaisemiseen. Lisäksi kuvaajatietokannat edustavat hyvin hierarkkisia tietoja, kuten pääsynhallintaa, tuoteluetteloita, elokuvatietokantoja tai jopa verkkotopologioita ja organisaatiokaavioita. Kun sinulla on useita suhteita sisältäviä objekteja, huomaat nopeasti, että kaaviotietokannat tarjoavat tyylikkään, olioihin perustuvan paradigman näiden objektien hallintaan.
Graafitietokantojen tapaus
Kuten nimestä voi päätellä, kaaviotietokannat pystyvät edustamaan kaavioita tiedoista. Tämä on erityisen hyödyllistä sosiaalisissa ohjelmistoissa, joissa joka kerta kun muodostat yhteyden jonkun kanssa, suhde on määritelty sinun välille. Luultavasti viimeisimmässä työnhakussa valitsit muutamia kiinnostuneita yrityksiä ja etsit sitten yhteyksiä sosiaalisiin verkostoihisi. Vaikka et ehkä tunne ketään, joka työskentelee yhdessä näistä yrityksistä, joku sosiaalisessa verkostossasi todennäköisesti tekee. Tällaisen ongelman ratkaiseminen on helppoa yhdellä tai kahdella erotusasteella (ystäväsi tai ystäväsi ystävä), mutta mitä tapahtuu, kun aloitat haun laajentamisen verkon kautta?
Aleksa Vukotic ja Nicki Watt tutkivat kirjassaan Neo4j In Action eroja relaatiotietokantojen ja graafitietokantojen välillä sosiaalisten verkostojen ongelmien ratkaisemiseksi. Käytän heidän työstään muutamia seuraavia esimerkkejä osoittaakseni sinulle, miksi graafitietokannoista on tulossa yhä suositumpi vaihtoehto relaatiotietokannoille.
Monimutkaisten suhteiden mallintaminen: Neo4j vs MySQL
Tietotekniikan näkökulmasta, kun ajattelemme käyttäjien välisten suhteiden mallintamista sosiaalisessa verkostossa, voimme piirtää kuvion 1 kaltaisen kaavion.
Steven Haines Käyttäjällä on IS_FRIEND_OF suhteita muihin käyttäjiin, ja niillä käyttäjillä on IS_FRIEND_OF suhteet muihin käyttäjiin ja niin edelleen. Kuvassa 2 on esitetty, kuinka edustaisimme tätä relaatiotietokannassa.
Steven Haines KÄYTTÄJÄ taulukolla on yksi moniin-suhde USER_FRIEND taulukko, joka mallintaa "käyttäjän" suhdetta kahden käyttäjän välillä. Nyt kun olemme mallinnaneet suhteet, miten kysyisimme tietoja? Vukotic ja Watt mittaivat kyselyn suorituskyvyn laskemalla viiden tason syvyydessä olevien erillisten ystävien määrän (ystävien ystävien ystävien ystävät ja ystävien ystävät). Relaatiotietokannassa kyselyt näyttävät seuraavalta:
# Syvyys 1 valitse määrä (erillinen uf. *) Käyttäjän_ystävä uf kohdasta missä uf.user_1 =? # Syvyys 2 valitse määrä (erillinen uf2. *) Käyttäjän_käyttäjä uf1 sisäisestä liittymisestä käyttäjän_käyttäjä uf2 kohtaan uf1.user_1 = uf2.user_2 missä uf1.user_1 =? # Syvyys 3 valitse määrä (erillinen uf3. *) T_user_friend uf1: n sisäisestä liittymästä t_user_friend uf2: een uf1.user_1 = uf2.user_2 sisemmässä liittymässä t_user_friend uf3: ssa uf2.user_1 = uf3.user_2 missä uf1.user_1 =? # Ja niin edelleen... Näissä kyselyissä on mielenkiintoista, että joka kerta kun nousemme vielä yhden tason, meidän on liityttävä USER_FRIEND pöytä itsensä kanssa. Taulukko 1 osoittaa, mitä tutkijat Vukotic ja Watt löysivät, kun he lisäsivät 1000 käyttäjää, joilla kullakin oli noin 50 suhdetta (50000 suhdetta), ja suorittivat kyselyt.
Taulukko 1. MySQL-kyselyn vasteaika suhteiden eri syvyyksille
Syvyys Suoritusaika (sekuntia) Laske tulos
| 2 | 0.028 | ~900 |
| 3 | 0.213 | ~999 |
| 4 | 10.273 | ~999 |
| 5 | 92.613 | ~999 |
MySQL tekee hienoa työtä yhdistämällä tietoja jopa kolmen tason päästä, mutta suorituskyky heikkenee nopeasti sen jälkeen. Syynä on, että joka kerta USER_FRIEND taulukko on liitetty itseensä, MySQL: n on laskettava taulukon suorakulmainen tulo, vaikka suurin osa tiedoista heitetään pois. Esimerkiksi kun suoritetaan kyseinen liitos viisi kertaa, suorakulmainen tuote johtaa 50000 ^ 5 riviin tai 102,4 * 10 ^ 21 riviin. Se on tuhlaa, kun olemme kiinnostuneita vain tuhannesta heistä!
Seuraavaksi Vukotic ja Watt yrittivät suorittaa saman tyyppisiä kyselyjä Neo4j: tä vastaan. Nämä täysin erilaiset tulokset on esitetty taulukossa 2.
Taulukko 2. Neo4j-vasteaika suhteiden eri syvyyksille
Syvyys Suoritusaika (sekuntia) Laske tulos
| 2 | 0.04 | ~900 |
| 3 | 0.06 | ~999 |
| 4 | 0.07 | ~999 |
| 5 | 0.07 | ~999 |
Näiden toteutusvertailujen takeaway on ei että Neo4j on parempi kuin MySQL. Pikemminkin kun liikutaan tämän tyyppisiä suhteita, Neo4j: n suorituskyky riippuu haettujen tietueiden lukumäärästä, kun taas MySQL: n suorituskyky riippuu tietueiden lukumäärästä. USER_FRIEND pöytä. Siten suhteiden määrän kasvaessa myös MySQL-kyselyjen vasteajat pidentyvät, kun taas Neo4j-kyselyjen vasteajat pysyvät samana. Tämä johtuu siitä, että Neo4j: n vasteaika riippuu tietyn kyselyn suhteiden määrästä eikä suhteiden kokonaismäärästä.
Neo4j: n skaalaus suurille tiedoille
Laajentamalla tätä ajatusprojektia askelta pidemmälle, Vukotic ja Watt loivat seuraavaksi miljoonan käyttäjän, joiden välillä oli 50 miljoonaa suhdetta. Taulukko 3 näyttää kyseisen tietojoukon tulokset.
Taulukko 3. Neo4j-vasteaika 50 miljoonalle suhteelle
Syvyys Suoritusaika (sekuntia) Laske tulos
| 2 | 0.01 | ~2,500 |
| 3 | 0.168 | ~110,000 |
| 4 | 1.359 | ~600,000 |
| 5 | 2.132 | ~800,000 |
Lienee tarpeetonta sanoa, että olen velkaa Aleksa Vukoticille ja Nicki Wattille ja suosittelen lämpimästi heidän työnsä tarkistamista. Otin kaikki tämän osan testit heidän kirjansa ensimmäisestä luvusta, Neo4j toiminnassa.
Neo4j: n käytön aloittaminen
Olet nähnyt, että Neo4j pystyy suorittamaan valtavia määriä hyvin liittyviä tietoja hyvin nopeasti, eikä ole epäilystäkään siitä, että se sopii paremmin kuin MySQL (tai mikä tahansa relaatiotietokanta) tietyntyyppisiin ongelmiin. Jos haluat tietää enemmän Neo4j: n toiminnasta, helpoin tapa on olla vuorovaikutuksessa sen kanssa verkkokonsolin kautta.
Aloita lataamalla Neo4j. Tätä artikkelia varten tarvitaan yhteisöversio, joka on tämän kirjoituksen jälkeen versiossa 3.2.3.
- Lataa Mac-tietokoneella DMG-tiedosto ja asenna se kuten muillakin sovelluksilla.
- Windowsissa joko lataa EXE ja käy ohjatun asennustoiminnon läpi tai lataa ZIP-tiedosto ja pura se kiintolevylle.
- Lataa Linuxissa TAR-tiedosto ja pura se kiintolevylle.
- Vaihtoehtoisesti voit käyttää Docker-kuvaa missä tahansa käyttöjärjestelmässä.
Kun olet asentanut Neo4j, käynnistä se ja avaa selainikkuna seuraavaan URL-osoitteeseen:
//127.0.0.1:7474/browser/Kirjaudu sisään oletustunnuksella neo4j ja oletussalasana neo4j. Sinun pitäisi nähdä kuvan 3 kaltainen näyttö.
Steven Haines Solmut ja suhteet Neo4j: ssä
Neo4j on suunniteltu solmujen ja suhteiden ympärille:
- A solmu edustaa jotain, kuten käyttäjää, elokuvaa tai kirjaa.
- Solmu sisältää joukon avain / arvo-parit, kuten nimi, otsikko tai julkaisija.
- Solmu etiketti määrittää, minkä tyyppinen asia on - jälleen käyttäjä, elokuva tai kirja.
- Ihmissuhteet määrittää solmujen väliset assosiaatiot ja ovat tietyntyyppisiä.
Esimerkkinä voimme määritellä hahmosolmut, kuten Iron Man ja Captain America; määritellä elokuvasolmu nimeltä "Avengers"; ja määritä sitten Esiintyy_IN Iron Manin ja Avengersin sekä kapteeni Amerikan ja Avengersin suhde. Kaikki tämä on esitetty kuvassa 4.
Steven Haines Kuvassa 4 on kolme solmua (kaksi merkkisolmua ja yksi elokuvasolmu) ja kaksi yhteyttä (molemmat tyyppiä) NÄKYY_IN).
Solmujen ja suhteiden mallinnus ja kysely
Samoin kuin relaatiotietokanta käyttää strukturoitua kyselykieltä (SQL) vuorovaikutuksessa tietojen kanssa, Neo4j käyttää Cypher Query Language -ohjelmaa solmujen ja suhteiden kanssa.
Käytetään Cypheriä luomaan yksinkertainen esitys perheestä. Etsi web-käyttöliittymän yläosasta dollarin merkki. Tämä tarkoittaa kenttää, jonka avulla voit suorittaa Cypher-kyselyjä suoraan Neo4j: tä vastaan. Kirjoita seuraava Cypher-kysely kyseiseen kenttään (käytän perhettäni esimerkkinä, mutta voit muuttaa yksityiskohtia mallinnamaan oman perheen, jos haluat):
LUO (henkilö: Henkilö {nimi: "Steven", ikä: 45}) PALAA henkilöTulos on esitetty kuvassa 5.
Steven Haines Kuvassa 5 on uusi solmu, jonka otsikko on Henkilö ja nimi Steven. Jos viet hiiren verkkokonsolin solmun päälle, näet sen ominaisuudet alareunassa. Tässä tapauksessa ominaisuudet ovat ID: 19, nimi: Steven ja ikä: 45. Jaetaan nyt Cypher-kysely:
- LUODA:
LUODAavainsanaa käytetään solmujen ja suhteiden luomiseen. Tässä tapauksessa annamme sille yhden argumentin, joka onHenkilösulkeissa, joten sen on tarkoitus luoda yksi solmu. - (henkilö: henkilö {...}): Pienet kirjaimet "
henkilö"on muuttujan nimi, jonka avulla voimme käyttää luotavaa henkilöä, kun taas pääoma"Henkilö"on tarra. Huomaa, että kaksoispiste erottaa muuttujan nimen tunnisteesta. - {nimi: "Steven, ikä: 45}: Nämä ovat avaimen / arvon ominaisuudet, jotka määritämme luomallemme solmulle. Neo4j ei vaadi skeeman määrittelyä ennen solmujen luomista, ja jokaisella solmulla voi olla ainutlaatuinen joukko elementtejä. (Useimmiten määrität solmut, joilla on sama tarra, joilla on samat ominaisuudet, mutta sitä ei vaadita.)
- PALAA henkilö: Kun solmu on luotu, pyydämme Neo4j: tä palauttamaan sen takaisin meille. Siksi näimme solmun näkyvän käyttöliittymässä.
LUODA komentoa (joka on kirjainkoon erottamaton) käytetään solmujen luomiseen ja se voidaan lukea seuraavasti: luo uusi solmu Person-tarralla, joka sisältää nimen ja iän ominaisuudet; määritä se henkilömuuttujalle ja palauta se takaisin soittajalle.
Kysely Cypher-kyselykielellä
Seuraavaksi haluamme kokeilla kyselyjä Cypherin kanssa. Ensinnäkin meidän on luotava muutama henkilö lisää, jotta voimme määrittää heidän väliset suhteet.
LUO (henkilö: Henkilö {nimi: "Michael", ikä: 16}) PALAUTA henkilö LUO (henkilö: Henkilö {nimi: "Rebecca", ikä: 7}) Palauta henkilö LUO (henkilö: Henkilö {nimi: "Linda"} ) PALAA henkilö Kun olet luonut neljä ihmistä, voit joko napsauttaa Henkilö -painiketta Solmutarrat (näkyy, jos napsautat verkkosivun vasemmassa yläkulmassa olevaa tietokantakuvaketta) tai suoritat seuraavan Cypher-kyselyn:
MATCH (henkilö: henkilö) RETURN henkilöCypher käyttää OTTELU avainsanalla löytää asioita Neo4j: stä. Tässä esimerkissä pyydämme Cypheriä vastaamaan kaikkia solmuja, joilla on Henkilön nimi, osoittamaan nämä solmut henkilö muuttuja ja palauta muuttujaan liittyvä arvo. Tämän seurauksena sinun pitäisi nähdä neljä luomasi solmu. Jos viet hiiren Web-konsolin jokaisen solmun päälle, näet kunkin henkilön ominaisuudet. (Saatat huomata, että jätin vaimoni iän pois hänen solmustaan, mikä osoittaa, että ominaisuuksien ei tarvitse olla johdonmukaisia kaikissa solmuissa, edes saman merkinnän. En ole myöskään tarpeeksi tyhmä julkaisemaan vaimoni ikää.)
Voimme jatkaa tätä OTTELU esimerkki hieman pitemmälle lisäämällä ehtoja solmuihin, jotka haluamme palauttaa. Jos esimerkiksi halusimme vain "Steven" -solmun, voisimme noutaa sen vastaamalla nimiominaisuuteen:
MATCH (henkilö: Henkilö {nimi: "Steven"}) PALAA henkilöTai jos haluaisimme palauttaa kaikki lapset, voisimme pyytää kaikkia alle 18-vuotiaita ihmisiä:
MATCH (henkilö: henkilö) WHERE henkilö. Ikä <18 PALUU henkilöTässä esimerkissä lisättiin MISSÄ lauseke kyselyyn kaventaa tuloksia. MISSÄ toimii hyvin samalla tavalla kuin SQL-vastaava: MATCH (henkilö: henkilö) löytää kaikki solmut, joissa on Henkilötunniste, ja sitten MISSÄ lauseke suodattaa arvot tulosjoukosta.
Suunnan mallintaminen suhteissa
Meillä on neljä solmua, joten luodaan joitain suhteita. Ensinnäkin, luodaan IS_MARRIED_TO Stevenin ja Lindan välinen suhde:
MATCH (steven: Henkilö {nimi: "Steven"}), (linda: Henkilö {nimi: "Linda"}) LUO (steven) - [: IS_MARRIED_TO] -> (linda) palaa steven, lindaTässä esimerkissä sovitamme kaksi Person-solmua, jotka on merkitty Steven ja Linda, ja luomme tyyppisen suhteen IS_MARRIED_TO Stevenistä Lindaan. Suhteen luomisen muoto on seuraava:
(solmu1) - [relationshipVariable: RELATIONSHIP_TYPE -> (solmu2)
