Графови бази

Накратко: Графовата база, като Neo4j, пази възли и връзки вместо таблици, а заявките на Cypher търсят шаблони и пътища през тях.

Проблем

Купилите кафе купиха още

Под всеки продукт магазинът иска ред „Купилите това купиха още“. За кафето на зърна заявката към SQL базата е тази:

SQLбаза: магазин

SELECT p2.name, COUNT(DISTINCT o2.customer_id) AS buyers
FROM products p1
JOIN order_items i1 ON i1.product_id = p1.id
JOIN orders o1 ON o1.id = i1.order_id AND o1.status <> 'cancelled'
JOIN orders o2 ON o2.customer_id = o1.customer_id AND o2.status <> 'cancelled'
JOIN order_items i2 ON i2.order_id = o2.id
JOIN products p2 ON p2.id = i2.product_id
WHERE p1.name = 'Кафе на зърна' AND p2.id <> p1.id
GROUP BY p2.id, p2.name
ORDER BY buyers DESC, p2.name
LIMIT 5;

SELECT p2.name, COUNT(DISTINCT o2.customer_id) AS buyers FROM products p1 JOIN order_items i1 ON i1.product_id = p1.id JOIN orders o1 ON o1.id = i1.order_id AND o1.status <> 'cancelled' JOIN orders o2 ON o2.customer_id = o1.customer_id AND o2.status <> 'cancelled' JOIN order_items i2 ON i2.order_id = o2.id JOIN products p2 ON p2.id = i2.product_id WHERE p1.name = 'Кафе на зърна' AND p2.id <> p1.id GROUP BY p2.id, p2.name ORDER BY buyers DESC, p2.name LIMIT 5;

▶ ИзпълниВърни заявкатаНова база

Тя минава по шест таблици: от продукта до редовете на поръчките, до поръчките, до клиента, до другите му поръчки, до техните редове и до продуктите. orders и order_items участват по два пъти. Следващото желание е още по-тежко: „продуктите на хората, чиито препоръки следваш, и на хората, които те следват“. Всяка стъпка е още съединения, а „до три стъпки“ иска WITH RECURSIVE. Въпросът е за връзките между нещата, а в таблиците връзките са разпилени във външни ключове.

Идеята

Възли и връзки

Графовата база пази данните като граф: възли (нещата, например клиент и продукт) и връзки между тях. Всяка връзка има тип (BOUGHT) и посока (от клиента към продукта). Възлите имат етикети (:Customer), а възлите и връзките имат свойства (name, price, quantity). Връзката е записана в базата, а не се търси с JOIN при всяка заявка: от възела базата стига направо до съседите му.

Най-известната графова база е Neo4j, а езикът ѝ е Cypher. Шаблоните в него са рисунка с букви: (c:Customer) е възел, а -[:BOUGHT]-> е стрелка.

графова (като Neo4j)симулатор

CREATE (m:Customer {name: 'Мария Иванова', city: 'София'})
CREATE (k:Product {name: 'Кафе на зърна', price: 14.90})
CREATE (m)-[:BOUGHT {quantity: 2}]->(k);

MATCH (c:Customer)-[b:BOUGHT]->(p:Product)
RETURN c.name, b.quantity, p.name;

CREATE (m:Customer {name: 'Мария Иванова', city: 'София'}) CREATE (k:Product {name: 'Кафе на зърна', price: 14.90}) CREATE (m)-[:BOUGHT {quantity: 2}]->(k); MATCH (c:Customer)-[b:BOUGHT]->(p:Product) RETURN c.name, b.quantity, p.name;

▶ ИзпълниВърни командитеНова база

Заявката завършва с ;, затова може да е на няколко реда. CREATE прави възли и връзки. MATCH намира всичко, което пасва на шаблона, а RETURN казва какво да се покаже. Под изхода симулаторът рисува намерените възли и връзки.

По-точно, за любопитните

Симулаторът знае част от Cypher: MATCH, WHERE, CREATE, MERGE, SET, DELETE, DETACH DELETE, RETURN, ORDER BY, SKIP, LIMIT и няколко функции. Няма WITH, OPTIONAL MATCH, UNWIND, индекси и ограничения. Изходът е като в конзолата cypher-shell, но без реда с времето на заявката, а съобщенията за грешки са по-кратки. Симулаторът показва подканата пред всеки ред на заявката. Neo4j Browser не иска ; в края и рисува резултата сам. Без ORDER BY симулаторът връща редовете в реда, в който са направени възлите, а Neo4j не обещава никакъв ред.

