Почему язык запросов к базе данных имеет значение

Поиск лучшей базы данных для вашего приложения или стека разработки — это больше, чем просто функции, масштабируемость и производительность. Хотя все это важно, есть еще один элемент графовой базы данных, который слишком многие архитекторы упускают из виду: язык запросов к базе данных.

Большинство реляционных баз данных (RDBMS) используют вариант SQL (язык структурированных запросов ), что делает SQL де-факто языком запросов к базе данных среди большинства профессионалов в области данных. Но с появлением графовых баз данных, которые более эффективны, чем реляционные базы данных , пришло время соответствующего перехода на более мощный язык запросов.

В этой серии блогов «Графические базы данных для начинающих» я познакомлю вас с основами графовой технологии, предполагая, что у вас мало (или нет) опыта в пространстве. В последние недели мы обсуждали, почему графы — это будущее , почему важны взаимосвязи данных , основы моделирования данных и как избежать наиболее распространенных (и фатальных) ошибок моделирования данных .

На этой неделе мы обсудим, почему язык запросов к базе данных имеет значение, даже если вы не разработчик.

Почему нам нужны языки запросов

До этого момента в нашей серии для начинающих все наши модели баз данных были в форме диаграмм, подобных приведенной ниже.

Графические диаграммы, подобные этой, идеально подходят для описания графической базы данных вне любого технологического контекста. Однако, когда дело доходит до фактического использования базы данных, каждому разработчику, архитектору и заинтересованным сторонам бизнеса нужен конкретный механизм для создания, обработки и запроса данных. То есть нам нужен язык запросов.

До сих пор язык запросов, используемый разработчиками и архитекторами данных (например, SQL), был слишком загадочным и эзотерическим, чтобы его могли понять лица, принимающие бизнес-решения. Но так же, как базы данных графов сделали процесс моделирования более понятным для непосвященных, так и язык запросов к базе данных графов облегчил обычному человеку понимание и создание собственных запросов.

Почему лингвистическая эффективность имеет значение

Если вы не технический специалист, вам может быть интересно, почему язык запросов к базе данных имеет значение вообще. В конце концов, если языки запросов являются чем-то похожим на естественные человеческие языки, то не должны ли они все в конечном итоге передать одну и ту же точку с несколькими отличиями в выражениях? Ответ и да, и нет.

Давайте рассмотрим пример на естественном языке. На английском вы можете сказать: «Я любил послеобеденный разговор», вспоминая свое детство. На испанском языке эта же фраза написана так: « Disfrutaba sobremesa. «Оба языка выражают одну и ту же идею, но гораздо эффективнее передать ее.

Когда дело доходит до языка запросов, лингвистика эффективности аналогична. Один запрос в SQL может быть на много строк длиннее, чем тот же запрос в языке запросов к базе данных графа, таком как Cypher . (Вот один прекрасный пример эффективного отображения с естественного языка на Cypher .)

Длинные запросы не только требуют больше времени для выполнения, но они также с большей вероятностью включают ошибки кодирования человеком из-за их сложности. Кроме того, более короткие запросы упрощают понимание и сопровождение в вашей команде разработчиков. Например, представьте, что если внешний разработчик должен был выполнить сложный запрос и попытаться выяснить намерения первоначального разработчика, проблема наверняка возникнет.

Но о каком уровне эффективности мы говорим между запросами SQL и графовыми запросами? Как гораздо более эффективным является один против другого? Ответ: достаточно быстро, чтобы существенно изменить ваш бизнес .

Эффективность графовых запросов означает, что они выполняются в режиме реального времени, а в экономике, которая работает со скоростью одного твита , это разница, которую вы не можете игнорировать.

Интимные отношения между моделированием и запросами

Прежде чем углубиться в механику языка запросов к базе данных графов, приведенного ниже, стоит отметить, что язык запросов — это не просто запрос (или запрос) базы данных для определенного набора результатов; это также о моделировании этих данных в первую очередь.

Из предыдущих сообщений мы знаем, что моделирование данных для графической базы данных так же просто, как соединение кругов и линий на доске. То, что вы рисуете на доске, — это то, что вы храните в базе данных.

