Действительно ли это - хорошая идея использовать MySQL и Neo4j вместе?
Я подам заявку с большим количеством подобных объектов (миллионы), и я хотел бы сохранить их в базе данных 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 работал бы в этом случае?
3 ответа
Несколько мыслей по этому поводу:
Я бы попробовал смоделировать ваш Модель предметной области Neo4j для включения атрибутов каждого узла в граф. Разделив ваши данные на два разных хранилища данных, вы можете ограничить некоторые операции, которые вы, возможно, захотите выполнить.
Думаю, все сводится к тому, что вы будете делать со своим графиком. Если, например,вы хотите найти все узлы, подключенные к конкретному узлу, атрибуты которого (например, имя, возраст и т.д.) являются определенными значениями, нужно ли вам сначала найти правильный идентификатор узла в базе данных MySQL, а затем перейти в Neo4j? Это кажется медленным и чрезмерно сложным, если вы можете делать все это в Neo4j. Возникает вопрос: понадобятся ли вам атрибуты узла при обходе графа?
Будут ли ваши данные изменяться или они статичны? Наличие двух отдельных хранилищ данных усложняет ситуацию.
Хотя создание статистики с использованием базы данных MySQL может быть проще, чем выполнение всего в Neo4j, код, необходимый для обхода графа, чтобы найти все узлы, удовлетворяющие определенным критериям, не является слишком сложным. Эта статистика должна определять ваше решение.
Я не могу комментировать производительность запроса MySQL для выбора идентификаторов узлов. Я предполагаю, что это сводится к тому, сколько узлов вам нужно будет выбрать, и вашей стратегии индексации. Я согласен с точки зрения производительности, когда дело доходит до обхода графика.
Это хорошая статья именно об этом: MySQL против Neo4j при обходе крупномасштабного графа , и в этом случае, когда они говорят «большой», они имеют в виду только миллион вершин / узлов и четыре миллиона края. Так что это даже не был особенно плотный граф.
Я в основном работаю с Binary Nerd, но хотел бы добавить вариант. Вы можете хранить живые данные в Neo4j, а затем извлекать данные, необходимые для статистики / отчетности, и помещать в MySQL. Для поиска я бы выбрал интеграцию Neo4j-Lucene , если она соответствует вашим потребностям.
Вы можете улучшить запрос, используя IN:
SELECT *
FROM items
WHERE item_id IN (45, 345435, 343, 78, 4522, 676, 443, 4255, 4345)
Также не совсем верно, что реляционные базы данных плохо хранят древовидные структуры. Конечно, в MySQL отсутствуют некоторые функции, которые упростили бы задачу, но большинство других баз данных ее хорошо поддерживают. Oracle имеет CONNECT BY . Большинство основных СУБД имеют ту или иную форму рекурсивных запросов, и MySQL является заметным исключением.Может быть, вы могли бы взглянуть на PostgreSQL и посмотреть, соответствует ли это вашим потребностям?