Uma análise crítica sobre o uso do NoSQL para desenvolvimento de aplicações

Uma an´alise cr´ıtica sobre o uso do NoSQL para desenvolvimento de aplicac¸o˜ es Antonio Alves Lopes Filho1 , Adriana M. R. Nascimento1 , Elidiane Martins Freitas1 , Francisco Edvan Chaves1 , Hitalo Joserfeson Batista Nascimento 1 1

Ciˆencia da Computac¸a˜ o - Faculdade Integrada da Grande Fortaleza (FGF) Av. Porto Velho, 410 – 60.510-040 – Fortaleza – CE – Brasil

{[email protected]}, {adri,edvan,hitalo,elidiane}@fgf.edu.br

Resumo. A Internet ap´os a WEB 2.0 vem gerando uma quantidade expressiva de dados e com isso vem a necessidade de agilizar o gerenciamento desses dados, bem como seu armazenamento de forma que fiquem dispon´ıveis sempre que precisar. NoSQL (Not Only SQL) vem com a miss˜ao de resolver esse gargalo de forma eficaz, com isso o presente artigo visa apresentar os conceitos que envolvem o termo NoSQL, a sua necessidade de implementac¸a˜ o para com a escalabilidade e performance na WEB 2.0, relata comparac¸o˜ es com o modelo relacional nas propriedades ACID e BASE e a sua relac¸a˜ o com o Teorema CAP. No estudo de caso e´ mostrada uma implementac¸a˜ o utilizando o MongoDB, demonstrando a abordagem de desenvolvimento junto com o seu driver e a tecnologia Java. Por fim, ele explana os resultados do estudo de caso e sugere como trabalhos futuros a implementac¸a˜ o do algoritmo MapReduce. Palavras-chave: nosql, sgbd, sql. Abstract. The Internet after Web 2.0 has generated a significant amount of data and with that comes the need to streamline the management of these data and their storage so they are available whenever you need. NoSQL ( it Not Only SQL) comes with the mission to solve this bottleneck effectively, thus this article is to present the concepts involving the term NoSQL, their need for implementation towards the scalability and performance on the Web 2.0 reports comparisons with the relational model in ACID and BASE and its relationship with the CAP theorem. In the case study is shown an implementation using MongoDB, demonstrating the development approach together with its it driver and Java technology. Finally, he explains the results of the case study and suggests future work as the implementation of the MapReduce algorithm. Keywords: nosql, sgbd, sql.

1. Introduc¸a˜ o Durante muito tempo os Sistemas Gerenciadores de Banco de Dados (SGBD) relacionais dominaram com eficiˆencia a forma como as pessoas armazenavam e buscavam seus dados, de forma segura e consistente. Por´em, com o advento da WEB 2.0 e sua gama incont´avel de dados manipul´aveis, gerou-se um problema para abordagem antes dominante, o armazenamento e a escalabilidade desses dados. Atualmente, os grandes sites coletam informac¸o˜ es acerca de seus usu´arios, que hoje passam de bilh˜oes (caso do Google e Facebook)[Rubinstein and Good 2013], e cada usu´ario tem diversas nuances que

devem ser analisadas para melhor gerenciamento dessas informac¸o˜ es, e por conseguinte gerar receita para essas empresas atrav´es de propagandas e desenvolvimento de plataformas espec´ıficas para utilizac¸a˜ o em massa. Diante deste novo panorama, termos como escalabilidade e performance vieram a` tona com mais forc¸a do que nunca. Os grandes SGBD’s n˜ao possu´ıam suporte adequado a` s novas exigˆencias, como escalonamento horizontal e velocidade de manipulac¸a˜ o de uma grande quantidade de dados. Com isso, vem a ideia do NoSQL (Not Only SQL), onde se torna mais f´acil o escalonamento horizontal e a grande capacidade para armazenamento[Leavitt 2010]. Ao pesquisar trabalhos relacionados com o assunto aqui enfatizado foram identificados artigos que abordam as diversas nuances do modelo n˜ao relacional, dentre estes podemos citar: “NoSQL no desenvolvimento de aplicac¸o˜ es Web colaborativas”[L´oscio et al. 2011]; o artigo “Bancos de Dados NoSQL x SGBDs Relacionais: An´alise Comparativa”[Brito 2010]; foi utilizado tamb´em o minicurso “Bancos de Dados NoSQL: Conceitos, Ferramentas, Linguagens e Estudos de Casos no Contexto de Big Data”[Vieira et al. 2012]; e o livro “NoSQL: Um Guia Conciso para o Mundo Emergente da Persistˆencia Poliglota”[Sadalage and Fowler 2012] e “NoSQL para leigos”[Fowler 2015]. Este artigo tem como objetivo mostrar os conceitos norteados em torno do NoSQL, suas caracter´ısticas, as diferenc¸as com o modelo relacional, os seus tipos de arquitetura, e por fim demonstrar uma aplicac¸a˜ o usando MongoDB com o uso da sua API de manipulac¸a˜ o. Ele est´a dividido da seguinte forma: na sec¸a˜ o 2 e´ dado um breve comparativo da tecnologia n˜ao relacional com a relacional, e´ explicado como funciona o Teorema CAP e o seu surgimento, e´ mostrado o conceito de escalonamento horizontal e vertical e os tipos de particionamento em rede, tamb´em e´ mostrado o hist´orico do termo NoSQL e como foi dada a sua influˆencia de desenvolvimento, no final da sec¸a˜ o e´ explanado os principais tipos de bancos de dados n˜ao relacionais e uma pequena comparac¸a˜ o com um banco de dados relacional, na sec¸a˜ o 3 e´ descrita a metodologia utilizada para desenvolver o trabalho, na sec¸a˜ o 4 e´ feita uma an´alise dos dados utilizando uma implementac¸a˜ o como estudo de caso com MongoDB e Java, e finalmente na sec¸a˜ o 5 temos as considerac¸o˜ es finais sugerindo trabalhos futuros.

2. Referencial Te´orico Neste cap´ıtulo apresentamos paralelos entre o modelo atual de gerenciamento de dados, os modelos relacionais, com o paradigma de dados distribu´ıdos, os ditos NoSQL. E´ definido alguns conceitos primordiais na elaborac¸a˜ o do modelo NoSQL atrav´es do Teorema CAP. Tamb´em apresentamos as caracter´ısticas dos banco de dados n˜ao relacionais, junto com os m´etodos de implementac¸a˜ o e distribuic¸a˜ o em rede. S˜ao apresentados os quatro principais tipos de banco de dados n˜ao relacionais conhecidos atualmente, representado por cada um de seus representantes no mercado. E por fim e´ apresentado algumas caracter´ısticas do MongoDB, objeto de caso de estudo deste artigo. 2.1. Modelo Relacional O modelo relacional tem caracter´ısticas estruturadas h´a muito tempo, inclusive possui uma comunidade apenas para definir os padr˜oes adotados pelas diversas empresas que