Сама по себе такая простота моделирования имеет много преимуществ для бизнеса, наиболее очевидным из которых является то, что вы можете понять, что, черт возьми, создают ваши разработчики баз данных. Но это еще не все: интуитивно понятная модель, построенная на правильном языке запросов, гарантирует отсутствие несоответствия между тем, как вы построили данные, и тем, как вы их анализируете.

Язык запросов представляет свою модель тесно. Вот почему SQL — это все о таблицах и объединениях, а Cypher — об отношениях между сущностями. Как с моделью графа работать более естественно, так и с Сайфер, поскольку она заимствует из графического представления окружностей, связанных стрелками, которое может понять даже ребенок.

В реляционной базе данных процесс моделирования данных настолько абстрагирован от реальных повседневных SQL-запросов, что существует существенное несоответствие между анализом и реализацией. Другими словами, процесс построения модели реляционной базы данных не подходит для эффективного (и ответа) на вопросы из этой же модели.

С другой стороны, модели графовых баз данных не только сообщают, как связаны ваши данные, но и помогают вам четко определить, какие вопросы вы хотите задать в своей модели данных. Графовые модели и графовые запросы — это всего лишь две стороны одной медали.

Правильный язык запросов к базе данных помогает нам пересекать обе стороны.

Введение в Cypher, язык запросов к базе данных графов

Пришло время погрузиться в детали. В то время как большинство реляционных баз данных используют форму SQL в качестве языка запросов, мир графовых баз данных более разнообразен, поэтому мы рассмотрим конкретный язык запросов баз данных графов: Cypher.

Хотя в настоящее время специфично для Neo4j , близкое отношение Cypher к представлению графов в виде диаграмм делает его идеальным для описания графов. Cypher, пожалуй, самый простой в изучении язык запросов к графам, и как только вы поймете Cypher, станет очень легко переходить и изучать другие языки запросов к графам.

Это введение не является справочным документом для Cypher, а является просто обзором высокого уровня.

Cypher предназначен для легкого чтения и понимания разработчиками, специалистами по базам данных и заинтересованными сторонами. Его легко использовать, потому что он соответствует тому, как мы интуитивно описываем графики с помощью диаграмм.

Основное понятие Cypher заключается в том, что он позволяет запрашивать базу данных для поиска данных, которые соответствуют определенному шаблону. В разговорной речи мы могли бы попросить базу данных «найти такие вещи», и способ, которым мы описываем, как «такие вещи» выглядят, состоит в том, чтобы нарисовать их, используя искусство ASCII .

Рассмотрим простой рисунок на рисунке ниже.

Эта графическая диаграмма описывает трех общих друзей.

Если мы хотим выразить шаблон этого базового графа в Cypher, мы бы написали:

(emil)<-[:KNOWS]-(jim)-[:KNOWS]->(ian)-[:KNOWS]->(emil) 

Это утверждение Cypher описывает путь, который образует треугольник, который соединяет узел, который мы называем jimс двумя узлами, которые мы называем ianи emil, и который также соединяет ianузел с emilузлом. Как видите, Cypher, естественно, следует тому, как мы рисуем графики на доске.

Теперь, хотя этот шаблон Cypher описывает простую структуру графа, он еще не ссылается на какие-либо конкретные данные в базе данных. Чтобы связать шаблон с конкретными узлами и отношениями в существующем наборе данных, нам сначала нужно указать некоторые значения свойств и метки узлов, которые помогут найти соответствующие элементы в наборе данных.

Вот наш более конкретный запрос:

(emil:Person {name:'Emil'})
     <-[:KNOWS]-(jim:Person {name:'Jim'})
     -[:KNOWS]->(ian:Person {name:'Ian'})
     -[:KNOWS]->(emil)

MATCH (a:Person {name:'Jim'})-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c) 
RETURN b, c

(a:Person {name:'Jim'})
(b)
(c)
(a)

-[:KNOWS]->

(a:Person … )

( … {name:'Jim'})

(a)-[:KNOWS]->(b)-[:KNOWS]->(c), (a)-[:KNOWS]->(c)