Comparação das bases de Dados Relacionais e das bases de dados Gráficas

A principal diferença entre um grafo e uma base de dados relacional é que as bases de dados relacionais funcionam com conjuntos enquanto as bases de dados de grafos funcionam com caminhos.

Isto manifesta-se de formas inesperadas e inúteis para um utilizador de 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 cresce imprevisivelmente e maciçamente como o uso da memória, já para não mencionar que tortura o SQL para expressar esses tipos de operacao. Mais dados significa mais lento em um banco de dados set-based, mesmo se você pode atrasar a dor através de indexação judiciosa. Como dan1111 insinuou, a maioria das bases de dados de grafos não sofrem este tipo de dor de junção porque expressam relacionamentos em um nível fundamental. Isto é, as relações existem fisicamente no disco e elas são nomeadas, direcionadas, e podem ser elas mesmas decoradas com propriedades (isto é chamado de modelo de gráfico de propriedade, veja: https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model isto significa que, se o fizer, poderá ver as relações no disco e ver como elas "se juntam" às entidades. As relações são, portanto, entidades de primeira classe em um banco de dados de grafos e são semanticamente muito mais fortes do que aquelas relações implícitas reificadas em tempo de execução em uma loja relacional. Então porque te importarias? Por duas razões:

1. as bases de dados dos grafos são muito mais rápidas do que as bases de dados relacionais para dados conectados - uma força do modelo subjacente. Uma conseqüência disso é que a latência da consulta em uma base de dados de gráficos é proporcional à quantidade de gráfico que você escolher para explorar em uma consulta, e não é proporcional à quantidade de dados armazenados, revertendo a juntar bomba.
As bases de dados dos gráficos tornam a modelização e a procura muito mais agradáveis, o que significa um desenvolvimento mais rápido e menos momentos WTF. Por exemplo, expressando amigo-de-amigo para uma rede social típica no Cypher de Neo4j a linguagem da consulta é apenas MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

O Dan1111 já deu uma resposta marcada como correcta. Alguns pontos adicionais são dignos de nota de passagem.

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

Teoricamente, pode-se baralhar todos os registos de uma vez e descobrir uma maneira de localizar e reparar todos os ponteiros. Na prática, esta é uma operação que pode levar semanas em um grande banco de dados de grafos, durante o qual o banco de dados teria que estar fora do ar. Não é viável. Em contraste, numa base de dados relacional, os registos podem ser remodelados em larga escala, e a única coisa que tem de ser feita é reconstruir quaisquer índices que tenham sido afectados. Isto é ... uma operação bastante grande, mas não tão grande como o equivalente para um banco de dados de grafos. O segundo ponto que vale a pena notar de passagem é que a world Wide web pode ser vista como uma gigantesca base de dados de grafos. As páginas web contêm hiperligações, e referências de hiperligações, entre outras coisas, outras páginas web. A referência é através de URLs, que funcionam como ponteiros.

Quando uma página web é movida para um URL diferente sem deixar um endereço de encaminhamento no URL antigo, um número desconhecido de as hiperligações vão quebrar-se. Estes links quebrados, em seguida, dão origem ao temido, "erro 404: page not found" mensagem que interrompe o prazer de tantos surfistas.

Com uma base de dados relacional podemos modelar e consultar um gráfico usando chaves estrangeiras e auto-juntas. Só porque as RDBMS contêm a palavra relacional não significa que elas sejam boas em lidar com relacionamentos. A palavra relacional em RDBMS deriva da álgebra relacional e não da relação. Em um RDBMS, a própria relação não existe como um objeto em seu próprio direito. Ou precisa de ser representada explicitamente como uma chave estrangeira ou implicitamente como um valor numa tabela de ligações (quando utilização de uma abordagem genérica/universal de modelização). As ligações entre conjuntos de dados são armazenadas nos próprios dados. Quanto mais aumentamos a profundidade de pesquisa em um banco de dados relacional, mais auto-junta precisamos realizar e mais nosso desempenho de consulta sofre. Quanto mais fundo formos em nossa hierarquia, mais tabelas precisamos entrar e mais lenta nossa consulta fica. Matematicamente, o custo cresce exponencialmente numa base de dados relacional. Por outras palavras, quanto mais complexas são as nossas consultas e relações mais nos beneficiamos de um gráfico versus uma base de dados relacional. Não temos problemas de desempenho em um banco de dados de grafos ao navegar no grafo. Isto é porque um banco de dados de grafos armazena as relações como objetos separados. No entanto, o desempenho de leitura superior vem ao custo de escritas mais lentas.

Em certas situações é mais fácil alterar o modelo de dados numa base de dados de grafos do que num RDBMS, por exemplo, num RDBMS se alterar uma relação de tabela de 1: n Para m: n É necessário aplicar o DDL com potencial tempo de inatividade.

As RDBMS têm, por outro lado, vantagens noutras áreas, por exemplo, a agregação de dados ou a realização de controlos de versões com intervalos de tempo nos dados.

Eu discuto alguns dos outros prós e contras no meu post no meu blog em graph databases for data warehousing

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

1. o SQL não tem a sintaxe para executar facilmente a travessia dos grafos, especialmente traversais onde a profundidade é desconhecida ou não limitada. Por exemplo, usar SQL para determinar amigos de seus amigos é fácil o suficiente, mas é difícil resolver o problema dos "graus de separação".
A Performance degrada-se rapidamente quando atravessamos o gráfico. Um nível de travessia adiciona significativamente ao tempo de Resposta da consulta.

Referência: Bases De Dados Da Próxima Geração