implementam SGBDS, dentre os quais podemos ressaltar: Oracle1 , Microsoft SQL Server2 , MySQL3 e PostgreSQL4 . Dentre as principais caracter´ısticas de um SGBD, destacam-se: controle de concorrˆencia, seguranc¸a, recuperac¸a˜ o de falhas, gerenciamento do mecanismos de armazenamento de dados e controle das restric¸o˜ es de integridade do banco de dados. Outra importante func¸a˜ o de um SGBD e´ o gerenciamento de transac¸o˜ es. A execuc¸a˜ o de transac¸o˜ es em um SGBD deve obedecer a algumas propriedades a fim de garantir o correto funcionamento do sistema e a respectiva consistˆencia dos dados. Estas propriedades s˜ao chamadas ACID(Atomicidade, Consistˆencia, Durabilidade e Isolamento)[Gray et al. 1981]. Elas garantem que transac¸o˜ es sejam feitas com seguranc¸a, garantindo atomicidade de cada uma delas, consistˆencia dos dados, isolamento e integridade durante todas as transac¸o˜ es. Entretanto, garantir todos esses atributos pode acarretar em configurac¸o˜ es complexas e um p´essimo desempenho em uma transac¸a˜ o. Os conflitos surgem entre os diferentes aspectos da necessidade de garantir as propriedades ACID em sistemas distribu´ıdos[Hadjigeorgiou et al. 2013]. 2.2. Modelos n˜ao relacionais Nesta sec¸a˜ o e´ apresentado conceitos que envolvem o modelo n˜ao relacional quanto a sua arquitetura de funcionamento. E´ apresentado o Teorema CAP, os m´etodos de escalonamento vertical e horizontal e os m´etodos de particionamento em rede. 2.2.1. O Teorema CAP No ano 2000, no Simp´osio de Princ´ıpios de Computac¸a˜ o Distribu´ıda (ACM Symposium on the Principles of Distributed Computing), o Dr. Eric A. Brewer discursava sobre o seu trabalho te´orico na empresa que fundou, Inktomi. Na ocasi˜ao, Dr. Brewer mostrou em sua apresentac¸a˜ o que os sistemas executados em ambientes distribu´ıdos possuem trˆes n´ucleos fundamentais, e definiu uma relac¸a˜ o de funcionamento entre estes, de forma que apenas dois destes sejam genuinamente vi´aveis[Browne 2009]. O teorema CAP foi formalmente provado[Gilbert and Lynch 2002] em 2002, por Seth Gilbert e Nancy Lynch do MIT. Nascendo assim o teorema CAP. Trˆes n´ucleos fundamentais s˜ao[Browne 2009]: 1. (C - Consistency) Consistˆencia: Todos os n´os da rede necessitam ter a mesma vers˜ao do arquivo. 2. (A - Availability) Disponibilidade: Todos os clientes podem sempre encontrar pelo menos uma c´opia dos dados solicitados, mesmo que um cluster esteja desligado. 3. (P - Partition Tolerance): Tolerˆancia a partic¸o˜ es [na rede]. O sistema continua com seus dados, propriedades e caracter´ısticas mesmo se for implantado em servidores diferentes, transparente para o cliente. O teorema de CAP postula que apenas dois desses trˆes itens, citados acima, podem ser alcanc¸ados plenamente, ao mesmo tempo. Com isso, para garantir a melhor escalabilidade e armazenamento dos dados, foi proposto enfraquecer o atributo de consistˆencia, 1

http://www.oracle.com/br/index.html https://www.microsoft.com/pt-br/server-cloud/products/sql-server 3 https://www.mysql.com 4 https://www.postgresql.org 2

focando-se em melhorar a disponibilidade e a tolerˆancia de criar mais partic¸o˜ es. Foi dessa ideia que nasceu o conceito BASE (Basically Available, Soft state, Eventual consistency) com propriedades e filosofia oposta. Esse novo conceito considera um cen´ario que provˆe transac¸o˜ es distribu´ıdas, tolerˆancia a falhas de consistˆencia e replicac¸a˜ o otimista em um sistema distribu´ıdo, por´em essa e´ uma das abordagens na implementac¸a˜ o do banco de dados NoSQL usando esse teorema. Outras formas de pensar j´a foram divulgadas a` comunidade baseado no teorema CAP, onde e´ posto em evidˆencia o P (Partition Tolerance) e a partir deste faz-se variac¸o˜ es acerca dos outros dois n´ucleos, pois poder particionar os dados em v´arios clusters atrav´es da rede, e´ uma das vantagens na abordagem de banco de dados NoSQL, onde os sistemas de banco de dados relacionais mostram-se menos eficazes justamente por causa da ACID, explicado anteriormente na sec¸a˜ o 2.1. 2.2.2. Escalonamento horizontal e vertical No in´ıcio dos anos 2000, quando o mundo foi imerso pela crescente utilizac¸a˜ o da WEB e os dom´ınios “.com”, enquanto ainda surgiam questionamentos quanto ao funcionamento em si e o futuro econˆomico desse novo paradigma, houve, tamb´em, uma crescente preocupac¸a˜ o com a forma que essa grande e frequente quantidade de dados seria utilizada, armazenada e processada. Seguir com este aumento de dados exige t´ecnicas de expans˜ao de hardware, que hoje podem ser[Sadalage and Fowler 2012]: escalonamento vertical (scale-up) ou escalonamento horizontal (scale-out). Escalonamento vertical diz respeito a adquirir m´aquinas maiores, mais processadores, mais mem´oria prim´aria, aumento da mem´oria secund´aria, ou seja, aumentar os componentes de determinado servidor que atende as requisic¸o˜ es para determinada tarefa, no entanto, isso tende a se tornar extremamente caro com o passar do tempo, e uma hora ir´a esbarrar na pr´opria limitac¸a˜ o f´ısica da m´aquina, visto que h´a um limite para este tipo de crescimento. J´a o escalonamento horizontal visa aumentar o n´umero de servidores e dividir a carga entre eles formando um cluster. Esses servidores n˜ao precisam ser m´aquinas super potentes, e sim m´aquinas de menor custo (commodity server), o que deixaria o projeto bem mais barato do que o apresentado anteriormente. Outra caracter´ıstica positiva dessa abordagem e´ a resiliˆencia, onde e´ normal que m´aquinas apresentem problemas de funcionamento, no entanto, caso uma apresente neste modelo, n˜ao interferir´a no trabalho das outras (excec¸o˜ es se for um modelo masterslave e o que falhar for o master), atribuindo, assim, um aspecto de alta confiabilidade. Na Tabela 1 [Appuswamy et al. 2013] e´ apresentado uma an´alise comparativa dessas duas abordagens. Ao passo que a maioria das empresas percebe que a segunda alternativa e´ a mais vi´avel, surge um novo problema: bancos de dados relacionais n˜ao foram projetados para serem executados em clusters [Sadalage and Fowler 2012]. Os bancos relacionais atuais baseiam-se no conceito de um subsistema de disco compartilhado. Eles utilizam um sistema que reconhece o ambiente de cluster, por´em h´a uma rotina de replicac¸a˜ o para um disco de alta disponibilidade. Sendo assim, mesmo balanceando as cargas, ainda necessita de um ponto u´ nico, o que pode gerar falhas, caso ocorra algo com este ponto, todo o sistema fica comprometido. Todo esse gargalo com relac¸a˜ o aos clusters e aos bancos de dados relacionais,

Escalonamento Vertical

Pr´os

Contras

- Menor consumo de energia do que comparado a` m´ultiplos servidores.

