Resumo - Guia Definitivo de Bancos de Dados Grafos:
Para Desenvolvedores RDBMS
Por Michael Hunger, Ryan Boyd e William Lyon
Capítulo 1: Porque bancos de dados relacionais não são sempre suficientes
Apesar de ser dos bancos de dados relacionais serem o modelo para armazenamento de dados
mais adotado da década de 80 até os dias atuais, eles já começam a apresentar problemas de
desempenho para representar modelos de dados onde nem sempre o dado do registro é tão
relevante quanto as relações entre estes dados.
Apesar do nome Banco de dados relacional, seu foco não é nas relações em si, este nome é
apenas uma derivação do modelo matemático em que se baseiam, a álgebra relacional.
A principal dificuldade que se vem encontrando no uso de banco de dados relacionais é a sua
característica de esquema estático, ou seja, é um modelo muito bom para lidar com
armazenamento de dados de situações em que o tamanho da base de dados já é muito bem
predefinida e não sofre constantes alterações.
Entretanto já é notável que nos dias de hoje com alterações constantes em modelos de negócio e
representações de dados que se atualizam constantemente, os RDBMS se tornam cada vez mais
custosos e lentos.
Alguns sinais claros destas dificuldades que o RDBMS sofrem com alto esforço de SQL:
●
●
●
●
●
Grande número de JOINS.
Numerosos JOINs Recursivos(Self-Joins).
Mudança Frequentes no Esquema do banco de dados.
Consultas de execução lentas mesmo com extensivos ajustes
Pré-Computação de dados gerando desperdício de recursos.
Capítulo 2: Por Que Bancos de Dados Orientados a Grafos?
Embora existam várias opções de bancos de dados, como NoSQL e outros, nenhum deles é
especificamente projetado para armazenar e lidar especificamente com o relacionamento dos
dados, e é aí que os bancos de dados grafos se destacam, pois eles são capazes de armazenar os
relacionamentos como entidades de primeira classe, quando se fala em armazenamento de dados
onde as aplicações dependem de dados conectados. Um grafo é composto por dois elementos: um
nó e um relacionamento. Um banco de dados orientado a grafos é um modelo de banco que
realiza as 4 operações do CRUD mas que trabalha em um modelo baseado em grafos. Ao
contrário de outros bancos de dados, os relacionamentos ocupam a primeira prioridade em bancos
de dados grafos. Alguns bancos de dados permitem o armazenamento nativo de grafos, porém a
maioria do armazenamento é não nativo, especialmente quando o volume de dados e a
complexidade das consultas crescem. O processamento de grafos nativo é o meio mais eficiente
para processamento de dados de grafos, já que nós conectados fisicamente se posicionam um
junto ao outro no banco de dados.
Algumas vantagens que estão levando empresas a optar por banco de dados orientados a grafos
são:
Desempenho de Minutos a Milissegundos
Os bancos de dados orientados a grafos superam esse problema de complexidade das consultas
SQL, transformando JOINs complexos em operações eficientes de grafos, garantindo
desempenho em milissegundos, independentemente do tamanho total do conjunto de dados.
Ciclos de Desenvolvimento Drasticamente Acelerados
A redução do tempo de desenvolvimento é devido a remoção da necessidade de traduzir
representações de objetos em relações. O que reduz incompatibilidade e tempo de
desenvolvimento.
Capacidade de Resposta Extrema ao Negócio
O modelo de BD orientado a grafos se alinha perfeitamente com os modelos atuais de negócio
que requerem constantes atualizações e expansões no modelo de negócios.
Capacidade de Resposta Ágil
Bancos de dados orientados a grafos permitem uma evolução contínua das aplicações em
resposta a mudanças, facilitando ajustes e expansões na estrutura de grafos sem comprometer a
funcionalidade atual.
Capítulo 3: Modelagem de Dados: Modelos Relacionais vs. Grafos
Os bancos de dados orientados a grafos representam a próxima geração dos relacionais,
destacando-se pela ênfase em "relacionamentos". Cada nó no modelo de grafos contém uma lista
direta de registros de relacionamento, eliminando a necessidade de JOINs computacionais. Essa
pré-materialização impulsiona o desempenho das consultas, indo de minutos a milissegundos. Os
modelos resultantes são mais simples e expressivos, suportando flexibilidade e facilitando a
modelagem intuitiva de domínios ricos. Além disso, a granularidade permite operações sem
limites fixos, com transações ACID suportadas. Comparado aos relacionais, o modelo de grafos é
mais fácil de entender e direcionar, refletindo um claro e eficiente modelo do domínio.
Os passos para criar um modelo orientado a grafos são claros e simples:
● Cada linha da tabela de entidade se torna um nó.
● Represente cada tabela de entidade com uma label e inclua os nós correspondentes.
● As colunas das tabelas se convertem em propriedades dos nós.
● Remova chaves primárias técnicas, mantendo as chaves de negócios.
● Adicione constraints únicas para chaves de negócios e índices para atributos
frequentemente pesquisados.
● Substitua chaves estrangeiras por relações com outras tabelas, removendo-as se
necessário.
● Elimine dados com valores padrão não utilizados.
● Se necessário, separe dados desnormalizados e duplicados em nós distintos para um
modelo mais limpo.
● Considere indicar propriedades de arrays em colunas indexadas (por exemplo, email1,
email2, email3).
● Transforme tabelas JOIN (N..N) em relacionamentos, com as colunas dessas tabelas
sendo propriedades dos relacionamentos.
O paradigma relacional enfrenta desafios de desempenho devido à necessidade frequente de
desnormalização para atender às demandas do mundo real. A desnormalização envolve
duplicação de dados para melhorar o desempenho, resultando em complexidades e resistência à
evolução rápida. As mudanças no modelo relacional exigem migrações demoradas, criando um
fosso entre a concepção inicial e a implementação física, dificultando a colaboração entre as
partes interessadas não técnicas. Em contraste, os bancos de dados orientados a grafos
oferecem um modelo mais flexível e alinhado com o domínio, facilitando mudanças rápidas sem
comprometer a integridade dos dados. A modelagem de dados em grafos concentra-se em
enriquecer a estrutura conceitual, representando papéis, atributos e conexões de forma intuitiva,
eliminando a necessidade de tabelas, normalização e desnormalização. O contexto semântico é
garantido por relacionamentos nomeados e direcionados, simplificando a transição para o banco
de dados.
Capítulo 4: Query Languages: SQL vs. Cypher
O Cypher é a linguagem de consulta para bancos de dados orientados a grafos, similar ao SQL
para bancos de dados relacionais. Sua origem no projeto openCypher ampliou seu uso para além
do Neo4j. De natureza declarativa e construída sobre conceitos SQL, o Cypher simplifica
consultas em modelos de grafo, sendo legível e compreensível. Ao contrário de instruções SQL
complexas, a sintaxe do Cypher permanece clara e focada em conceitos de domínio, facilitando a
expressão visual de consultas. O Cypher permite buscar dados que correspondam a padrões
específicos, sendo intuitivo e fácil de usar. Ao representar grafos usando arte ASCII, o Cypher
segue naturalmente a forma como desenhamos grafos no quadro branco. A consulta envolve
cláusulas como MATCH e RETURN, sendo especialmente eficiente para dados altamente
conectados, superando as limitações do SQL em tais cenários. O aprendizado do Cypher é
facilitado para equipes com experiência em SQL, oferecendo uma linguagem embutida eficiente
para desenvolvimento corporativo.
Capítulo 5: Importando Dados: do RDBMS Para o Grafo
Existem três abordagens principais para migrar dados de um banco de dados relacional para um
orientado a grafo, cada uma com seus próprios méritos. A escolha da abordagem depende dos
objetivos específicos da aplicação e da arquitetura em questão. As abordagens incluem:
● Migração em massa única: Algumas equipes realizam uma migração completa de todos os
dados do banco de dados relacional para o banco de dados orientado a grafo em uma
única operação.
● Armazenamento seletivo: Outras equipes continuam utilizando o banco de dados relacional
para casos de uso que dependem de dados suplementares, armazenando no banco de
dados orientado a grafo apenas os dados envolvidos em operações com muitos JOINs ou
relacionamentos complexos.
● Persistência em ambos os bancos: Algumas equipes mantêm todos os dados em ambos
os bancos, permitindo consultas em qualquer formato ideal para os diferentes casos de
uso.
Não há uma abordagem "correta", e a escolha depende dos requisitos específicos da aplicação.
Se a opção for migrar dados, é possível fazê-lo exportando tabelas, utilizando drivers de banco de
dados ou sincronizando dados regularmente com base em timestamps.
A extração de dados de um RDBMS pode ser feita por meio de despejo de tabelas, exportação
CSV ou consultas. O processo pode ser desafiador, e é importante considerar o desempenho ao
lidar com grandes volumes de dados. O Neo4j oferece a facilidade de importar dados via LOAD
CSV no Cypher, permitindo a conversão de arquivos CSV em dados de grafo conectados. Essa
abordagem oferece flexibilidade, controle sobre transações e suporte para diversas operações.
Outras ferramentas de importação, como o carregador de massa de linha de comando, são úteis
para inserções em massa, especialmente na população inicial do banco de dados. Além disso,
um carregador personalizado baseado em Cypher permite inserções altamente concorrentes,
sendo eficaz para grandes conjuntos de dados. A API Neo4j também oferece a capacidade de
executar instruções Cypher, proporcionando controle sobre transações de importação. A escolha
da ferramenta dependerá das necessidades específicas do projeto e do ambiente.
Estudo Aplicado: Instalação e Testes do NEO4J
O Neo4j é um banco de dados orientado a grafos, projetado para armazenar e manipular dados
que possuem relações complexas. Sua estrutura de dados baseia-se em nós, que representam
entidades, e arestas, que indicam as relações entre essas entidades. Essa abordagem torna o
Neo4j particularmente eficaz para modelar e consultar dados interconectados, como redes
sociais, sistemas de recomendação, análise de fraudes e outras aplicações onde as relações são
fundamentais. A linguagem de consulta Cypher é utilizada para interagir com o Neo4j, permitindo
a execução de consultas poderosas para explorar e extrair informações valiosas a partir dos
grafos armazenados. O neo4j desktop pode ser baixado no site oficial.
Após o download e instalação do neo4j é possível a realização de consultar por meio da
linguagem cypher, para os nossos testes. Para atender a proposta da atividade e executar
algoritmos orientados a grafos no neo4j, notou-se que era necessário a instalação de dois plugins
para a execução correta dos algoritmos em cypher.
Deve Instalar os plugins APOC e Graph Data Science Library, são elas que contém as extensões
que serão necessárias para a execução dos algoritmos. O script para criar nossa base de dados
será o mostrado abaixo.
CREATE (alice:Person:Vegan {name: 'Alice', age: 24, lotteryNumbers: [1, 3], embedding: [1.0, 3.0]})
CREATE (bob:Person:Vegan {name: 'Bob', age: 73, lotteryNumbers: [1, 2, 3], embedding: [2.1, 1.6]})
CREATE (carol:Person {name: 'Carol', age: 24, lotteryNumbers: [3], embedding: [1.5, 3.1]})
CREATE (dave:Person:Vegan {name: 'Dave', age: 48, lotteryNumbers: [2, 4], embedding: [0.6, 0.2]})
CREATE (eve:Person:Vegan {name: 'Eve', age: 67, lotteryNumbers: [1, 5], embedding: [1.8, 2.7]});
*Imagem de: neo4j.com
O algoritmos que iremos implementar na plataforma será o algoritmo de “Filtered K-Nearest
Neighbors”.O algoritmo Filtered K-Nearest Neighbors (FKNN) é como um assistente que ajuda a
classificar coisas com base em seus vizinhos mais próximos. Imagine que você tem um monte de
fotos de animais e quer saber que tipo de animal é cada foto. O FKNN olha para as fotos que são
mais parecidas com as que você está tentando classificar e usa isso para dar uma resposta.
A diferença importante com o FKNN é que ele primeiro dá uma olhada rápida nas fotos para
eliminar aquelas que não são tão importantes. É como se o assistente filtrasse as fotos, deixando
apenas as mais relevantes, antes de decidir a resposta final. Isso ajuda a tornar o processo mais
eficiente e preciso, especialmente quando há muitas fotos para analisar.
O seguinte algoritmo executará o comando cyher e aplicará um filtro nos nós de origem e
transmite os resultados:
Na janela superior na linha 1 a 12 vemos o algoritmo cypher para encontrar os vizinhos mais
próximos de um dado vértice.
E abaixo notamos o resultado da execução do algoritmo, tendo o resultado de similaridade entre
os
nós
mais
próximos
descritos
na
coluna
“similarity”.
E com isso obtemos informação de que Alice e Carol são as pessoas com a maior proximidade de
vizinhança no grafo implementado.
Em uma segunda implementação experimental nos realizamos a implementação do algoritmo:
Este algoritmo encontra o nó mais semelhante com base na idade, considerando apenas os nós
filtrados pela propriedade 'Vegan' no grafo com nome de myGraph, nome padrão do neo4j. Os
resultados são:
Além dos algoritmos K-Nearest Neighbors (KNN) e Filtered K-Nearest Neighbors (FKNN), o Neo4j
oferece uma variedade de algoritmos especializados em grafos para atender a diferentes
necessidades analíticas. Entre eles, destacam-se o algoritmo de PageRank, que avalia a
importância relativa dos nós em um grafo, e o algoritmo de Community Detection, que identifica
grupos ou comunidades de nós fortemente conectados. Outros algoritmos incluem Shortest Path
para encontrar o caminho mais curto entre dois nós, e Betweenness Centrality para avaliar a
influência de um nó na comunicação entre outros.
Conclusões Finais
As vantagens dos bancos de dados de grafos, como o Neo4j, são notáveis em cenários onde as
relações são tão importantes quanto os próprios dados. Esses bancos são altamente eficientes
na representação e navegação de conexões complexas, permitindo consultas rápidas e intuitivas
sobre a estrutura do grafo. Além disso, os algoritmos especializados facilitam a análise de
padrões e propriedades emergentes nos dados interconectados. A modelagem de dados baseada
em grafos também reflete de maneira natural muitos cenários do mundo real, como redes sociais,
cadeias de suprimentos e sistemas de recomendação, tornando os bancos de grafos uma
escolha poderosa para aplicações que envolvem dados altamente relacionados e interativos.
Referências Bibliográficas:
The Top 10 Use Cases of Graph Database Technology Unlock New Possibilities with Connected
Data Por Jim Webber, Chief Scientist, Neo4j.
Guia Definitivo de Bancos de Dados Grafos: Para Desenvolvedores RDBMS Por Michael Hunger,
Ryan Boyd e William Lyon
Uma Introdução Sucinta à Teoria dos Grafos Por P. Feofiloff, Y. Kohayakawa, Y. Wakabayashi
https://www.ime.usp.br/~pf/teoriadosgrafos/
https://neo4j.com/docs/graph-data-science/current/introduction/
https://neo4j.com/docs/graph-data-science/current/algorithms/