Comparação de bancos de dados relacionais e bancos de dados gráficos


90

Alguém pode me explicar as vantagens e desvantagens de um banco de dados de relacionamento como o MySQL em comparação com um banco de dados gráfico como o Neo4j?

No SQL, você tem várias tabelas com vários ids vinculando-as. Então você tem que entrar para conectar as mesas. Da perspectiva de um novato, por que você projetaria o banco de dados para exigir uma junção em vez de ter as conexões explícitas como arestas desde o início, como acontece com um banco de dados de gráfico. Conceitualmente, não faria sentido para um novato. Presumivelmente, há uma razão muito técnica, mas não conceitual, para isso.


Os métodos de acesso são diferentes. Em um Banco de Dados Relacional, você usa Álgebra Relacional , melhor aumentada com recursão, uma representação estranha, mas popular, que é (recursiva, com extras procedurais) SQL. Em um banco de dados de gráfico, você usa linguagens de passagem de gráfico como Gremlin . As implementações de banco de dados subjacentes até o layout em disco seriam escolhidas para fornecer o melhor desempenho para o respectivo método de acesso, e ajuste / variação arbitrária podem ser encontrados nas implementações.
David Tonhofer

Respostas:


115

Na verdade, há um raciocínio conceitual por trás de ambos os estilos. A Wikipedia sobre o modelo relacional e os bancos de dados de gráficos oferece boas visões gerais disso.

A principal diferença é que em um banco de dados gráfico, os relacionamentos são armazenados no nível de registro individual, enquanto em um banco de dados relacional, a estrutura é definida em um nível superior (as definições da tabela).

Isso tem ramificações importantes:

  • Um banco de dados relacional é muito mais rápido ao operar em um grande número de registros. Em um banco de dados de gráficos, cada registro deve ser examinado individualmente durante uma consulta para determinar a estrutura dos dados, enquanto isso é conhecido com antecedência em um banco de dados relacional.
  • Os bancos de dados relacionais usam menos espaço de armazenamento, porque eles não precisam armazenar todos esses relacionamentos.

Armazenar todos os relacionamentos no nível de registro individual só faz sentido se houver muita variação nos relacionamentos; caso contrário, você estará apenas duplicando as mesmas coisas continuamente. Isso significa que os bancos de dados gráficos são adequados para estruturas complexas e irregulares. Mas, no mundo real, a maioria dos bancos de dados exige estruturas regulares e relativamente simples. É por isso que os bancos de dados relacionais predominam.


16
Armazenar relacionamentos no nível de registro também faz sentido em outros casos, pois fornece adjacência livre de índice. Ou seja, as travessias de gráfico podem ser realizadas sem pesquisas de índice, levando a um desempenho muito melhor. E não é duplicação, pois você armazena os relacionamentos reais, que são diferentes.
nawroth

4
Você diz: "Em um banco de dados gráfico, cada registro deve ser examinado individualmente durante uma consulta para determinar a estrutura dos dados". Esta é uma propriedade universal dos bancos de dados gráficos ou mais ou menos verdadeira em geral? Que tal OrientDb que suporta esquema completo para vértices e arestas?
Lodewijk Bogaards de

@LodewijkBogaards alguns bancos de dados gráficos, como o Neo4j, permitem indexação básica. Se a consulta atingir os índices, acredito que não há necessidade de determinar a estrutura dos dados por trás do índice. Mas depende da consulta.
Vojtěch Vít

3
Discordo totalmente de ambos os pontos. O banco de dados de gráficos é sempre mais rápido quando há chaves estrangeiras. Porque não precisamos de operações de junção. Os bancos de dados relacionais precisam armazenar a chave estrangeira em muitas tabelas. Uma borda e uma chave estrangeira devem ocupar o mesmo espaço de armazenamento.
cegprakash

3
@cegprakash Você também tem uma documentação da qual possamos concluir o mesmo?
Victor

102

A principal diferença entre um gráfico e um banco de dados relacional é que os bancos de dados relacionais funcionam com conjuntos, enquanto os bancos de dados gráficos funcionam com caminhos.

Isso se manifesta de maneiras inesperadas e inúteis para um usuário RDBMS. Por exemplo, ao tentar emular operações de caminho (por exemplo, amigos de amigos) juntando-se recursivamente em um banco de dados relacional, a latência da consulta aumenta de maneira imprevisível e massiva, assim como o uso da memória, sem mencionar que tortura o SQL para expressar esses tipos de operações. Mais dados significam mais lentidão em um banco de dados baseado em conjunto, mesmo se você puder atrasar a dor por meio de uma indexação criteriosa.

