Простой сценарий из реальной жизни, который Neo4j может обрабатывать быстрее, чем MySQL - PullRequest
0 голосов
/ 07 декабря 2018

Я поговорю о Neo4j и хочу показать 1 сценарий, который Neo4j может обрабатывать быстрее, чем MySQL.

Я создал случайные данные и SQL-таблицы для «социальной сети», такой как Twitter:1 000 000 человек, и каждый из них следует за 50 другими людьми.Таким образом, есть две таблицы "персона" и "следующие":

Есть ли Cypher-запрос, который намного быстрее, чем запрос MySQL, который должен делать то же самое?

Я пробовал что-то вроде«друг друга жареного» сценария, но MySQL решает их быстро ...

1 Ответ

0 голосов
/ 07 декабря 2018

Один из сценариев, который сложнее для rdbms, - это когда типы узлов (таблиц) для прохождения неизвестны.Возьмите график, который имеет: Person узлы различных соединений через разные типы узлов (: Workplace,: Organization,: School и т. Д.), И вам нужен запрос, который может выполнять запрос достижимости на расстоянии между двумя известными узлами (являются ли эти узлысвязаны с помощью любых средств, или с помощью каких-либо средств, с использованием некоторого поднабора меток и типов отношений?), или выполнения 7-градусного запроса Кевина Бэкона или чего-то подобного.

Когда вы пишете такие запросы, у вас есть минимальноеИнформация об узлах, через которые нужно пройти, вы хотите знать, если и как они связаны, вы заранее не знаете точный способ этого соединения.Как вы пишете это в SQL?Обычно вам нужно заранее знать, какие таблицы объединения нужно использовать, и промежуточные таблицы (особенно, если вам нужно выполнить фильтрацию свойств на некоторых промежуточных узлах).

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

Например, если у вас есть: Поместите узлы, которые имеют отношения: IN_LOCATION, где эти отношения могут указывать либо на: Адрес,: Город,: Штат или: Страна, в зависимости от того, какое место и насколько точны ваши данные, а также сами эти узлы: В отношениях между ними вы можете попытаться получить информацию о состоянии следующим образом:

MATCH (p:Place {name:'Yosemite National Park'})-[:IN_LOCATION]->()-[:WITHIN*0..]->(state:State)
RETURN state

В этом запросе вы не знаете метку (тип) левого пустого узла, на который указывает отношение: IN_LOCATION.Однако вы знаете, что если он находится на уровне: State или ниже, вы хотите продолжать проходить отношения: WITHIN до тех пор, пока не достигнете узла: State (возможно, вообще не пройдя ни одного, если этот начальный узел является: State узлом), не заботясь отипы промежуточных узлов.

Это то, что может делать SQL?

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

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

MATCH (k:Person{name:'Keanu Reeves'})-[:ACTED_IN|DIRECTED*..5]-(m:Movie)
RETURN collect(DISTINCT m) as movies
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...