- Alto custo a medida que a necessidade aumenta. - Maior risco de falha por estar localizado em um u´ nico ponto.

- Manutenc¸a˜ o de refrigerac¸a˜ o. - Custo com licenc¸as de softwares diminu´ıdas. - Escalonamento Horizontal

- Mais barato do que um u´ nico servidor robusto. - Lida bem com falhas no n´os. (Tolerˆancia a falhas). - Upgrade mais acess´ıvel.

- Limite f´ısico para crescimento. - Pode ser usado mais licenc¸as de softwares. - Maior custo com energia el´etrica. - Precisa de mais equipamentos de rede (switches/roteadores).

Tabela 1. Vantagens e desvantagens de escalonamento vertical e horizontal

levou grandes empresas a buscarem uma nova forma de armazenar os dados. Com isso, entra em cena duas empresas percussoras da arquitetura de dados e sistemas distribu´ıdos, Google e Amazon. Essas empresas no in´ıcio da d´ecada j´a projetavam suas soluc¸o˜ es para contornar esta falha dos modelos relacionais. Com isso, em 2004 a Google comec¸ava seu trabalho com o BigTable[Chang et al. 2008] e a Amazon, em 2005, com o Dynamo[DeCandia et al. 2007]. Ambas as empresas publicaram seus resultados para o p´ublico em geral, e por causa disso, se tornaram as percussoras e grandes influentes no mercado quando o assunto era sistemas distribu´ıdos em clusters e NoSQL. 2.2.3. M´etodos de particionamento em rede Uma das caracter´ısticas em NoSQL e´ a sua capacidade de executar em v´arios n´os da rede (particionamento). Sendo assim, a` medida que os dados fossem evoluindo, pode-se usar cluster de servidores para gerenciar e balancear as cargas. Cada modelo de distribuic¸a˜ o possui uma forma de armazenamento de dados, gerˆencia de tr´afego de rede com relac¸a˜ o a leitura e gravac¸a˜ o, ou mais disponibilidade quanto a atrasos e interrupc¸o˜ es na rede. Os benef´ıcios s˜ao muito atrativos para sua utilizac¸a˜ o, no entanto deve-se lembrar que existe v´arios custos relacionados. A execuc¸a˜ o em ambiente de cluster introduz uma complexidade muito alta, portanto n˜ao trata-se de algo trivial e s´o deve ser utilizada em casos em que os benef´ıcios sejam bastantes recompensadores. Atualmente, s˜ao discutidos dois m´etodos de distribuic¸a˜ o em rede de dados[Sadalage and Fowler 2012]: fragmentac¸a˜ o (sharding) e replicac¸a˜ o. De forma resumida, pode-se dizer que fragmentac¸a˜ o busca distribuir dados diferentes em v´arios pontos da rede, enquanto que a replicac¸a˜ o distribui os dados de um ponto u´ nico e os replica aos diversos n´os na rede. Essas duas t´ecnicas s˜ao diferentes, por´em n˜ao precisam ser implementadas isoladamente, podem se complementar. • Fragmentac¸a˜ o (Sharding): Trata-se de um processo para escalonamento horizontal, onde s˜ao postos diferentes conjuntos de dados em diferentes servidores. Em termos gerais, usu´arios diferentes consultam dados espec´ıficos em servidores

que contivessem a informac¸a˜ o buscada[Sadalage and Fowler 2012] . V´arios bancos de dados NoSQL j´a implementam a auto-fragmentac¸a˜ o, onde fica a cargo do banco de dados distribuir os dados e garantir que os mesmos sejam recuperados. Tamb´em e´ necess´ario frisar que em caso de falha em algum n´o, os dados deste n˜ao ficar˜ao mais dispon´ıveis, sendo assim podendo ter um sistema parcialmente indispon´ıvel. • Replicac¸a˜ o mestre-escravo: Uma distribuic¸a˜ o mestre-escravo acontece quando h´a replicac¸a˜ o de dados de um servidor mestre (prim´ario) aos servidores escravos (secund´arios). Um n´o e´ considerado como mestre (prim´ario), quando este e´ a fonte principal dos dados e onde s˜ao feitas as escritas. Este tipo de procedimento e´ u´ til quando estamos lidando com um ambiente onde tem-se muitas leituras de dados. No entanto, h´a a necessidade de mais processamento para o servidor mestre replicar as informac¸o˜ es aos escravos e uma eventual falha do mestre compromete o sistema quanto a` escrita de novas informac¸o˜ es. Um fator interessante nessa arquitetura diz respeito ao fato de que, se o mestre falhar, o sistema continua operando normalmente para leituras, isso e´ muito bom quando temos um ambiente que exige muito mais leitura que escrita. A falha no mestre pode ser lidada com a escolha de seu sucessor por um dos n´os escravos. Essa escolha pode ser autom´atica, programaticamente selecion´avel, ou manualmente selecionada pelo operador do sistema[Sadalage and Fowler 2012]. • Replicac¸a˜ o ponto a ponto: A replicac¸a˜ o mestre-escravo possui alguns gargalos com relac¸a˜ o a gravac¸a˜ o, por ter um ponto centralizador, e possivelmente de falhas para gravac¸o˜ es, dizemos que temos uma escalabilidade para leitura, n˜ao para gravac¸a˜ o. Com a replicac¸a˜ o ponto a ponto, divide-se os dados em v´arios n´os e todos tem a habilidade de gravar e ler os dados simultaneamente, eliminando a necessidade de sincronizac¸a˜ o das informac¸o˜ es de um n´o mestre. Por´em, novamente, esbarra-se no problema de consistˆencia visto anteriormente, tendo um agravante, pois a inconsistˆencia pode ser de gravac¸a˜ o, o que geraria problemas piores do que a inconsistˆencia de leitura. Para este problema h´a abordagens que podem ser utilizadas. A primeira e´ criar uma rotina que ao perceber uma nova atualizac¸a˜ o, esta seja sincronizada com todos os n´os e estes, atrav´es de um algoritmo, escolher se a atualizac¸a˜ o ser´a ou n˜ao aprovada. O algoritmo n˜ao precisa escolher gravar se a escolha for unˆanime, e sim de uma maioria dos n´os. A segunda, e´ ao lidarmos com as gravac¸o˜ es inconsistentes posteriormente, utilizando de heur´ısticas para mesclar essas gravac¸o˜ es. 2.3. NoSQL Nesta sec¸a˜ o e´ explanado acerca do hist´orico do NoSQL, as principais caracter´ısticas e os principais tipos de bancos de dados existentes hoje no Mercado. 2.3.1. Hist´orico O termo NoSQL foi utilizado pela primeira vez em 1998, por Carlo Strozzi[Nascimento 2015], como nome de seu SGBD, baseado no Modelo Relacional de c´odigo aberto (open source), sem interface SQL. Este banco de dados utilizava shell script para recuperar os dados, e estes, por sua vez, ficavam armazenados em forma

