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

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.

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.

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.

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.

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

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

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