Banco de Dados de Grafo

Ideia central

Bancos de dados de grafo modelam dados como nós (entidades) e arestas (relacionamentos), ambos podendo ter propriedades. São a escolha natural quando os relacionamentos entre os dados são tão importantes quanto os dados em si, algo que bancos relacionais resolvem mal (joins recursivos custosos) e NoSQL de documento resolve pior ainda.

Modelo de dados

         [Pessoa]                [Pessoa]
         nome: Logan  ─── CONHECE ───  nome: Ana
              │                            │
         TRABALHA_EM                  TRABALHA_EM
              │                            │
         [Empresa]                    [Empresa]
         nome: Acme                   nome: Acme

• Nó (Node): entidade, podendo ter labels (tipos) e propriedades
• Aresta (Relationship/Edge): sempre tem direção, tipo e pode ter propriedades
• Propriedade: par chave-valor em nós ou arestas

Cypher: linguagem do Neo4j

-- Criar nós e relacionamentos
CREATE (logan:Pessoa {nome: "Logan", idade: 30})
CREATE (ana:Pessoa {nome: "Ana", idade: 28})
CREATE (acme:Empresa {nome: "Acme Corp"})
 
CREATE (logan)-[:TRABALHA_EM {desde: 2022}]->(acme)
CREATE (ana)-[:TRABALHA_EM {desde: 2023}]->(acme)
CREATE (logan)-[:CONHECE {desde: 2021}]->(ana)
 
-- Encontrar colegas de trabalho de Logan
MATCH (logan:Pessoa {nome: "Logan"})-[:TRABALHA_EM]->(empresa)<-[:TRABALHA_EM]-(colega)
RETURN colega.nome, empresa.nome
 
-- Encontrar amigos de amigos (2 graus de separação)
MATCH (logan:Pessoa {nome: "Logan"})-[:CONHECE*2]->(pessoa)
RETURN pessoa.nome
 
-- Caminho mais curto entre duas pessoas
MATCH path = shortestPath(
  (logan:Pessoa {nome: "Logan"})-[:CONHECE*]-(alvo:Pessoa {nome: "Carlos"})
)
RETURN path

Principais bancos de grafo

Banco	Modelo	Linguagem	Destaque
Neo4j	Propriedades	Cypher	Mais popular, ecossistema maduro
Amazon Neptune	Propriedades / RDF	Gremlin / SPARQL	Managed na AWS
ArangoDB	Multi-model	AQL	Grafo + documento + K-V em um só
TigerGraph	Propriedades	GSQL	Alta performance para analytics
Dgraph	GraphQL nativo	GraphQL+	Schema-first, distribuído

Casos de uso clássicos

• Redes sociais: quem segue quem, sugestão de amizade, feed personalizado
• Sistemas de recomendação: “usuários que compraram X também compraram Y”
• Detecção de fraude: identificar padrões de relacionamento suspeitos entre contas
• Grafos de conhecimento: ontologias, motores de busca semântica
• Gestão de identidade e acesso: hierarquia de permissões complexa (RBAC/ABAC)
• Roteamento e logística: menor caminho, análise de dependências

Quando grafo ganha do relacional

Em bancos relacionais, consultas que percorrem relacionamentos profundos exigem JOINs recursivos que escalam mal:

-- SQL: amigos de amigos de amigos (N graus), ficando cada vez mais custoso
WITH RECURSIVE amigos AS (
    SELECT amigo_id FROM conexoes WHERE usuario_id = 1
    UNION
    SELECT c.amigo_id FROM conexoes c
    JOIN amigos a ON c.usuario_id = a.amigo_id
)
SELECT * FROM amigos;

Em grafo, a mesma query é linear em relação ao número de nós visitados; o custo não cresce com o tamanho total do banco, mas com o subgrafo percorrido.

Quando não usar grafo

• Dados puramente tabulares sem relacionamentos complexos
• Relatórios e analytics em larga escala (OLAP), onde bancos colunares ganham
• Quando joins simples (1-2 níveis) já resolvem, o overhead de um banco de grafo não se justifica

Conexões

• db-tipos-de-bancos-de-dados - Comparativo geral
• db-nosql - Grafo como subcategoria de NoSQL
• db-relacional - Contraponto: quando o modelo relacional é suficiente

Referências

• Neo4j Documentation
• Graph Databases - O’Reilly (Ian Robinson et al.)
• Amazon Neptune