de arquivos ASCII, uma tupla era representada por uma linha com os campos separados por tabulac¸o˜ es, ou seja, n˜ao se assemelha em nada aos modelos de NoSQL atuais, assemelhando-se mais a um SGBD onde n˜ao se utilizava o modelo relacional para as consultas, pode ser melhor abordado como NoREL (No Relational), concluindo-se que, apesar do nome, o termo de Strozzi n˜ao teve influˆencia sobre o que ser´a abordado neste artigo. J´a o termo NoSQL como conhecemos atualmente foi introduzido no in´ıcio de 2009[Evans 2009] por um funcion´ario do Rackspace, Eric Evans, quando Johan Oskarsson, um desenvolvedor de software de Londres que trabalhava na Last.fm5 , organizou um evento para discutir bancos de dados open source distribu´ıdos. Este evento ocorreu em S˜ao Francisco, nos Estados Unidos. Johan estava interessado em descobrir mais sobre esses novos tipos de bancos, inspirados no BigTable6 e DynamoDB7 , Google e Amazon, respectivamente. Como ele dispunha de pouco tempo na cidade, viu que n˜ao era vi´avel visitar todas as empresas que estava participando do desenvolvimento desses softwares, ent˜ao decidiu realizar o evento e convidou a todos para mostrar seus trabalhos e discutir sobre o futuro da tecnologia. Este evento ficou conhecido como primeiro encontro NoSQL. Atualmente h´a diversas soluc¸o˜ es NoSQL implementadas, sendo majoritariamente Open Source, mostrando o interesse da comunidade em disseminar da forma mais a´ gil poss´ıvel essa nova tecnologia. Por´em, com isso, vem o que pode ser problem´atico a longo prazo, a quantidade relativamente grande de SGBD’s implementando diferentes padr˜oes NoSQL. Dentre eles citamos: Key-value, Document store, Column Store e Graphs.

2.3.2. Caracter´ısticas Os modelos n˜ao relacionais possuem algumas caracter´ısticas fundamentais que o diferenciam dos relacionais, dando-lhe vaz˜oes para gerenciamento de grandes quantidades de dados estruturados e semi-estruturados, bem como escalabilidade e replicac¸a˜ o. S˜ao elas[L´oscio et al. 2011]: • N˜ao utiliza SQL: Os bancos de dados relacionais s˜ao conhecidos pelo seu padr˜ao SQL, linguagem de consulta estruturada. J´a tratando-se de NoSQL, percebemos que os mesmos n˜ao utilizam esse padr˜ao, implementando suas pr´oprias API’s de consultas. Hoje o Cassandra, por exemplo, implementa uma linguagem bastante similar ao SQL, o CQL. Todavia, at´e hoje, n˜ao existe uma padronizac¸a˜ o de API’s de consultas para o NoSQL. Algo realmente esperado para os pr´oximos anos. • C´odigo aberto (Open-source): Uma caracter´ıstica importante e´ que eles s˜ao projetados, em sua maioria, em c´odigo aberto. N˜ao significa dizer que para ser um SGBD NoSQL precisa ser de c´odigo aberto, por´em a sua grande maioria o e´ . • WEB do s´eculo XXI: Os bancos de dados NoSQL vieram da necessidade de resolver gargalos enfrentados com o advento da WEB do s´eculo XXI, a dita WEB 2.0, sendo assim e´ normal relacionarmos o desenvolvimento destes terem sidos 5

http://last.fm https://cloud.google.com/bigtable 7 https://aws.amazon.com/pt/documentation/dynamodb 6

iniciados apenas ap´os o in´ıcio do milˆenio, o que exclui v´arios bancos com algumas caracter´ısticas similares. • Schemaless ou Esquemas dinˆamicos: Diferente dos modelos relacionais, o NoSQL n˜ao implementa uma forma de definic¸a˜ o r´ıgida dos dados, ou seja, campos podem ser retirados e inseridos sem a preocupac¸a˜ o de consistˆencia. Com isso ganha-se em escalabilidade de uma forma geral e tamb´em garante maior aumento da disponibilidade. • Consistˆencia eventual: E´ uma caracter´ıstica de bancos NoSQL relacionada ao fato da consistˆencia nem sempre ser mantida entre os diversos pontos de distribuic¸a˜ o de dados. Esta caracter´ıstica tem como princ´ıpio o teorema CAP (Consistency, Availability e Partition Tolerance). • Sharding: Particionamento horizontal e´ um princ´ıpio de projeto de banco de dados pelo qual as linhas de um banco de dados s˜ao armazenadas separadamente, em vez de serem quebradas em colunas (que e´ o que a normalizac¸a˜ o e o particionamento vertical fazem, para diferenciar extens˜oes). Cada partic¸a˜ o forma parte de um shard, que pode, por sua vez, ser instalada em um servidor de banco de dados ou localizac¸a˜ o f´ısica separada. Essas caracter´ısticas fazem parte de um sistema comum para reconhecimento do que e´ um SGBD NoSQL. Por´em, nenhuma delas define em 100% dos casos. Sendo uma melhor definic¸a˜ o, segundo Martin Fowler [Sadalage and Fowler 2012], como um conjunto de bancos de dados criados a partir do s´eculo XXI que n˜ao utilizam SQL e pensados para distribuic¸a˜ o em n´os de rede. 2.3.3. Tipos de banco de dados Nesta sec¸a˜ o e´ mostrado os quatro tipos de banco de dados relacionais existentes atualmente que s˜ao: Chave-Valor, Documentos, Fam´ılia de Colunas e Grafos. Aqui elenca-se as suas caracter´ısticas, trac¸ando um paralelo com alguns modelos relacionais e exemplificado com alguns representantes de cada um. • Bancos de dados de chave-valor: Um banco de dados chave-valor pode ser definido como um dep´osito hash simples. De forma que a chave prim´aria seja a principal fonte da busca na diferenciac¸a˜ o dos registros obtidos. De forma a uma melhor exemplificac¸a˜ o, imagina-se uma tabela de um banco de dados relacional, onde esta dever´a possuir duas colunas: CHAVE e VALOR. Na coluna CHAVE armazena-se dados do tipo texto, que dever´a conter algum crit´erio que permita a busca posteriormente, e a coluna VALOR e´ o valor agregado a CHAVE. Na Tabela 2[Sadalage and Fowler 2012], podemos verificar essas terminologias como seria no PostgreSQL (banco de dados relacional) e Riak (banco de dados n˜ao-relacional baseado em chave-valor). Os bancos de dados chave-valor s˜ao os mais simples NoSQL quando o assunto e´ com relac¸a˜ o a sua API (Application Programming Interface). Onde todas as operac¸o˜ es se d˜ao, basicamente, por meio das chaves, caso queira inserir, basta lanc¸ar o par chave-valor, caso a chave n˜ao exista ser´a lanc¸ado um novo registro, quando h´a a chave no banco, este atualiza o valor correspondente

