Artigo
Artigo
SQL vs NoSQL – Qual a melhor opção para armazenamento de grafos?
O volume de dados gerados e armazenados no mundo está em constante crescimento. Em estudo recente, o Instituto Gartner estimou que são criados, todos os dias, 2,2 milhões de terabytes de novos dados.
Na corrida pela extração de conhecimento desse imenso montante de dados, diversas tecnologias propõem suportar o recebimento, armazenamento e processamento das informações. Diante desse cardápio de tecnologias, é comum que as instituições tenham dúvidas sobre qual escolher. Uma boa tática para diminuir essa insegurança é a realização de estudos comparativos entre bancos de dados.
De fato, para cada modelo e tipo de dado (estruturado, não estruturado, vídeos, imagens, sons, logs etc.) é necessário analisar qual tecnologia mais se adequa aos quesitos: performance de acesso aos dados, facilidade de consulta, interoperabilidade, maturidade tecnológica etc.
Apesar dos SGBD (Sistema Gerenciador de Banco de Dados) relacionais, como PostgreSQL, Oracle, DB2, SQL server, entre outros, dominarem o mercado da Tecnologia da Informação, há uma crescente expansão de novas tecnologias de armazenamento, como os bancos de dados NoSQL (Not Only SQL), com potencial para resolver problemas que bancos tradicionais muitas vezes não são capazes.
Neste estudo, foi realizada uma análise comparativa entre duas tecnologias (PostgreSQL e Neo4J), com uma base de dados pública. A finalidade foi a de coletar indicadores sobre qual tecnologia pode ser mais apropriada para esse conjunto de dados. O experimento utilizou os dados de viagens do Sistema de Bicicletas Compartilhadas do Distrito Federal, disponibilizados no site dados.org, o Portal Brasileiro de Dados Abertos.
Seleção das ferramentas
Foram utilizadas as seguintes ferramentas: Banco de Dados o PostgreSQL, a ferramenta de ETL Talend Open Studio (para a importação no PostgreSQL) e o banco Neo4J.
O PostgreSQL é um SGBD objeto relacional amplamente utilizado e reconhecido por sua estabilidade e robustez.
Já o Neo4J é um sistema de banco de dados orientado a grafos com crescente utilização, com destaque para o uso por algumas empresas renomadas, como WalMart, Adobe, eBay, Monsanto, Microsoft e IBM. Diferentemente de outros bancos NoSQL, é compatível com as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) e possibilita a representação e o processamento de grafos de forma nativa. Está disponível para download sob licença GPL3 e possui diversas extensões licenciadas.
Nele, os dados são representados por meio de nós e arestas, que podem possuir atributos relacionados. Os nós se ligam por meio de relações que podem possuir um nome específico. Apesar de simples, essa notação é interessante, pois permite a identificação de padrões de forma visual, consulta do grau de relacionamento entre diferentes nós, entre outras qualidades.
A linguagem de programação utilizada para manipulação dos dados do Neo4J é o Cypher. Quando instalado, ele pode ser manipulado a partir de um client (disponível no site do Neo4J, como o que foi utilizado neste trabalho), via bibliotecas integradas às linguagens de programação ou por meio do terminal.
Modelagem dos dados
A base de dados de viagens feitas com as bicicletas compartilhadas do DF possui um volume interessante e informações que podem ser traduzidas como grafos. Selecionamos as viagens de bicicleta realizadas de 27 de maio a 22 de junho de 2014, totalizando 11.443 registros. Segue breve descritivo dos campos encontrados nesse conjunto de planilhas:
| Campo | Descrição |
| Gênero | Gênero do ciclista |
| Data nascimento | Data de nascimento |
| Cidade / Região Administrativa | Local onde habita originalmente o ciclista |
| Idade | Idade do ciclista |
| Data | Data e hora da retirada da bicicleta |
| Horário de devolução | Data e hora da devolução da bicicleta |
| Tempo de viagem | Tempo de viagem com a bicicleta |
| Estação de origem | Estação onde a bicicleta foi retirada |
| Estação de Destino | Estação onde a bicicleta foi devolvida |
Tabela 1 – Descritivo dos dados
A fim de possibilitar uma modelagem relacional menos trivial, a planilha de viagens foi dividida em três tabelas no banco PostgreSQL, conforme a Figura 1:
Figura 1 – Modelo relacional
Já no Neo4j, a modelagem escolhida para os grafos incluiu dois tipos de nós e dois tipos de arestas:
Nó Viajante – contém os dados do viajante, diferenciada pelo campo idviajante.
Nó Estação – contém os dados da estação, representada pelo nome da estação.
Aresta embarcou – indica a estação que o viajante embarcou.
Aresta pedalou - indica a estação até onde o viajante pedalou, a partir da estação de embarque.
Figura 2 – Modelo do Neo4J
Os campos citados na Tabela 1 foram incluídos como atributos dos nós e das arestas.
Analisamos quesitos como tempo de processamento da importação dos dados e consultas nos bancos de dados. Também avaliamos algumas vantagens qualitativas na visualização dos dados.
Importação dos dados
Para importação dos dados no PostgreSQL, foi utilizada a solução Talend. Nela criamos três jobs: carregamento da tabela estação, carregamento da tabela viajante e carregamento da tabela viagens.
Para importação no Noe4J, foi utilizado o comando LOAD CSV. Com ele é possível carregar os dados diretamente de um arquivo CSV. Adicionalmente, foi empregado o comando CREATE e MATCH para criar os nós e as arestas.
Somando o tempo de importação de cada etapa, é possível observar que o tempo de carregamento dos dados no Neo4J foi aproximadamente 30 vezes superior ao tempo de importação no PostgreSQL.
| Tempo total de importação | |
| PostgreSQL | 4,17 segundos |
| Neo4J | 129,05 segundos |
Tabela 2 – Tempo total de importação
A importação no Neo4J foi mais onerosa devido ao carregamento da relação entre os viajantes e as estações. Nessa etapa, foi necessário selecionar viajantes, selecionar estações de origem e de destino e, com esses dados, criar as relações de “embarcou” e “pedalou”. A diferença entre os tempos é justificada pelo fato de que o Neo4J possui um paradigma de modelagem muito diferente do PostgreSQL e sua importação não é uma operação trivial, visto que o carregamento das relações envolve etapas distintas.
Consultas
Para analisar os diferenciais entre as consultas no PostgreSQL e no Neo4J, foram selecionados seis consultas diferentes e executadas nos dois bancos, cada um com suas linguagens específicas. Coletamos o tempo da execução e alguns resultados que apontam diferenciais entre os bancos.
| Consulta | Tempo (milissegundos) | |
| PostgreSQL | Neo4J | |
| Consulta 1: Selecionar todos registros | 1400 | 60502 |
| Consulta 2: Contar todos registros | 89 | 17 |
| Consulta 3: Todas viagens realizadas por pessoas do sexo feminino | 377 | 50850 |
| Consulta 4: Todos que pedalaram até a estação Rodoviária | 451 | 15010 |
| Consulta 5: Lista das estações por quantidade de embarques | 64 | 45 |
| Consulta 6: Lista das estações de destino por quantidade | 61 | 75 |
Tabela 3 – Resultados das consultas
É alto o tempo de processamento para plotagem do grafo no Neo4J. Com isso, para este artigo, foi considerado como o tempo de processamento o tempo entre a requisição da consulta e a montagem inicial dos grafos com nós e arestas, mesmo que o computador demore mais para finalizar o carregamento visual dos grafos.
No PostgreSQL, todas essas consultas retornaram tabelas, sendo que a segunda consulta retornou apenas a quantidade de registros.
Já no Neo4J, as consultas 1, 3 e 4 retornaram gráficos plotados. Foi possível observar que, nesses casos, o tempo gasto para retorno dos dados foi superior ao tempo de retorno do PostgreSQL. As demais consultas do Neo4J, que não envolveram plotagem de grafos, concorreram bem com o PostgreSQL, sendo que em duas (consultas 2 e 5) obtiveram tempos de processamento melhores.
Comparativo entre a visualização dos resultados
Como estamos comparando um banco relacional a um orientado a grafos, é interessante avaliar aspectos qualitativos relacionados à visualização dos dados armazenados.
Nos bancos relacionais há uma dificuldade de visualização de dados que envolvam relacionamentos entre as entidades, pois essas informações estão dispostas em “listas” que podem ser extensas. No Neo4J, há o grande diferencial de visualização dos dados em grafos. Com esse recurso, podem-se tomar conclusões, observar tendências e analisar comportamentos, sem a necessidade de consulta individual aos dados.
Para dar visibilidade a essa diferenciação, foram consultados todos os ciclistas do sexo Masculino que embarcaram na estação Rodoviária 3. Este foi o resultado nos diferentes bancos:
PostgreSQL:
Neo4J:
Visualmente, o gráfico do Neo4J ficou mais intuitivo do que a tabela. Sem realizar totalizações, é possível observar que alguns ciclistas embarcaram na estação Rodoviária 3 e retornaram para a mesma estação, enquanto outros se deslocaram até outras cinco estações diferentes.
Para ilustrar o potencial do Neo4J, foi gerado também um gráfico da consulta de todas as Mulheres que pedalaram até o Ministério da Defesa:
Conclusão
O teste de comportamento de um conjunto de informações em diferentes bancos de dados é de extrema importância para a definição tecnológica e arquitetural dos sistemas de Big Data. Nesses testes, é possível coletar dados objetivos e informações relevantes para evitar erros nessa definição, causando problemas futuros nas aplicações.
Nesse trabalho, foi observado que a escolha de um banco de dados orientado a grafos pode ser indicada quando se analisam dados sobre movimentações e relacionamentos. Sobre o banco Neo4J, concluímos que a solução apresentou bons resultados nas consultas. Os tempos necessários para plotagem dos dados podem ser diminuídos consideravelmente em uma arquitetura mais robusta, que use componentes mais eficientes, como SDKs e equipamentos mais performáticos.
O banco PostgreSQL apresentou ótima performance e facilidade de importação e consultas, entretanto, dada sua natureza relacional, não é a melhor escolha para visualização dessa base de dados.
A habilidade de testar e comparar diferentes bancos de dados é indispensável para as empresas de TI. Com determinada frequência, realizamos esses testes com dados reais em situações de trabalho e a variedade de bancos NoSQL disponíveis no mercado leva à necessidade de sempre testar e verificar novos paradigmas.
Loreane Evelyn Nazareth Brandizzi é pós-graduada em Gestão Estratégica de TI pela FGV e graduada em Computação pela Universidade de Brasília. Atualmente é aluna da Pós-graduação em Big-data e Analytics, na FACSENAC.Trabalha no Serpro desde 2011 como analista de negócios, e hoje atua como consultora de negócios na Superintendência de Relacionamento com o Cliente Ministério da Economia.