Eu me comprometi com os leitores do blog, a publicar posts semanais. Mas desta vez eu falhei, por uma causa nobre… Vim para a Bélgica palestrar sobre Neo4J e PHP, em um evento super bacana chamado PHP Benelux.
Esta semana postarei as fotos e conto como foi o evento… Mas só dando um spoiler, separei algumas fotos.
Esta foi a minha primeira palestra na Europa, e quando terminei, fiquei tão anestesiada que escrevi 80% deste post. Acho que esta foi a minha maneira de compartilhar com todos a minha felicidade e também agradecer o apoio.
Eu, os Grafos e o Neo4J
Eu sempre dizia que fugi das aulas de grafos na faculdade… Mas na verdade meu “problema”era o vício no modelo relacional que eu aprendi na faculdade (e que eu adoro), e todo meu pensamento de modelagem estava pautado em premissas que nem sempre são válidas.
Resisti muito aos grafos, mas estou totalmente apaixonada, porque eles são muito naturais. Acredite!
Teve uma época na minha vida que eu acreditava que os problemas das aplicações se resumiam a código mal escrito e problemas no banco de dados.
Não posso falar muito de código ruim porque codificar não é minha especialidade (embora eu ame programar).
Mas quando o problema é o banco de dados, a solução não depende só do DBA… Depende muito do arquiteto da solução, porque nem todos os problemas são resolvidos com índices, nem melhorando as queries, nem aumentando a memória do servidor, CPU e rede… São resolvidos com o uso do SGBD correto.
Persistência Poliglota
Não me odeiem por falar novamente deste assunto…
Este é um conceito “velhinho” mas sempre bom de lembrar… Martin Fowler falou sobre ele em 2012, quando afirmou que um sistema pode ter diversos tipos de dados diferentes, e para cada tipo de dados podemos ter um SGBD.
Sendo assim, este post não significa que os bancos de dados relacionais nunca mais devem ser usados, ou que o MongoDB é ruim… Significa que temos mais uma possibilidade, que é muito poderosa se usada no contexto correto.
Quando usar Bancos de Dados Relacionais?
Assunto fofinho que nós conversamos no primeiro post desta série. Para não ser a chata repetitiva, te convido para acessar este link.
Quando usar o MongoDB?
Este é o assunto polêmico do rolê… Mas que já conversamos no último post e está disponível no link.
Aliás um comentário… Estou assustada com tudo o que eu ouvi sobre o MongoDB! Ele é fantástico, mas por ser muito simples acaba sendo pessimamente utilizado. Se você não quer ter problemas gigantes no futuro, ou está em dúvida, me chamem para uma mentoria, uma consultoria, um café, um bate papo… Tenho certeza que posso te ajudar, e no futuro você terá bem menos problemas.
O que é um grafo?
Primeira coisa… Entenda que tudo está conectado…
O modelo de grafos representa uma maneira flexível de lidar com relacionamentos em seus dados, porque este tipo de SGBD fornece também armazenamento, recuperação e consultas rápidas e eficientes.
Vamos então para a definição de grafo: Um grafo é uma coleção de objetos, cada um com um conjunto de links com os outros objetos.
Sendo assim, você já percebeu que um grafo é composto por objetos e os seus links…
Que no Neo4J são chamados de Nodes/ Nós e Relacionamentos
Os nodes são os principais objetos de um gráfico. Dizemos isso não porque os eles que eles contêm mais dados que os relacionamentos – embora normalmente tenham – mas porque é perfeitamente aceitável ter nodes sem nenhum relacionamento. Por outro lado, não é possível ter um relacionamento sem nodes.
Os nodes possuem labels, que servem para agrupar e indexar os nodes, possuem também propriedades que são pares do tipo chave e valor com suas características.
Cada node representa uma entidade (uma pessoa, local, coisa, categoria ou outro dado). No Neo4J os labels são um recurso incrível para representar o “papel de um node”. Por exemplo, um node Localização é um node com o label Localização . Esse mesmo node também pode ter um label, Residência . Outro node Localização também pode ter um label, Comercial . Um label pode ser usado para agrupar nós do mesmo tipo (eu sei que fui repetitiva, mas é de propósito!).
Relacionamentos são os links entre os nodes. Na sua forma mais simples, os relacionamentos não precisam conter nenhuma informação além de quais nós eles ligam. Mas eles podem conter muito mais. Por exemplo, os relacionamentos podem incluir uma direção. “Maria possui um carro” é um relacionamento muito diferente de “Um carro possui Maria”, é a direção do relacionamento entre Maria e seu carro que captura essa diferença.
Cada relacionamento representa como dois nodes estão conectados. Por exemplo, os dois nodes, Pessoa e Local , podem ter o relacionamento Mora apontando de um nó Pessoa para o nó Local . Um relacionamento representa o verbo ou ação entre duas entidades. O relacionamento Ama é definido de um nó Pessoa para outro nó Pessoa. Embora o relacionamento seja definido como direcional, ele pode ser consultado de maneira não direcional. Ou seja, você pode consultar se dois nodes de Pessoa têm um relacionamento chamado Gosta, independentemente da direção do relacionamento.
Um relacionamento também pode ter propriedades, com elas seu grafo fica mais próximo do mundo real. Por exemplo, um relacionamento, CASADO COM pode ter uma propriedade, data .
E o relacional?
Fazendo um paralelo com o universo dos bancos de dados relacionais, nós temos:
Relacional | Grafo |
Linhas | Nodes |
Joins | Relacionamentos |
Nomes de tabela | Rótulos |
Colunas | Propriedades |
Mas devemos ter atenção para o fato de que existem algumas diferenças muito importantes
Relacional | Grafo |
Cada coluna deve ter um valor | Nodes com o mesmo label não precisam ter o mesmo conjunto de propriedades |
Os joins são calculadas no momento da consulta | Os relacionamentos são armazenados no disco quando são criados |
Uma linha pode pertencer a uma tabela | Um node pode ter muitos labels. |
Ok… Ok… Mas para que serve um grafo?
Grafos são muito usados para representar a existência ou não de relações entre elementos de um dado conjunto. Assim, redes sociais, redes de comunicação, fluxos em rede de transporte, mapas geográficos, organogramas, recursões e relações binárias em geral podem ser representadas por grafos.
Fofo né?
Mas e o relacional?
Sim, podemos representar dados conectados com bancos de dados relacionais… Mas temos como desafio o desempenho quando o volume de dados cresce. Lembre-se que estamos buscando a melhor alternativa, e fazer joins com muitas tabelas tende a não ser uma alternativa esperta.
Diferente de outros bancos de dados, os relacionamentos têm prioridade nos bancos de dados orientados a grafos. Isso significa que seu aplicativo não precisa inferir conexões de dados usando chaves estrangeiras, ou desnormalizando os dados criando “tabelões” e fazendo o volume dos dados crescer absurdamente.
O que é o Neo4J?
O Neo4j, o banco de dados orientado a grafos mais popular do mundo segundo o site db-engines.com. Ele tem muitos casos de uso bem fofos, e é usado por grandes empresas, por que é capaz de lidar com grandes quantidades de dados altamente conectados.
Sim ... Use o Neo4J se precisar manipular grafos!
O Neo4J tem um alto desempenho porque usa estruturas de armazenamento dedicadas para nós e relacionamentos. Ele não precisa fazer os JOINS no momento da consulta, ele armazena os relacionamentos de forma eficiente como “parte de seus dados”.
No Neo4J, não é possível criar um relacionamento sem nós … Portanto, temos o ACID que garante que os nós e todos os seus relacionamentos serão criados ou que nada será criado ou atualizado (fofinho né?).
Neo4j’s Graph Query Language: Cypher
Me falaram muitas vezes que o Cypher parecia a linguagem SQL e eu resisti muito com esta história, mas sabe que hoje em dia eu vejo muitas semelhanças, se analisarmos a essência da linguagem SQL e os comandos Cypher (assunto para um post inteiro…)
Os comandos escritos com Cypher são interpretados pela Graph Engine do Neo4J, que também executa o código no nível do kernel para armazenar e recuperar dados, estejam eles em disco ou armazenados em cache na memória.
Em um ambiente de desenvolvimento, você usará o Neo4j Browser ou um browser da Web para acessar dados e testar suas instruções Cypher, a maioria das quais será usada como parte do código dos seus aplicativos.
A Neo4j desenvolveu o Cypher para facilitar a consulta em grafos. É uma linguagem declarativa, focada na legibilidade e expressividade para humanos.
Sendo declarativo, o Cypher se concentra em expressar o que recuperar de um grafo, em vez de como recuperá-lo.
Não vou dar todos os mil detalhes fofos do Cypher, mas recomento que você guarde o seguinte link no coração: https://neo4j.com/docs/cypher-refcard/current/
As palavras chave mais importantes do Cypher são:
MATCH: Busca no grafo, dados que correspondem a um padrão fornecido
WHERE: Filtra os resultados com predicados, como no SQL.
RETURN: Informa qual o retorno da sua consulta
CREATE: Cria elementos (nodes e relacionamentos) com rótulos e propriedades.
MERGE: É uma combinação de MATCH e CREATE.
Como usar o Neo4J?
Vamos lá… Lembra que o Neo4J é um Sistema Gerenciador de Banco de Dados, e em produção deve estar instalado em um servidor, e você precisa estar atento a sua versão, e ao tipo de licença… Nada de ficar achando que NoSQL é gratuito, usar a versão errada é pirataria e pode dar problemas para a sua empresa, porque é crime né amigos…
Se você não quer ter este tipo de preocupação, pode usar o Neo4J Aura, que é a versão do Neo4J na nuvem. Eu achei o preço bem competitivo. Você escolhe a quantidade de memória e CPU mais adequada para a sua demanda de trabalho, e é cobrado por hora.
A grande vantagem é que ele é seguro, você pode escalar (para cima – mais recursos – e para baixo – diminuir os recursos) conforme a sua necessidade, e utiliza o Cypher porque é basicamente o mesmo Neo4J que você instala no servidor.
O Neo4J Aura está disponível neste link.
Se você está tendo o seu primeiro contato com o Neo4J e quer conhecer suas possibilidades, eu recomendo fortemente que você conheça o Neo4J Sandbox. Ele é um recurso incrível!!! Tem diversos grafos de exemplo, e você também pode criar o seu próprio grafo. Nesta semana vou publicar no meu canal do youtube um vídeo mostrando o Neo4J Sandbox. Se inscreve lá para receber a notificação.
O Neo4J Sandbox é uma versão web e tem a duração máxima de 10 dias (3 dias é o padrão, mas você pode estender por mais 7) . Ou seja, nele você faz testes, ok? Depois de 10 dias você vai perder seus grafos e não vai recuperar mais. Você pode acessar o sandbox neste link .
Outra possibilidade é o Neo4J desktop, que você instala localmente e usa. Esta versão está disponível no link.
Agora para o seu ambiente de produção use o Neo4J Server, a versão community está disponível neste link e a enterprise neste.
Quando usar o Neo4J?
Agora que já apresentei rapidamente o Neo4J (aguarde, em breve farei mais posts sobre ele), vamos conversar sobre quando ele é a melhor alternativa.
Sendo bem repetitiva, o Neo4J é um banco de dados NoSQL que armazena grafos, e grafos são conjuntos de objetos conectados.
Use o Neo4J sem medo se:
- É necessário manipular dados conectados e em grande volume;
- Necessidade de máximo desempenho para recuperar dados conectados;
- Quando os dados são hierárquicos (por exemplo, hierarquia de funcionários de um departamento);
- Se em seu modelo Entidade-Relacionamento você identificar muitos relacionamentos do tipo Muitos para Muitos (MXN);
- Se a for necessário fazer a correspondência entre dados históricos e dados em memória (dados de sessão), como em mecanismos de recomendação em tempo real;
- Quando seus dados são normalizados (leia aqui consultas que têm muitos joins), com grande volume de escritas e que você precisa segregar as leituras, você pode combinar o Neo4J com outros bancos de dados é lindo! E ele tem plug-ins para te ajudar nesta tarefa (hummm que tal um post de MongoDB com Neo4J? Comenta este post dizendo o que você acha da ideia!)
Percebeu quantas vezes eu usei a palavra CONECTADO? Então… Foi só para você lembrar quando o Neo4J é extremamente poderoso.
Para finalizar o post e sem fechar o assunto…
Dando continuidade para a nossa super planilha, adicionei mais uma aba, indicando quando usar o Neo4J.
Lembre-se que a planilha é nossa, então fique à vontade para mandar suas colaborações.
Outros posts desta série
Se você quer ler os outros posts desta série, acesse os links abaixo:
- SQL ou NoSQL – Parte 1 – http://db4beginners.com/blog/sql-ou-nosql/
- SQL ou NoSQL – Parte 2: Quando usar o MongoDB http://db4beginners.com/blog/sql-ou-nosql-mongodb/
Referências
http://www.pucrs.br/ciencias/viali/graduacao/po_2/literatura/grafos/monografias/tcc1.pdf
https://rubygarage.org/blog/neo4j-database-guide-with-use-cases
Parceiros
Eu já tinha contado que o blog agora tem parceiros né? Têm uma moral para o patrocinador, que eu agradeço imensamente!
A SPEsportes, é uma loja super legal, com produtos incríveis e preço justo! Os leitores do blog tem desconto de 20% em todos os produtos, informando o cupom de desconto DB4BEGINNERS
Se a sua empresa quiser ser parceira também, temos algumas possibilidades.