PostgreSQL

Riak

Banco de dados Cluster riak Tabela Bucket Linha chave-valor OID Chave Tabela 2. Comparativo PostgreSQL e Riak

aquele registro. Bancos de dados baseados em chave-valor fazem acesso somente pela chave prim´aria, eles possuem, geralmente, um bom desempenho e f´acil escalabilidade[Sadalage and Fowler 2012]. Alguns dos bancos de dados de chave-valor mais populares s˜ao: Riak8 , Redis9 , Memcached DB10 e suas variedades, Berkeley DB11 , Amazon DynamoDB12 (n˜ao e´ open-source) e o Projeto Voldemort13 (uma implmentac¸a˜ o do open-source do Amazon DynamoDB). • Bancos de dados de documentos: Os bancos de dados baseados em documentos utilizam como conceito principal armazenar estruturas de dados de a´ rvores hier´arquicas e declarativas. Essas estruturas de dados podem ser XML (EXtensible Markup Language), JSON (JavaScript Object Notation), BSON (JSON em formato bin´ario), entre outros. Os documentos podem ser imaginados como os registros no banco de dados relacional, por´em estes n˜ao precisam ter o mesmo formato dos j´a inseridos anteriormente (Schemaless). Bancos de dados de documentos s˜ao bastante parecidos com os de chave-valor, por´em, diferentemente, aqui os valores podem ser verificados e estes podem ser, inclusive, referˆencias a outros documentos. Na Tabela 3[Sadalage and Fowler 2012] vemos a comparac¸a˜ o de terminologias entre PostgreSQL e MongoDB. PostgreSQL

MongoDB

Banco de dados Instˆancia MongoDB Esquema Banco de dados Tabela Colec¸o˜ es Linha Documento OID id Junc¸a˜ o DBRef Tabela 3. Comparativo PostgreSQL e MongoDB

O campo “ id”´e um campo especial no MongoDB, este existe em todo documento criado, e e´ criado automaticamente. O usu´ario pode definir o valor deste campo, contanto que este seja u´ nico na colec¸a˜ o. Os bancos de dados de documentos adotam o modelo schemaless, ou seja n˜ao e´ preciso definir um esquema 8

http://basho.com/products http://redis.io 10 http://memcachedb.org 11 http://www.oracle.com/technetwork/database/database-technologies/berkeleydb 12 https://aws.amazon.com/pt/documentation/dynamodb 13 http://www.project-voldemort.com/voldemort 9

para uma determinada colec¸a˜ o, na mesma colec¸a˜ o e´ poss´ıvel ter documentos totalmente diferentes entre si, algo que n˜ao acontece no modelo relacional, onde devemos definir um esquema de colunas, e todas as linhas daquela tabela dever˜ao obedecer ao padr˜ao de colunas criado. Em documentos n˜ao h´a atributos vazios[Sadalage and Fowler 2012], quando um valor n˜ao e´ encontrado, e´ suposto que este n˜ao foi configurado anteriormente e, portanto, n˜ao e´ relevante para a consulta. Os bancos de dados baseados em documentos mais populares atualmente s˜ao: MongoDB14 , CouchDB15 , Terrastore16 , OrientDB17 , RavenDB18 e o Lotus Notes19 . • Bancos de dados em fam´ılias de colunas: O armazenamento em fam´ılia de colunas ficaram bastante conhecidos devido a sua primeira implementac¸a˜ o, o Google Big Table[Chang et al. 2008]. Nesse modelo h´a tamb´em muitas similaridades a sua API de manipulac¸a˜ o de dados e a o padr˜ao SQL (Structered Query Language). Esse modelo armazena os dados em chaves mapeadas para valores, e os valores s˜ao agrupados em fam´ılias de colunas, cada uma dessas fam´ılias de colunas funcionando como um mapa de dados. Diferente do modelo relacional, onde os dados s˜ao agrupados por linhas seguindo um esquema pr´e-estabelecido de colunas, ou seja, as linhas precisam seguir aquele leiaute, j´a aqui tem-se esse paradigma trocado, onde as informac¸o˜ es est˜ao em colunas, e o conjunto dessas colunas forma uma fam´ılia de colunas. Na Tabela 4[Sadalage and Fowler 2012] trac¸a-se um paralelo de conceitos entre o modelo relacional com PostgreSQL e este novo modelo representado pelo Cassandra. PostgreSQL

Cassandra

Banco de dados Keyspace Tabela Fam´ılia de colunas Linha Linha Coluna (a mesma para todas as linhas) Colunas (podem ser diferentes por linha) Tabela 4. Comparativo PostgreSQL e Cassandra

As fam´ılias de colunas armazenam os seus dados em um conjunto onde as informac¸o˜ es, geralmente, s˜ao associadas, fazendo disso uma chave de linha. Elas s˜ao um grupo de dados relacionados onde o seu acesso se d´a de maneira uniforme, ou seja, s˜ao acessados juntos. Para melhor entendimento, verifica-se o acesso de um perfil de um cliente para listar seus pedidos, no modelo relacional este se d´a atrav´es de junc¸o˜ es, com a tabela de clientes e a tabela de pedidos, no entanto, torna-se computacionalmente custoso essa transac¸a˜ o. Na fam´ılia de colunas temse um ID para identificar a linha do cliente, e nas colunas desse cliente tem-se todas as informac¸o˜ es pertinentes a este, bem como as informac¸o˜ es de pedidos, 14

https://www.mongodb.org http://couchdb.apache.org 16 https://code.google.com/archive/p/terrastore 17 http://orientdb.com/orientdb 18 https://ravendb.net 19 https://www.ibm.com/developerworks/lotus 15

