É uma boa ideia usar MySQL e Neo4j juntos?

Question

Farei uma aplicação com muitos itens semelhantes (milhões) e gostaria de armazená-los em um banco de dados MySQL, pois gostaria de fazer muitas estatísticas e pesquisar valores específicos para colunas específicas.

Mas, ao mesmo tempo, armazenarei relações entre todos os itens, que estão relacionados em muitas estruturas semelhantes a árvores binárias conectadas (fechamento transitivo), e bancos de dados relacionais não são bons para esse tipo de estrutura, então eu gostaria de armazenar todas as relações no Neo4j que apresentam bom desempenho para este tipo de dados.

Meu plano é ter todos os dados, exceto as relações no banco de dados MySQL e todas as relações com item_id armazenado no banco de dados Neo4j.Quando quero pesquisar uma árvore, primeiro procuro no Neo4j todos os item_id:s na árvore, então procuro no banco de dados MySQL todos os itens especificados em uma consulta que seria semelhante a:

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

É uma boa ideia ou estou muito errado? Eu nunca usei bancos de dados gráficos antes.Existem abordagens melhores para o meu problema?Como seria o desempenho da consulta MySQL neste caso?

Answer 1

Algumas reflexões sobre isso:

Eu tentaria modelar seu modelo de domínio Neo4j para incluir os atributos de cada nó no gráfico.Ao separar seus dados em dois armazenamentos de dados diferentes, você pode limitar algumas operações que talvez queira realizar.

Acho que tudo se resume ao que você fará com seu gráfico.Se, por exemplo, você deseja encontrar todos os nós conectados a um nó específico cujos atributos (ou seja, nome, idade..seja qual for) são determinados valores, você primeiro teria que encontrar o ID do nó correto em seu banco de dados MySQL e depois entrar no Neo4j?Isso parece lento e complicado demais quando você pode fazer tudo isso no Neo4j.Então a questão é:você precisará dos atributos de um nó ao percorrer o gráfico?

Seus dados mudarão ou serão estáticos?Ter dois armazenamentos de dados separados complicará as coisas.

Embora gerar estatísticas usando um banco de dados MySQL possa ser mais fácil do que fazer tudo no Neo4j, o código necessário para percorrer um gráfico para encontrar todos os nós que atendem a um critério definido não é muito difícil.Quais são essas estatísticas devem orientar sua solução.

Não posso comentar sobre o desempenho da consulta MySQL para selecionar IDs de nós.Acho que isso se resume a quantos nós você precisará selecionar e à sua estratégia de indexação.Eu concordo com o lado do desempenho quando se trata de percorrer um gráfico.

Este é um bom artigo exatamente sobre isso: MySQL vs.Neo4j em uma travessia gráfica em grande escala e neste caso, quando dizem grande, significam apenas um milhão de vértices/nós e quatro milhões de arestas.Portanto, nem era um gráfico particularmente denso.

Answer 2

Os bancos de dados relacionais podem lidar com estruturas de gráficos. Alguns deles podem até lidar com eles de maneira elegante (tão elegantemente quanto um banco de dados relacional!).

A chave para o manuseio geral de gráficos em bancos de dados relacionais é o expressão de mesa comum recursiva (RCTE), que basicamente permite que você (não recursivamente, apesar do nome) expanda uma consulta sobre um conjunto de linhas, combinando uma consulta que seleciona um conjunto de linhas raiz e uma consulta que define os vizinhos de linhas selecionadas até agora. A sintaxe é um pouco desajeitada, mas é geral e poderosa.

Os RCTEs são suportados no PostgreSQL, Firebird, SQL Server e aparentemente no DB2. O Oracle tem uma construção diferente, mas equivalente; Eu li que as versões recentes suportam RCtes adequados. O MySQL não suporta RCTES. Se você não estiver casado com o MySQL, recomendamos que você considere usar o PostgreSQL, o que é basicamente um banco de dados muito melhor em toda a volta.

No entanto, parece que você não precisa suportar gráficos gerais, apenas árvores. Nesse caso, existem opções mais específicas abertas para você.

Um é o clássico, mas sim, alerta conjuntos aninhados.

Um mais simples é armazenar um caminho a cada linha: esta é uma string que representa a posição da linha na árvore e tem a propriedade de que o caminho para um nó é um prefixo do caminho para qualquer subnodo, o que permite que você Várias consultas sobre ancestralidade ("O nó é um filho de nó B?", "Qual é o ancestral comum mais baixo do nó A e o nó B?", etc.). Por exemplo, você pode construir um caminho para uma fileira andando pela árvore da raiz e juntando -se aos IDs das linhas encontradas no caminho com barras. Isso é simples de construir, mas tome cuidado para manter se você reorganizar a árvore. Com uma coluna de caminho, você pode restringir uma consulta a uma determinada árvore simplesmente adicionando and path like '23/%', Onde 23 é o ID da raiz.

Portanto, embora um banco de dados de gráficos seja provavelmente a melhor maneira de armazenar e consultar dados gráficos, ele não é a única opção e eu sugiro que você pese as vantagens de usar uma contra as vantagens de ter todos os seus dados em um único banco de dados.

Answer 3

Estou principalmente com o nerd binário, mas gostaria de adicionar uma variação. Você pode armazenar os dados ao vivo no Neo4J e extrair os dados necessários para estatísticas/relatórios e colocar no MySQL. Para pesquisas, eu iria com o Integração Neo4J-Lucene Se isso atender às suas necessidades.

Answer 4

Você pode melhorar a consulta usando IN:

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

Também não é inteiramente verdade que os bancos de dados relacionais sejam ruins no armazenamento de estruturas em árvore.Certamente faltam algumas funcionalidades no MySQL que o tornariam mais fácil, mas a maioria dos outros bancos de dados o suportam bem.Oráculo tem CONNECT BY.A maioria dos RDBMS convencionais tem alguma forma de consultas recursivas - o MySQL é uma exceção notável.Talvez você possa dar uma olhada no PostgreSQL e ver se ele atende às suas necessidades?