Como Dan1111 sugeriu, a maioria dos bancos de dados de gráficos não sofre esse tipo de problema de junção porque eles expressam relacionamentos em um nível fundamental. Ou seja, os relacionamentos existem fisicamente no disco e são nomeados, direcionados e podem ser decorados com propriedades (isso é chamado de modelo de gráfico de propriedades, consulte: https://github.com/tinkerpop/blueprints/wiki/Property-Graph -Modelo ). Isso significa que, se você decidir, poderá observar os relacionamentos no disco e ver como eles "unem" entidades. Relacionamentos são, portanto, entidades de primeira classe em um banco de dados gráfico e semanticamente muito mais fortes do que aqueles relacionamentos implícitos reificados no tempo de execução em um armazenamento relacional.

Então por que você deveria se preocupar? Por dois motivos:

  1. Os bancos de dados gráficos são muito mais rápidos do que os bancos de dados relacionais para dados conectados - um ponto forte do modelo subjacente. Uma consequência disso é que a latência da consulta em um banco de dados de gráficos é proporcional a quanto do gráfico você escolhe explorar em uma consulta e não é proporcional à quantidade de dados armazenados, desativando assim a bomba de junção .
  2. Os bancos de dados de gráficos tornam a modelagem e a consulta muito mais agradáveis, o que significa um desenvolvimento mais rápido e menos momentos WTF. Por exemplo, expressar amigo de um amigo para uma rede social típica na linguagem de consulta Cypher do Neo4j é justo MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

3
"Relacionamentos são, portanto, entidades de primeira classe em um banco de dados gráfico". O mesmo é normalmente verdadeiro em um banco de dados relacional: as entidades são mapeadas para tuplas nas relações, assim como os relacionamentos muitos-muitos. É a distinção que você descreve para os relacionamentos um-muitos, que muitas vezes são fundidos em relacionamentos de entidade?
beldaz

52
Esta comparação parece um pouco tendenciosa. E quanto às desvantagens?
Kurren

9
Um pouco? Muito tendencioso na minha opinião honesta. Na melhor das hipóteses, parece um anúncio "Este é um bom produto! Compre este"!
ilgaar

37
Isso requer uma advertência enorme : esse cara é o "cientista-chefe" da Neo Technology, que faz o banco de dados de gráficos Neo4J.
Rob Grant

4
Que tal uma pesquisa arbitrária ... me dê todos os usuários que têm entre 35 e 55 anos e compraram no walmart nos últimos 90 dias.
Matthew Whited

20

Dan1111 já deu uma resposta marcada como correta. Alguns pontos adicionais devem ser observados de passagem.

Primeiro, em quase todas as implementações de bancos de dados gráficos, os registros são "fixados" porque há um número desconhecido de ponteiros apontando para o registro em sua localização atual. Isso significa que um registro não pode ser embaralhado para um novo local sem deixar um endereço de encaminhamento no local antigo ou quebrar um número desconhecido de ponteiros.

Teoricamente, pode-se embaralhar todos os registros de uma vez e descobrir uma maneira de localizar e reparar todos os ponteiros. Na prática, essa é uma operação que pode levar semanas em um grande banco de dados de gráficos, período durante o qual o banco de dados teria que estar fora do ar. Simplesmente não é viável.

Por outro lado, em um banco de dados relacional, os registros podem ser reorganizados em uma escala razoavelmente grande e a única coisa que precisa ser feita é reconstruir todos os índices que foram afetados. Esta é uma operação bastante grande, mas nem de longe tão grande quanto o equivalente para um banco de dados de gráficos.

O segundo ponto que vale a pena notar de passagem é que a rede mundial de computadores pode ser vista como um gigantesco banco de dados de gráficos. As páginas da web contêm hiperlinks e fazem referência a hiperlinks, entre outras coisas, a outras páginas da web. A referência é por meio de URLs, que funcionam como ponteiros.

Quando uma página da web é movida para um URL diferente sem deixar um endereço de encaminhamento no URL antigo, um número desconhecido de hiperlinks será quebrado. Esses links quebrados dão origem à temida mensagem "Erro 404: página não encontrada", que interrompe o prazer de tantos surfistas.


4
Só que a maioria dos bancos de dados gráficos tem regras de integridade que não permitem links quebrados.
Michael Hunger

1
Se o DBMS fixar o alvo, isso obviamente evitará a quebra do link devido à movimentação do destino do link. Não conheço nenhum banco de dados gráfico que não fixe registros que possam ser alvos de links.
Walter Mitty

Os bancos de dados gráficos geralmente não têm esquema porque uma alteração do esquema seria uma operação muito pesada devido à necessidade de reescrever todos os ponteiros? O problema de remodelagem não pode ser contornado simplesmente armazenando ponteiros virtuais, que passam por uma tabela de pesquisa? Isso ainda funcionaria em O (1) certo?
Lodewijk Bogaards de

Tenho operado com uma definição de bancos de dados gráficos que incluem bancos de dados pré-relacionais, como os hierárquicos ou de rede. Alguns desses bancos de dados tinham esquemas, embora não esquemas relacionais. Não tenho certeza se minha definição operacional concorda ou não com a definição padrão.
Walter Mitty de

Uma estrutura de dados que fornece um mapeamento entre ponteiros virtuais e ponteiros físicos é essencialmente a mesma coisa que um índice, com aproximadamente os mesmos custos. Você também pode ir em frente e usar um banco de dados relacional.
Walter Mitty

7

Com um banco de dados relacional, podemos modelar e consultar um gráfico usando chaves estrangeiras e autojunções. Só porque RDBMS contém a palavra relacional, não significa que eles sejam bons em lidar com relacionamentos. A palavra relacional em RDBMS deriva da álgebra relacional e não de relacionamento. Em um RDBMS, o relacionamento em si não existe como um objeto por si só. Ele precisa ser representado explicitamente como uma chave estrangeira ou implicitamente como um valor em uma tabela de links (ao usar uma abordagem de modelagem genérica / universal). Links entre conjuntos de dados são armazenados nos próprios dados.

Quanto mais aumentamos a profundidade da pesquisa em um banco de dados relacional, mais self-joins precisamos realizar e mais o desempenho de nossas consultas sofre. Quanto mais nos aprofundamos em nossa hierarquia, mais tabelas precisamos juntar e mais lenta nossa consulta fica. Matematicamente, o custo cresce exponencialmente em um banco de dados relacional. Em outras palavras, quanto mais complexas nossas consultas e relacionamentos se tornam, mais nos beneficiamos de um gráfico em comparação com um banco de dados relacional. Não temos problemas de desempenho em um banco de dados de gráficos ao navegar no gráfico. Isso ocorre porque um banco de dados gráfico armazena os relacionamentos como objetos separados. No entanto, o desempenho de leitura superior tem o custo de gravações mais lentas.

Em certas situações, é mais fácil alterar o modelo de dados em um banco de dados gráfico do que em um RDBMS, por exemplo, em um RDBMS, se eu alterar um relacionamento de tabela de 1: n para m: n, preciso aplicar DDL com possível tempo de inatividade.

Por outro lado, o RDBMS tem vantagens em outras áreas, por exemplo, agregando dados ou fazendo controle de versão com carimbo de data / hora nos dados.

Discuto alguns dos outros prós e contras em minha postagem do blog sobre bancos de dados de gráficos para armazenamento de dados


4

Embora o modelo relacional possa representar facilmente os dados contidos em um modelo de gráfico, enfrentamos dois problemas significativos na prática:

  1. SQL carece de sintaxe para realizar facilmente a travessia do gráfico, especialmente travessias onde a profundidade é desconhecida ou ilimitada. Por exemplo, usar SQL para determinar os amigos de seus amigos é fácil, mas é difícil resolver o problema dos “graus de separação”.
  2. O desempenho diminui rapidamente à medida que percorremos o gráfico. Cada nível de travessia aumenta significativamente o tempo de resposta da consulta.

Referência: Bancos de dados de última geração


0

Vale a pena investigar os bancos de dados gráficos para os casos de uso nos quais eles se destacam, mas tive alguns motivos para questionar algumas afirmações nas respostas acima. Em particular:

Um banco de dados relacional é muito mais rápido quando opera em um grande número de registros (primeiro ponto de bala de dan1111)

Os bancos de dados gráficos são muito mais rápidos do que os bancos de dados relacionais para dados conectados - um ponto forte do modelo subjacente. Uma consequência disso é que a latência da consulta em um banco de dados de gráficos é proporcional a quanto do gráfico você escolhe explorar em uma consulta e não é proporcional à quantidade de dados armazenados, desativando assim a bomba de junção. (Primeiro ponto de Jim Webber)

Em outras palavras, quanto mais complexas nossas consultas e relacionamentos se tornam, mais nos beneficiamos de um gráfico em comparação com um banco de dados relacional. (Segundo parágrafo de Uli Bethke)

Embora essas afirmações possam ter mérito, ainda tenho que encontrar uma maneira de fazer com que meu caso de uso específico se alinhe a elas. Referência: banco de dados gráfico ou banco de dados relacional Extensões de tabela comuns: comparando o desempenho de consulta de gráfico acíclico

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.