Какво е база данни с графики? По-добър начин за съхраняване на свързани данни

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

Един от най-малко разбираемите видове бази данни е базата данни с графики. Проектирана за работа с силно взаимосвързани данни, базата данни с графики може да бъде описана като по-„релационна“, отколкото релационна база данни. Графичните бази данни блестят, когато целта е да се уловят сложни взаимоотношения в обширни мрежи от информация. 

Ето по-подробен поглед върху това какво представляват графичните бази данни, защо те за разлика от другите бази данни и какви проблеми с данните са създадени да решават.

Графична база данни спрямо релационна база данни

В традиционната релационна или SQL база данни данните са организирани в таблици. Всяка таблица записва данни в определен формат с фиксиран брой колони, всяка колона със собствен тип данни (цяло число, час / дата, текст на свободна форма и т.н.).

Този модел работи най-добре, когато се занимавате главно с данни от която и да е таблица. Също така не работи твърде зле, когато обединявате данни, съхранявани в множество таблици. Но това поведение има някои забележими граници.

Помислете за музикална база данни с албуми, групи, етикети и изпълнители. Ако искате да докладвате за всички изпълнители, които са включени в този албум от тази група, издадена на тези етикети - четири различни таблици - трябва изрично да опишете тези взаимоотношения. С релационна база данни вие постигате това чрез нови колони с данни (за връзки едно към едно или едно към много) или нови таблици (за връзки много към много).

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

Накратко, ако  връзките между данните , а не самите данни, са вашата основна грижа, тогава друг вид база данни - база данни с графики - е в ред.

Графични характеристики на базата данни

Терминът „графика“ идва от употребата на думата в математиката. Там се използва за описване на колекция от възли (или върхове ), всяка от които съдържа информация ( свойства ) и с обозначени връзки (или ръбове ) между възлите.

Социалната мрежа е добър пример за графика. Хората в мрежата ще бъдат възлите, атрибутите на всеки човек (като име, възраст и т.н.) ще бъдат свойства, а линиите, свързващи хората (с етикети като „приятел“ или „майка“ или „ супервизор ”) би посочила връзката им. 

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

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

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

Графирайте случаи на използване на база данни

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

Отново социалната мрежа е полезен пример. Графичните бази данни намаляват обема на работата, необходима за изграждане и показване на изгледите на данни, намерени в социалните мрежи, като например емисии за активност, или определяне дали може да познавате дадено лице поради близостта му до други приятели, които имате в мрежата.

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

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

Графирайте заявки към база данни

Графичните бази данни - подобно на други бази данни NoSQL - обикновено използват собствена методология за персонализирани заявки вместо SQL.

Един често използван език за заявки за графики е Cypher, първоначално разработен за базата данни за графики Neo4j. От края на 2015 г. Cypher е разработен като отделен проект с отворен код и редица други доставчици са го приели като система за заявки за своите продукти (напр. SAP HANA).

Ето пример за заявка на Cypher, която връща резултат от търсенето за всеки, който е приятел на Скот:

МАТЧ (а: Лице {име: 'Скот'}) - [: FRIENDOF] -> (b) ВРЪЩАНЕ b 

Символът със стрелка ( ->) се използва в заявки на Cypher, за да представи насочена връзка в графиката.

Друг често срещан език за заявки на графики, Gremlin, е разработен за рамката за изчисляване на графики Apache TinkerPop. Синтаксисът на Gremlin е подобен на този, използван от библиотеките за достъп до бази данни на OR на някои езици.

Ето пример за заявка „приятели на Скот“ в Гремлин:

gV (). has (“name”, “Scott”). out (“friendof”) 

Много бази данни с графики имат поддръжка за Gremlin чрез библиотека, било то вградена или трета страна.

Още един език за заявки е SPARQL. Първоначално е разработен от W3C за заявка на данни, съхранявани във формат за рамка за описание на ресурсите (RDF) за метаданни. С други думи, SPARQL не е създаден за търсене в графични бази данни, но може да се използва за тях. Като цяло Сайфър и Гремлин са възприети по-широко.

Запитванията на SPARQL имат някои елементи, напомнящи на SQL, а именно  SELECTи WHEREклаузи, но останалата част от синтаксиса е коренно различна. Не мислете за SPARQL като за свързан със SQL изобщо или по този въпрос с други езици на графични заявки.

Популярни графични бази данни

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

Neo4j

Neo4j е лесно най-зрялата (11 години и отчитане) и най-известната от графичните бази данни за общо ползване. За разлика от предишните продукти с бази данни на графики, той не използва SQL back-end. Neo4j е родна база данни на графи, която е проектирана отвътре навън, за да поддържа големи графични структури, както при заявки, връщащи стотици хиляди връзки и повече.

Neo4j се предлага както в безплатни корпоративни издания с отворен код, така и срещу заплащане, като последните нямат ограничения за размера на набор от данни (наред с други функции). Можете също така да експериментирате с Neo4j онлайн чрез неговата Sandbox, която включва някои примерни набори от данни, с които да практикувате.

Вижте прегледа на Neo4j за повече подробности.

Microsoft Azure Cosmos DB

Облачната база данни Azure Cosmos DB е амбициозен проект. Предназначен е да емулира множество видове бази данни - конвенционални таблици, ориентирани към документи, семейство колони и графики - всичко това чрез една единна унифицирана услуга с последователен набор от API.

За тази цел базата данни с графики е само един от различните режими, в които може да работи Cosmos DB. Той използва езика за заявки Gremlin и API за заявки от графичен тип и поддържа конзолата Gremlin, създадена за Apache TinkerPop като друг интерфейс.

Друга голяма точка на продажба на Cosmos DB е, че индексирането, мащабирането и гео-репликацията се обработват автоматично в облака на Azure, без да се въртят копчета на вашия край. Все още не е ясно как цялостната архитектура на Microsoft измерва базите данни на графиките по отношение на производителността, но Cosmos DB със сигурност предлага полезна комбинация от гъвкавост и мащаб.

Вижте прегледа на Azure Cosmos DB за повече подробности.

Янус Граф

JanusGraph беше раздвоен от проекта TitanDB и сега е под управлението на Linux Foundation. Той използва всеки от редица поддържани задни краища - Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB - за съхраняване на графични данни, поддържа езика за заявки на Gremlin (както и други елементи от стека Apache TinkerPop) и може също включете търсене на пълен текст чрез проектите Apache Solr, Apache Lucene или Elasticsearch.

IBM, един от поддръжниците на проекта JanusGraph, предлага хоствана версия на JanusGraph в IBM Cloud, наречена Compose for JanusGraph. Подобно на Azure Cosmos DB, Compose for JanusGraph осигурява автоматично мащабиране и висока наличност, като цените се базират на използването на ресурсите.