parecido com o que temos no modelo de documentos JSON, onde h´a informac¸a˜ o hierarquizada. • Banco de de dados de Grafos: Os bancos de dados em grafos utilizam conceitos da Teoria dos Grafos para estruturar seus dados. Basicamente, a topologia de um grafo G pode ser expressa como G = (V, E), onde V e´ o conjunto de v´ertices (nodos) e E e´ o conjunto de arestas. Cada aresta representa uma relac¸a˜ o entre dois nodos. Um conjunto de v´ertices conectados por meio de arestas definem um caminho no grafo. No modelo de dados em Grafos temos a figura da Entidade, que seria o v´ertice no grafo, esta entidade possui propriedades. Os relacionamentos entre as Entidades s˜ao as arestas, e estas tamb´em possuem propriedades, sendo uma caracter´ıstica essencial o direcionamento entre as arestas e os nodos. Dessa forma pode-se construir consultas otimizadas a esses relacionamentos. Atualmente tem-se muitos bancos de dados baseados em grafos, tais como Neo4J20 , Infinite Graph21 , o OrientDB22 e o FlockDB23 . Com relac¸a˜ o a consistˆencia nesse modelo, temos uma diferenc¸a em relac¸a˜ o aos outros modelos n˜ao-relacionais mostrados at´e agora, podemos ver que a maioria dos bancos de dados em grafos implementam as propriedades ACID[Sadalage and Fowler 2012], isso se d´a porque as soluc¸o˜ es implementadas atualmente n˜ao suportam a distribuic¸a˜ o dos nodos em um cluster de servidores, por´em o Infinite Graph24 possui essa funcionalidade. 2.4. MongoDB MongoDB e´ um banco de dados de c´odigo aberto, n˜ao relacional orientado a documentos, que provˆe mecanismos para aumento de performance, alta disponibilidade e escalonamento horizontal autom´atico. A API de manipulac¸a˜ o de dados, que ser´a mostrada na implementac¸a˜ o do estudo de caso, deriva do conceito de ORM (Object Relational Map), Mapeamento Objeto-Relacional, para ODM (Objetct Document Model), Mapeamento Objeto-Documento. Esta t´ecnica, por sua vez, determina a interoperabilidade entre a programac¸a˜ o orientada a objetos e os modelos relacionais de banco de dados. 2.4.1. Documentos Um registro em MongoDB e´ um documento, que por sua vez e´ uma estrutura que consiste em um par de chave e valor, por´em, diferentemente de um outro banco Chave-Valor, este par pode ser aninhado com outros pares dessa mesma estrutura, algo bastante similar ao que j´a temos com objetos JSON (Java Script Object Notation), que e´ um formato leve para intercˆambio de dados computacionais, no entanto, em MongoDB, temos uma melhoria dessa estrutura de dados, onde o seu armazenamento e´ feito em BSON, que e´ o documento JSON guardado e indexado em forma bin´aria, isso traz muitas melhorias com relac¸a˜ o a velocidade de acesso e manipulac¸a˜ o das informac¸o˜ es, em contra-partida, documentos BSON s˜ao maiores o que gera maior tamanho em disco. Um documento 20

http://neo4j.com http://www.objectivity.com/products/infinitegrap 22 http://orientdb.com/orientdb 23 https://github.com/twitter/flockdb 24 http://www.objectivity.com/products/infinitegraph 21

em MongoDB e´ equivalente a um registro no banco de dados relacional. O c´odigo 1 exemplifica um documento JSON utilizado pelo MongoDB[MongoDB 2016]. ´ Codigo 1 - Exemplo de objeto JSON 1 2

{ "address": { "building": "1007", "street": "Morris Park Ave", "zipcode": "10462" }, "borough": "Bronx", "cuisine": "Bakery", "name": "Morris Park Bake Shop", "restaurant_id": "30075445"

3 4 5 6 7 8 9 10 11 12

}

2.4.2. Colec¸o˜ es Colec¸o˜ es em MongoDB s˜ao um conjunto de documentos. Semelhante ao que temos no modelo relacional, as tabelas. No entanto, temos nas colec¸o˜ es a falta de esquema que e´ caracter´ıstica forte nos modelos n˜ao-relacionais, ou seja, uma colec¸a˜ o n˜ao precisa que todos os seus documentos tenham as mesmas quantidades de pares e valores, ou mesmo equidade de tipos. 2.4.3. Recuperac¸a˜ o de dados As operac¸o˜ es de manipulac¸a˜ o de dados em MongoDB se d´a atrav´es da sua API. Dentro do MongoShell (cliente do MongoDB) esta se dar´a de forma nativa, diferente do driver, onde usa-se uma linguagem baseada em ODM (Object Document Model) que simula, atrav´es do pr´oprio c´odigo, as consultas e manipulac¸o˜ es da API. Diferentemente do SQL, onde as querys s˜ao passadas diretamente do driver para o banco, aqui n˜ao se faz necess´ario. A API de manipulac¸a˜ o do MongoDB e´ bastante rica e possui muitas caracter´ısticas que deixar´a, dificilmente, um desenvolvedor sem opc¸o˜ es para resolver determinado problema.

3. Metodologia Para exemplificar os conceitos discorridos at´e agora, foi implementado uma aplicac¸a˜ o que usa os conceitos de banco de dados n˜ao relacional. Ela e´ uma aplicac¸a˜ o WEB usando Java e MongoDB para consulta e manipulac¸a˜ o de informac¸o˜ es referentes a um cat´alogo de restaurantes. Nela o usu´ario poder´a consultar restaurantes por enderec¸o, nome e cidade. Poder´a, tamb´em, mesclar as consultas em uma u´ nica usando o full text search do MongoDB e cadastrar um novo restaurante no cat´alogo. Para esta aplicac¸a˜ o foi usado o driver Java do MongoDB, API de consultas diretamente da linguagem, que se assemelha bastante com a implementada no MongoShell.

Tamb´em foi utilizado uma base de dados disponibilizada na documentac¸a˜ o do MongoDB, que consiste em uma colec¸a˜ o de documentos JSON com informac¸o˜ es de restaurantes, como nome, enderec¸o e avaliac¸a˜ o de qualidade.

4. An´alise dos dados Nesta sec¸a˜ o e´ mostrado como foi desenvolvido a aplicac¸a˜ o com MongoDB, demonstrando as classes criadas e os servic¸os utilizadas como base para tal. 4.1. Estudo de caso Para reproduc¸a˜ o dos exemplos de uso do MongoDB foram necess´arios conhecimentos b´asicos da linguagem Java com JSF, Primefaces e uso na ferramenta Eclipse, bem como a criac¸a˜ o de projetos utilizando Maven. Para a implementac¸a˜ o foram utilizados as seguintes vers˜oes: a JDK 1.8, Maven 3.3.9, MongoDB 3.22 no ambiente de desenvolvimento Eclipse Mars. Os drivers referentes API de Java para MongoDB podem ser baixados do pr´oprio site ou carregando as dependˆencias via Maven. Para fazer uso das func¸o˜ es da API do MongoDB com o driver Java, foram constru´ıdos m´etodos que realizam, primeiramente, as operac¸o˜ es b´asicas para conex˜ao com a base e manipulac¸a˜ o das informac¸o˜ es. No contexto da colec¸a˜ o de restaurantes foi usado m´etodos que acessam as informac¸o˜ es desses com base em busca realizada pelo usu´ario nos campos desta colec¸a˜ o. Sendo assim, a aplicac¸a˜ o tem as seguintes classes: • Connection.java : Classe respons´avel por prover as conex˜oes do MongoDB para aplicac¸a˜ o; • RestaurantDAO.java : Classe respons´avel por prover os m´etodos que manipulam as informac¸o˜ es referentes aos restaurantes; • UsersDAO.java : Classe respons´avel por prover os m´etodos que manipulam as informac¸o˜ es referentes aos usu´arios, incluindo o controle de acesso; • User.java : Classe que modela as caracter´ısticas dos usu´arios do sistema; • Restaurant.java : Classe que modela as carater´ısticas dos restaurantes, usada para receber os valores do banco. Al´em dessas, foram usadas classes beans, que s˜ao as classes anotadas como Managed Bean referentes ao framework JSF (Java Server Faces) para acesso, controle e manutenc¸a˜ o das p´aginas webs criadas (.xhtml). Como citado acima, a classe Connection provˆe o mecanismo para acessar o banco de dados, esta interface se d´a atrav´es do driver desenvolvido pela pr´opria empresa MongoDB para Java. Essa implementac¸a˜ o difere do usual pela sua enorme facilidade e por n˜ao exigir registro de classes, m´etodos de abertura e fechamento, tamb´em n˜ao exigindo URL de conex˜ao, caso n˜ao seja passado estes como parˆametro da chamada do m´etodo “getDatabase”, ele ir´a pedir apenas o nome do banco de dados e se conectar´a automaticamente na m´aquina local (localhost) na porta 27017 (porta padr˜ao). A seguir, no C´odigo 2, e´ mostrado sua implementac¸a˜ o. ´ ˜ com o MongoDB Codigo 2 - Classe de conexao 1 2

