DIFERENÇAS NO DESENVOLVIMENTO DE APLICAÇÕES WEB COM BD TRADICIONAL E BD NOSQL MONGODB

Transcrição

1 DIFERENÇAS NO DESENVOLVIMENTO DE APLICAÇÕES WEB COM BD TRADICIONAL E BD NOSQL MONGODB Nicolas Ignacio RYBERG 1.2 ; Angelo Augusto FROZZA 3 ; Daniel de Andrade VARELA 3 Identificação autores: 1 Bolsista PIBIC-EM/CNPq; 2 Curso Téc. em Informática; 3 Professor IFC-Camboriú. Resumo Este trabalho busca fazer uma introdução aos bancos de dados (BDs) NoSQL, apresentando os principais conceitos e características desse novo paradigma. Para demonstrar as diferenças no uso de diferentes paradigmas de BDs, foram desenvolvidas duas versões de uma aplicação web na arquitetura cliente-servidor: uma utilizando BD Relacional e outra usando BD NoSQL. 1. Introdução Durante décadas, foram usados bancos de dados (BDs) relacionais para armazenar dados estruturados. Porém, com o avanço da Internet, tem-se quantidades de dados nunca antes trabalhadas (Big Data), além destes estarem cada vez menos estruturados. São exemplos, os dados contidos em sites como Facebook, Google e Amazon. Estas empresas buscaram meios eficientes e baratos para processar seus dados. A solução encontrada foi a escalabilidade horizontal, que significa aumentar o número de máquinas, ao invés de aumentar o poder de processamento de uma máquina (escalabilidade vertical). Os BDs NoSQL chegaram como solução para este problema, já que permitem o gerenciamento em larga escala de dados distribuídos. Entre suas características, destacam-se: não-relacional, distribuído, de código aberto, escalável horizontalmente, ausência de esquema ou esquema flexível, suporte à replicação nativo e acesso via APIs simples. Alguns conceitos relevantes: Modelo de Dados: é como se percebem e se manipulam os dados (SALADAGE; FOWLER, 2013). Informalmente, entende-se como o modelo de dados de um aplicativo. Neste artigo, refere-se à forma que o Sistema Gerenciador de Banco de Dados (SGBD) organiza seus dados. Modelo Relacional: é o modelo de dados padrão dos BDs relacionais. Representa um conjunto de tabelas relacionadas por colunas em comum. Cada tabela possui linhas e colunas, sendo cada linha uma entidade de interesse e as colunas são os atributos desta entidade. A menor unidade de informação armazenada é a tupla (registro). Paradigmas NoSQL: BDs NoSQL se diferenciam de acordo com seu paradigma, sendo os principais: Orientado a documentos (BDOD), Armazém Chave-Valor (key-value), Orientado a colunas, Orientado a grafos. Uma característica comum entre estes paradigmas é que eles podem manipular dados agregados. Modelo Orientado a Agregados: é um modelo de dados para estruturas mais complexas. Agregado é um tipo de registro complexo, com listas e outras estruturas de dados aninhadas, e leva em consideração como os dados são acessados. Um Agregado é um conjunto de objetos relacionados que se deseja tratar como uma unidade (SALADAGE; FOWLER, 2013).

2 BDs Orientado a Documentos (BDOD): Documentos são coleções de atributos e valores armazenados em formatos como JSON, XML ou PDF. Este tipo de BD é considerado como o flexível, poderoso e popular entre todos os NoSQL (MCCREARY; KELLY, 2014). Um Documento implica em como os dados estão estruturados e devem ser apresentados, tornando-o altamente eficiente para o armazenamento de dados semiestruturados. Documentos diferentes de uma mesma coleção podem ter diferentes números de campos ou propriedades (PEREIRA, 2014), além de permitir que um documento seja embutido em outro. Os principais BDs nessa categoria são o MongoDB e o CouchDB. MongoDB: É um dos principais BDs NoSQL orientado a documentos. Nele, os documentos são serializados no formato JSON (JavaScript Object Notation) (Figura 1) e são armazenados fisicamente em BSON (codificação binária do JSON). Os documentos são agrupados em coleções, em conformidade com a sua estrutura (PEREIRA, 2014). Documentos com diferentes estruturas também podem ser armazenados na mesma coleção (BERNARDINO; ABRAMAHOVA, 2013). Figura 1 - Exemplo de documento JSON (Fonte: elaborado pelo autor, 2016) O objetivo deste trabalho é adquirir domínio sobre os conceitos de BDs NoSQL e desenvolver material para introduzir esse tipo de BDs nos cursos do IFC-Camboriú, além de identificar linhas de pesquisa ligadas à BDs NoSQL. 2. Material e métodos Este projeto tem caráter bibliográfico e exploratório, pelo qual se propõe fazer um estudo sobre a tecnologia de BD chamada NoSQL. Para atingir os objetivos propostos, primeiro foram feitas pesquisas para entender os conceitos relacionados aos BDs NoSQL, seus diferentes paradigmas e que dados são tratados em cada paradigma. Identificar em que caso um BD NoSQL é melhor que um BD relacional, apresentar os principais produtos (nomes) de banco de dados NoSQL existentes, classificando-os de acordo com o paradigma suportado e apresentar as características de cada BD NoSQL identificado durante a pesquisa.

