Защо трябва да използвате база данни с графики

Джеф Карпентър е технически евангелизатор в DataStax.

Напоследък има много шум за базите данни с графики. Докато графичните бази данни като DataStax Enterprise Graph (базирани на Titan DB), Neo4 и IBM Graph съществуват от няколко години, последните съобщения за управлявани облачни услуги като AWS Neptune и добавянето от Microsoft на графични възможности към Azure Cosmos DB показват, че графичните бази данни са влезли в мейнстрийма. С целия този интерес, как да определите дали базата данни с графики е подходяща за вашето приложение?

Какво е база данни с графики?

Преди да продължим по-нататък, нека дефинираме малко терминология. Какво е база данни с графики? Мислете за него от гледна точка на модела на данни. Графичният модел на данни се състои от върхове, които представляват обектите в домейн, и ръбове, които представляват връзките между тези обекти. Тъй като и върховете, и ребрата могат да имат допълнителни двойки име-стойност, наречени свойства , този модел на данни е официално известен като графика на свойствата . Някои бази данни на графики изискват да дефинирате схема за вашата графика - т.е. дефиниране на етикети или имена за вашите върхове, ръбове и свойства преди попълване на каквито и да е данни, докато други бази данни ви позволяват да работите без фиксирана схема.

Както може би сте забелязали, в модела на графичните данни няма нова информация, която да не можем да уловим в традиционен релационен модел на данни. В края на краищата е лесно да се опишат връзките между таблици, като се използват външни ключове, или можем да опишем свойствата на връзка с таблица за присъединяване. Ключовата разлика между тези модели данни е начинът на организиране и достъп до данните. Разпознаването на ръбове като „гражданин от първа класа“ заедно с върховете в модела на графичните данни позволява на основния механизъм на базата данни да се итерира много бързо във всяка посока чрез мрежи от върхове и ребра, за да задоволи заявките за приложения, процес, известен като обхождане .

Гъвкавостта на модела на графичните данни е ключов фактор, движещ скорошния скок в популярността на базата данни с графики. Същите изисквания за наличност и масивен мащаб, които стимулираха разработването и приемането на различни предложения на NoSQL през последните 10 или повече години, продължават да дават плодове в последната тенденция на графиката.

Как да разберете кога имате нужда от база данни с графики

Въпреки това, както при всяка популярна технология, може да има тенденция да се прилагат графични бази данни за всеки проблем. Важно е да се уверите, че имате подходящ случай на употреба. Например графиките често се прилагат към проблемни домейни като:

  • Социални мрежи
  • Препоръка и персонализация
  • Клиент 360, включително разделителна способност на обекта (свързване на потребителски данни от множество източници)
  • Откриване на измами
  • Управление на активи

Независимо дали вашият случай на употреба се вписва в един от тези домейни или не, има някои други фактори, които трябва да вземете предвид, които могат да помогнат да се определи дали базата данни с графики е подходяща за вас:

  • Връзки много към много. В книгата си „Проектиране на интензивни приложения за данни“ (O’Reilly) Мартин Клепман предполага, че честите връзки „много към много“ във вашия домейн на проблема са добър показател за използване на графики, тъй като релационните бази данни са склонни да се борят ефективно за тези навигации.
  • Висока стойност на връзките. Друга евристика, която често съм чувал: ако връзките между вашите елементи от данни са също толкова важни или по-важни от самите елементи, трябва да помислите за използване на графика.
  • Ниска латентност в голям мащаб. Добавянето на друга база данни към вашето приложение също добавя сложност към вашето приложение. Способността на графичните бази данни да се придвижват през връзките, представени в големи масиви от данни, по-бързо от другите видове бази данни е това, което оправдава тази допълнителна сложност. Това е особено вярно в случаите, когато сложна релационна заявка за присъединяване вече не се изпълнява и няма допълнителни печалби за оптимизация на заявката или релационната структура.

Дефиниране на схема на графики и заявки с Gremlin

Нека да разгледаме как да започнем да използваме база данни с графики, като използваме реален пример, препоръчителната система, която наскоро добавихме към KillrVideo. KillrVideo е справочно приложение за споделяне и гледане на видеоклипове, което създадохме, за да помогнем на разработчиците да се научат как да използват DataStax Enterprise, включително DataStax Enterprise Graph, база данни на графики, изградена върху високо мащабируеми технологии за данни, включително Apache Cassandra и Apache Spark.

Езикът, използван за описване и взаимодействие с графики в DataStax Enterprise Graph е Gremlin, който е част от проекта Apache TinkerPop. Gremlin е известен като език за преминаване към описване на обхождания на графики поради своята гъвкавост, разширяемост и поддръжка както на декларативни, така и на императивни заявки. Gremlin се основава на езика Groovy, а драйверите се предлагат на множество езици. Най-важното е, че Gremlin се поддържа от най-популярните бази данни с графики, включително DataStax Enterprise Graph, Neo4j, AWS Neptune и Azure Cosmos DB.