Пробвай

Георги и хлябът

Базата е празна. Запиши, че клиентът Георги Петров е купил бял хляб: възел с етикет Customer и свойство name, възел с етикет Product и свойство name и връзка BOUGHT от клиента към продукта.

графова (като Neo4j)симулатор

CREATE (g:Customer {name: 'Георги Петров'});

CREATE (g:Customer {name: 'Георги Петров'});

Провери▶ Изпълни

Идеята

Шаблоните

От тук нататък базата е магазинът: 20 клиенти, 25 продукта в 6 категории и 109 връзки BOUGHT, по една за всеки клиент и продукт от поръчките, които не са отменени. Те са взети от SQL базата на курса. Продуктът е свързан с категорията си с връзка IN.

Шаблонът може да е дълъг колкото трябва: от клиента през продукта до категорията, без нито едно съединение.

графова (като Neo4j)симулатор

MATCH (c:Customer {name: 'Елена Димитрова'})-[:BOUGHT]->(p:Product)-[:IN]->(cat:Category)
RETURN p.name, p.price, cat.name
ORDER BY p.name;

MATCH (c:Customer {name: 'Елена Димитрова'})-[:BOUGHT]->(p:Product)-[:IN]->(cat:Category) RETURN p.name, p.price, cat.name ORDER BY p.name;

▶ ИзпълниВърни командитеНова база

Посоката в шаблона трябва да съвпада с посоката на връзката:

графова (като Neo4j)симулатор

// Стрелката сочи от клиента към продукта. Обратно няма нищо:
MATCH (:Product {name: 'Кафе на зърна'})-[:BOUGHT]->(c:Customer)
RETURN c.name;

// Същата връзка, прочетена от другия край:
MATCH (:Product {name: 'Кафе на зърна'})<-[:BOUGHT]-(c:Customer)
RETURN c.name, c.city
ORDER BY c.name;

// Стрелката сочи от клиента към продукта. Обратно няма нищо: MATCH (:Product {name: 'Кафе на зърна'})-[:BOUGHT]->(c:Customer) RETURN c.name; // Същата връзка, прочетена от другия край: MATCH (:Product {name: 'Кафе на зърна'})<-[:BOUGHT]-(c:Customer) RETURN c.name, c.city ORDER BY c.name;

▶ ИзпълниВърни командитеНова база

От продукта към клиента няма стрелки BOUGHT, затова първата заявка не намира никого. <-[:BOUGHT]- чете същата връзка от другия ѝ край. -[:BOUGHT]- без стрелка намира връзката в която и да е посока.

По-точно, за любопитните

Графът не пази отделните поръчки: връзката BOUGHT казва само, че клиентът е купувал продукта. Ако трябват и поръчките, те стават възли: (:Customer)-[:PLACED]->(:Order)-[:CONTAINS {quantity: 2}]->(:Product). Кое е възел и кое е връзка се решава по въпросите, които ще задаваш, както при схемата на SQL базата.

Виж го

Същият въпрос, един шаблон

Ето „купилите кафе купиха още“ на Cypher:

графова (като Neo4j)симулатор

MATCH (:Product {name: 'Кафе на зърна'})<-[:BOUGHT]-(c:Customer)-[:BOUGHT]->(p:Product)
RETURN p.name, count(c) AS buyers
ORDER BY buyers DESC, p.name
LIMIT 5;

MATCH (:Product {name: 'Кафе на зърна'})<-[:BOUGHT]-(c:Customer)-[:BOUGHT]->(p:Product) RETURN p.name, count(c) AS buyers ORDER BY buyers DESC, p.name LIMIT 5;

▶ ИзпълниВърни командитеНова база

Отговорът е същият като на SQL заявката от началото, ред по ред. Шаблонът се чете отляво надясно: кафето, купено от клиент, който е купил и друг продукт. Кафето не се брои към себе си: в един MATCH една и съща връзка не участва два пъти, а връзката към кафето вече е заета. В SQL това беше отделно условие (p2.id <> p1.id). Кафе са купили само трима души, затова петте продукта са с по двама купувачи и се подреждат по име.