3 Com os resultados da pesquisa, foi desenvolvida uma Wiki, acessível em: (GEATI, 2016). Para melhor entendimento do funcionamento de um BD NoSQL em relação a um BD relacional, foram feitos dois sites cliente-servidor, com a mesma estrutura do lado do cliente, diferindo no lado servidor. O primeiro usa os SGBDs relacionais MySQL e PostgreSQL, e o segundo, usa o BD NoSQL MongoDB. Com os resultados obtidos foi feita uma análise sobre o desenvolvimento dos dois sistemas. Por fim, as diferenças na implementação dos dois sistemas foram discutidas como resultados finais deste trabalho. 3. Resultados e discussão Aplicação proposta serve para era entender as diferenças de modelagem e manipulação de diferentes BDs. Para tanto, foi desenvolvido um sistema de loja virtual, no qual o cliente se autentica através de um login para acessar a aplicação. O cadastro e exclusão de usuário é feito por ele próprio na página inicial. Uma vez autenticado na loja, o usuário adiciona itens ao carrinho de compras, visualiza os itens do carrinho, remove itens do carrinho, finaliza a compra e visualiza a nota fiscal. A aplicação não possui nenhuma estilização de layout, uma vez que o foco do trabalho não é o desenvolvimento web, mas sim, entender as diferenças no acesso aos dados em BD. Porém, essa limitação não interfere no funcionamento do site ou nos resultados. Para uma comparação mais precisa, o desenvolvimento da aplicação foi separado em dois níveis, cliente e servidor, sendo que o lado cliente é exatamente igual para as duas aplicações. Para tal, foi usado o conceito de programação AJAX, pelo qual separa-se completamente os lados cliente e servidor e, desde que o cliente receba a mesma resposta do servidor, independe o que aconteça neste último. Para a aplicação server side usando BD relacional, a criação do BD se deu através de queries CREATE TABLE com os respectivos Primary keys e Foreign Keys. Os dados da tabela Produto, necessários antes de colocar o site em funcionamento, foram inseridos através de queries INSERT. A conexão com o BD foi feita através de um include do documento _database.php, sempre que a página PHP fosse executar qualquer tipo de query. O fragmento de código a seguir é usado para a conexão com o BD MySQL: <?php $pdo = new PDO('mysql:host=localhost; dbname=relacional','root','',[]); Para demonstrar o uso de todos os tipos de querys, foram criadas opções de inserir, selecionar, excluir e atualizar. Como exemplo, a seguir são apresentados fragmentos do código das páginas que tinham essas operações: Cadastrar usuário: $stmt = $pdo->prepare('insert INTO cliente(nome, login, senha, cpf, rg, data_nascimento) VALUES(?,?,?,?,?,?)'); $result = $stmt execute([$_post['nome'],$_post['login'], $_POST['senha'], POST['cpf'], POST['rg'],POST['data_nascimento']]);

