Конечно, вы и сами можете легко нагуглить ответы на этот вопрос, однако, как я обнаружил, большинство ответов, которые вы найдете, раскрывают эту тему чересчур поверхностно.
В сегодняшнем вечно занятом мире новые данные, теперь представляющие из себя фундаментальные активы большинства предприятий, создаются без остановки. Системы доступны 24/7, генерируя данные каждую секунду каждого дня. И даже больше, эти сложные композиции систем генерации и обработки данных непрерывно взаимодействуют друг с другом для предоставления услуг конечному пользователю. В последнее время я все чаще натыкаюсь на один вопрос, который заключается в следующем: как обстоят дела с графовыми базами данных и чем они выделяются на фоне реляционных? И в итоге я решил как следует разобраться в этой теме. Найти множество ответов на этот вопрос не представляет особого труда, достаточно просто немного погуглить. Однако, как я обнаружил, большинство ответов перечисляют преимущества очень поверхностно. Именно поэтому я решил поделиться с вами в этой статье кратким разбором того, в чем по моему мнению заключается их истинная ценность — независимо от маркетинговых презентаций крупных компаний и технологических инфлюенсеров.
Базы данных хранят материализованное состояние всех ранее обработанных событий, поступающих в нашу систему.
Событие — это автономное и неизменное сообщение, поступающее в нашу систему. Когда мы настраиваем базу данных для обработки и хранения таких событий, нам приходится принимать различные проектные решения:
Какие данные мы хотим хранить?
Как они представлены?
На каком уровне абстракции мы храним данные?
Какие события мы хотели бы обрабатывать и как применять их к нашим данным?
Например: мы можем сохранять все события в необработанном виде по мере их поступления в наши системы или отражать их в базе данных, только если они обновляют наши данные.
У базы данных есть функциональное назначение и причина для хранения данных определенным образом.
Например, если база данных служит в качестве слоя хранения данных для пользовательского приложения, обслуживающего пользовательские запросы в режиме реального времени, то она должна включать представление, обеспечивающее быстрый доступ к данным для этого конкретного набора запросов. И напротив, для ответов на статистические бизнес-вопросы, которые охватывают большие объемы исторических данных, это может быть не самый лучший подход.
Так в чем же разница между графовыми и реляционными базами данных? Поскольку графовые базы данных привлекают все больше и больше внимания со стороны многих компаний, но в то же время большинство компаний все еще используют традиционные реляционные базы данных, я решил сосредоточиться именно на этих двух типах баз данных.
Реляционные базы данных сущность-ориентированные
Начнем с реляционной модели. Реляционные базы данных хранят данные в таблицах. Таблица представляет сущность. Я бы назвал такой тип баз данных сущность-ориентированными (entity-first). Их подход заключается в том, чтобы определить схему для таблицы, а затем хранить в этой таблице только объекты этого конкретного типа. Поэтому данные с одинаковой структурой хранятся близко друг к другу.
Реляционные модели хранят отношения как данные в домене пользователя
В реляционной модели не существует концепции отношения между данными. Это означает, что вы не можете определить связь между таблицами. Чтобы связать данные в реляционной модели, вы должны явно смоделировать связь с вашими данными. Вы не можете отделить фактические данные от данных, которые хранятся только для представления отношений. Единственный способ смоделировать отношение — это смоделировать его как внешний ключ в вашей таблице — либо как атрибут вашей сущности (один-к-одному, многие-к-одному), либо с помощью дополнительной таблицы (один-к-многим, многие-к-многим). Можно рассматривать эту таблицу отображения (mapping table) как таблицу отношений и, следовательно, представлять отношение в виде сущности. Тем не менее, эта технология не подразумевает поддержки отношений — мы просто создаем новые данные в таблице. Это приводит к одному фундаментальному выводу: реляционные базы данных хранят внешние ключи как пользовательские данные — например, ссылки на другие записи в таблице сущностей. Поскольку ссылка представляет собой данные в домене пользователя, такая база данных не может иметь автоматического механизма для управления ими — эта задача ложится на пользовательскую логику.
Графовые базы данных отношение-ориентированные
Графовая модель, напротив, имеет явно определенные понятия для сущностей (узлы) и отношений (ребра), в чем и заключается ее главное отличие от реляционной модели. Поскольку мы можем определять отношения между сущностями напрямую, нам не нужно заботиться о том, как их моделировать в нашей схеме. Нам не нужно знать о внешних ключах, и нам также не нужно прописывать логику того, как их хранить. Мы определяем схему сущностей и отношений, и система позаботится об этом всем сама. Это дает нам огромное преимущество, если мы хотим моделировать сильно связанные данные: реализация может позаботиться о ссылках наиболее эффективным образом. Вместо явного хранения дополнительных данных (ссылок) в виде атрибутов в наших таблицах с данными, система графовой базы данных может хранить настоящие указатели памяти на ближайшую связанную сущность. Большинство систем графовых баз данных хранят данные в структурах, похожих на связанные списки (linked lists). Они хранят прямые ссылки на данные, которые связаны, а не аналогичные объекты, для представления этих связей. Я бы назвал их отношение-ориентированными (relationship-first).
Вышеупомянутые различия в этих двух подходах наталкивают на некоторые выводы о областях применения, где каждый из них будет максимально полезен.
Графовые базы данных хранят данные подобно объектно-ориентированным языкам
Поскольку реляционные базы данных не включают в себя понятие отношения, нам необходимо явно смоделировать их как данные в нашей схеме. Это приводит к несоответствию с объектно-ориентированным моделированием, которое мы используем в большинстве языков программирования. Каждый объект может содержать набор других объектов, с которыми он связан. Эти ссылки обычно являются указателями на объекты в памяти, и нам не нужно хранить их явно. Нам также не нужно находить объект в памяти по каким-либо атрибуту внешнего ключа. Следовательно, для выполнения так называемого объектно-реляционного отображения (object-relational mapping) требуются значительные накладные расходы.
Графовые базы данных хранят данные подобно объектно-ориентированным языкам — у нас есть прямые указатели на связанные объекты. Следовательно, объектно-реляционное отображение здесь максимально прямолинейно.
Просмотр одного отношения может быть выполнен за константное время
Поскольку графовые базы данных могут переходить от одной сущности к связанной с ней, просто следуя указателю памяти, мы называем это смежностью без индекса (index-free adjacency). Нам не нужно искать внешний ключ в другой таблице (используя индекс) или, что еще хуже, искать ключ в таблице отображения, а полученный внешний ключ - в третьей таблице, все чтобы просмотреть одно отношение. Следовательно, просмотр одного отношения может выполняться за константное время. Это означает, что он не зависит от объема или размера данных, хранящихся в графовой базе данных. В то время как в реляционном базе данных нам приходится сканировать индекс (потенциально даже несколько индексов), затраты на что возрастают по мере увеличения объема данных.
Просто это даже ощущается как-то неправильно — писать SQL-запросы для поиска связанных данных.
Хоть мы и можем моделировать связанные данные и отношения в реляционных моделях, но когда мы пытаемся проследить путь с несколькими переходами, используя язык запросов SQL, у нас может возникнуть ощущение, что то, что мы описываем, — это не совсем то, чего мы хотим достичь. Мы должны объединять (оператором join) таблицы по определенному условию, которое мы должны указать вручную, чтобы найти соседние данные — потенциально несколько раз и, следовательно, через уродливые вложенные запросы. Такие запросы выглядят очень громоздко и требуют много накладных расходов. Если что-то такое имеет место быть, обычно это явный признак того, что мы используем технологию не совсем так, как предполагалось. Мы не хотим объединять целые таблицы — мы просто хотим найти конкретные данные.
В графовых базах данных все это выглядит иначе. Поскольку они были разработаны для обработки запросов связанных данных на основе структуры их соединения, они предлагают для этого лаконичный и интуитивно понятный синтаксис. Мы можем точно указать, какие пути мы хотим найти. Никаких условий объединений или сложных вложенных запросов, никаких таблиц отображения — только простое описание того, что мы хотим найти.
Заключение
Графовые и реляционные базы данных отличаются одним фундаментальным принципом их архитектуры: графовая модель определяет понятие отношения, а реляционная — нет. Вот почему графовая база данных может гораздо эффективнее управлять взаимосвязанными данными. Тем не менее, у обоих подходов есть свои причины для существования: графовые модели работают лучше и более интуитивно понятны при анализе всего контекста вокруг одной точки данных — потенциально с несколькими переходами. Однако, если исследование данных с высокой степенью соединения и высокой степенью связанности не является обязательным требованием, реляционная модель вполне может удовлетворить эти потребности.
Всех желающих приглашаем на открытое занятие «Работа с ГЕО-данными в DWH: координаты, зоны, агрегация». На открытом уроке рассмотрим:
- Привязка событий к зонам на карте города;
- Агрегирование и аналитика данных с помощью H3 (гексагоны);
- Оптмизация расчетов и производительности, кэширование.