Разликата не е само в дължината. SQL базата търси всяко съединение в индекс или в цялата таблица. Графовата тръгва от кафето и минава само по неговите връзки: работата зависи от това колко връзки има около кафето, а не колко поръчки има магазинът.

Идеята

Пътища с променлива дължина

Да кажем, че магазинът има профили и всеки клиент може да следва препоръките на други клиенти: (:Customer)-[:FOLLOWS]->(:Customer). Тези връзки са измислени за урока, в SQL базата ги няма.

-[:FOLLOWS*1..2]-> е път от една до две стъпки по FOLLOWS. p = … дава име на целия път, а length(p) е броят на стъпките му:

графова (като Neo4j)симулатор

// Всички маршрути от една или две стъпки. Виктория е два пъти: до нея се стига по два пътя
MATCH (me:Customer {name: 'Елена Димитрова'})-[:FOLLOWS*1..2]->(f:Customer)
RETURN f.name;

// Всеки човек веднъж, с най-късия път до него
MATCH p = (me:Customer {name: 'Елена Димитрова'})-[:FOLLOWS*1..3]->(f:Customer)
WHERE f <> me
RETURN f.name, min(length(p)) AS steps
ORDER BY steps, f.name;

// Всички маршрути от една или две стъпки. Виктория е два пъти: до нея се стига по два пътя MATCH (me:Customer {name: 'Елена Димитрова'})-[:FOLLOWS*1..2]->(f:Customer) RETURN f.name; // Всеки човек веднъж, с най-късия път до него MATCH p = (me:Customer {name: 'Елена Димитрова'})-[:FOLLOWS*1..3]->(f:Customer) WHERE f <> me RETURN f.name, min(length(p)) AS steps ORDER BY steps, f.name;

▶ ИзпълниВърни командитеНова база

В първия резултат Виктория е два пъти: Елена следва Мария и Димитър, а двамата следват Виктория. MATCH връща всеки път, не всеки човек. Във втората заявка WHERE f <> me маха самата Елена: по три стъпки пътят се връща при нея (Елена, Мария, Виктория, Елена).

Кои са хората по пътя, се вижда с nodes(p):

графова (като Neo4j)симулатор

MATCH p = (:Customer {name: 'Елена Димитрова'})-[:FOLLOWS*2]->(:Customer {name: 'Александър Илиев'})
RETURN [n IN nodes(p) | n.name] AS route;

MATCH p = (:Customer {name: 'Елена Димитрова'})-[:FOLLOWS*2]->(:Customer {name: 'Александър Илиев'}) RETURN [n IN nodes(p) | n.name] AS route;

▶ ИзпълниВърни командитеНова база

В SQL същото е WITH RECURSIVE върху таблица follows: начало, UNION ALL и стъпка, която съединява follows с предните редове, плюс брояч на стъпките. Тук е *1..3.

Виж го

Път без граница

Шаблон без тип и без посока, „всичко, свързано с Елена“, с все по-дълъг път:

графова (като Neo4j)симулатор

// Всичко, свързано с Елена, по каквато и да е връзка, в каквато и да е посока
MATCH (:Customer {name: 'Елена Димитрова'})-[*1..2]-(x)
RETURN count(*) AS routes;
MATCH (:Customer {name: 'Елена Димитрова'})-[*1..3]-(x)
RETURN count(*) AS routes;
MATCH (:Customer {name: 'Елена Димитрова'})-[*1..4]-(x)
RETURN count(*) AS routes;

// Без горна граница
MATCH (:Customer {name: 'Елена Димитрова'})-[*]-(x)
RETURN count(*) AS routes;

// Всичко, свързано с Елена, по каквато и да е връзка, в каквато и да е посока MATCH (:Customer {name: 'Елена Димитрова'})-[*1..2]-(x) RETURN count(*) AS routes; MATCH (:Customer {name: 'Елена Димитрова'})-[*1..3]-(x) RETURN count(*) AS routes; MATCH (:Customer {name: 'Елена Димитрова'})-[*1..4]-(x) RETURN count(*) AS routes; // Без горна граница MATCH (:Customer {name: 'Елена Димитрова'})-[*]-(x) RETURN count(*) AS routes;

▶ ИзпълниВърни командитеНова база

