Jeffas Carpenteris yra „DataStax“ techninis evangelistas.
Pastaruoju metu buvo daug ažiotažo dėl grafikų duomenų bazių. Nors grafikų duomenų bazės, tokios kaip „DataStax Enterprise Graph“ (pagrįstos „Titan DB“), „Neo4“ ir „IBM Graph“, egzistuoja jau kelerius metus, paskutiniai pranešimai apie valdomas debesies paslaugas, tokias kaip „AWS Neptune“ ir „Microsoft“ pridėjus grafikų galimybes prie „Azure Cosmos DB“, rodo, kad grafikų duomenų bazės pateko į pagrindinę srovę. Atsižvelgiant į visus šiuos interesus, kaip nustatyti, ar grafikų duomenų bazė tinka jūsų programai?
Kas yra grafikų duomenų bazė?
Prieš eidami toliau, apibrėžkime terminologiją. Kas yra grafikų duomenų bazė? Pagalvokite apie tai pagal duomenų modelį. Grafiko duomenų modelį sudaro viršūnės kurie atstovauja domeno subjektams ir kraštai kurie atstovauja šių subjektų santykiams. Nes tiek viršūnėse, tiek briaunose gali būti vadinamos papildomos vardo ir vertės poros savybes, šis duomenų modelis oficialiai žinomas kaip a nuosavybės grafikas. Kai kuriose grafikų duomenų bazėse reikia apibrėžti a schema jūsų grafikui - t. apibrėžiantis etikečių arba viršūnių, briaunų ir ypatybių pavadinimai prieš pildant bet kokius duomenis - tuo tarpu kitos duomenų bazės leidžia veikti be fiksuotos schemos.
Kaip jau pastebėjote, diagramos duomenų modelyje nėra naujos informacijos, kurios negalėtume užfiksuoti tradiciniame reliacinių duomenų modelyje. Galų gale paprasta apibūdinti ryšius tarp lentelių naudojant svetimus raktus, arba mes galime apibūdinti santykio su prisijungimo lentele savybes. Esminis šių duomenų modelių skirtumas yra duomenų tvarkymo ir prieigos būdas. Briaunų kaip „pirmos klasės piliečio“ atpažinimas šalia viršūnių grafiko duomenų modelyje leidžia pagrindiniam duomenų bazės varikliui labai greitai pasikartoti bet kuria kryptimi per viršūnių ir briaunų tinklus, kad būtų patenkintos programos užklausos, procesas vadinamas perėjimas.
Grafikų duomenų modelio lankstumas yra pagrindinis veiksnys, skatinantis pastaruoju metu didėjantį grafikų duomenų bazių populiarumą. Tie patys prieinamumo ir masto reikalavimai, kurie paskatino kurti ir priimti įvairius „NoSQL“ pasiūlymus per pastaruosius maždaug dešimt metų, ir toliau duoda vaisių pagal naujausią grafiko tendenciją.
Kaip sužinoti, kada jums reikia grafikų duomenų bazės
Tačiau, kaip ir naudojant bet kurią populiarią technologiją, kiekvienoje problemoje gali būti tendencija taikyti grafiko duomenų bazes. Svarbu įsitikinti, kad turite tinkamą naudojimo atvejį. Pvz., Diagramos dažnai taikomos tokioms probleminėms sritims kaip:
- Socialiniai tinklai
- Rekomendacijos ir pritaikymas
- „Customer 360“, įskaitant objekto skiriamąją gebą (koreliuojantys vartotojo duomenis iš kelių šaltinių)
- Sukčiavimo nustatymas
- Turto valdymas
Nesvarbu, ar jūsų naudojimo atvejis tinka vienai iš tų sričių, ar ne, turėtumėte apsvarstyti keletą kitų veiksnių, kurie gali padėti nustatyti, ar grafikų duomenų bazė jums tinka:
- Santykiai nuo daugelio iki daugelio. Savo knygoje „Duomenų intensyvių programų kūrimas“ (O’Reilly) Martinas Kleppmannas siūlo, kad dažnas ryšys tarp daugelio jūsų problemos srityje yra geras grafikų naudojimo rodiklis, nes reliacinės duomenų bazės dažniausiai stengiasi efektyviai naršyti šiuose santykiuose.
- Didelė santykių vertė. Kita euristika, kurią dažnai girdėjau: jei jūsų duomenų elementų santykiai yra tokie pat svarbūs ar svarbesni nei patys elementai, turėtumėte apsvarstyti galimybę naudoti diagramą.
- Mažas vėlavimas dideliu mastu. Įtraukus kitą duomenų bazę į savo programą, jūsų programa taip pat tampa sudėtingesnė. Grafikų duomenų bazių galimybė greičiau nei kitų tipų duomenų bazėse naršyti dideliuose duomenų rinkiniuose pateiktuose ryšiuose pateisina šį papildomą sudėtingumą. Tai ypač pasakytina tais atvejais, kai sudėtinga reliacijų prisijungimo užklausa nebevykdo ir nėra papildomų optimizavimo rezultatų, susijusių su užklausa ar reliacine struktūra.
Grafiko schemos ir užklausų apibrėžimas naudojant „Gremlin“
Pažvelkime, kaip pradėti naudoti grafikų duomenų bazę, naudojant tikrą pavyzdį - rekomendavimo sistemą, kurią neseniai pridėjome prie „KillrVideo“. „KillrVideo“ yra informacinė programa, skirta dalytis ir žiūrėti vaizdo įrašus, kurią sukūrėme tam, kad kūrėjai galėtų išmokti naudotis „DataStax Enterprise“, įskaitant „DataStax Enterprise Graph“ - grafikų duomenų bazę, sukurtą ant labai keičiamų duomenų technologijų, įskaitant „Apache Cassandra“ ir „Apache Spark“.
Kalba, naudojama „DataStax Enterprise Graph“ grafikams apibūdinti ir sąveikauti su jais, yra „Gremlin“, kuris yra „Apache TinkerPop“ projekto dalis. Gremlinas yra žinomas kaip pereinamoji kalba grafų perėjimams apibūdinti dėl jo lankstumo, išplėtimo ir palaikymo deklaratyvioms ir imperatyvioms užklausoms. „Gremlin“ yra pagrįstas „Groovy“ kalba, o tvarkykles galima įsigyti keliomis kalbomis. Svarbiausia, kad „Gremlin“ palaiko populiariausios grafikų duomenų bazės, įskaitant „DataStax Enterprise Graph“, „Neo4j“, „AWS Neptune“ ir „Azure Cosmos DB“.
Sukūrėme rekomendacijų algoritmą duomenims, kurių mums reikės kaip įvestį, nustatyti. Buvo siekiama sugeneruoti rekomendacijas tam tikram vartotojui pagal vaizdo įrašus, kurie patiko panašiems vartotojams. Mūsų tikslas buvo generuoti rekomendacijas realiuoju laiku, kai vartotojai sąveikauja su „KillrVideo“ programa, t. Y. Kaip OLTP sąveika.
Norėdami apibrėžti schemą, nustatėme „KillrVideo“ valdomų duomenų pogrupį, kurio mums reikia mūsų grafikui. Tai apėmė naudotojus, vaizdo įrašus, įvertinimus ir žymas, taip pat šių elementų savybes, į kurias galime atsižvelgti algoritme arba pateikti rekomendacijų rezultatuose. Tada Gremline sukūrėme grafiko schemą, kuri atrodė taip:
// sukurti viršūnių etiketesschema.vertexLabel („vartotojas“). partitionKey (‘userId’).
ypatybės („userId“, „email“, „added_date“). ifNotExists (). create ();
schema.vertexLabel („video“). partitionKey (‘videoId’).
ypatybės („videoId“, „pavadinimas“, „aprašymas“, „pridėtas_datos“,
preview_image_location “). ifNotExists (). sukurti ();
schema.vertexLabel („tag“). partitionKey (‘vardas’).
ypatybės („pavadinimas“, „tagged_date“). ifNotExists (). sukurti ();
// sukurti krašto etiketes
schema.edgeLabel („įvertinta“). kelios (). savybės („įvertinimas“).
ryšys („vartotojas“, „vaizdo įrašas“). ifNotExists (). sukurti ();
schema.edgeLabel („įkeltas“). vienas (). ypatybės („pridėtas_datos“).
ryšys („vartotojas“, „vaizdo įrašas“). ifNotExists (). sukurti ();
schema.edgeLabel („taggedWith“). singlas ().
ryšys („video“, „tag“). ifNotExists (). sukurti ();
Pasirinkome modeliuoti vartotojus, vaizdo įrašus ir žymas kaip viršūnes, o naudodami kraštus nustatėme, kurie vartotojai kokius vaizdo įrašus įkėlė, vaizdo įrašų naudotojų įvertinimus ir su kiekvienu vaizdo įrašu susietas žymas. Priskyrėme ypatybes viršūnėms ir briaunoms, į kurias nurodoma užklausose arba įtraukta į rezultatus. Gauta schema atrodo taip „DataStax Studio“ - nešiojamojo kompiuterio stiliaus kūrėjų įrankyje, skirtame kurti ir vykdyti užklausas CQL ir Gremlin.
Remdamiesi šia schema, mes apibrėžėme užklausas, kurios užpildo duomenis diagramoje, ir užklausas, kurios gauna duomenis iš diagramos. Pažvelkime į diagramos užklausą, kuri generuoja rekomendacijas. Čia pateikiamas pagrindinis srautas: nustatykite konkretaus vartotojo panašius vartotojus, kuriems patiko vaizdo įrašai, kurie patiko tam tikram vartotojui, pasirinkite vaizdo įrašus, kurie patiko panašiems vartotojams, išskirkite vaizdo įrašus, kuriuos jau žiūrėjo tas vartotojas, užsisakykite tuos vaizdo įrašus pagal populiarumą ir pateikite rezultatus.
def numRatingsToSample = 1000def localUserRatingsToSample = 10
def minPositiveRating = 4
def vartotojo ID = ...
g.V (). has („vartotojas“, „userId“, vartotojo ID) .as („^ currentUser“)
// gauti visus naudotojo žiūrėtus vaizdo įrašus ir juos išsaugoti
.map (out (‘įvertinta’). dedup (). fold ()). as („^ watchVideos“)
// grįžti pas dabartinį vartotoją
.select („^ currentUser“)
// nustatykite vaizdo įrašus, kuriuos vartotojas įvertino gerai
.outE („įvertinta“). turi („įvertinimas“, gte (minPositiveRating)). inV ()
// kokie kiti vartotojai gerai įvertino tuos vaizdo įrašus?
.inE („įvertinta“). turi („įvertinimas“, gte (minPositiveRating))
// apriboti rezultatų skaičių, todėl tai veiks kaip OLTP užklausa
.sample (numRatingsToSample)
// rūšiuoti pagal įvertinimą, kad būtų palankūs vartotojai, kurie tuos vaizdo įrašus įvertino geriausiai
.by („įvertinimas“). outV ()
// pašalinti dabartinį vartotoją
.kur (neq („^ currentUser“))
Trumpam stabtelėkime, kad atgautume kvapą. Iki šiol šioje kelionėje mes nustatėme panašius vartotojus. Antroji perėjimo dalis užima tuos panašius vartotojus, paima ribotą skaičių vaizdo įrašų, kurie patiko panašiems vartotojams, pašalina vaizdo įrašus, kuriuos vartotojas jau žiūrėjo, ir sukuria rezultatų rinkinį, surūšiuotą pagal populiarumą.
// pasirinkite ribotą skaičių labai vertinamų vaizdo įrašų iš kiekvieno panašaus vartotojo.local (outE (‘įvertintas’). has (‘įvertinimas’, gte (minPositiveRating)). riba (localUserRatingsToSample)). maišas (priskirti). by (‘įvertinimas’). inV ()
// neįtraukti vaizdo įrašų, kuriuos vartotojas jau žiūrėjo
.not (kur (per („^ watchVideos“))))
// nustatykite populiariausius vaizdo įrašus pagal visų įvertinimų sumą
.grupė (). pagal (). pagal (maišas (). suma ())
// dabar, kai turime didelį [video: rezultatas] žemėlapį, užsisakykite jį
. order (local) .by (reikšmės, decr) .limit (local, 100). pasirinkite (keys) .unfold ()
// išves rekomenduojamus vaizdo įrašus, įskaitant vartotoją, kuris įkėlė kiekvieną vaizdo įrašą
.project („video“, „user“)
.pagal ()
.by (__. („įkeltas“))
Nors šis perėjimas atrodo sudėtingas, nepamirškite, kad tai yra visa rekomendacijų algoritmo verslo logika. Čia išsamiai nesigilinsime į kiekvieną šio perėjimo etapą, tačiau kalbos nuoroda yra puikus šaltinis ir yra aukštos kokybės mokymo kursai.
Aš rekomenduoju interaktyviai kurti važiavimus per reprezentatyvų duomenų rinkinį, naudojant tokį įrankį kaip „DataStax Studio“ ar „Gremlin“ konsolę iš „Apache TinkerPop“. Tai leidžia greitai pakartoti ir patobulinti savo keliones. „DataStax Studio“ yra žiniatinklio aplinka, teikianti kelis būdus, kaip vizualizuoti perėjimo rezultatus kaip mazgų ir briaunų tinklus, kaip parodyta paveikslėlyje žemiau. Kiti palaikomi rodiniai yra lentelės, diagramos ir diagramos, taip pat našumo sekimas.
„DataStax“Grafikų duomenų bazės įtraukimas į savo architektūrą
Sukūrę diagramų schemą ir užklausas, atėjo laikas integruoti diagramą į savo programą. Štai kaip mes integravome „DataStax Enterprise Graph“ į „KillrVideo“. „KillrVideo“ daugiapakopė architektūra susideda iš žiniatinklio programos, esančios ant mikro paslaugų, valdančių vartotojus, vaizdo įrašus (įskaitant žymas) ir įvertinimus, rinkinio. Šios paslaugos naudoja „DataStax Enterprise Graph“ duomenų bazę (pastatytą „Apache Cassandra“), kad būtų galima saugoti duomenis ir pasiekti duomenis naudojant CQL.
Savo rekomendacijų variklį įdiegėme kaip „Siūlomų vaizdo įrašų“ paslaugos dalį, kaip parodyta žemiau. Ši paslauga sukuria rekomendacijų, kurioms suteikiamas vartotojo ID, sąrašą. Norėdami įdiegti rekomendacijų variklį, pirmiau aprašytą „Gremlin“ perėjimą išvertėme į „Java“ kodą.
„DataStax“Ši architektūra pabrėžia dažną mikropaslaugų architektūros iššūkį - būtinybę sąveikauti su keleto tarnybų turimais duomenimis. Kaip parodyta aukščiau, rekomendacijoms generuoti naudojama schema remiasi „User Management“, „Video Catalog“ ir „Ratings“ paslaugų duomenimis.
Išsaugojome esamų paslaugų duomenų nuosavybės teisę naudodami asinchroninį pranešimų siuntimą. Vartotojų valdymo, vaizdo įrašų katalogo ir įvertinimų paslaugos skelbia įvykius apie duomenų pasikeitimus. Siūlomų vaizdo įrašų tarnyba užsiprenumeruoja šiuos įvykius ir atitinkamai atnaujina diagramą. Kompromisai, kuriuos čia padarėme, yra būdingi programoms, naudojančioms kelių modelių metodą, kurią aš nagrinėjau savo ankstesniame straipsnyje.
„Gremlin“ kelionių įgyvendinimas „Java“
„DataStax Java“ tvarkyklė suteikia draugišką, sklandų API, skirtą „Gremlin“ perėjimams su „DataStax Enterprise Graph“ įgyvendinti. Dėl API tapo nereikšminga perkelti Groovy pagrindu sukurtas užklausas, kurias sukūrėme „DataStax Studio“, į „Java“ kodą.
Tada mes sugebėjome padaryti savo „Java“ kodą dar labiau įskaitomą ir prižiūrimą naudodami „Gremlin“ funkciją, vadinamą DSL, domenui būdingomis kalbomis. DSL yra „Gremlin“ išplėtimas į tam tikrą domeną. „KillrVideo“ sukūrėme DSL, kad išplėstume „Gremlin“ perėjimo įgyvendinimą terminais, susijusiais su vaizdo įrašų sritimi. KillrVideoTraversalDsl klasė apibrėžia užklausos operacijas, tokias kaip user (), kuris nurodo viršūnę diagramoje su pateiktu UUID, ir rekomenduotiByUserRating (), kuris generuoja rekomendacijas teikiamam vartotojui, remdamasis tokiais parametrais kaip minimalus įvertinimas ir prašomas rekomendacijų skaičius.
DSL naudojimas supaprastino „Suggested Videos“ paslaugos įgyvendinimą panašiai kaip žemiau pateiktame pavyzdyje, o tai sukuria „GraphStatement“ kurį tada vykdome naudodami „DataStax Java“ tvarkyklę:
GraphStatement gStatement = DseGraph.statementFromTraversal (killr.users (userIdString).recommendByUserRating (100, 4, 500, 10)
);
DSL naudojimas leido paslėpti kai kuriuos mūsų grafikų sąveikos sudėtingumą pakartotinai naudojamose funkcijose, kurias prireikus galima sujungti sudarant sudėtingesnes perėjas. Tai leis mums įdiegti papildomus rekomendacinius variklius, kurie prasideda nuo pasirinktos vartotojo viršūnės, kurią teikia Vartotojas() metodą ir leisti programai keistis tarp skirtingų diegimų.
Veikiantis grafiko pavyzdys
„DataStax Enterprise Graph“ integravimo į „KillrVideo“ rezultatus galite pamatyti toliau pateiktoje žiniatinklio programos skiltyje „Jums rekomenduojama“. Išbandykite patys apsilankę //www.killrvideo.com, sukūrę paskyrą ir įvertinę kelis vaizdo įrašus.
„DataStax“Tikiuosi, kad šiame straipsnyje pateikiamos puikios idėjos, kaip diagramų duomenų bazė gali būti naudinga jūsų programai ir kaip pradėti naudotis „Gremlin“ ir „DataStax Enterprise Graph“.
Jeffas Carpenteris yra techninis „DataStax“ evangelistas, kur jis naudojasi savo sistemos architektūros, mikropaslaugų ir „Apache Cassandra“ patirtimi, kad kūrėjai ir operacijų inžinieriai galėtų kurti paskirstytas, patikimas ir saugias sistemas. Jeffas yra knygos „Cassandra: The Definitive Guide“, 2-ojo leidimo, autorius.
—
Naujųjų technologijų forumas suteikia galimybę tyrinėti ir aptarti besiformuojančios įmonės technologijas beprecedentiame gylyje. Atranka yra subjektyvi, atsižvelgiant į mūsų pasirinktas technologijas, kurios, mūsų manymu, yra svarbios ir labiausiai domina skaitytojus. nepriima rinkodaros užtikrinimo priemonės paskelbimui ir pasilieka teisę redaguoti visą pateiktą turinį. Visus klausimus siųskite adresu[email protected].