public class Connection { private static MongoClient mongoClient;

3 4 5 6 7 8 9 10

private Connection (){ } public static MongoDatabase getConnection (){ mongoClient = new MongoClient (); MongoDatabase db = mongoClient.getDatabase ("test "); return db; } }

Vˆe-se que no c´odigo mostrado, a classe MongoDatabase e´ respons´avel por guardar a instˆancia de conex˜ao provida pela classe MongoClient, nesta e´ passado em sua chamada ao m´etodo “getDataBase” o nome do banco de dados a ser recuperado. Nota-se que n˜ao e´ preciso passar os dados de conex˜ao com o servidor, como enderec¸o e porta, e´ poss´ıvel passar esses argumentos, como usualmente e´ feito nas aplicac¸o˜ es com modelos relacionais. Devido a sua natureza NoSQL, e´ poss´ıvel invocar v´arios servidores na chamada deste m´etodo, implementando assim o conceito visto na sec¸a˜ o de caracter´ısticas do NoSQL o conceito de sharding e replication. No c´odigo 3, a seguir, podese ver como seria a implementac¸ao desse c´odigo, de acordo com a documentac¸a˜ o do MongoDB[MongoDB 2016]. ´ Codigo 3 - Modelo de chamada de servidores 1 2 3 4

MongoClient mongoClient = new MongoClient (Arrays.asList ( new ServerAddress ("localhost", 27017), new ServerAddress ("localhost", 27018), new ServerAddress ("localhost", 27019)));

Por padr˜ao, todas as leituras e escritas s˜ao feitas no servidor prim´ario, mas e´ poss´ıvel que as leituras sejam feitas nos servidores secund´arios, para isso e´ necess´ario configurar as preferˆencias de leitura conforme c´odigo a seguir. 1 2

mongoClient.setReadPreference (ReadPreference.secondaryPreferred ());

Na classe RestaurantDAO, s˜ao feitas todas as interac¸o˜ es de manipulac¸a˜ o de dados com a base de dados. No c´odigo 4, o m´etodo “getAllRestaurants”espera como parˆametro um inteiro que representa o n´umero de linhas a serem retornadas na consulta, que por sua vez traz todos os dados da colec¸a˜ o “restaurant”. ´ ´ Codigo 4 - Metodo de busca de registros 1 2 3 4 5 6 7 8 9

public List getAllRestaurants (int limit){ FindIterable it = db.getCollection ("restaurants"). find ().sort (new Document ("name", -1)).limit (limit); List rests = new ArrayList (); it.forEach (new Block () { @Override public void apply (final Document t) { Restaurant rest = new Restaurant (); rest.setAddressBuilding ( (String) ( (Document) t.get ("address")).getString ("building")); rest.setAddressStreet ( (String) ( (Document) t. get ("address")).getString ("street"));

10 11 12 13 14 15 16 17 18 19

rest.setAddressZipCode ( (String) ( (Document)t. get ("address")).getString ("zipcode")); rest.setBorough ( (String) t.get ("borough")); rest.setCuisine ( (String) t.get ("cuisine")); rest.setName (t.get ("name").toString ()); rests.add (rest); } }); return rests; }