4 Verificar Login: $stmt=$pdo->prepare("select * FROM cliente WHERE login=? and senha=?"); $stmt->execute([$login,$senha]); $result = $stmt->fetchall (PDO::FETCH_ASSOC); Excluir usuário: $stmt = $pdo->prepare("delete FROM cliente WHERE login =? and senha =?"); $result = $stmt execute([$login,$senha]); Alterar senha: $stmt=$pdo->prepare("update cliente SET senha=? WHERE login=? and senha=?"); $stmt->execute([$novasenha, $login, $senha]); $result = $stmt->fetchall(pdo::fetch_assoc); Para a aplicação server side usando o BD MongoDB, a criação do banco de dados é dinâmica, através do método insertone(), pelo qual os relacionamentos ocorrem ao inserir um objeto dentro de outro. Os objetos são manipulados através dos métodos: update(), find() e delete() (MONGODB, 2016). Os dados da tabela Produto, foram inseridos diretamente no SGBD pelo mesmo método insert(). O fragmento de código a seguir é usado para a conexão com o MongoDB e, em seguida, são apresentados os fragmentos de código para manipulação de dados. require 'vendor/autoload.php'; $mongo = newmongodb\client("mongodb://localhost:27017"); Cadastrar usuário: $colecaocliente = $mongo->db->cliente; $dadoscadastro =['nome_cliente'=>$_post['nome'],'login'=>$_post ['login'],'senha'=>$_post['senha'],'cpf'=>$_post['cpf'],'rg' =>$_POST['rg'],'data_nascimento'=>$_POST['data_nascimento']]; $colecaocliente->insertone($dadoscadastro); Verificar Login: $colecaocliente = $mongo->db->cliente; $dadoslogin = ['login' => $login, 'senha'=> $senha]; $cliente=$colecaocliente>findone($dadoslogin); Excluir usuário: $cliente = $mongo db cliente; $dadosdel = ['login' => $login, 'senha'=> $senha]; $result = $cliente->deleteone($dadosdel); Alterar senha: $cliente = $mongo->db->cliente; $dadoscliente = ['login' => $login,'senha'=> $senha]; $result = $cliente->updateone($dadoscliente,['$set' => ["senha" => $novasenha]]); A aplicação tem operações que exigiram queries com relacionamentos através de Foreign Keys, no caso da aplicação com BD relacional e da inserção e seleção de objetos aninhados através do objectid, porém, pelo

5 espaço limitado do artigo, foi procurado apresentar aqui as queries elementares de CRUD (Create, Read, Update e Delete). Mais detalhes da aplicação podem ser encontrados na Wiki do projeto. 4. Conclusão Não houve diferença na implementação da aplicação client side com os dois modelos de BD, até foram usados os mesmos arquivos HTML. Isto se deu graças a aplicação cliente side ser AJAX e a aplicação server side retornar as informações em formato de documento JSON ao cliente. No que diz respeito a aplicação server side, o código inteiro teve que ser reescrito, podendo-se reutilizar apenas pequenas partes que não tinham relação com o BD e mecanismos de sessão. A conexão ao banco em ambos os casos foi semelhante, já que foi usado o PDO do PHP, diferindo apenas na estrutura do objeto instanciado. As diferenças sobre como os dados são armazenados foram as mais perceptíveis. Na aplicação MongoDB, os objetos são inseridos por métodos insert(), por serem armazenados na mesma estrutura em que eram implementados. Já na aplicação MySQL (relacional), foram necessários diversos métodos do objeto PDO para poder inserir os dados na tabela, comprovando as diferenças estudadas sobre os modelos até então. Não foi foco desse trabalho avaliar performance. Porém, teoricamente, um BD NoSQL seria mais eficiente para uma aplicação deste tipo e porte, por não exigir muitas consultas e atualizações, tendo como vantagem, o armazenando os objetos praticamente da forma como foram implementados. Por nunca ter entrado em contato com a tecnologia NoSQL e, nos três anos de curso ser apresentado apenas o modelo Relacional, inicialmente houve dificuldade para desenvolver o projeto. Porém, com o tempo ficou até mais fácil, por não existir uma diferença tão grande entre implementação e armazenamento, facilitando a visualização do todo. Este projeto de pesquisa recebeu apoio do IFC, através do Edital N o 504/2014 PIBIC-EM. Referências BERNARDINO, J.; ABRAMAHOVA, V. NoSQL databases: MongoDB vs Cassandra. In: Proceedings of the International C* Conference. ACM, GEATI. NoSQL. In: Wiki do GEATI. Disponível em: < Acessado em: 31 jul MCCREARY, D. G.; KELLY, A. M. Making Sense of NoSQL: A guide for managers and the rest of us. Manning, p. MONGODB. Site oficial. Disponível em: < Acessado em: 25 jul PEREIRA, D. J. P. Armazéns de dados em bases de dados NoSQL f. Dissertação (Mestrado em Engenharia Informática) ISEP, Porto. SALADAGE, P. J; FOWLER, M. NOSQL Essencial: Um guia conciso para o mundo emergente de persistência poliglota. São Paulo: Pearson, p.