NoSQL - Graph databases (Neo4J) ,ou o modelo gráfico!

For english version, please

/* Olá Senhores, senhoras e senhoritas DBAS!!!


     

     

     




Fig.1 – Modelando minha familia



     

Um nó é um objeto que possui propriedades. Exemplo: Em um e-commerce de livros, os nós podem ser Livros, Autores e

     

     

Ferramentas

      aqui. O Neo4J é uma implementação do
  
     
      A linguagem que usaremos para manipular o banco é a

Nota:





Criando um graph



     

     






   Para inserir o nó clique na aba


Inserindo nós, propriedades e listando.

  
   

   Segue código para adicionar algumas pessoas (pequena homenagem a alguns amigos visitantes)





            Logo após a ASCII Art do Gremlin o webadmin já carrega a variagel g que representa o gráfico.

Na sequencia usamos a função addVertex para adicionar o primeiro nó. (g.addVertex)
            As properties do nó são passadas como parâmetro (um JSON), que basicamente tem essa estrutura

[Nome_da_Propriedade:Valor_Da_Propriedade, ...]

É interessante notar que diferente do banco relacional que possue um schema fixo de colunas, as propriedades de cada nó podem variar, existindo ou não. Todo noSQL é schemaless.

Para listar os nós, simplesmente use g.V, onde V é a coleção de Vertices dentro do grafico g. A lista exibirá apenas os nós, voce pode pedir para exibir os nomes usando g.V.Nome, ou g.V.Qualquer_propriedade que voce_tenha criado.




Notamos que a profissão do Bruno Salim está com a grafia errada (foi de propósito, juro). Vamos fazer o update então. Note que o ID do nó dele é 28.






Simples assim. Assim como é fácil adicionar novas propriedades. Por Exemplo, no caso do Gustavo que foi adicionado sem uma profissão.





Ou adicionar uma nova propriedade que nem estava na inicialização (essa é a característica do schemaless)



     Aqui o map é uma exibição de todas as propriedades do nó em JSON 


Relacionando os nós

      Agora vamos estabelecer as relações entre os usuários atrávés do relacionamento CONHECE.





Na primeira parte atribuimos os nós a variaveis com nomes mais amigáveis, na segunda adicionamos os relacionamentos(edges) CONHECE entre eles.
Com o Gráfico criado vamos começar a responder algumas consultas típicas das redes sociais e perceber o poder do graph db.
      As consultas do Gremlin são feitas em passos divididos pelo ponto.
Objeto.passo1.passo2.passoN.propriedade
O passo usa o resultado do passo anterior e pode transforma-lo, filtra-lo ou o chamado sideeffect usado para agregações.

Então vamos as consultas!

Quem eu conheço?
      



Quem são os amigos de meus amigos?
    

     Uma forma de evitar o uso do out repetidas vezes é usando ó pasos loop, que repete o passo anterior até que a regra entre colchetes não seja mais satisfeita (no caso limitando a duas vezes o numero de iterações do loop)



Através de quem Felipe pode conhecer Gustavo?

     Essa é uma das mais interessantes propriedades dos graphs, responder esse tipo de pergunta em um modelo relacional é muito dificil e inevitavelmente geraria uma consulta muito pesada e isso seria fatal para uma aplicação web com muitos usuários. A vantagem do graph é que independentemente da quantidade de nós e iterações a resposta para essa pergunta mantém a mesma velocidade.

      
      
     A condição para o loop foi que ele não parasse enquanto não encontrasse o nó referente ao gustavo. Assim ele me apresentou dois caminhos possiveis.

     Podemos também trocar o out por uma combinação de outE (relacionamentos de saida) e inV (para obter os nós) e termos como esses nós se relacionam


     Como existem dois caminhos possiveis     Vamos remover o link entre Spigariol e Gustavo e tentar novamente 




Na primeira linha a identificação do relacionamento, 'g.E' para listar todos os edges, seguido de 'inV' para pegar os nós retornados e 'has' para filtrar aqueles com nome Gustavo. E por fim, um back(2), para exibir os resultados de dois passos atras. (voltando no E).

A remoção e novamente o comando para listar o caminho entre os dois nós.


Conclusão

Fizemos um pequeno tour sobre o que é o GraphDB, quais são as peças que você deve juntar para usá-lo e uma lab "mão na massa" de como criar, apagar e consultar os nós armazenados. Apesar de extenso, esse post está muito longe de ser um tutorial completo, para isso recomendo esse ótimo video tutorial, onde o analista Andreas Kollegger <twitter>;

Enfim obrigado por ler até aqui, se você ficou com alguma dúvida fique a vontade para me encaminhar um email, ou me siga no twitter onde sempre tento postar links e materias interessantes desse nosso maravilhoso mundo dos dados!



Abraços!

Felipe Antunes

Modelagem - NoSQL - Experimentando novos sabores - Introdução

/*
Olá senhores, senhoras e senhoritas DBAs!!!


 Recentemente recebi uma solicitação de um leitor do blog. Ele me pedia uma comparação entre o MS-SQL, Oracle e o DB2, quais são suas características, quais são suas vantagens, o que eles comem, como eles vivem, tudo isso e muito mais no Globo Reporter.

  Infelizmente, caro leitor, para uma analise desse nível eu teria que conhecer profundamente cada uma delas. E teria que ser profundamente pelo simples motivo de que na essência elas são iguais!

  Explico melhor. Tanto Oracle, MS-SQL ou MySQL são bancos de dados relacionais, todos possuem tabelas, chaves primárias e estrangeiras,índices e demais objetos relacionais. A linguagem é padrão (SQL) com acréscimos de funções para diferenciar um fornecedor do outro, mas em teoria, se você conhecer apenas o padrão ANSI já estará qualificado a trabalhar com qualquer uma delas.

  Tenho comigo também que na maioria dos casos tanto faz qual dessas ferramentas você usará, sua escolha estará mais baseada em critérios não técnicos (licenciamento, mão de obra disponível ou cultura organizacional) do que em requisitos específicos da solução que você quer prover.

  De forma que a orientação simples é: Escolha uma que tenha mercado ou aquela que a vida te impôs e fique bom nela, mais tarde e opcionalmente, você pode adicionar outra a sua bagagem e se tornar um DBA bilíngue.

  Agora se você quer ir além do DBA SQL Server e tentar ser um provedor de soluções de plataforma de dados, minha sugestão é dar uma espiadela fora do mundo relacional.

noSQL

  Não vou ficar de histórinha, pois tudo isso já está muito bem definido e explicado na Wikipedia ou em livros sobre o assunto, mas basicamente você deve entender como noSQL um grupo bem diversificado de SGBDs que não usam o modelo relacional, alguns deles, inclusive, nem mesmo possuem as propriedades ACID (atomicidade, consistencia, isolamento e durabilidade) em sua totalidade. E não é porque eles são grandes rebeldes ou querem reinventar a roda, mas sim porque eles podem responder de maneira mais eficiente alguns problemas que são “possíveis mas dolorosos” no modelo relacional.

  Existem vários tipos de bancos NoSQl (key-value, document based, graph, entre outros) e apenas uma vez vi uma solução completamente baseada em um deles, nos outros casos a combinação de SQL e NoSQL é que entregava o pacote completo.

  Estou planejando pelo menos mais um post prático ou quem sabe até uma série sobre esse tipo de banco, então não perca os próximos capítulos!

Abraços!

Felipe Antunes
twitter: @felipe_store
email: fjantunes@gmail.com