Nessa consulta a quantidade de registros est´a de acordo com o parˆametro passado no m´etodo “limit”, e´ percebido que h´a um m´etodo que ordena o resultado pelo campo “name”. No MongoDB e´ usado o m´etodo “sort”aninhado a` consulta, e e´ passado como parˆametro um Documento contendo o campo a ser ordenado e o tipo de ordenac¸a˜ o, que no caso e´ 1 para crescente e -1 para decrescente. Se fosse necess´ario usar um crit´erio para a busca das informac¸o˜ es usando esta API, precisava-se passar como parˆametro ao m´etodo “find”um ou mais Documentos contendo os pares, chave e valor, a serem buscados. Pode-se ver o exemplo desse caso no c´odigo 5, a seguir, onde e´ passado um objeto do tipo Document, este objeto deve ser preenchido previamente com os valores a serem buscados como crit´erio. ´ ´ ˜ de registros Codigo 5 - Metodo de obtenc¸ao 1 2 3 4 5 6 7 8 9 10 11

12

13

14 15 16 17 18

public List getDocumentsByCriteria (Document document , int limit){ //consulta para recuperar restaurantes dado um criterio FindIterable it = db.getCollection (" restaurants").find (document).limit (limit); List rests = new ArrayList (); it.forEach (new Block () { @Override public void apply (final Document t) { Restaurant rest = new Restaurant (); rest.setAddressBuilding ( (String) ( ( Document) t.get ("address")). getString ("building")); rest.setAddressStreet ( (String) ( ( Document) t.get ("address")). getString ("street")); rest.setAddressZipCode ( (String) ( ( Document)t.get ("address")).getString ("zipcode")); rest.setBorough ( (String) t.get (" borough")); rest.setCuisine ( (String) t.get (" cuisine")); rest.setName (t.get ("name").toString ()) ;

19 20 21 22 23 24

rests.add (rest); } }); return rests; }

A estrutura do MongoDB foi implementada visando a simplicidade de operac¸o˜ es que utilizam o seu framework, e busca sempre se manter em consonˆancia com os comandos utilizados no seu shell, dado a sua disponibilidade na plataforma utilizada. As operac¸o˜ es de inserc¸a˜ o, delec¸a˜ o e atualizac¸a˜ o, tamb´em mostram-se muito simples devido ao seu modelo schemaless ou esquema dinˆamico, e v´arias operac¸o˜ es s˜ao bastante simplificadas. Ao verificar o c´odigo 6, a seguir, e´ poss´ıvel ver sua implementac¸a˜ o. ´ ´ ˜ de dados Codigo 6 - Metodos de acesso e manipulac¸ao 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public void updateRestaurant (Document criteria, Document toUpdate){ db.getCollection ("restaurants").updateMany (criteria, new Document ("\$set", toUpdate)); } public void replaceRestaurant (Document criteria, Document toReplace){ db.getCollection ("restaurants").replaceOne (criteria, toReplace); } public void deleteRestaurant (Document criteria){ db.getCollection ("restaurants").deleteMany (criteria); } public void insertRestaurant (Document t){ db.getCollection ("restaurants").insertOne (t); }

Nesses m´etodos s˜ao definidas as suas caracter´ısticas de utilizac¸a˜ o conforme se segue: • void insertOne (TDocument document): Insere o documento provido. Caso este n˜ao possua um identificador, o driver dever´a cri´a-lo. Caso a colec¸a˜ o passada n˜ao exista, o driver tamb´em criar´a a colec¸a˜ o. • void insertMany (List documents): Insere uma lista de Documentos na colec¸a˜ o passada. • UpdateResult updateOne (Bson filter, Bson update): Atualiza um documento de acordo com os parˆametros passados como crit´erio, sendo o primeiro o filtro e o segundo o valor a atualizar. • DeleteResult deleteOne (Bson filter): Remove um documento da colec¸a˜ o conforme o filtro passado como argumento. • UpdateResult replaceOne (Bson filter, TDocument replacement): Substitui um documento inteiro da colec¸a˜ o de acordo com o filtro passado. Com o conhecimento desses comandos b´asicos, de como funciona a estrutura, pode-se implementar uma aplicac¸a˜ o web, ou standalone de forma bastante simplificada e

usando o melhor que o NoSQL pode oferecer para que aplicac¸o˜ es performem satisfatoriamente com alto volume de dados. Na figura 1, e´ mostrada a tela de busca dos dados utilizada no sistema desenvolvido.

Figura 1. Tela de busca de restaurantes

5. Considerac¸o˜ es Finais Neste artigo foi visto a hist´oria por tr´as da criac¸a˜ o do NoSQL, os conceitos b´asicos para o reconhecimento dessas aplicac¸o˜ es, fundamentac¸a˜ o de pontos chaves na implementac¸a˜ o de uma soluc¸a˜ o n˜ao relacional com escalabilidade horizontal e implementando o Teorema CAP. Foi visto tamb´em as caracter´ısticas das principais implementac¸o˜ es existentes no Mercado e suas comparac¸o˜ es com outros bancos relacionais. E por fim, foi mostrado um estudo de caso usando MongoDB, para demonstrar como e´ usada a API de consultas e o seu driver desenvolvido para a plataforma Java. Com base nisso, este trabalho agrega o conhecimento necess´ario para o entendimento dos modelos n˜ao relacionais de gerenciamento de dados, e como este relaciona-se com os modelos relacionais existentes. Aqui tem-se tamb´em, os conhecimentos iniciais para o desenvolvimento de uma aplicac¸a˜ o que o usa o driver para Java do MongoDB. Diante deste artigo, sugere-se como trabalhos futuros o aprofundamento na quest˜ao de escalabilidade horizontal, dando eˆ nfase aos algoritmos de mapeamento e reduc¸a˜ o (MapReduce), visando a verificac¸a˜ o da eficiˆencia quanto a disponibilidade e consistˆencia em ambiente de cluster. Tamb´em pode-se verificar as outras API’s de consultas dos outros SGBD’s, bem como sua integrac¸a˜ o com as linguagens de programac¸a˜ o atuais atrav´es de seus frameworks. Por fim, percebe-se que estamos no in´ıcio de uma caminhada em tecnologia bastante promissora, que se apoia nas costas de gigantes, como Google, Amazon e Facebook, que a cada dia contribuem com o fomento e disseminac¸a˜ o dessa nova forma de manipular e armazenar nossos dados. Vale ressaltar que o modelo relacional ainda e´ o mais apropriado para a maioria dos casos e, principalmente, onde o crescimento dos dados n˜ao seja t˜ao grande.

Referˆencias Appuswamy, R., Gkantsidis, C., Narayanan, D., Hodson, O., and Rowstron, A. (2013). Scale-up vs scale-out for hadoop: Time to rethink? In Proceedings of the 4th annual Symposium on Cloud Computing, page 20. ACM. Brito, R. W. (2010). Bancos de dados nosql x sgbds relacionais: an´alise comparativa. Faculdade Farias Brito e Universidade de Fortaleza. Browne, J. (2009). Brewer’s CAP Theorem – Dispon´ıvel em: http://www. julianbrowne.com/article/viewer/brewers-captheorem. Acessado em: 01/06/2016. Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M., Chandra, T., Fikes, A., and Gruber, R. E. (2008). Bigtable: A distributed storage system for structured data. ACM Transactions on Computer Systems (TOCS), 26(2):4. DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P., and Vogels, W. (2007). Dynamo: amazon’s highly available key-value store. In ACM SIGOPS Operating Systems Review, volume 41, pages 205–220. ACM. Evans, E. (2009). NoSQL – 2009. Dispon´ıvel em: http://blog.sym-link.com/ 2009/05/12/nosql_2009.html. Acessado em: 03/06/2016. Fowler, A. (2015). NoSQL for Dummies. John Wiley & Sons. Gilbert, S. and Lynch, N. (2002). Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News, 33(2):51–59. Gray, J. et al. (1981). The transaction concept: Virtues and limitations. In VLDB, volume 81, pages 144–154. Hadjigeorgiou, C. et al. (2013). Rdbms vs nosql: Performance and scaling comparison. Leavitt, N. (2010). Will nosql databases live up to their promise? Computer, 43(2):12–14. L´oscio, B. F., OLIVEIRA, H. R. d., and PONTES, J. C. d. S. (2011). Nosql no desenvolvimento de aplicac¸o˜ es web colaborativas. VIII Simp´osio Brasileiro de Sistemas Colaborativos, Brasil. MongoDB (2016). Documentac¸a˜ o MongoDB – Dispon´ıvel em: http://api. mongodb.com/java/3.0, Acessado em: 01/06/2016. Nascimento, J. C. (2015). Introduc¸a˜ o ao NoSQL. Rubinstein, I. S. and Good, N. (2013). Privacy by design: A counterfactual analysis of google and facebook privacy incidents. Berkeley Tech. LJ, 28:1333. Sadalage, P. J. and Fowler, M. (2012). NoSQL distilled: a brief guide to the emerging world of polyglot persistence. Pearson Education. Vieira, M. R., FIGUEIREDO, J. M. d., Liberatti, G., and Viebrantz, A. F. M. (2012). Bancos de dados nosql: conceitos, ferramentas, linguagens e estudos de casos no contexto de big data. Simp´osio Brasileiro de Bancos de Dados.