Это хорошая идея, чтобы использовать MySQL и Neo4j вместе?

Question

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

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

Мой план состоит в том, чтобы все данные, кроме отношений в базе данных MySQL и всех отношений с item_id, сохранялись в базе данных Neo4j. Когда я хочу найти дерево, я сначала ищу в Neo4j все item_id: s в дереве, затем я ищу в базе данных MySQL все указанные элементы в запросе, который будет выглядеть следующим образом:

SELECT * FROM items WHERE item_id = 45 OR item_id = 345435 OR item_id = 343 OR item_id = 78 OR item_id = 4522 OR item_id = 676 OR item_id = 443 OR item_id = 4255 OR item_id = 4345

Это хорошая идея, или я совершенно не прав? Я раньше не пользовался графовыми базами данных. Есть ли лучшие подходы к моей проблеме? Как будет работать MySQL-запрос в этом случае?

Answer 1

Несколько мыслей по этому поводу:

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

Полагаю, все сводится к тому, что вы будете делать со своим графиком. Например, если вы хотите найти все узлы, подключенные к определенному узлу, чьи атрибуты (то есть имя, возраст и т. Д.) Являются определенными значениями, вам сначала нужно найти правильный идентификатор узла в базе данных MySQL, а затем перейти Neo4j? Это кажется медленным и слишком сложным, когда вы можете делать все это в Neo4j. Вопрос в том, понадобятся ли вам атрибуты узла при обходе графа?

Изменится ли ваша информация или она статическая? Наличие двух отдельных хранилищ данных усложнит ситуацию.

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

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

Это хорошая статья на эту тему: MySQL против Neo4j на крупномасштабном обходе графа и в этом случае, когда они говорят, что большие, они означают только миллион вершин / узлов и четыре миллиона кромки. Так что это был даже не очень плотный график.

Answer 2

Реляционные базы данных могут обрабатывать графовые структуры. Некоторые из них могут даже элегантно обрабатывать их (так же элегантно, как и реляционная база данных!).

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

RCTE поддерживаются в PostgreSQL, Firebird, SQL Server и, очевидно, в DB2. Oracle имеет другую, но эквивалентную конструкцию; Я читал, что последние версии поддерживают правильные RCTE. MySQL не поддерживает RCTE. Если вы не знакомы с MySQL, я бы настоятельно рекомендовал вам использовать PostgreSQL, который по сути является гораздо лучшей базой данных.

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

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

Более простым является сохранение пути с каждой строкой: это строка, которая представляет позицию строки в дереве, и обладает свойством того, что путь для узла является префиксом пути для любого подузла, что позволяет Вы очень эффективно выполняете различные запросы о происхождении («является ли узел A дочерним по отношению к узлу B?», «что такое узел A и самый низкий общий предок узла B?» и т. д.). Например, вы можете построить путь для строки, пройдя дерево от корня и соединив идентификаторы строк, встречающихся на пути, с косой чертой. Это просто построить, но позаботиться о сохранении, если вы переставите дерево. С помощью столбца пути вы можете ограничить запрос заданным деревом, просто добавив and path like '23/%', где 23 - идентификатор корня.

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

Answer 3

Я в основном с Binary Nerd, но хотел бы добавить вариант. Вы можете сохранить оперативные данные в Neo4j, а затем извлечь данные, необходимые для статистики / отчетности, и поместить их в MySQL. Для поиска я бы пошел с интеграцией Neo4j-Lucene , если это соответствует вашим потребностям.

Answer 4

Вы можете улучшить запрос, используя IN:

SELECT *
FROM items
WHERE item_id IN (45, 345435, 343, 78, 4522, 676, 443, 4255, 4345)

Также не совсем верно, что реляционные базы данных плохо хранят древовидные структуры. Конечно, в MySQL отсутствует некоторая функциональность, которая упростила бы его, но большинство других баз данных хорошо его поддерживают. Oracle имеет CONNECT BY. Большинство основных СУБД имеют некоторую форму рекурсивных запросов - MySQL является заметным исключением. Возможно, вы могли бы взглянуть на PostgreSQL и посмотреть, соответствует ли это вашим потребностям?