Създадохме препоръчителен алгоритъм, за да идентифицираме данните, които ще ни трябват като вход. Подходът беше да се генерират препоръки за даден потребител въз основа на видеоклипове, харесвани от подобни потребители. Нашата цел беше да генерираме препоръки в реално време, докато потребителите взаимодействат с приложението KillrVideo, т.е. като OLTP взаимодействие.

За да дефинираме схемата, идентифицирахме подмножество от данни, управлявани от KillrVideo, които са ни необходими за нашата графика. Това включваше потребители, видеоклипове, оценки и тагове, както и свойства на тези елементи, на които може да се позовем в алгоритъма или да ги представим в резултатите от препоръките. След това създадохме графична схема в Gremlin, която изглеждаше така:

// създаване на етикети на върхове

schema.vertexLabel („потребител“). partitionKey ('userId').

  свойства (“userId”, “email”, “added_date”). ifNotExists (). create ();

schema.vertexLabel (“video”). partitionKey ('videoId').

  свойства („videoId“, „name“, „description“, „added_date“,

preview_image_location ”). ifNotExists (). create ();

schema.vertexLabel („таг“). partitionKey („име“).

  свойства (“name”, “tagged_date”). ifNotExists (). create ();

// създаване на етикети на ръбове

schema.edgeLabel („оценен“). множествени (). свойства („рейтинг“).

  връзка („потребител“, „видео“). ifNotExists (). create ();

schema.edgeLabel („качен“). single (). свойства („added_date“).

  връзка („потребител“, „видео“). ifNotExists (). create ();

schema.edgeLabel (“taggedWith”). single ().

  връзка („видео“, „таг“). ifNotExists (). create ();

Избрахме да моделираме потребителите, видеоклиповете и етикетите като върхове и използвахме ръбове, за да идентифицираме кои потребители са качили кои видеоклипове, потребителски оценки на видеоклипове и маркери, свързани с всеки видеоклип. Присвоихме свойства на върхове и ребра, които са посочени в заявки или са включени в резултатите. Получената схема изглежда така в DataStax Studio, инструмент за разработчици в стил бележник за разработване и изпълнение на заявки в CQL и Gremlin.

Въз основа на тази схема дефинирахме заявки, които попълват данни в графиката и заявки, които извличат данни от графиката. Нека разгледаме графична заявка, която генерира препоръки. Ето основния поток: За даден потребител идентифицирайте подобни потребители, които харесаха видеоклипове, харесани от дадения потребител, изберете видеоклипове, които също са харесали подобни потребители, изключете видеоклипове, които даден потребител вече е гледал, поръчайте тези видеоклипове по популярност и предоставете резултатите

def numRatingsToSample = 1000

def localUserRatingsToSample = 10

def minPositiveRating = 4

def userID = ...

gV (). has (“user”, “userId”, userID) .as (“^ currentUser”)

    // получаваме всички видеоклипове, които потребителят е гледал, и ги съхраняваме

    .map (out ('rated'). dedup (). fold ()). as (“^ gledanVideos”)

    // връщане към текущия потребител

    .select (“^ currentUser”)

    // идентифициране на видеоклиповете, които потребителят е оценил високо

    .outE („оценен“). has („рейтинг“, gte (minPositiveRating)). inV ()

    // какви други потребители оцениха тези видеоклипове високо?

    .inE („оценен“). има („рейтинг“, gte (minPositiveRating))

    // ограничаваме броя на резултатите, така че това ще работи като OLTP заявка

    .sample (numRatingsToSample)

    // сортиране по рейтинг в полза на потребители, които са оценили тези видеоклипове с най-висока оценка

    .by ('рейтинг'). outV ()

    // премахване на текущия потребител

    . къде (neq („^ currentUser”))

Нека да спрем за момент, за да си поемем дъх. Досега в това обръщане идентифицирахме подобни потребители. Втората част от обхода взема тези подобни потребители, грабва ограничен брой видеоклипове, които тези подобни потребители харесват, премахва видеоклипове, които потребителят вече е гледал, и генерира набор от резултати, сортиран по популярност.

    // изберете ограничен брой високо оценени видеоклипове от всеки подобен потребител

   .local (outE ('rated'). has ('rating', gte (minPositiveRating)). limit (localUserRatingsToSample)). sack (assign) .by ('rating'). inV ()

     // изключваме видеоклипове, които потребителят вече е гледал

    .not (където (в рамките на („^ gledalVideos”)))

    // идентифициране на най-популярните видеоклипове по сбор от всички оценки

    .group (). by (). by (sack (). sum ())

    // сега, когато имаме голяма карта на [видео: резултат], поръчайте го

    .order (local) .by (values, decr) .limit (local, 100) .select (ключове) .unfold ()

    // извежда препоръчителни видеоклипове, включително потребителя, който е качил всеки видеоклип

    .project ('видео', 'потребител')

        .by ()

        .by (__. в („качено“))

Въпреки че това обръщане изглежда сложно, имайте предвид, че това е цялата бизнес логика на препоръчителния алгоритъм. Тук няма да разглеждаме подробно всяка стъпка от това обръщане, но езиковата справка е чудесен ресурс и са налични висококачествени курсове за обучение.

