Victor Lee on TigerGraphin tuotehallintojohtaja.
Graafitietokannat vastaavat erinomaisesti suurten tietojoukkojen suhteita koskeviin monimutkaisiin kysymyksiin. Mutta ne törmäävät seinään - sekä suorituskyvyn että analyysin suhteen - kun datan määrä kasvaa hyvin suureksi ja kun vastaukset on annettava reaaliajassa.
Tämä johtuu siitä, että nykyisillä kaaviotekniikoilla on vaikeuksia ladata suuria määriä dataa tai syödä nopeasti saapuvia tietoja reaaliajassa. He kamppailevat myös nopean liikenopeuden tuottamiseksi. Vaikka syvempi analyysi vaatii kaavion syvemmän läpikäynnin, nykypäivän kaaviotietokannat yleensä hidastuvat tai aikakatkaisevat kahden läpikäynnin jälkeen.
TigerGraph on hajautettu, alkuperäinen grafiikkalaskenta-alusta, joka on suunniteltu kiertämään nämä rajoitukset. TigerGraphin alkuperäisen rinnakkaisgraafiarkkitehtuurin ja reaaliaikaisen syvälinkkianalytiikan tavoitteena on tarjota seuraavat edut:
- Nopeampi tietojen lataaminen kaavioiden luomiseksi nopeasti
- Nopeampi rinnakkaiskaavioalgoritmien toteutus
- Reaaliaikainen mahdollisuus suoratoistaa päivityksiä ja lisäyksiä REST-toiminnolla
- Kyky yhdistää reaaliaikainen analytiikka laajamittaisella offline-datankäsittelyllä
- Kyky laajentaa ja laajentaa hajautettuja sovelluksia
Seuraavissa osioissa tarkastellaan lyhyesti kaavion käsittelyä, tutkitaan syvälinkkianalytiikan etuja ja nostetaan TigerGraphin huppu ymmärtämään, miten se pystyy tarjoamaan syvälinkkianalytiikkaa reaaliajassa.
Kaavion läpikäynti: Lisää humalaa, enemmän oivalluksia
Miksi syvälinkkianalytiikka? Koska mitä enemmän linkkejä voit kulkea (hypätä) kaaviossa, sitä suurempi oivallus saavutat. Harkitse hybriditietoa ja sosiaalista kuvaajaa. Jokainen solmu muodostaa yhteyden mitä tiedät ja WHO tiedät kyllä. Suorat linkit (yksi hyppy) paljastavat sen, mitä tiedät. Kaksi humalaa paljastaa kaiken, mitä ystäväsi ja tuttavat tietävät. Kolme humalaa? Olet matkalla paljastamaan mitä kaikki tietää.
Kuvaajan etuna on tietojoukossa olevien tieto-olioiden välisten suhteiden tunteminen, mikä on tiedon löytämisen, mallintamisen ja ennustamisen ydin. Jokainen hyppy voi johtaa yhteyksien määrän ja vastaavasti tiedon määrän eksponentiaaliseen kasvuun. Mutta siinä on teknologinen este. Ainoastaan järjestelmä, joka suorittaa humalan tehokkaasti ja samanaikaisesti, voi tuottaa reaaliaikaisen syvälinkki (multi-hop) -analytiikan.
Yksinkertainen esimerkki, kuten reaaliaikainen henkilökohtainen suositus, paljastaa useiden linkkien seuraamisen arvon ja voiman kaaviossa:
"Asiakkaat, jotka pitivät siitä, mistä pidit, ostivat myös nämä tuotteet."
Tämä tarkoittaa kolmen hypyn kyselyä:
- Aloita henkilöstä (sinusta), tunnista kohteet, joita olet katsellut / tykännyt / ostanut.
- Toiseksi, etsi muita ihmisiä, jotka ovat katsoneet / pitäneet / ostaneet nuo tuotteet.
- Kolmanneksi, tunnista näiden ihmisten ostamat lisäesineet.
Henkilö → tuote → (muut) henkilöt → (muut) tuotteet
Aikaisempaa kaaviotekniikkaa käytettäessä vain kahdessa humalassa suuremmissa tietojoukoissa. TigerGraph laajentaa kyselyn helposti kolmeen tai useampaan hyppyyn tarjotakseen tärkeitä oivalluksia erittäin suurista tietojoukoista.
TigerGraphin reaaliaikainen syvälinkkien analytiikka
TigerGraph tukee kolmesta yli 10 humalaan läpikulkua isossa kuvaajassa sekä nopeita kaavion nopeutta ja datapäivityksiä. Tämä nopeuden, syvien kulkujen ja skaalautuvuuden yhdistelmä tarjoaa valtavia etuja useissa käyttötapauksissa.
Yksi käyttötapaus on petosten ehkäisy. Yksi tapa, jolla yritykset havaitsevat mahdolliset petokset, on löytää yhteydet tunnetuille huonoille liiketoimille. Esimerkiksi saapuvasta luottokorttitapahtumasta alkaen tässä on yksi tie huonoihin tapahtumiin:
Uusi tapahtuma → luottokortti → kortinhaltija → (muut) luottokortit → (muut) huonot tapahtumat
Kaavio kyselyssä tämä malli käyttää neljää hyppyä löytääksesi yhteydet vain yhden kortin päässä saapuvasta tapahtumasta. Nykypäivän huijarit yrittävät peittää toimintansa piireillä itsensä ja tunnetun huonon toiminnan tai huonojen toimijoiden välillä. Petosten tunnistamiseksi tarkasti sinun on tutkittava useita mahdollisia malleja ja koottava kokonaisvaltaisempi näkymä.
Kyky paljastaa useita piilotettuja yhteyksiä TigerGraph pystyy minimoimaan luottokorttipetokset. Tämä läpikulkumalli koskee monia muita käyttötapauksia - joissa voit yksinkertaisesti korvata luottokorttitapahtuman verkkoklikkaustapahtumalla, puhelutietueella tai rahansiirrolla.
TigerGraph-järjestelmän yleiskatsaus
Kyky vetää syviä yhteyksiä datayksiköiden välille reaaliajassa vaatii uutta tekniikkaa, joka on suunniteltu mittakaavalle ja suorituskyvylle. On monia suunnittelupäätöksiä, jotka toimivat yhteistyössä TigerGraphin läpimurtonopeuden ja skaalautuvuuden saavuttamiseksi. Seuraavassa tarkastelemme näitä suunnitteluominaisuuksia ja keskustelemme niiden yhteistyöstä.
Alkuperäinen kaavio
TigerGraph on puhdas graafitietokanta alusta asti. Sen tietovarasto sisältää solmut, linkit ja niiden määritteet, ajanjakson. Jotkut markkinoilla olevat graafitietokantatuotteet ovat todella kääreitä, jotka on rakennettu yleisemmän NoSQL-tietovaraston päälle. Tällä virtuaalikuvaajastrategialla on kaksinkertainen rangaistus suorituskyvyn suhteen. Ensinnäkin käännös virtuaalikuvaajaoperaatiosta fyysiseen tallennustoimintoon tuo mukanaan ylimääräistä työtä. Toiseksi taustarakennetta ei ole optimoitu kaaviotoimintoja varten.
Pienikokoinen ja nopea pääsy
Emme kuvaile TigerGraphia muistin sisäisenä tietokantana, koska tietojen pitäminen muistissa on etusija, mutta ei vaatimus. Käyttäjät voivat asettaa parametreja, jotka määrittelevät, kuinka paljon vapaata muistia voidaan käyttää kaavion pitämiseen. Jos koko kaavio ei mahdu muistiin, ylimääräinen osa tallennetaan levylle. Paras suorituskyky saavutetaan, kun koko kaavio mahtuu tietysti muistiin.
Data-arvot tallennetaan koodatuissa muodoissa, jotka pakkaavat tiedot tehokkaasti. Pakkauskerroin vaihtelee kuvaajan rakenteen ja datan mukaan, mutta tyypilliset pakkauskertoimet ovat välillä 2x - 10x. Pakkauksella on kaksi etua: Ensinnäkin suurempi määrä kaaviotietoja mahtuu muistiin ja välimuistiin. Tällainen pakkaus vähentää paitsi muistin jalanjälkeä myös CPU-välimuistin menetyksiä, mikä nopeuttaa kyselyn yleistä suorituskykyä. Toiseksi käyttäjille, joilla on erittäin suuret kaaviot, laitteistokustannukset vähenevät. Esimerkiksi, jos pakkauskerroin on 4x, organisaatio voi pystyä sovittamaan kaikki tietonsa yhteen koneeseen neljän sijasta.
Pakkauksen purku / dekoodaus on erittäin nopeaa ja läpinäkyvää loppukäyttäjille, joten pakkaamisen edut ovat suuremmat kuin pieni viive pakkauksessa / purkamisessa. Yleensä purkamista tarvitaan vain tietojen näyttämiseen. Kun arvoja käytetään sisäisesti, ne voivat usein jäädä koodattuina ja pakattuina.
Hash-indeksejä käytetään viittaamaan solmuihin ja linkkeihin. Big-O-termeillä keskimääräinen pääsyaikamme on O (1) ja keskimääräinen indeksin päivitysaika on myös O (1). Käännös: Tietyn solmun tai linkin käyttö kaaviossa on erittäin nopeaa ja pysyy nopeana, vaikka kuvaajan koko kasvaa. Lisäksi indeksin ylläpitäminen uusien solmujen ja linkkien lisäämiseksi kaavioon on myös erittäin nopeaa.
Rinnakkaisuus ja yhteiset arvot
Kun nopeus on tavoitteesi, sinulla on kaksi perusreittiä: Suorita jokainen tehtävä nopeammin tai tee useita tehtäviä kerralla. Jälkimmäinen tie on rinnakkaisuus. Pyrkiessään tekemään jokaisen tehtävän nopeasti, TigerGraph on myös ylivertainen rinnakkaisuudessa. Sen graafimoottori käyttää useita suorituslankoja kaavion kulkemiseen.
Kaavakyselyjen luonne on "seurata linkkejä". Aloita yhdestä tai useammasta solmusta. Katso näiden solmujen käytettävissä olevat yhteydet ja seuraa näitä yhteyksiä joihinkin tai kaikkiin naapurisolmuihin. Sanomme, että olet juuri "kulkenut" yhden "hypyn". Toista tämä prosessi siirtyäksesi alkuperäisen solmun naapureiden naapureille, ja olet käynyt läpi kaksi humalaa. Koska kullakin solmulla voi olla monia yhteyksiä, tähän kahden hypyn kulkemiseen liittyy monia polkuja päästäksesi aloitussolmuista kohdesolmuihin. Kuvaajat soveltuvat luonnollisesti rinnakkaiseen, monisäikeiseen suoritukseen.
Kyselyn pitäisi tietysti tehdä muutakin kuin vain käydä solmussa. Yksinkertaisessa tapauksessa voimme laskea ainutlaatuisten kahden hypyn naapureiden määrän tai tehdä luettelon heidän tunnuksistaan. Kuinka lasketaan kokonaismäärä, kun sinulla on useita rinnakkaisia laskureita? Prosessi on samanlainen kuin mitä tekisit tosielämässä: Pyydä jokaista laskuria tekemään osuutensa maailmasta ja yhdistämään sitten lopputuloksensa.
Muista, että kyselyssä kysyttiin niiden määrää ainutlaatuinen solmut. On mahdollista, että sama solmu on laskettu kahdella eri laskurilla, koska määränpäähän on enemmän kuin yksi polku. Tämä ongelma voi ilmetä jopa yksisäikeisissä rakenteissa. Tavallinen ratkaisu on määrittää väliaikainen muuttuja kullekin solmulle. Muuttujat alustetaan arvoon False. Kun yksi laskuri vierailee solmussa, kyseisen solmun muuttujaksi asetetaan True, jotta muut laskurit eivät tiedä laskevan sitä.
Varastointi- ja käsittelymoottorit kirjoitettuna C ++: lla
Kielivalinnat vaikuttavat myös suorituskykyyn. TigerGraphin graafin tallennusmoottori ja prosessori on toteutettu C ++: ssa. Yleiskäyttöisten menettelykielien perheessä C: tä ja C ++: a pidetään alemmalla tasolla verrattuna muihin kieliin, kuten Java. Tämä tarkoittaa sitä, että ohjelmoijat, jotka ymmärtävät, kuinka tietokonelaitteisto suorittaa ohjelmistokomennonsa, voivat tehdä tietoisia valintoja suorituskyvyn optimoimiseksi. TigerGraph on suunniteltu huolella käyttämään muistia tehokkaasti ja vapauttamaan käyttämätön muisti. Huolellinen muistinhallinta edistää TigerGraphin kykyä kuljettaa monia linkkejä sekä syvyyden että leveyden suhteen yhdellä kyselyllä.
Monet muut graafitietokantatuotteet on kirjoitettu Java-kielellä, jolla on hyviä ja huonoja puolia. Java-ohjelmat toimivat Java-virtuaalikoneessa (JVM). JVM huolehtii muistin hallinnasta ja roskien keräyksestä (vapauttaa muistia, jota ei enää tarvita). Vaikka tämä on kätevää, ohjelmoijan on vaikea optimoida muistin käyttöä tai hallita, kun käyttämätöntä muistia tulee saataville.
GSQL-kuvaajan kyselykieli
TigerGraphilla on myös oma graafin kysely- ja päivityskieli, GSQL. Vaikka GSQL: stä löytyy monia hienoja yksityiskohtia, keskityn kahteen näkökohtaan, jotka ovat avain tehokkaan rinnakkaislaskennan tukemiseen: ACCUM-lauseke ja akumuuttujat.
Useimpien GSQL-kyselyjen ydin on SELECT-käsky, joka on mallinnettu tarkasti SQL-käskyn jälkeen. SELECT-, FROM- ja WHERE -lausekkeita käytetään valitsemaan ja suodattamaan joukko linkkejä tai solmuja. Tämän valinnan jälkeen valinnaista ACCUM-lauseketta voidaan käyttää määrittämään joukko toimintoja, jotka kukin linkki tai viereinen solmu suorittaa. Sanon "suorittaa" eikä "suorita", koska käsitteellisesti jokainen kaavioobjekti on itsenäinen laskentayksikkö. Graafirakenne toimii kuin massiivisesti yhdensuuntainen laskennallinen verkko. Kaavio ei ole vain tietosi tallennus; se on myös kyselysi tai analyysimoottorisi.
ACCUM-lauseke voi sisältää monia erilaisia toimintoja tai lauseita. Nämä lauseet voivat lukea arvoja kaavio-objekteista, suorittaa paikallisia laskutoimituksia, soveltaa ehdollisia lauseita ja ajoittaa kaavion päivityksiä. (Päivityksiä ei tehdä ennen kuin kysely on ohi.)
Näiden hajautettujen kyselyjen sisäisten laskelmien tukemiseksi GSQL-kieli tarjoaa kerääjämuuttujia. Akkuilla on monia makuja, mutta ne ovat kaikki väliaikaisia (olemassa vain kyselyn suorituksen aikana), jaettuja (saatavana mille tahansa suorituslangalle) ja sulkevat toisiaan pois (vain yksi ketju voi päivittää sen kerrallaan). Esimerkiksi kaikkien yllä mainittujen naapureiden naapureiden laskennassa käytettäisiin yksinkertaista summa-akumulaattoria. Asetettua akkua käytettäisiin kaikkien näiden naapureiden naapureiden tunnusten tallentamiseen. Akkuja on saatavana kahdella laajuudella: globaali ja solmukohtainen. Aikaisemmassa kyselyesimerkissä mainitsimme tarpeen merkitä kukin solmu vierailuneeksi tai ei. Tässä käytettäisiin solmukohtaisia akkuja.
MPP-laskennallinen malli
Toistamme yllä paljastamamme, että TigerGraph-graafi on sekä tallennusmalli että laskennallinen malli. Jokainen solmu ja linkki voidaan liittää laskentatoimintoon. Siksi TigerGraph toimii samanaikaisesti tallennus- ja laskentayksikkönä. Tätä ei voida saavuttaa käyttämällä yleistä NoSQL-tietovarastoa tai ilman akkujen käyttöä.
Automaattinen osiointi
Nykypäivän suuressa datamaailmassa yritykset tarvitsevat tietokantaratkaisunsa voidakseen laajentaa useita koneita, koska niiden tiedot voivat kasvaa liian suuriksi, jotta niitä voidaan tallentaa taloudellisesti yhdelle palvelimelle. TigerGraph on suunniteltu jakamaan kaaviotiedot automaattisesti palvelinjoukon yli ja suorittamaan silti nopeasti. Hajautusindeksiä käytetään määrittämään palvelimen sisäisen datan sijainnin lisäksi myös mikä palvelin. Kaikki linkit, jotka muodostavat yhteyden tietystä solmusta, tallennetaan samalle palvelimelle. Tietojenkäsittelyteoria kertoo meille, että parhaan yleisen kuvaajan osioinnin löytäminen, jos voimme jopa määritellä "paras", on yleensä hyvin hidasta, joten emme yritä. Oletustilamme on käyttää satunnaista hajautusta, joka toimii erittäin hyvin useimmissa tapauksissa. TigerGraph-järjestelmä tukee myös käyttäjälähtöistä osiointia käyttäjille, joilla on tietty osiointijärjestelmä mielessä.
