Esta comparação do Neo4j com o tempo de execução do RDBMS está correta?

Histórico: A seguir, é apresentado o livro Graph Databases , que cobre um teste de desempenho mencionado no livro Neo4j in Action :

Os relacionamentos em um gráfico formam naturalmente caminhos. Ao consultar ou percorrer, o gráfico envolve os seguintes caminhos. Devido à natureza fundamentalmente orientada ao caminho do modelo de dados, a maioria das operações de banco de dados de gráficos com base em caminhos está altamente alinhada com a maneira como os dados são dispostos, tornando-os extremamente eficientes. Em seu livro Neo4j in Action, Partner e Vukotic realizam um experimento usando uma loja relacional e o Neo4j.

A comparação mostra que o banco de dados gráfico é substancialmente mais rápido para dados conectados do que uma loja relacional. O experimento da Partner e da Vukotic procura encontrar amigos em uma rede social, até uma profundidade máxima de cinco. Dadas duas pessoas escolhidas aleatoriamente, existe um caminho que as conecte com no máximo cinco relacionamentos? Para uma rede social que contém 1.000.000 de pessoas, cada uma com aproximadamente 50 amigos, os resultados sugerem fortemente que os bancos de dados gráficos são a melhor opção para dados conectados, como podemos ver na Tabela 2-1.

Tabela 2-1. Localizando amigos estendidos em um banco de dados relacional versus localizações eficientes no Neo4j

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

Na profundidade dois (amigos de amigos), o banco de dados relacional e o banco de dados de gráficos apresentam desempenho suficiente para considerarmos usá-los em um sistema online. Enquanto a consulta Neo4j é executada em dois terços do tempo da relacional, um usuário final mal notaria a diferença de milissegundos entre os dois. Quando atingimos a profundidade três (amigo de amigo), fica claro que o banco de dados relacional não pode mais lidar com a consulta em um prazo razoável: os trinta segundos necessários para concluir seriam completamente inaceitáveis para um sistema online. Por outro lado, o tempo de resposta do Neo4j permanece relativamente baixo: apenas uma fração de segundo para executar a consulta - definitivamente rápido o suficiente para um sistema online.

Na profundidade quatro, o banco de dados relacional exibe latência incapacitante, tornando-o praticamente inútil para um sistema online. Os tempos do Neo4j também se deterioraram um pouco, mas a latência aqui está na periferia de ser aceitável para um sistema online responsivo. Finalmente, na profundidade cinco, o banco de dados relacional simplesmente leva muito tempo para concluir a consulta. O Neo4j, por outro lado, retorna um resultado em cerca de dois segundos. Na profundidade cinco, transparece que quase toda a rede é nossa amiga: para muitos casos de uso do mundo real, provavelmente apararíamos os resultados e os prazos.

As perguntas são:

• Esse é um teste razoável para simular o que se poderia encontrar em uma rede social? (O que significa que as redes sociais reais normalmente têm nós com aproximadamente 50 amigos, por exemplo; parece que o modelo "os ricos ficam mais ricos " seria mais natural para as redes sociais, embora possa estar errado.)
• Independentemente da naturalidade da emulação, há alguma razão para acreditar que os resultados estão errados ou improdutíveis?

Observando este documento chamado Anatomia do Facebook , observo que a mediana é 100. Observando o gráfico da função cumulativa, posso apostar que a média é maior, perto de 200. Portanto, 50 parece não ser o melhor número aqui. No entanto, acho que esse não é o principal problema aqui.

O principal problema é a falta de informações sobre como o banco de dados foi usado.

Parece razoável que um armazenamento de dados projetado especialmente para estruturas de gráfico seja mais eficiente que os RDBMs tradicionais. No entanto, mesmo que os RDBMs não estejam nas últimas tendências como um armazenamento de dados de escolha, esses sistemas evoluíram continuamente em uma corrida com as dimensões do conjunto de dados. Existem vários tipos de designs possíveis, várias maneiras de indexar dados, aprimoramentos relacionados à simultaneidade e assim por diante.

Para concluir, acho que, quanto à reprodutibilidade, o estudo carece de uma descrição adequada de como o esquema do banco de dados foi projetado. Não espero que um banco de dados domine esse rei de interrogatórios, mas esperaria que, com um design bem ajustado, as diferenças não fossem tão grandes.

Existem maneiras boas / rápidas de modelar gráficos no RDBMS e maneiras burras / lentas.

• Alguns usam indexação inteligente e procs armazenados, negociando carga de CPU e tabelas temporárias ajustadas em discos de RAM para obter uma velocidade mais rápida de recuperação de gráficos.

• Alguns usam caminhos gráficos pré-computados (isso pode ser menos viável no cenário de rede social, mas em uma árvore com a maioria dos nós sendo nós folha, é uma troca muito boa de espaço por tempo

• Alguns simplesmente calculam em um loop, usando a tabela temporária indexada não ajustada. Dos #s lançados no artigo, isso tem o cheiro do que eles fizeram (desempenho de 30 segundos em um conjunto de dados bastante pequeno)

  Por exemplo, eu tenho meu próprio cálculo em árvore.

  • Ele é encapsulado em um processo armazenado altamente ajustado

  • Enquanto está sendo executado em um servidor de dados Sybase ASE15 de hardware de tamanho corporativo, esse servidor é compartilhado com alguns terabytes de dados de todos os outros aplicativos empresariais, alguns com muito mais fome do que o meu; e não se dedica exclusivamente à execução de minhas consultas.

  • Eu fiz não têm acesso à ferramenta de aceleração principal, uma tabela temporária em um disco RAM.

  • Um conjunto representativo de dados que eu estava recuperando e que parecia corresponder ao deles estava obtendo uma subárvore de 150.000 nós do conjunto de dados completo da floresta de 2,5 milhões de nós (profundidade ilimitada da árvore, que varia entre 5 e 15, mas menor aridade média de um nó do que os 50 amigos listados na experiência)

  • Eu ajustei ao ponto que esta consulta ~ 30-45 segundos. Certamente NÃO exibe a desaceleração exponencial que os números na pergunta parecem indicar no desempenho do RDBMS, o que é um duplo estranho, uma vez que não há crescimento exponencial no conjunto de resultados (o que para mim cheira a um índice não ajustado em um tabela temporária por experiência pessoal).

Portanto, é provável que essa comparação seja incorreta e se baseie no design lateral do RDBMS ruim, embora, como a resposta anterior notou, seja impossível determinar sem eles abrirem 100% de suas definições de código e tabela.