Препоръчвам интерактивно разработване на обхождания през представителен набор от данни с помощта на инструмент като DataStax Studio или конзолата Gremlin от Apache TinkerPop. Това ви позволява бързо да повторите и усъвършенствате вашите траверса. DataStax Studio е уеб-базирана среда, която предоставя множество начини за визуализиране на резултатите от обхода като мрежи от възли и ръбове, както е показано на снимката по-долу. Други поддържани изгледи включват таблици, диаграми и графики, както и проследяване на производителността.

DataStax

Включване на база данни с графики във вашата архитектура

След като сте проектирали вашата схема на графики и заявки, е време да интегрирате графиката във вашето приложение. Ето как интегрирахме DataStax Enterprise Graph в KillrVideo. Многостепенната архитектура на KillrVideo се състои от уеб приложение, което е разположено върху набор от микроуслуги, които управляват потребители, видеоклипове (включително маркери) и оценки. Тези услуги използват базата данни DataStax Enterprise Graph (изградена върху Apache Cassandra) за съхранение на данни и достъп до данните с помощта на CQL.

Внедрихме нашия механизъм за препоръки като част от услугата за предложени видеоклипове, както е показано по-долу. Тази услуга генерира списък с препоръки с даден идентификатор на потребителя. За да приложим механизма за препоръки, преведохме описанието по-горе в Gremlin в Java код.

DataStax

Тази архитектура подчертава честото предизвикателство в микросервисните архитектури - необходимостта от взаимодействие с данни, притежавани от множество услуги. Както е показано по-горе, графиката, използвана за генериране на препоръки, разчита на данни от услугите за управление на потребители, видео каталог и рейтинги.

Запазихме собствеността върху данните на съществуващите ни услуги, като използвахме асинхронни съобщения. Услугите за управление на потребители, видео каталог и рейтинги публикуват събития за промени в данните. Предлаганата услуга за видеоклипове се абонира за тези събития и прави съответните актуализации на графиката. Компромисите, които направихме тук, са типични за приложения, които използват мултимоделен подход, тема, която изследвах в предишната си статия.

Внедряване на обхождания на Gremlin в Java

Java драйверът DataStax предоставя приятелски, плавен API за внедряване на обхождания на Gremlin с DataStax Enterprise Graph. API го направи тривиален за мигриране на Groovy-базирани заявки, които създадохме в DataStax Studio в Java код.

След това успяхме да направим нашия Java код още по-четим и поддържаем, използвайки функция на Gremlin, известна като DSL, специфични за домейна езици. DSL е разширение на Gremlin в определен домейн. За KillrVideo създадохме DSL, за да разширим изпълнението на обхода на Gremlin с термини, които са от значение за видео домейна. На KillrVideoTraversalDslопределя класа на заявката операции като ф ser(), която е локализирана връх в графиката с условие UUID и recommendByUserRating(), които генерира препоръки за предоставен на потребителя въз основа на параметри, като например минимален рейтинг и заявен брой препоръки.

Използването на DSL опрости изпълнението на предложената услуга за видеоклипове до нещо като примерната по-долу, което създава GraphStatement, което след това изпълняваме, използвайки DataStax Java Driver:

GraphStatement gStatement = DseGraph.statementFromTraversal (killr.users (userIdString)

       .recommendByUserRating (100, 4, 500, 10)

);

Използването на DSL ни позволи да скрием част от сложността на нашите графични взаимодействия във функции за многократна употреба, които след това могат да се комбинират, ако е необходимо, за да образуват по-сложни обхождания. Това ще ни позволи да внедрим допълнителни механизми за препоръки, които започват от избрания потребителски връх, предоставен от user()метода, и ще позволи на приложението да сменя между различните реализации.

Пример за работеща графика

Можете да видите резултатите от нашата интеграция на DataStax Enterprise Graph в KillrVideo в раздела „Препоръчано за вас“ на уеб приложението, показано по-долу. Изпробвайте сами на //www.killrvideo.com, като създадете акаунт и оцените няколко видеоклипа.

DataStax

Надявам се, че тази статия ви дава някои чудесни идеи за това как базата данни с графики може да има смисъл за вашето приложение и как да започнете с Gremlin и DataStax Enterprise Graph.

Джеф Карпентър е технически евангелизатор в DataStax, където използва своя опит в системната архитектура, микроуслугите и Apache Cassandra, за да помогне на разработчиците и операционните инженери да изградят разпределени системи, които са мащабируеми, надеждни и сигурни. Джеф е автор на Cassandra: The Definitive Guide, 2nd Edition.

-

Форумът New Tech предоставя място за изследване и обсъждане на нововъзникващите корпоративни технологии в безпрецедентна дълбочина и широчина. Изборът е субективен, базиран на нашия избор на технологиите, които смятаме, че са важни и представляват най-голям интерес за читателите. не приема маркетингово обезпечение за публикуване и си запазва правото да редактира цялото съдържание. Изпращайте всички запитвания на  [email protected] .