Relacional não pode fazer tudo

Registrar Debate Bem-vindo de volta ao mais recente Register Debate, no qual os escritores discutem tópicos de tecnologia e você, o leitor, escolhe o argumento vencedor.

O formato é simples: propomos uma moção, os argumentos a favor da moção são executados na segunda e quarta-feira, e os argumentos contra são executados hoje e quinta-feira. Durante a semana, você pode votar em qual lado você apoia usando a enquete incorporada abaixo, escolhendo se você é a favor ou contra. A pontuação final será anunciada na sexta-feira, revelando qual argumento foi mais popular.

Cabe aos nossos escritores convencê-lo a votar no lado deles.

A moção desta semana é:

Bancos de dados gráficos – nos quais os relacionamentos são armazenados nativamente junto com os elementos de dados – não fornecem uma vantagem significativa sobre bancos de dados relacionais bem arquitetados para a maioria dos mesmos casos de uso.

Já se passaram cerca de 20 anos desde a primeira implantação de produção do Neo4j, um dos principais protagonistas na história do banco de dados gráfico.

O forte crescimento do mercado e o interesse dos investidores sugerem que ele pode estar alcançando as linhas e colunas dos RDBMSes, devido à sua análise de dados de acordo com os relacionamentos em rede que vemos ao nosso redor: nos negócios, na mídia, na sociedade, na medicina e na ciência.

Mas os detratores ainda têm suas dúvidas, sugerindo que os benefícios que os sistemas gráficos parecem oferecer podem ser criados em sistemas relacionais, que têm uma história mais longa – e são sem dúvida mais maduros e fáceis de gerenciar – do que seus equivalentes gráficos.

Jim Webbernosso primeiro colaborador argumentando CONTRA a moção, é o cientista-chefe da Neo4j e professor visitante de ciência da computação na Universidade de Newcastle.

Relacional não pode lidar com todos os casos de uso

Concordamos com muitas das afirmações da casa sobre a utilidade das APIs gráficas. O cerne de nosso desacordo é simplesmente com a alegação de que algum futuro mecanismo de banco de dados relacional “bem arquitetado” poderia tornar desnecessário o uso dos bancos de dados de gráficos em produção existentes e úteis de hoje. O adjetivo “bem arquitetado” faz muito trabalho pesado aqui para tornar essa especulação tão pouco confiável quanto é.

Jim Webber: A ideia de que relacional é uma opção de banco de dados universal é espúria

Também devemos apontar que a ideia de que relacional pode lidar com qualquer caso de uso e é uma opção de banco de dados universal é espúria. A noção de “tamanho único” foi descartada [PDF] por um dos teóricos mais influentes da escola relacional, Michael Stonebraker. Stonebraker argumenta que cargas de trabalho distintas, mesmo dentro do escopo de bancos de dados relacionais, exigem diferentes mecanismos de dados para funcionar bem. Dentro do Neo4j, estamos felizes em adotar essa especialização, pois o banco de dados de gráficos possui um mecanismo diferente da plataforma de análise de gráficos. Na verdade, existe uma rica tradição de fazê-lo em documentos, séries temporais e, sim – bancos de dados relacionais [PDF].

Não podemos aceitar que o relacional possa fazer qualquer coisa. Também não podemos aceitar”[graph] os sistemas ignoram muitas das lições duramente aprendidas… dos últimos 50 anos”, como se os gráficos existissem fora do gerenciamento de dados operacionais do dia-a-dia. No entanto, os bancos de dados de gráficos abordaram consistentemente transações, planejamento/execução de consultas, indexação, consenso, replicação e controle de concorrência usando uma mistura de técnicas testadas e comprovadas.

Estamos contentes que a casa veja “benefícios de… APIs gráficas” e linguagens de consulta orientadas a consultas. É por isso que construímos o Cypher, uma linguagem declarativa [PDF] com semântica formalmente descrita. Estamos envolvidos com a academia e a indústria para definir GQL, uma contraparte gráfica padronizada ISO para SQL baseada em Cypher, pelo mesmo comitê ISO que padronizou o SQL. O GQL permitirá que um grande número de novos usuários expressem de forma sucinta e humana consultas gráficas que são complicadas e propensas a erros no SQL.

Rejeitamos a afirmação de que os bancos de dados de gráficos não podem suportar exibições e migrações adequadamente e, portanto, carecem de (uma definição restrita de) independência de dados. As migrações são frequentemente executadas na prática (como neste exemplo), enquanto o GQL inclui sintaxe nativa para definir exibições de gráficos. Na verdade, a natureza opcional do esquema de muitos bancos de dados de gráficos e as habilidades de correspondência de padrões difusos de suas linguagens de consulta significam que eles estão em melhor situação do que outros com relação à independência de dados.

Mas os bancos de dados não são apenas sobre teoria. Eles são sistemas complexos projetados para executar algumas das tarefas mais exigentes da computação. Não é suficiente oferecer noções vagas de “bem arquitetado”, implicando que os bancos de dados anteriores foram mal arquitetados. Muitos milhares de sistemas de produção de gráficos em uso hoje certamente não escolheram gráficos por ignorância, mas porque o modelo de gráfico e o desempenho eram o melhor mecanismo para seus requisitos específicos.

Quanto à alegação de que você pode apenas escrever SQL que faz o trabalho gráfico, os gráficos heterogêneos têm relacionamentos entre os nós que são muitos, variados e bidirecionais. Às vezes são regulares, às vezes não; às vezes são esparsos e às vezes densos. A noção da casa de que os gráficos devem ser modelados como uma coleção de tabelas não é prática. Sabemos disso muito bem porque foi assim que o Neo4j começou: usando uma API de gráfico em cima de um banco de dados relacional, acabamos indo na contramão com complexidade explosiva e desempenho cada vez menor. É essa lacuna tecnológica precisa que nos obrigou a construir um motor que pudesse processar gráficos nativamente, não uma vontade perversa de construir nosso próprio banco de dados!

O fato é que, para casos de uso de gráficos comuns na natureza, os mecanismos de armazenamento nativos costumam ter benefícios de tempo de execução muito significativos, que incluem maior localidade de dados, melhor suporte à simultaneidade e uso de espaço reduzido, para citar apenas alguns. Alguns estudos escolhidos a dedo de mais de 5 anos atrás, que se concentram principalmente em cargas de trabalho analíticas em gráficos homogêneos, não mudam essa realidade.

Tivemos 50 anos para entender os bancos de dados relacionais. Passamos a respeitar sua utilidade e compreender suas limitações. Assim, argumentamos que o mecanismo de processamento “bem arquitetado” proposto pela casa já está aqui. E é chamado de banco de dados gráfico. ®

Dê seu voto abaixo. Fecharemos a enquete na noite de quinta-feira e publicaremos o resultado final na sexta-feira. Você pode acompanhar o andamento do debate aqui.

JavaScript desabilitado

Ative o JavaScript para usar este recurso.