UNIVERSIDADE DE RIBEIRÃO PRETO
CENTRO DE CIÊNCIAS EXATAS, NATURAIS E TECNOLÓGICAS
PÓS-GRADUAÇÃO LATO SENSU EM BANCO DE DAD...
CRISTIANE BRANDÃO COBO
NoSQL: Características e Aplicações
Monografia apresentada ao Centro de Ciências
Exatas, Naturais e...
Ficha catalográfica preparada pelo Centro de Processamento Técnico
da Biblioteca Central da UNAERP
- Universidade de Ribei...
FOLHA DE APROVAÇÃO
Cristiane Brandão Cobo
NoSQL: Características e Aplicações
Monografia apresentada ao Centro de Ciências...
DEDICATÓRIA
Aos meus amados pais, que com muito amor e
paciência me deram todo o apoio necessário
para que eu obtivesse ta...
AGRADECIMENTOS
Agradeço à minha querida amiga, Prof. Daniella, por ter me acompanhado durante todo o
curso, inclusive dura...
RESUMO
Esta monografia aborda o NoSQL, banco de dados não relacional, que tem como pontos
principais a escalabilidade que ...
ABSTRACT
This monograph will address the NoSQL, non-relational database, whose main points are the
scalability which incre...
SUMÁRIO
1 INTRODUÇÃO
1.1 OBJETIVO
1.2 ESTRUTURA DA MONOGRAFIA
2 REVISÃO DE LITERATURA
2.1 CONCEITO DE NOSQL
2.2 NOSQL X BA...
LISTA DE FIGURAS
Figura 1 – Quadrante Mágico do Gardner
Figura 2 – Empresas Consumidoras do MongoDB.
Figura 3 – Empresas C...
LISTA DE SIGLAS
ACID Atomicidade, Consistência, Isolamento e Durabilidade
API Application Programming Interface (Interface...
10
1 INTRODUÇÃO
Os bancos de dados relacionais tem sido a escolha padrão para o armazenamento
de dados, mas depois de um l...
11
Figura 1 – Quadrante Mágico do Gardner
Fonte: Disponível em: <https://www.mongodb.com/lp/misc/gartner-mq-op-db-report>
...
12
No segundo capítulo, será efetuado um breve comparativo entre NoSQL e os
bancos de dados relacionais para que o entendi...
13
2 REVISAO DE LITERATURA
2.1 CONCEITO DE NOSQL
O termo NoSQL (Not only SQL - Não só SQL) vem do conceito de que o banco
...
14
2.2 NOSQL X BANCO DE DADOS RELACIONAIS
Um dos pontos de contraste entre os NoSQL e os bancos de dados relacionais é o
s...
15
2.3 CARACTERÍSTICAS DO NOSQL
2.3.1 Escalabilidade
Escalabilidade é uma característica desejável em todo sistema, que in...
16
maneira, pode-se facilmente distribuir a execução de uma consulta em diversos nós. Porém, se
um dos servidores utilizad...
17
Cada computador que faz parte do cluster recebe o nome de nó. Teoricamente,
não há limite máximo de nós, mas independen...
18
O modelo Map-Reduce oferece apenas uma interface entre a implementação de
um sistema distribuído e o usuário desse sist...
19
De acordo com Saladage e Fowler (2013), os bancos de dados no esquema
chave/valor são indicados para armazenamento de i...
20
Para esses casos onde se quer otimizar a leitura de dados estruturados, bancos de
dados de famílias de colunas são mais...
21
os dados propriamente ditos. O modelo orientado a grafos possui três componentes básicos:
os nós (são os vértices do gr...
22
Ao longo dos anos, temos estudado e registrado através de mapas ou cartas de
dados sobre o relevo, fauna, rotas comerci...
23
2.6 EXEMPLOS REAIS DE UTILIZAÇÃO
Serão exemplificadas, a seguir, três empresas consumidoras de cada um dos
bancos de da...
24
Com uma grande quantidade de aplicações integradas ao MongoDB, os usuários
podem personalizar as suas experiências atra...
25
Para atender melhor as expectativas de seus clientes, a Expedia decidiu oferecer
uma melhor forma de planejamento de vi...
26
Os ricos índices do MongoDB são utilizados para poderosas análises que fazem
sugestões personalizadas para usuários enq...
27
Com apenas um engenheiro trabalhando em tempo integral e outro trabalhando
meio período, o time de desenvolvimento de a...
28
2.6.2 Neo4j
2.6.2.1 InfoJobs
Objetivo: Desenvolver o Portal de Plano de Carreira para identificar os passos e
experiênc...
29
O Neo4j é usado como base de dados para armazenar toda a informação estática e
as informações são atualizadas uma vez p...
30
Como Marcos explicou: "Um banco de dados relacional não estava satisfazendo
nossas necessidades sobre o desempenho e si...
31
serviço de entrega local, está atualmente disponível em quatro mercados norte-americanos,
com planos de expansão para 2...
32
O Neo4j foi selecionado pela sua flexibilidade, velocidade e facilidade de
utilização. E pelo seu modelo de propriedade...
33
Fonte: Elaborada pela autora a partir de informações disponíveis no site oficial do Neo4J, na
sessão de Consumidores.
34
3 MATERIAIS E MÉTODOS
Nesta sessão será apresentado como o NoSQL funciona na prática. Este
desenvolvimento foi baseado ...
35
- Elaboração e inclusão dos scripts de inserção de dados de teste no PostgreSQL;
- Desenvolvimento de página de análise...
36
Figura 5 – Tela de criação de nova postagem
Fonte: Elaborada pela autora.
- Sair da aplicação
A seguir será exibida a t...
37
Fonte: Elaborada pela autora.
38
4 RESULTADOS E DISCUSSÃO
Na aplicação de Blogs, citada na sessão anterior, podemos também comparar e
observar as difere...
39
Figura 8 – Modelo relacional da aplicação de blogs
Fonte: Elaborada pela autora a partir de informações disponíveis no ...
40
Figura 9 – Exemplo de representação de dados da aplicação de blogs no MongoDB
Fonte: Elaborada pela autora a partir de ...
41
1- Recuperar os dados da tabela de postagens fazendo junção com a tabela de
usuários para recuperar também o nome do au...
42
Comprar um carro não é uma tarefa fácil. A pessoa quer um carro que não seja
muito caro, tenha uma grande aceleração, p...
43
Nas últimas décadas, o desenvolvimento tecnológico tem sido rápido e
progressivo. Logo, é importante que os profissiona...
44
5 CONCLUSÃO
Durante o desenvolvimento deste trabalho foi apresentado que os bancos NoSLQ
se caracterizam principalmente...
45
REFERÊNCIAS
ALECRIM, Emerson. (2013). Cluster: conceito e características. Disponível em:
<http://www.infowester.com/cl...
Próximos SlideShares
Carregando em…5
×

Cobo, Cristiane Brandão. Especialização Banco de Dados

297 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
297
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Cobo, Cristiane Brandão. Especialização Banco de Dados

  1. 1. UNIVERSIDADE DE RIBEIRÃO PRETO CENTRO DE CIÊNCIAS EXATAS, NATURAIS E TECNOLÓGICAS PÓS-GRADUAÇÃO LATO SENSU EM BANCO DE DADOS CRISTIANE BRANDÃO COBO NoSQL: Características e Aplicações Ribeirão Preto 2015
  2. 2. CRISTIANE BRANDÃO COBO NoSQL: Características e Aplicações Monografia apresentada ao Centro de Ciências Exatas, Naturais e Tecnológicas da Universidade de Ribeirão Preto como parte dos requisitos para obtenção do título de Especialista em Banco de Dados. Orientador: Prof. Dr. Rinaldo Macedo de Morais Ribeirão Preto 2015
  3. 3. Ficha catalográfica preparada pelo Centro de Processamento Técnico da Biblioteca Central da UNAERP - Universidade de Ribeirão Preto - Cobo, Cristiane Brandão, 1983- C657n NoSQL - Características e Aplicações / Cristiane Brandão Cobo. - - Ribeirão Preto, 2015. 45f. : il. color. Orientador: Prof. Dr. Rinaldo Macedo Morais. Monografia (especialização) - Universidade de Ribeirão Preto, UNAERP, Banco de dados. Ribeirão Preto, 2015. 1. Banco de dados. 2. NoSQL. 3. Big data. I. Título. CDD 005.1
  4. 4. FOLHA DE APROVAÇÃO Cristiane Brandão Cobo NoSQL: Características e Aplicações Monografia apresentada ao Centro de Ciências Exatas, Naturais e Tecnológicas da Universidade de Ribeirão Preto como parte dos requisitos para obtenção do título de Especialista em Banco de Dados. Orientador: Prof. Dr. Rinaldo Macedo de Morais Aprovada em: 22/08/2015 Banca Examinadora Prof. Dr. Rinaldo Macedo de Morais Instituição: Universidade de Ribeirão Preto – UNAERP Prof. Dr. Edilson Carlos Caritá Instituição: Universidade de Ribeirão Preto – UNAERP Prof. Marco Aurélio Arantes Instituição: Universidade de Ribeirão Preto – UNAERP
  5. 5. DEDICATÓRIA Aos meus amados pais, que com muito amor e paciência me deram todo o apoio necessário para que eu obtivesse tantas conquistas. À minha querida avó, pelo carinho, pelos conselhos, elogios e puxões de orelha. Aos meus primos, tios e amigos, pelos momentos de alegria, descontração e constante torcida pela minha realização.
  6. 6. AGRADECIMENTOS Agradeço à minha querida amiga, Prof. Daniella, por ter me acompanhado durante todo o curso, inclusive durante o desenvolvimento deste trabalho, me aconselhando, orientando, com toda paciência, carinho e atenção. Aos professores do curso de Especialização em Banco de Dados, pela dedicação ao ministrar as aulas com tanto amor. Ao meu orientador, Rinaldo Macedo de Morais, pelo apoio e atenção no desenvolvimento deste trabalho. Aos colegas de sala, pela receptividade e por terem sido tão prestativos me oferecendo suporte com o material de metodologia científica.
  7. 7. RESUMO Esta monografia aborda o NoSQL, banco de dados não relacional, que tem como pontos principais a escalabilidade que aumenta sua velocidade e capacidade de armazenamento de dados, a simplicidade de desenvolvimento e manutenção e a ausência de um esquema pré definido. Atualmente, ele está em grande desenvolvimento e utilização. Grandes empresas conhecidas mundialmente, como o Google, Amazon, Twitter, Facebook, Ebay e LinkedIn fazem uso desse tipo de banco. Assim, apresentar sua aplicação, bem como suas principais características e a importância de os profissionais da área de TI obterem conhecimento sobre ele, são objetivos desse trabalho. Para isso foi efetuada uma pesquisa bibliográfica sobre o tema e suas aplicações, bem como consultas sobre sistemas reais de utilização em sites de alguns fabricantes de bancos de dados não relacionais. Foi também desenvolvida uma aplicação de Blogs simples, utilizando o MongoDB, apenas para mostrar como funciona seu desenvolvimento. O PostgreSQL, banco de dados relacional, foi utilizado para comparação de desempenho caso fosse necessário implementar futuramente consultas que envolvessem um volume maior de dados, em que neste caso o MongoDB respondeu mais rapidamente e a complexidade de desenvolvimento foi reduzida. Sendo assim, foi sugerido que os atuais profissionais de TI necessitam de conhecimento sobre o assunto para que, ao se depararem com novos requisitos de desenvolvimento, possam avaliar a viabilidade de utilização do NoSQL, bem como, para que continuem no mercado de trabalho, visto que diversas empresas estão adotando este tipo de bancos de dados no desenvolvimento de seus sistemas. Palavras chave: Banco de dados. NoSQL. Não relacional. Big data.
  8. 8. ABSTRACT This monograph will address the NoSQL, non-relational database, whose main points are the scalability which increases its speed and storage capacity, the ease of development and maintenance and the absence of a pre-defined schema. Currently, it is in great development and use. Large companies known worldwide, such as Google, Amazon, Twitter, Facebook, Ebay and LinkedIn make use of this type of data base. Thus, present its application, as well as its main characteristics and the importance of the IT professionals gain knowledge about it are goals of this work. To achieve these goals, was made a bibliographic research on the subject and its applications, as well as searches on some manufacturers of non-relational databases’s sites to find systems that currently use the NoSQL. A simply Blogs application was also developed using MongoDB, just to show how its development works. PostgreSQL is the relational database that was used to compare performance if in the future would be necessary to implement queries that involve a larger volume of data, in which case MongoDB responded faster and the development complexity was reduced. Thus, it was suggested that today's IT professionals need to know about it so, when faced with new development requirements, they will be able to evaluate the feasibility of using NoSQL as well, to continue in the job market, as that many companies are adopting this kind of databases in their systems development. Keywords: Data base. NoSQL. Non-relational. Big data.
  9. 9. SUMÁRIO 1 INTRODUÇÃO 1.1 OBJETIVO 1.2 ESTRUTURA DA MONOGRAFIA 2 REVISÃO DE LITERATURA 2.1 CONCEITO DE NOSQL 2.2 NOSQL X BANCO DE DADOS RELACIONAIS 2.3 CARACTERÍSTICAS DO NOSQL 2.3.1 Escalabilidade 2.3.2 Schemaless 2.3.3 Clusterização 2.3.4 Map-Reduce 2.4 TIPOS DE BANCO DE DADOS NOSQL 2.4.1 Bancos de Dados no Esquema Chave/valor (key/value) 2.4.2 Bancos de Dados Orientados a Documentos 2.4.3 Bancos de Dados de Famílias de Colunas 2.4.4 Bancos de Dados de Grafos 2.5 GEOPROCESSAMENTO EM BANCOS DE DADOS NOSQL 2.6 EXEMPLOS REAIS DE UTILIZAÇÃO 2.6.1 MongoDB 2.6.1.1 The Weather Channel 2.6.1.2 Expedia 2.6.1.3 Forbes 2.6.2 Neo4j 2.6.2.1 InfoJobs 2.6.2.2 Walmart 2.6.2.3 Ebay 3 MATERIAIS E MÉTODOS 4 RESULTADOS E DISCUSSÃO 5 CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS
  10. 10. LISTA DE FIGURAS Figura 1 – Quadrante Mágico do Gardner Figura 2 – Empresas Consumidoras do MongoDB. Figura 3 – Empresas Consumidoras do Neo4J Figura 4 – Tela de visualização de postagens Figura 5 – Tela de criação de nova postagem Figura 6 – Tela de análise de desempenho Figura 7 – Modelo relacional da aplicação de blogs Figura 8 – Exemplo de representação de dados da aplicação de blogs no MongoDB Figura 9 – Resultados das consultas na aplicação de blogs
  11. 11. LISTA DE SIGLAS ACID Atomicidade, Consistência, Isolamento e Durabilidade API Application Programming Interface (Interface de Programação de Aplicativos) BASE Basic Availability, Soft state, Eventual consistency (Basicamente disponível, Estado leve, Eventualmente consistente) CAP Consistency, Availability, and Partition tolerance (Consistência, Disponibilidade, Tolerância a falhas) CMS Custom Management System (Sistema de Gerenciamento de Conteúdo) DBMS Database Management System (Sistema de Gerenciamento de Banco de Dados) ETL Extract Transform Load (Extração Transformação Carga) JSON JavaScript Object Notation (Notação de Objeto JavaScript) NoSQL Not Only SQL (Não só SQL) OLAP Online Analytical Processing (Processamento Analítico em Tempo Real) OLTP Online Transaction Processing (Processamento de Transações em Tempo Real) RAM Random Access Memory (Memória de Acesso Aleatório) RDBMS Relational Database Management System (Sistema Relacional de Gerenciamento de Banco de Dados) SOA Service-oriented architecture (Arquitetura Orientada a Serviços) SQL Structured Query Language (Linguagem Estruturada de Consulta) TI Tecnologia da Informação XML eXtensible Markup Language (Linguagem de Marcação Extensível)
  12. 12. 10 1 INTRODUÇÃO Os bancos de dados relacionais tem sido a escolha padrão para o armazenamento de dados, mas depois de um longo período de total dominância, há cerca de uma década, com o surgimento de grandes aplicações web necessitando de manipulação de dados em grande escala surgiram os bancos de dados NoSQL que vieram pra suprir em demandas onde os bancos de dados relacionais não são tão eficientes. Alguns bancos de dados NoSQL possuem linguagens de consulta similares ao SQL, tornando-o assim mais fácil de aprender. O resultado mais importante da ascensão do NoSQL é a persistência poliglota, ou seja, o uso de mais de um banco de dados em uma mesma aplicação, em que os bancos deixam de ser o gargalo, e se transformam na principal solução e pode elevar muito o nível de maturidade de qualquer aplicação, independente de sua natureza. A maioria dos NoSQL são open-source, característica do MongoDB, principal banco de dados utilizado neste trabalho para exemplificações do funcionamento do NoSQL. O MongoDB é um banco de dados não relacional que armazena os dados usando um modelo de documento de dados flexível de estrutura semelhante ao JSON. Os documentos contém um ou mais campos incluindo arrays, dados binários e sub-documentos. Os campos podem variar de documento a documento. Para acessar os documentos, existem drivers disponíveis na maioria das linguagens de programação. O MongoDB possui o auto-sharding para escalonamento horizontal e replicação nativa, fazendo uso extensivo de RAM, proporcionando velocidade na memória e capacidade em disco. Ele também fornece índices secundários abrangentes, incluindo geoespaciais e de pesquisa de texto, bem como extensas capacidades de segurança e de agregação. Em 2014, o MongoDB foi avaliado como challenger, competidor, tradução minha, pelo Gardner, uma das maiores empresas de auditoria, avaliação e análise de mercado em todo o mundo, que gera dados e números que influenciam tomadas de decisões importantes em vários pontos do globo, no que se trata de investimentos e desenvolvimento de novas soluções.
  13. 13. 11 Figura 1 – Quadrante Mágico do Gardner Fonte: Disponível em: <https://www.mongodb.com/lp/misc/gartner-mq-op-db-report> Acesso em Agosto. 2015. Por essas características, este foi o banco escolhido para a maioria das exemplificações deste trabalho. 1.1 OBJETIVO O objetivo desse trabalho é apresentar as principais características do banco de dados não relacional – NoSQL, sua aplicação e pontuar a importância de os profissionais da área de TI obterem conhecimento sobre esse tipo de banco de dados. 1.2 ESTRUTURA DA MONOGRAFIA No primeiro capítulo da revisão de literatura será apresentado o conceito de NoSQL, um resumo do seu surgimento e serão citadas algumas de suas características.
  14. 14. 12 No segundo capítulo, será efetuado um breve comparativo entre NoSQL e os bancos de dados relacionais para que o entendimento do NoSQL seja mais facilmente compreendido, nele, será também brevemente explicado, sobre as transações ACID que são a base para o sistema de bancos de dados relacionais, e sobre o BASE e Teorema CAP citados, por vários autores como fundamentação dos bancos de dados não relacionais. No terceiro capítulo, serão abordadas as características do NoSQL, entre elas, escalabilidade: vertical, horizontal, replicação e sharding, e também será explicado sobre schemaless, clusterização e map-reduce. No quarto capítulo, serão apresentados os tipos de bancos de dados NoSQL, suas descrições, principais características e exemplos de bancos de dados que os utilizam. Entre estes exemplos, foram escolhidos alguns para serem descritos brevemente. Os tipos de bancos NoSQL são: bancos de dados no esquema chave/valor, orientados a documentos, famílias de colunas e de grafos. No quinto capítulo, será abordado sobre o geoprocessamento em bancos de dados NoSQL e citados alguns exemplos. No sexto capítulo, serão apresentados alguns exemplos reais de utilização, para esta apresentação foram escolhidos o The Weather Channel, Expedia e Forbes, que são algumas das empresas consumidoras do MongoDB e o InfoJobs, Walmart e Ebay, consumidores do Neo4J. MongoDB e o Neo4J são bancos de dados muito utilizados atualmente, sendo o primeiro um banco de dados orientado a documentos e o segundo, banco de dados de grafos. E as empresas consumidoras escolhidas são populares e mundialmente reconhecidas. Na sessão de materiais e métodos, uma aplicação de blogs desenvolvida na linguagem Java juntamente com MongoDB será utilizada como exemplo para abordagem prática do NoSQL. Nesta abordagem será exibido um esquema relacional desta aplicação e uma exemplificação de armazenamento dos dados no MongoDB para comparação juntamente com um exemplo de consulta. Em seguida, os resultados de desempenho de consultas realizadas na aplicação de blogs utilizando o MongoDB e PostgreSQL serão exibidos e, na discussão, será abordada a importância dos profissionais de TI obterem conhecimento sobre o NoSQL. Por fim, a conclusão do trabalho com observações sobre o desenvolvimento e resultados obtidos.
  15. 15. 13 2 REVISAO DE LITERATURA 2.1 CONCEITO DE NOSQL O termo NoSQL (Not only SQL - Não só SQL) vem do conceito de que o banco de dados não necessita de normalização e relacionamentos (GONDIM, 2013), ou seja, não segue normas de tabelas (esquemas) determinadas previamente. Foi inicialmente utilizado, em 1998, como o nome de um banco de dados não relacional de código aberto, criado por Carlos Strozzi, que acabou alegando que o movimento NoSQL ”é completamente distinto do modelo relacional e portanto deveria ser mais apropriadamente chamado "NoREL" ou algo que produzisse o mesmo efeito”. A partir de então, NoSQL passou a ser utilizado para designar os bancos de dados não relacionais. Os bancos de dados NoSQL, possuem características muito interessantes como alta performance, escalabilidade, replicação, suporte a dados estruturados e sub colunas. Surgiram da necessidade de uma alta escalabilidade e performance superior, pois os atuais bancos de dados relacionais são muito restritos a isso por utilizarem, em sua maioria, a distribuição vertical de servidores, ou seja, quanto mais dados, mais memória e mais disco um servidor precisa. O NoSQL tem uma grande facilidade na distribuição horizontal, ou seja, mais dados, mais servidores, não necessariamente de alta performance. O Google é um grande utilizador desse conceito, que usa computadores de pequeno e médio porte para a distribuição dos dados, pois essa forma de utilização é muito mais econômica e eficiente. Pode-se dizer que NoSql apresenta um padrão de armazenamento de dados alternativo ao relacional, oferecendo melhor robustez e escalabilidade para alguns tipos de sistemas. Cabe ainda destacar que os bancos de dados NoSQL possuem a característica de poder trabalhar com dados crus vindos de diversas origens (arquivos de log, web-sites, arquivos multimídia, entre outros) ou até mesmo dados semi-estruturados e são também muito tolerantes a erros. No entanto, os bancos de dados NoSQL não têm como objetivo substituir os bancos de dados relacionais, mas apenas propor algumas soluções que em determinados cenários são mais adequadas, tais como: escalabilidade, capacidade de armazenamento, gerenciamento de grandes volumes de dados e baixa latência.
  16. 16. 14 2.2 NOSQL X BANCO DE DADOS RELACIONAIS Um dos pontos de contraste entre os NoSQL e os bancos de dados relacionais é o suporte a transações ACID (ELSMARI e NAVATHE, 2005), que são o foco dos RDBMS tradicionais: - Atomicidade: A transação será executada totalmente ou não será executada. - Consistência: Uma transação não pode deixar a base de dados em um estado inconsistente. - Isolamento: Uma transação não pode interferir em outra. - Durabilidade: Garante que o que foi salvo não será mais perdido, mesmo após a aplicação reiniciar. Segundo Gaurav Vaish (2013), muitos NoSQLs simplesmente não oferecem este recurso, considerado dispensável em algumas aplicações, principalmente pelo custo computacional envolvido para provê-las. Sendo assim, ao invés de manter o foco no ACID, o NoSQL é mais propenso a seguir um teorema chamado BASE, citado pelo cientista da computação Eric Brewer: • Basic availability (Basicamente disponível): Uma aplicação funciona basicamente todo o tempo e uma resposta é sempre garantida para toda requisição, seja de sucesso ou falha. • Soft state (Estado leve): O estado do sistema pode alterar ao longo do tempo, não precisa ser consistente o tempo todo. • Eventual consistency (Eventualmente consistente): A base de dados pode ser momentaneamente inconsistente, mas consistente eventualmente, ou seja, o sistema torna-se consistente no momento necessário. Eric Brewer também defende o teorema CAP que diz “que é impossível para um sistema de computador distribuído fornecer consistência, disponibilidade e tolerância ao particionamento simultaneamente”. Sendo assim, pode-se entender que para sistemas onde transações são críticas, como bolsa de valores ou bancários o NoSql definitivamente não é uma solução viável, mas é totalmente indicado para sites de busca ou redes sociais, aplicações que irão trabalhar com enormes quantidades de dados, que tem exigências de velocidade em suas consultas e escritas em grande volumes.
  17. 17. 15 2.3 CARACTERÍSTICAS DO NOSQL 2.3.1 Escalabilidade Escalabilidade é uma característica desejável em todo sistema, que indica sua habilidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar preparado para crescer. Em banco de dados, existem duas formas de escalabilidade em que de acordo com Veras (2011): Vertical: significa adicionar recursos em um único nó do sistema (mais memória ou um disco rígido mais rápido). Horizontal: significa adicionar mais nós ao sistema, tais como um novo computador com uma aplicação para clusterizar o software. Os NoSQL estão sendo projetados desde o início para atender a uma maior escalabilidade horizontal, isto é, fazer com que a adição de novas máquinas ajudem a melhorar o desempenho do sistema de forma linear. Este tipo de escalabilidade contrasta com a vertical, onde um servidor precisa ser substituído por outro mais potente para aumentar a capacidade computacional do sistema. Desta forma, pode-se observar que a horizontal possui menor custo de expansão. Replicação é conhecida como um meio de conseguir escalabilidade que consiste em armazenar cópias dos dados em mais de um lugar. É tradicionalmente implementada através da criação de uma estrutura master-slave. O banco master é aquele onde são efetuadas as alterações que são, então, replicadas para o slave. Com isso, as consultas podem ser executadas agora não só em um, mas em dois nós. Quando as máquinas se sobrecarregarem de consultas, cria-se um novo nó slave que permite aliviar o trabalho das primeiras. Em uma arquitetura comum, onde o banco funciona no esquema master-slaves baseado em replicação, todos os dados estão contidos em todos os nós: a consistência é mantida. Se um nó de leitura parar de funcionar, não tem problema para as consultas, pois todos os outros nós são capazes de responder a elas. Mas se o master falhar, as atualizações não funcionam. Sharding (decomposição) é outra forma de escalar que consiste em dividir a localização física dos dados, despedaçando-os e colocando seus pedaços em nós distintos. A escolha de como dividir esses dados é dada através de um algoritmo de Sharding. Dessa
  18. 18. 16 maneira, pode-se facilmente distribuir a execução de uma consulta em diversos nós. Porém, se um dos servidores utilizados nesse Sharding ficar momentaneamente fora do ar, os dados ficarão indisponíveis. Outro problema pode ocorrer quando uma consulta buscar dados em um nó e esse resultado envolver executar consultas em outros nós distintos de acordo com cada resultado original e causar lentidão. Por isso, decidir o algoritmo de Sharding deve depender das consultas a serem executadas a fim de fazer essa distribuição da melhor forma possível. Visto estes dois tipos de escalabilidade, uma das melhores soluções é misturar o sharding com replicação, ganhando maior disponibilidade e deixando ao algoritmo a decisão de quais nós conterão determinados dados. Mas este é um cenário de alta complexidade e, por isso mesmo, todo cuidado deve ser tomado para só ser adotado quando realmente necessário. Alguns sistemas NoSQL, como o “Cassandra”, o “Dynamo”, entre outros, suportam este cenário pois são descentralizados, ou seja, os dados encontram-se replicados por várias máquinas, e cada uma delas é autônoma, sendo capaz de responder a qualquer consulta, fazendo com que a disponibilidade do sistema aumente, uma vez que não existe um único ponto capaz de comprometer o seu funcionamento. Esta é uma característica que contrasta com a maior parte das implementações relacionais, onde, geralmente, é empregado somente um modelo master/slave. 2.3.2 Schemaless Schemaless ou esquema-free significa, segundo Martin Fowler (2013), “não ter que definir esquemas”, ou seja, a base de dados permite que qualquer dado estruturado com campos e estruturas individuais sejam armazenados, sendo assim, podem ser armazenados todos os dados sem uma definição prévia. 2.3.3 CLUSTERIZAÇÃO De acordo com Alecrim (2013), Cluster é o nome dado a um sistema que relaciona dois ou mais computadores para que estes trabalhem de maneira conjunta no intuito de processar uma tarefa. Estas máquinas dividem entre si as atividades de processamento e executam este trabalho de maneira simultânea.
  19. 19. 17 Cada computador que faz parte do cluster recebe o nome de nó. Teoricamente, não há limite máximo de nós, mas independentemente da quantidade de máquinas que o compõe, o cluster deve ser "transparente", ou seja, deve ser visto pelo usuário ou por outro sistema que necessite deste processamento como um único computador. Assim, técnicas de clusterização procuram semelhanças e diferenças num conjunto de dados e agrupam os registros semelhantes em clusters de uma forma automática, de acordo com algum critério ou métrica. Não é necessário definir os grupos nem os atributos que devem ser utilizados para segmentar o conjunto de dados. 2.3.4 Map-Reduce Map-Reduce consiste no framework e modelo de programação introduzido pela Google, inspirado nas funções map e reduce que trabalham a partir dessas duas fases. O modelo Map-Reduce é uma abstração criada para oferecer aos implementadores uma interface que seja poderosa e, ao mesmo tempo, simples, separando os problemas a serem resolvidos dos problemas de paralelização, buscando uma uniformidade na abordagem dessas questões de paralelismo. Assim, o Map-Reduce utiliza conceitos da programação funcional para criar a abstração em que o usuário deve programar duas funções, map e reduce, que servirão de interface para uma implementação no sistema distribuído que poderá paralelizar a execução dessas funções com balanço de carga, tolerância a falhas ou qualquer outra propriedade que o implementador do sistema distribuído decidir que é importante. As funções map e reduce funcionam da seguinte forma: map (chave, valor): recebe um par de entrada de chave e valor e produz um conjunto intermediário de chaves e valores. Reduce (chave, valores): recebe uma entrada chave e um conjunto de valores relacionados àquela chave. Assim, a implementação do Map-Reduce recebe um conjunto inicial de pares chave e valor e invoca a função map para cada par. Depois, a implementação cria listas, onde cada uma contém todos os valores intermediários (produzidos quando a função map é invocada) que estão associados à mesma chave intermediária e chama a função reduce para cada chave intermediária e a lista associada àquela chave intermediária.
  20. 20. 18 O modelo Map-Reduce oferece apenas uma interface entre a implementação de um sistema distribuído e o usuário desse sistema. Por isso, o sucesso do modelo depende de uma construção satisfatória de um sistema distribuído que atenda às expectativas de oferecer uma execução das funções map e reduce. Além disso, ainda devem ser adicionadas propriedades e atividades como protocolos de comunicação entre processos, tolerância a falhas, sistemas de arquivos, entre outras. Existem várias implementações diferentes para o modelo Map-Reduce. É na implementação que devem ser resolvidas as questões relativas à paralelização, como a exclusão mútua e a sincronização. Uma boa realização depende também do ambiente onde ela será executada: máquinas muito velozes conectadas por uma rede muito lenta requerem uma implementação diferente de um cluster de máquinas mais lentas conectadas por uma rede muito veloz. O modelo Map-Reduce traz, de forma simples, uma abordagem para lidar com problemas de computação distribuída. Sua eficácia reside, justamente, no fato de ele ser capaz de separar, de forma pouco complexa, as peculiaridades de cada problema das complicações de operar um sistema distribuído. Por ser simples, o Map-Reduce é um modelo fácil de usar por programadores que não têm experiência com sistemas distribuídos, já que a implementação dele encapsula a paralelização. 2.4 TIPOS DE BANCO DE DADOS NOSQL Há vários tipos de armazenamento NoSQL disponíveis. Nas sessões subseqüentes serão explorados os principais tipos de armazenamento. 2.4.1 Banco de Dados no Esquema Chave/Valor (Key/Value) Esse é o tipo de banco de dados NoSQL mais simples, o conceito dele é uma chave e um valor para essa chave. É também conhecido como tabela de hash dos bancos NoSql, este é o tipo que aguenta mais carga de dados e possui maior escalabilidade. Alguns bancos que utilizam esse padrão são: DynamoDb, Couchbase, Riak, Azure Table Storage, Redis, Tokyo Cabinet, Oracle Berkeley DB, Project Voldemort, MemcacheDB, SimpleBD, LevelDB, HBase etc.
  21. 21. 19 De acordo com Saladage e Fowler (2013), os bancos de dados no esquema chave/valor são indicados para armazenamento de informações de sessão, perfis e preferências de usuários, e dados de carrinhos de compras. E não são indicados quando relacionamento entre diferentes tipos de dados são necessários, ou então à necessidade de correlacionar os dados entre diferentes conjuntos de chave, também não são indicados em transações com múltiplas operações, consulta por dados e operações por conjuntos. 2.4.2 Bancos de Dados Orientados a Documentos Baseado em documentos XML ou JSON, que são coleções de atributos e valores, onde um atributo pode ser multi-valorado. Em geral, os bancos de dados orientados a documento não possuem esquema, ou seja, os documentos armazenados não precisam possuir estrutura em comum. Essa característica faz deles boas opções para o armazenamento de dados semi-estruturados. Alguns bancos que utilizam esse padrão são: MongoDb, CouchDB, RavenDb, Riak, MarkLogic Server, BaseX, eXist etc. Segundo Saladage e Fowler (2013), são apropriados para registros de eventos (logs), sistemas de gerenciamento de conteúdo (CMS), plataformas de blog, análises web ou em tempo real (analytics) e aplicativos de comércio eletrônico. Não são apropriados em situações que exigem transações complexas que abranjam diferentes operações e consultas em estruturas agregadas variáveis. 2.4.3 Bancos de Dados de Famílias de Colunas Suportam várias linhas e colunas, além de permitir subcolunas. Por exemplo, caso se queira guardar id, nome e endereço de usuários em um sistema de cadastro, os registros seriam:Id1, Nome1, Endereço1; Id2, Nome2, Endereço2. Essa estrutura torna a escrita muito rápida, pois todos os dados de um registro são colocados no disco com uma única escrita no banco. Essa estrutura também é eficiente caso se queira ler registros inteiros. Mas, para situações onde se quer ler algumas poucas colunas de muitos registros, essa estrutura é pouco eficiente, pois muitos blocos do disco terão de ser lidos.
  22. 22. 20 Para esses casos onde se quer otimizar a leitura de dados estruturados, bancos de dados de famílias de colunas são mais interessantes, pois eles guardam os dados contiguamente por coluna. O exemplo anterior em um banco de dados dessa categoria ficaria: Id1, Id2; Nome1, Nome2; Endereço1, Endereço2. Por esse exemplo é possível perceber a desvantagem de um banco de dados de famílias de colunas: a escrita de um novo registro é bem mais custosa do que em um banco de dados tradicional. Assim, num primeiro momento, os bancos tradicionais são mais adequados a OLTP enquanto os bancos de dados de famílias de colunas são mais interessantes para OLAP. O Bigtable é uma implementação da Google dessa categoria de bancos de dados. Outros bancos de dados que são orientados a coluna: Hadoop, Cassandra, Hypertable, Amazon SimpleDB, HPBase etc. O Cassandra faz uso de implementações de tabelas hash distribuídas, em que a estrutura de índice leva em consideração a replicação e particionamento dos dados em várias máquinas (nós), além da existência de diversos centros de dados (data centers). Saladage e Fowler (2013) afirmam que sua utilização é apropriada em registro de eventos (logs), sistemas de gerenciamento de conteúdo, plataformas de blogs, contadores, e para funcionalidade que expiram durante o uso, por exemplo, exibir banners de propaganda em um website durante um tempo específico utilizando colunas que expirem. Não são recomendados para sistemas que requerem transações ACID para gravações e leituras. 2.4.4 Bancos de Dados de Grafos Possuem uma complexidade maior, pois esses bancos de dados guardam objetos, e não registros como os outros tipos de NoSQL. A busca desses itens é feita pela navegação desses objetos. Diferentemente de outros tipos de bancos de dados NoSQL, esse está diretamente relacionado a um modelo de dados estabelecido, o modelo de grafos. A ideia desse modelo é representar os dados e/ou o esquema dos dados como grafos dirigidos, ou como estruturas que generalizem a noção de grafos. O modelo de grafos é mais interessante que outros quando informações sobre a inter-conectividade ou a topologia dos dados são mais importantes, ou tão importantes quanto
  23. 23. 21 os dados propriamente ditos. O modelo orientado a grafos possui três componentes básicos: os nós (são os vértices do grafo), os relacionamentos (são as arestas) e as propriedades (ou atributos) dos nós e relacionamentos. Os nós são usados para modelar objetos que existem de forma independente das ligações. Em geral, não possuem um esquema rígido. Assim, dois objetos representados por nós de um mesmo grafo podem ter atributos bem distintos. As arestas são usadas para materializar o relacionamento entre nós. As propriedades podem ser usadas tanto para descrever atributos de nós quanto de arestas. Neste caso, o banco de dados pode ser visto como um multigrafo rotulado e direcionado, onde cada par de nós pode ser conectado por mais de uma aresta. Um exemplo pode ser: “Quais cidades foram visitadas anteriormente (seja residindo ou viajando) por pessoas que viajaram para São Paulo?” No modelo relacional esta consulta poderia ser muito complexa devido à necessidade de múltiplas junções, o que poderia acarretar uma diminuição no desempenho da aplicação. Porém, por meio dos relacionamentos inerentes aos grafos, estas consultas tornam- se mais simples e diretas. Este modelo de dados tem se tornado popular em aplicações web de domínio social, fornecendo capacidades interessantes para a realização de consultas requeridas por este tipo de aplicação e com um bom desempenho. Alguns bancos que utilizam esse padrão são: Neo4J, OrientDB, Infinite Graph, InfoGrid, HyperGraphDB, BigData, FlockDB, DEX etc. Para Saladage e Fowler (2013), sua utilização é recomendada em sistemas que exijam dados conectados, como redes sociais, roteamento e envio de serviços baseados em localização e mecanismos de recomendação. Não utilizá-los quando o requisito for atualizar todas as entidades ou um subconjunto delas, como por exemplo, em um aplicativo de análise no qual todas as entidades precisem ser atualizadas com uma propriedade alterada. 2.5 GEOPROCESSAMENTO EM BANCOS DE DADOS NOSQL Geoprocessamento é a área do conhecimento que busca o tratamento da informação geográfica, possibilitando a interpretação dos dados coletados, o cruzamento de diferentes informações, a previsão de cenários, o apoio à tomada de decisões. (SCHWANKER, 2013, p.138)
  24. 24. 22 Ao longo dos anos, temos estudado e registrado através de mapas ou cartas de dados sobre o relevo, fauna, rotas comerciais, limites políticos etc. Entretanto, com o avanço da informática, surgiu a possibilidade de se integrar vários dados e mapas e analisá-los em conjunto, possibilitando, através de análises complexas e a criação de bancos de dados georreferenciados, o desenvolvimento de diversas áreas como a cartografia, principalmente, o planejamento urbano, comunicações, transportes e até a análise de recursos naturais. Atualmente, grandes volumes de dados geoespaciais são criados, armazenados e utilizados como nunca foram antes. Nesse cenário, gerenciadores de bancos de dados não relacionais podem ser, por suas características (capacidade de manipular grandes quantidades de dados sem a necessidade de definição de um esquema e ainda com alto desempenho), soluções mais eficientes para as aplicações que utilizam dados geoespaciais de grande volume. Algumas soluções NoSQL incluem suporte para dados geoespaciais tanto nativamente quanto como uma extensão. Outros não foram desenhados para aplicações geoespaciais, mas estão sendo implementados para suportar dados espaciais. Alguns bancos de dados NoSQL que atualmente estão sendo utilizados para gerenciar dados espaciais são: MongoDB (open source), BigTable (desenvolvido pelo Google, usado no Google Earth), Cassandra (desenvolvido pelo Facebook, que agora é open source e mantido pelo Apache), CouchDB (open source, Apache). A seguir, algumas aplicações que utilizam o NoSQL para tarefas geoespaciais: Foursquare: MongoDB SimpleGeo: Cassandra Where: MongoDB Scrabbly: MongoDB Google Earth: Google Big Table PDX API (API para a cidade de Portland, iniciativa de dados abertos do Oregon): CouchDB (GeoCouch)
  25. 25. 23 2.6 EXEMPLOS REAIS DE UTILIZAÇÃO Serão exemplificadas, a seguir, três empresas consumidoras de cada um dos bancos de dados populares atualmente, MongoDB e Neo4j. De acordo com consulta realizada nos sites dos respectivos fabricantes, na data de 18/05/2015, será apresentada uma breve descrição da aplicação, bem como seu desenvolvimento e utilização. Após as exemplificações de cada um dos bancos de dados, será exibida uma figura contendo seus consumidores oficiais. 2.6.1 MongoDB 2.6.1.1 The Weather Channel Objetivo: Disponibilizar, em tempo real, alertas e informações metereológicas para os usuários que utilizam aplicativos móveis personalizados. Em 1982, o The Weather Channel começou uma rede de televisão 24x7 para atender a demanda de divulgação da informação meteorológica. Vários anos mais tarde, seguindo a evolução natural de acesso às informações online, desenvolveram o weather.com. Mas, como o site foi construído utilizando um banco de dados relacional pesado, foi difícil continuar utilizando a mesma tecnologia para o desenvolvimento de aplicativos móveis. A equipe do Weather Channel precisou agir rapidamente, com aplicativos responsivos e um sistema escalável. Para uma base de usuários de 40 milhões, crescendo rapidamente em smartphones, a marca Weather Channel precisou ir além de uma abordagem de banco de dados relacional legado. Então, optou pelo MongoDB para enviar informações aos usuários rapidamente. Atualizações que costumavam levar semanas podem, agora, ser apresentadas em horas. Eles substituíram altos custos e complexidade por escalabilidade simplificada e velocidade. E agora que eles estão modernizados em uma infraestrutura de nuvem, estão transmitindo notícias, estilos de vida e conteúdo metereológico das suas propriedades digitais para o MongoDB.
  26. 26. 24 Com uma grande quantidade de aplicações integradas ao MongoDB, os usuários podem personalizar as suas experiências através de dispositivos móveis, tablets e no site. Eles podem visualizar rapidamente radares de mapas e receber diversos alertas meteorológicos em tempo real. “Como nós trabalhamos com nossa base de usuários para descobrir características críticas, ciclos de inovação rápidos com o MongoDB são um benefício real.” (LUKE KOLIN, vice presidente de arquitetura do The Weather Channel, tradução minha). De acordo com Kolin, os índices secundários e a rápida consulta do MongoDB o tornam o único produto que pode executar de forma confiável este tipo de pesquisa sobre essa grande base de usuários em meros segundos. 2.6.1.2 Expedia Objetivo: Oferecer planejamento de viagem fácil, rápido e altamente personalizado para milhões de clientes. O mercado de viagens on-line é dinâmico e complexo. De um lado, os fornecedores mudam constantemente, nos bastidores, o inventário e informações de preços. Por outro lado, os consumidores estão interagindo com o site a partir de muitos dispositivos e navegadores diferentes. Eles precisam escolher as datas, destinos, alinhar vôos, aluguéis de carros e hotéis. Os preços variam, a disponibilidade altera constantemente, e eles estão competindo com outros viajantes por um inventário limitado. Isto cria um enorme volume de dados altamente variáveis. O diretor técnico da engenharia Murari Gopalan disse: “Online travel is a hard nut to crack”, expressão que possui o mesmo sentido de, "Viagem on-line é um osso duro de roer". Um cliente típico irá procurar em diferentes locais antes de reservar seu vôo. Vai do laptop para o telefone e vice-versa, essa pesquisa pode durar dias. A maioria das pessoas esquece onde elas já olharam e acabam repetindo as mesmas pesquisas novamente. Alguns recorrem até mesmo à caneta e papel para fazer anotações, mas continuam sem nenhuma decisão.
  27. 27. 25 Para atender melhor as expectativas de seus clientes, a Expedia decidiu oferecer uma melhor forma de planejamento de viagem. Um recurso alimentado por MongoDB chamado Scratchpad (bloco de notas). O Scratchpad serve para automatizar o processo de tomada de notas, lembrar-se de forma inteligente das pesquisas, procurar os preços mais baixos e tornar mais fácil fazer compras em qualquer dispositivo. O cliente pode iniciar a busca em seu laptop e continuá-la em seu smartphone a qualquer momento, e depois rever as opções em um tablet com o seu parceiro mais tarde. Enquanto os requisitos para o aplicativo Scratchpad já existiam há anos, a rigidez das opções tradicionais dos RDBMS sufocou o seu desenvolvimento. No entanto, com o MongoDB, a Expedia foi capaz de desenvolve-lo muito mais rápido do que o esperado. Uma equipe de apenas três desenvolvedores construiu o primeiro protótipo para o Scratchpad em menos de dois meses, e lançou-o para produção apenas dois meses depois. “Sem o MongoDB, seria necessário uma equipe muito maior para lançar o aplicativo tão rapidamente.” (PRASHANTH KOKATI, engenheiro de software sênior da Expedia, tradução minha). Com um banco de dados relacional, seria lento e difícil normalizar todos os dados do cliente, da sessão e de produtos através de um processo de ETL, colocá-lo em um data warehouse e executar somente consultas prescritas. Esta não era uma opção para Scratchpad. O armazenamento de documentos flexível do MongoDB e a simples escala horizontal tornaram possível para a Expedia criar uma ferramenta que dá a cada usuário uma relevante experiência de compra. Que, em tempo real, coleta informações de clientes dinamicamente e apresenta ofertas personalizadas. E ainda realiza tudo isso em grande escala. O modelo de dados flexível do MongoDB tornou mais fácil armazenar qualquer combinação de pares de cidades, datas e destinos. A Expedia pode continuar comprando para alguém até mesmo depois de fechada a sessão. Quando o cliente regressa, todos os últimos preços e disponibilidade para suas buscas são exibidos lado a lado no seu Scratchpad.
  28. 28. 26 Os ricos índices do MongoDB são utilizados para poderosas análises que fazem sugestões personalizadas para usuários enquanto eles fazem compras. A Expedia também pode analisar os padrões para identificar tendências que oferecem uma melhor compreensão do que os clientes estão procurando. O esquema é alterado radicalmente em tempo real – sem efeitos colaterais, os casos de uso se modificam. A visão evolui. Sem a flexibilidade do banco de dados, a inovação encontra um obstáculo. Depois de colocar o "Scratchpad" em produção e vendo as dificuldades e o feedback do cliente, a equipe da Expedia alterou radicalmente a estrutura do esquema três vezes. Em um negócio que está sempre em rápido movimento, isso não é uma tarefa fácil - pelo menos para a maioria dos bancos de dados. Normalmente, a Expedia teria que colocar no ar uma página com o temido "em manutenção". No entanto, o MongoDB permitiu que a Expedia alterasse radicalmente seus esquemas durante a execução em produção, com impacto zero sobre a experiência do cliente. 2.6.1.3 Forbes Objetivo: Entregar um CMS (Sistema de Gerenciamento de Conteúdo) personalizado em 2 meses, e um novo site móvel em 1 mês. A Forbes é a principal fonte de notícias de negócios desde 1917, produzindo sempre conteúdo de qualidade. O que lhes faltava era velocidade. Eles não poderiam manter o ritmo acelerado do jornalismo com os antigos sistemas fechados. Interrupções eram comuns. Alterações na arquitetura, difíceis e caras. Era hora de refazer tudo completamente. A Forbes decidiu fazer uma jogada ousada, reformular toda a sua plataforma e reconstruir o seu sistema de gerenciamento de conteúdo (CMS) utilizando o MongoDB. Após esta modificação, o sistema é incrivelmente rápido, aberto a colaboradores a nível global e fácil de ser modificado sem sair do ar. Tudo na mesma fração de tempo e custo da antiga abordagem. A Forbes construiu um CMS personalizado utilizando o MongoDB em apenas dois meses. Em seguida, eles lançaram um novo site móvel em menos de um mês.
  29. 29. 27 Com apenas um engenheiro trabalhando em tempo integral e outro trabalhando meio período, o time de desenvolvimento de aplicativos móveis era minúsculo. Mas os resultados foram enormes. Durante a noite o tráfego móvel da Forbes.com saltou de 5% para um total de 15%, e rapidamente aumentou para 50%. “Em dois meses, engenheiros que nunca trabalharam com o MongoDB foram capazes de fazer um produto inovador… qualquer coisa que precisássemos fazer com o MongoDB, nós apenas extendíamos o esquema.” (STEVEN BOND, diretor da equipe de desenvolvimento de software da Forbes.com, tradução minha). Figura 2 – Empresas Consumidoras do MongoDB Fonte: Elaborada pela autora a partir de informações disponíveis no site oficial do MongoDB, na sessão de Consumidores.
  30. 30. 28 2.6.2 Neo4j 2.6.2.1 InfoJobs Objetivo: Desenvolver o Portal de Plano de Carreira para identificar os passos e experiências que os seus candidatos a emprego vivenciaram em suas vidas profissionais, para que outras pessoas possam usá-los como referência em seu próprio crescimento de carreira. O InfoJobs é o maior e mais popular site de busca de empregos da Europa que permite que os funcionários busquem por postagens de empregos, e empregadores postem novas oportunidades em uma mesma plataforma. Ele conecta funcionários às companhias através de um portal online e permite que as pessoas que buscam emprego armazenem suas informações de carreira e encontrem novas oportunidades. Marc Pou, gerente de produtos do InfoJobs, começou a pesquisar sobre as bases de dados de grafos quando se tornou difícil modelar e explorar facilmente seus dados. Com 8 milhões de currículos, cada documento continha a experiência profissional específica de cada candidato. Além de produzir informações úteis para ajudar os usuários a tomarem decisões sobre o seu próximo passo na carreira, com base em usuários semelhantes com as mesmas experiências, o Portal de Plano de Carreira fornece informações abrangentes, como “qual a probabilidade de eu conseguir esse cargo com base na minha situação atual?”. Este gerenciamento do Portal necessitava de quantidades enormes de informações, incluindo 4 milhões de candidatos, resultando em 26098726 nós, 12 milhões de experiências de trabalho resultando em 171882297 propriedades e 18 milhões de habilidades com 23 tipos de relacionamentos. A fim de otimizar o sistema para entregar os resultados interativamente, o InfoJobs combinou o Neo4j com cache de memória para armazenar os resultados dos algoritmos, baseados nas métricas de cada mês. Sem o Neo4j, estes algorítmos teriam exigido uma quantidade excessiva de pré- cálculos, complexidade e custo.
  31. 31. 29 O Neo4j é usado como base de dados para armazenar toda a informação estática e as informações são atualizadas uma vez por mês. Com base nos relacionamentos e nós, o sistema é capaz de realizar consultas baseadas nos grafos. Através da implantação do Neo4j, o InfoJobs descrobriu o valor dos seus dados através da visibilidade das conexões implícitas e economia de tempo e dinheiro para o projeto. 2.6.2.2 Walmart Objetivo: Oferecer recomendações, em tempo real, otimizadas e personalizadas. O Walmart é uma empresa familiar que em pouco mais de 50 anos se tornou a maior empresa pública do mundo, com mais de 2 milhões de funcionários e rendimentos anuais de 470 bilhões de dólares. O Walmart se tornou o maior varejista do mundo por entender as necessidades de seus clientes. O Walmart lida com quase 250 milhões de clientes semanais através de suas 11.000 lojas em 27 países e através dos seus sites de varejo em 10 países. O Grupo eCommerce brasileiro do Walmart escolheu o Neo4j para ajudá-lo a entender o comportamento e as preferências dos compradores on-line com bastante velocidade e em profundidade suficiente para que isso fosse feito em tempo real, recomendações personalizadas 'você também pode gostar de', uma forma comprovada para maximizar a receita. Como explica o Desenvolvedor de Software do Walmart, Marcos Wada: "O Neo4j nos ajuda a entender o comportamento dos nossos compradores on-line e as relações entre os nossos clientes e produtos, proporcionando uma ferramenta perfeita para recomendações de produtos em tempo real." Se esforçando para fornecer a melhor experiência web para seus clientes, o Walmart resolveu otimizar suas recomendações on-line. Nos dias de hoje, os compradores esperam recomendações altamente afinadas e personalizadas e não reagem tão bem a quaisquer sugestões. Mas, para conseguir isso, são necessários produtos que podem conectar massas de dados complexas de compradores e produtos. O Walmart reconheceu o desafio que enfrentaria se utilizasse a tecnologia de banco de dados relacional tradicional para concretizar este objetivo.
  32. 32. 30 Como Marcos explicou: "Um banco de dados relacional não estava satisfazendo nossas necessidades sobre o desempenho e simplicidade, devido à complexidade das nossas consultas." Para resolver isso, a equipe de Marcos decidiu usar banco de dados de grafos, o Neo4j. Por padrão, os bancos de dados de grafos podem rapidamente consultar as compras anteriores dos clientes, bem como capturar instantaneamente quaisquer novos interesses mostrados na visita online atual dos mesmos – características essenciais para fazer recomendações em tempo real. Combinar dessa forma dados de histórico e de sessão é trivial para bancos de dados de grafos como o Neo4j, permitindo facilmente superar os produtos de dados relacionais e outros "NoSQL" para este objetivo. O Walmart está agora utilizando o Neo4j para sentir o comportamento dos compradores on-line, a fim de otimizar e cruzar a venda das principais linhas de produtos nos principais mercados. Ele implantou o Neo4j em suas aplicações de mercado, executadas pela equipe de eCommerce de TI da empresa com sede no Brasil. O Walmart tem usado o Neo4j em produção desde o início de 2013 e este ano migrou para a versão 2.0. Marcos explicou os benefícios: "Com o Neo4j nós podemos substituir um processo em lote complexo que usávamos para preparar o nosso banco de dados relacional por um banco de dados gráfico simples e em tempo real. Nós pudemos construir um sistema de recomendação simples e em tempo real com consultas de baixa latência." Ele concluiu: "Sendo o atual líder de mercado em bases de dados do gráfico, e com características empresariais para escalabilidade e disponibilidade, o Neo4j foi a escolha certa para atender às nossas demandas." 2.6.2.3 Ebay Objetivo: Oferecer às pessoas a entrega mais rápida possível de e-commerce de compras. O eBay foi criado em 2009, de brinquedos a chinelos, laços ou iPhones, o eBay está fazendo entrega de encomendas on-line e através de dispositivos móveis rápida e convenientemente oferecendo a opção de ter o item entregue no mesmo dia. O "eBay Now"
  33. 33. 31 serviço de entrega local, está atualmente disponível em quatro mercados norte-americanos, com planos de expansão para 25 grandes cidades nos EUA e Reino Unido até o final de 2014. Alcançamos desempenho na consulta utilizando o Neo4j para criar um grafo que é o seu próprio índice. Isso representa uma flexibilidade de desenvolvimento impressionante. A implementação foi concluída dentro do prazo de apenas um ano. As consultas são agora mais fáceis e rápidas. O resultado é uma plataforma escalável que suporta expansão de negócios, que inclui o crescimento que ele está vivenciando agora com uma plataforma rodando por trás do "eBay Now". VOLKER PACHER, 2014 O eBay Now coordena entregas entre lojas, transportadores e compradores 24 horas por dias 7 dias por semana. Despachando a partir do ponto-de-venda, o serviço lida com logística de coleta e entrega com base na preferência do cliente, geralmente dentro de duas horas, ou dentro de um quadro de hora especifica agendada pelo cliente. O novo serviço do eBay aumenta o serviço ao cliente e a produtividade entre os parceiros de varejo e entrega. Todos ganham - clientes possuem opções de entrega, os entregadores não esperam, e os varejistas são capazes de fornecer um serviço adicional aos seus clientes on-line. Volker Pacher, desenvolvedor sênior do eBay, faz parte da equipe do núcleo da plataforma de serviços que oferece uma API para os transportadores e comerciantes. Quando o crescimento exponencial diminuiu os tempos de resposta da API, a equipe trabalhou para renovar a inicial plataforma. Ele sabia que um banco de dados de grafos poderia simplificar a modelagem de domínio de uma forma que não afetaria a estrutura existente. Usando o Neo4j e uma estrutura de grafo sem esquema, eles criaram um banco de dados que permite que as consultas permaneçam localizadas dentro do grafo, melhorando o desempenho com facilidade expressiva. O serviço de entrega no mesmo dia cresceu exponencialmente, com cobertura expandindo para 85% do Reino Unido. Sua plataforma de serviço precisou de uma reformulação para suportar o crescimento explosivo de dados e novas funcionalidades. As junções MySQL utilizadas criaram uma base de código muito lenta e complexa de manter. As consultas usadas para escolher a melhor transportadora simplesmente tomavam muito tempo e eles precisavam de uma solução para manter um serviço competitivo. Pacher e a equipe de desenvolvimento acreditavam que um banco de dados gráfico poderia ser adicionado à estrutura de SOA e aos serviços existentes, para resolver os desafios de desempenho e escalabilidade. A equipe escolheu, então, o Neo4j como a melhor solução.
  34. 34. 32 O Neo4j foi selecionado pela sua flexibilidade, velocidade e facilidade de utilização. E pelo seu modelo de propriedade gráfica harmonizado com o domínio que está sendo modelado. A natureza de esquema flexível do banco de dados permitiu uma fácil extensibilidade, e aceleração de desenvolvimento. E ele superou as limitações de velocidade e escalabilidade da solução anterior. Diz Volker, "Nossa solução Neo4j é, literalmente, milhares de vezes mais rápida do que a solução MySQL anterior, com consultas que exigem 10-100 vezes menos código. Ao mesmo tempo, o Neo4j permitiu-nos adicionar funcionalidades que anteriormente não eram possíveis". Cypher permitiu que consultas fossem expressadas de uma forma muito compacta e intuitiva, acelerando o desenvolvimento. A equipe foi capaz de tirar vantagem do código existente, usando uma biblioteca Ruby para Neo4j que também suporta Cypher. A nova plataforma usando o jRuby, Sinatra, MongoDB e Neo4j fornece transações rápidas com desempenho relativamente constante, com um modelo de dados que permite que as consultas permaneçam localizadas às suas respectivas porções do grafo. Figura 3 – Empresas Consumidoras do Neo4J
  35. 35. 33 Fonte: Elaborada pela autora a partir de informações disponíveis no site oficial do Neo4J, na sessão de Consumidores.
  36. 36. 34 3 MATERIAIS E MÉTODOS Nesta sessão será apresentado como o NoSQL funciona na prática. Este desenvolvimento foi baseado na prática do curso online oficial, MongoDB para Desenvolvedores Java, ministrado pela Universidade MongoDB. Para esta demonstração, foi desenvolvido um pequeno servidor de Blogs, utilizando o MongoDB como banco de dados principal de armazenamento, linguagem Java para desenvolvimento, Spark como servidor de aplicação, Freemarker como framework de interface, Eclipse como ferramenta de desenvolvimento e MongoChef como ferramenta de administração de dados. Também foi criada uma simples área para estudo de caso. Esta área é independente da prática oficial e foi desenvolvida apenas com a finalidade de avaliação prévia de desempenho e complexidade diante da necessidade de futuras adições de consultas mais complexas de postagens. Durante o desenvolvimento desta área foi adicionado à aplicação o PostgreSQL, como banco de dados SQL, e utilizado o pgAdmin como ferramenta de administração de dados. Tanto para o PostgreSQL quanto para o MongoDB, foram utilizadas as APIs nativas para acesso ao banco através da aplicação, PostgreSQL JDBC Driver e Java MongoDB Driver respectivamente. Este projeto está disponível para download e visualização no GitHub, que pode ser acessado através do seguinte endereço: https://github.com/CrisCoboQAT/nosql_blog. Os scripts de inserção de dados também se encontram dentro do projeto. Os seguintes passos foram realizados para o desenvolvimento desta aplicação: - Download, instalação e configuração do MongoDB, bem como do driver, das ferramentas, e frameworks a serem utilizados (Java MongoDB Driver, Eclipse, MongoChef ,Spark e Freemarker); - Codificação da aplicação utilizando o MongoDB; - Elaboração e inclusão dos scripts de inserção de dados de teste no MongoDB; - Execução da aplicação; - Download, instalação e configuração do PostgreSQL, pgAdmin e PostgreSQL JDBC Driver;
  37. 37. 35 - Elaboração e inclusão dos scripts de inserção de dados de teste no PostgreSQL; - Desenvolvimento de página de análise comparativa entre o MongoDB e PostgreSQL; Nesta aplicação há uma página de cadastro de usuário, outra de login. Ao acessar a aplicação, o usuário será redirecionado a uma tela de boas vindas onde terá acesso às seguintes áreas: - Visualizar Blog: As últimas dez postagens do usuário serão exibidas em ordem decrescente, com a quantidade total de comentários exibidos em um link que, ao ser acessado, exibe a postagem detalhadamente com todos os comentários e a opção “Curtir” em cada um deles, acompanhado da quantidade de curtidas. Figura 4 – Tela de visualização de postagens Fonte: Elaborada pela autora. - Criar Nova Postagem: Um formulário com título, conteúdo e tags será exibido para que o usuário possa inserir novas postagens.
  38. 38. 36 Figura 5 – Tela de criação de nova postagem Fonte: Elaborada pela autora. - Sair da aplicação A seguir será exibida a tela utilizada para análise de desempenho, que compara algumas consultas executadas utilizando o MongoDb e o Postgres, em que para obter os tempos de execução foi adicionado um timer nos métodos para medir a duração de execução das consultas. Os resultados serão abordados no capítulo seguinte. Figura 6 – Tela de análise de desempenho
  39. 39. 37 Fonte: Elaborada pela autora.
  40. 40. 38 4 RESULTADOS E DISCUSSÃO Na aplicação de Blogs, citada na sessão anterior, podemos também comparar e observar as diferenças de desempenho entre NoSQL e SQL. Caso fossem necessárias consultas mais complexas, os seguintes resultados seriam obtidos com as bases de dados populadas com os mesmos registros (dez mil de postagens com 10 comentários e 3 tags cada): Figura 7 – Resultados das consultas na aplicação de blogs Consulta Tempo de Execução MongoDB Tempo de Execução PostgreSQL Postagens ordenadas por data de inserção: 0:02.277 0:9.210 Postagens que contem uma determinada palavra ("postagem") em seu conteúdo: 0:00.626 0:08.489 Postagens comentadas por um determinado usuário ("autor comentario 1"): 0:00.783 0:09.391 Fonte: Elaborada pela autora. Após análise da Figura 7, pode-se observar que o tempo de execução das consultas utilizando o MongoDB é bastante inferior ao tempo obtido utilizando o PostgreSQL. Com base nesses resultados, conclui-se que o desempenho das consultas adicionais seria bastante otimizado com a utilização do MongoDB neste contexto. A seguir, será exibido o esquema de dados, caso fosse utilizado o modelo relacional para desenvolvimento desta aplicação.
  41. 41. 39 Figura 8 – Modelo relacional da aplicação de blogs Fonte: Elaborada pela autora a partir de informações disponíveis no curso oficial do MongoDB. Como pode ser observado, no modelo relacional acima, seria necessária a criação de seis tabelas para armazenamento e ligação dos dados. No MongoDB, não são utilizadas tabelas, mas sim, coleções. Para armazenamento das informações do Blog, no lugar de seis tabelas, seriam necessárias apenas duas coleções: uma para armazenamento de postagens e outra para armazenamento de usuários. Um dos recursos mais importantes do MongoDb é a possibilidade de embutir coleções dentro de coleções, sendo assim, como as tags e os comentários estarão relacionados a uma postagem específica, eles podem ser embutidos diretamente dentro das postagens. Utilizando o NoSQL, não existe um esquema normalizado, mas será exibido abaixo uma exemplificação de como poderia ser realizado o armazenamento dos dados no MongoDB:
  42. 42. 40 Figura 9 – Exemplo de representação de dados da aplicação de blogs no MongoDB Fonte: Elaborada pela autora a partir de informações disponíveis no curso oficial do MongoDB. Além dos ganhos em desempenho, identifica-se também a facilidade de implementação e, consequentemente, manutenção da aplicação utilizando o MongoDB. Como no MongoDB foram usadas apenas duas coleções, o número de junções foi bastante reduzido. Portanto, para a maioria das consultas, apenas a coleção de postagens deverá ser acessada. Com isso, a quantidade de linhas de codificação necessária é bem inferior à que seria necessária utilizando o modelo relacional. Consequentemente, a lógica se tornou mais simples e fácil manter o código. Por exemplo, para retornar as postagens com nome do autor, tags e comentários em ordem decrescente de inserção utilizando o modelo de dados relacional (PostgreSQL), seria necessária uma codificação similar à seguinte:
  43. 43. 41 1- Recuperar os dados da tabela de postagens fazendo junção com a tabela de usuários para recuperar também o nome do autor: SELECT post_id, titulo, conteudo, data, nome, email FROM postagens p INNER JOIN usuarios u ON (p.user_id = u.user_id) ORDER BY data DESC 2- Percorrer o resultado da consulta anterior, fazendo junção com a tabela relacional post_coments, utilizando o id das postagens para recuperar os dados dos comentários de cada postagem na tabela de comentários: SELECT c.coment_id, nome, comentario, data, email FROM comentarios c INNER JOIN post_coments pc ON (post_id = " + postId + " AND c.coment_id = pc.coment_id) 3- Percorrer o resultado da consulta na tabela de postagens, fazendo junção com a tabela relacional post_tags, utilizando o id das postagens para recuperar os dados das tags de cada postagem na tabela de tags: SELECT t.tag_id, nome FROM tags t INNER JOIN post_tags pt ON (post_id = " + postId + " AND t.tag_id = pt.tag_id) Já utilizando o modelo não relacional (MongoDB), apenas a linha abaixo seria necessária: db.postagens.find().sort({"date" : -1}); De acordo com os resultados acima, as características dos bancos de dados não relacionais descritas neste trabalho e com os casos reais de utilização apresentados, pode-se identificar que o uso do NoSQL é recomendado para sistemas que não necessitem do controle de transações ACID efetuado pelo banco, assim como para aplicações com alto número de acesso e com volume crescente de dados. No entanto, esta afirmação não pode ser generalizada, cada caso deve ser avaliado criteriosamente antes de decidir qual seria a melhor tecnologia a ser utilizada. Mccreary e Kelly (2014), fazem a seguinte analogia, tradução minha:
  44. 44. 42 Comprar um carro não é uma tarefa fácil. A pessoa quer um carro que não seja muito caro, tenha uma grande aceleração, possa acomodar quatro pessoas (mais bagagem de camping) e receba grande quilometragem. Então, ela percebe que nenhum carro possui tudo isso e cada carro possui coisas que ela gosta e que não gosta. É obrigação dela, descobrir quais as características que ela realmente quer e como pesar cada recurso para ajudá-la a tomar a decisão final. Para encontrar o melhor carro, é importante entender primeiro quais recursos são mais importantes para a sua necessidade. Uma vez que ela sabe disso, pode priorizar as necessidades, verificar as especificações do carro e encontrar algum que se adapta aos seus principais objetivos. Selecionar a correta arquitetura de banco de dados para determinado problema de negócio é semelhante à compra de um carro. Deve-se primeiro entender os requisitos e, em seguida, classificar como cada requisito é importante para o projeto. Em seguida, olhar para as opções de bancos de dados disponíveis e medir como cada um de seus requisitos funcionará em cada opção de banco. Uma vez em que é sabido como cada banco de dados funciona, é possível computar os resultados e pesar os critérios mais importantes com conformidade a um determinado banco. Por isso, faz-se necessário que os profissionais de TI possuam conhecimento tanto dos requisitos do sistema a ser desenvolvido, quanto dos conceitos e tecnologias disponíveis no mercado, e inclusive, possuam a visão de onde aquela aplicação poderá chegar futuramente, de quanto ela será mantida e modificada, da quantidade de acessos que ela possuirá, da necessidade de gerenciamento de transações etc. Não existe um banco de dados melhor que outro, um framework melhor que outro, uma linguagem melhor que outra. Enfim, uma tecnologia melhor que outra. Existe a tecnologia que se adapta melhor às necessidades de cada aplicação. De acordo com o que foi descrito neste trabalho e na quantidade crescente de empresas que estão adotando os bancos de dados NoSQL como ferramenta principal ou complementar dos seus aplicativos, é essencial que os profissionais de TI (desenvolvedores, engenheiros, arquitetos, analistas, administradores de bancos de dados, professores, entre outros) tenham conhecimento dos bancos de dados NoSQL, tanto quanto dos bancos de dados relacionais, para que possam decidir qual a melhor tecnologia a ser utilizada em cada caso, bem como ser capaz de desenvolver, analisar, manter, atualizar e ensinar sobre os diversos tipos de sistemas de informação.
  45. 45. 43 Nas últimas décadas, o desenvolvimento tecnológico tem sido rápido e progressivo. Logo, é importante que os profissionais de TI estejam atualizados quanto às exigências de mercado e recrutamento das empresas. Segundo busca realizada na data de 15/07/2015, na sessão de empregos de TI dos sites divulgadores de vagas e especializados em recrutamento de profissionais, LinkedIn, InfoJobs e Ceviu, diversas vagas exigiam conhecimento do conceito de NoSQL ou experiência em, pelo menos, um de seus bancos de dados. A grande maioria citava esse conhecimento como um diferencial. Portanto, é de suma importância que o profissional de TI da atualidade, principalmente os profissionais especializados em banco de dados, possuam conhecimento do NoSQL e estejam familiarizados com os cenários em que o mesmo possa ser utilizado bem como a melhor ferramenta de mercado para cada caso.
  46. 46. 44 5 CONCLUSÃO Durante o desenvolvimento deste trabalho foi apresentado que os bancos NoSLQ se caracterizam principalmente pela capacidade de escalabilidade horizontal, trabalhando bem em ambientes clusterizados, e também por serem schemaless e utilizarem o map-reduce. Foi também desenvolvida uma pequena aplicação de Blogs como exemplo de utilização e executadas algumas consultas comparando o desempenho entre o MongoDB e PostgreSQL. De acordo com esta apresentação pode-se concluir que as estruturas NoSQL se aplicam quando grandes volumes de dados devem ser manipulados, para obter desempenho ao gravá-los nessa quantidade e acessá-los com rapidez, ou quando os dados envolvidos não podem seguir um esquema claro ou não possuem uma estrutura bem definida. Por exemplo, suponha um site de buscas como o Google, que cataloga e armazena informações sobre bilhões de páginas na web em servidores localizados em diversos lugares do planeta, e, quando alguém faz uma pesquisa, retorna essas informações em questão de milésimos de segundos e em ordem de relevância para o usuário. Agora, pode-se notar claramente o ponto chave da questão: essa eficiência seria viável num mundo feito de tabelas, num paradigma onde os dados se encontram separados e normalizados? Para retornar esses resultados seriam executadas dezenas de junções. Visivelmente, a melhor saída é uma desnormalização dos dados, e mais, a utilização de uma estrutura de persistência de dados que se adapte melhor ao problema proposto, que torne a sua resolução mais apropriada ao cenário. O que existe não é “a melhor tecnologia”, mas sim, a tecnologia que melhor se adequa a um determinado cenário. Por isso é tão importante que os profissionais de TI obtenham conhecimento sobre os bancos de dados não relacionais para saberem qual tecnologia seria melhor aplicada em cada caso.
  47. 47. 45 REFERÊNCIAS ALECRIM, Emerson. (2013). Cluster: conceito e características. Disponível em: <http://www.infowester.com/cluster.php>. Acessado em: 07/02/2015. ELSMARI, Ramez; NAVATHE Shamkant B.. Sistemas de Bancos de Dados. 4ª Edição. São Paulo: Pearson Education do Brasil Ltda, 2005. 690p. FOWLER, Martin. Schemaless Data Structures. Chicago, 2013. Disponível em: <http://martinfowler.com/articles/schemaless/>. Acesso em: 08/03/2015 GONDIM, Gustavo Simões Pinto. Laboratório NoSQL (Parte 1): Conceitos de NoSQL. São Paulo, 2013. Disponível em: <http://www.buildando.com.br/p/equipe.html>. Acesso em: 02/06/2014. MCCREARY, Dan; KELLY Ann. Making Sense of NoSQL. First Edition. Shelter Island: Manning PublicationsCo, 2014. 286p. MONGODB. Who uses MongoDB. Disponível em: <https://www.mongodb.com/who-uses- mongodb/>. Acessado em 18/05/2015. MONGODB University. MongoDB Online Courses. Disponível em: <https://university.mongodb.com/>. Acessado em 23/09/2014. NEO4J. Neo4J Customers. Disponível em: <https://http://neo4j.com/customers//>. Acessado em 18/05/2015. SADALAGE, Pramod J.; FOWLER, Martin. NoSQL Essencial: Um Guia Conciso para o Mundo Emergente da Persistência Poliglota. Primeira Edição. São Paulo: Novatec, 2013. 217p. SCHWANKE, Cibele. Ambiente: Tecnologias: Série Tekne. Primeira Edição. Porto Alegre: Bookman Editora, 2013. 143p. VAISH, Gaurav. Getting Started with NoSQL. First Edition. Birmingham: Packt Publishing, 2013. 123p. VERAS, Manoel. Virtualização - Componente Central do Datacenter. . Primeira Edição. Rio de Janeiro: Brasport Livros e Multimídia Ltda, 2011. 331p.

×