98 маршрута, после 688, после 4 370. Всяка стъпка ги умножава между шест и седем пъти, защото продукт като бял хляб е свързан с много клиенти, а всеки от тях с много продукти. * без горна граница пробва всички маршрути. Симулаторът спира след 100 000 стъпки, а Neo4j не спира сама: заявката върви, докато свърши времето или паметта. Затова пиши горна граница винаги, а когато можеш, и типа и посоката на връзката.

Упражнение

Препоръки

1. Под сиренето също трябва ред „Купилите това купиха още“.

Кои три продукта са купували най-много от хората, купили сирене? Покажи името и броя купувачи (buyers), от най-много надолу, а при равен брой по име.

графова (като Neo4j)симулатор

MATCH (:Product {name: 'Сирене'})<-[:BOUGHT]-(c:Customer)
RETURN c.name;

MATCH (:Product {name: 'Сирене'})<-[:BOUGHT]-(c:Customer) RETURN c.name;

Провери▶ Изпълни

2. Мария Иванова следва няколко души, а те следват други.

Покажи клиентите, до които Мария Иванова стига по FOLLOWS в една или две стъпки, всеки по веднъж, подредени по име.

графова (като Neo4j)симулатор

MATCH (:Customer {name: 'Мария Иванова'})-[:FOLLOWS]->(f:Customer)
RETURN f.name;

MATCH (:Customer {name: 'Мария Иванова'})-[:FOLLOWS]->(f:Customer) RETURN f.name;

Провери▶ Изпълни

3. Сега истинската препоръка.

Намери продуктите, които са купили хората, следвани от Елена Димитрова в една или две стъпки, но тя още не ги е купила. Покажи трите, купени от най-много различни хора (people), а при равен брой по име.

графова (като Neo4j)симулатор

MATCH (me:Customer {name: 'Елена Димитрова'})-[:FOLLOWS*1..2]->(f:Customer)
RETURN DISTINCT f.name;

MATCH (me:Customer {name: 'Елена Димитрова'})-[:FOLLOWS*1..2]->(f:Customer) RETURN DISTINCT f.name;

Провери▶ Изпълни

Идеята

Кога графова база, кога не

Графовата база е добра, когато въпросът е за връзки, често на няколко стъпки: препоръки („купилите това купиха още“), социални мрежи, откриване на измами (сметки, които делят телефон или адрес), маршрути и зависимости, права за достъп през групи. Тя не е добра за отчети, които събират числа от всички записи, например оборот по месеци: такава заявка не обхожда връзки, а чете всичко подред. Това е работа за SQL с GROUP BY или за база за отчети (OLAP). Затова графът обикновено стои до SQL базата: поръчките и парите са в SQL, а копие на връзките отива в графа за препоръките.

По-точно, за любопитните

Освен Neo4j, Cypher разбират Memgraph и Amazon Neptune (там езикът се казва openCypher; Neptune разбира и Gremlin и SPARQL), а разширението Apache AGE добавя Cypher в PostgreSQL. През 2024 г. излезе международният стандарт GQL (ISO/IEC 39075), до голяма степен по идеите на Cypher. Друг вид графова база са RDF хранилищата с езика SPARQL, в които всичко е тройка „субект, предикат, обект“.

Тест

Провери се

1. Какво казва шаблонът (c:Customer)-[:BOUGHT]->(p:Product)?

Възел с етикет Customer, свързан с възел с етикет Product чрез връзка от тип BOUGHT, насочена към продуктаТаблицата Customer е съединена с таблицата ProductКлиентите и продуктите с едно и също име

2. MATCH (me)-[:FOLLOWS*1..2]->(f) RETURN f.name връща Виктория два пъти. Защо?

Базата е с грешкаДо нея се стига по два различни пътя, а MATCH връща всеки пътВиктория е записана два пъти

3. Какво става с шаблон -[*]- без горна граница в голям граф?

Нищо особено, само е малко по-бавноМаршрутите растат лавинообразно и заявката може да не свършиБазата сама спира на 3 стъпки

4. Трябва ти оборотът по месеци за последните две години. Къде е мястото на тази заявка?

В графовата база, защото поръчките са свързани с клиентитеВ кешаВ SQL базата (или в колонна база за отчети), с SUM и GROUP BY

Провери

Започни урока отначало

Свързани уроци

• Нужно отпреди: Дървета и редици: WITH RECURSIVE · Видове връзки: 1:1, 1:N, M:N · Индекси · OLTP и OLAP
• Продължава в: Как се избира база
• Задачи по темата: Видове бази данни