UNIVERSIDADE ESTADUAL DO CEARÁ CENTRO DE CIÊNCIAS E TECNOLOGIA CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO DIEGO GOMES TOMÉ

Transcrição

1 UNIVERSIDADE ESTADUAL DO CEARÁ CENTRO DE CIÊNCIAS E TECNOLOGIA CURSO BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO DIEGO GOMES TOMÉ MIGRAÇÃO DE UMA APLICAÇÃO QUE UTILIZA BANCO RELACIONAL PARA BANCO NOSQL: UM ESTUDO DE CASO FORTALEZA CEARÁ 2015

2 DIEGO GOMES TOMÉ MIGRAÇÃO DE UMA APLICAÇÃO QUE UTILIZA BANCO RELACIONAL PARA BANCO NOSQL: UM ESTUDO DE CASO Monografia apresentada ao Curso de Graduação em Ciência da Computação do Centro de Ciências e Tecnologia da Universidade Estadual do Ceará, como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação. Orientador: Prof. Dr. Paulo Henrique Mendes. FORTALEZA CEARÁ 2015

3 DIEGO GOMES TOMÉ MIGRAÇÃO DE UMA APLICAÇÃO QUE UTILIZA BANCO RELACIONAL PARA BANCO NOSQL: UM ESTUDO DE CASO Monografia submetida ao Curso de Graduação em Ciência da Computação do Centro de Ciências e Tecnologia da Universidade Estadual do Ceará, como requisito parcial para obtenção do grau de Bacharel. Aprovada em: / / BANCA EXAMINADORA Prof. Dr. Paulo Henrique Mendes (Orientador) Universidade Estadual do Ceará UECE Prof. Dr. Marcial Porto Fernandez Universidade Estadual do Ceará UECE Prof. Esp. Caio Holanda Costa Universidade Estadual do Ceará - UECE

4 Dedico este trabalho a minha companheira Jéssica de Aguiar,pela paciência nos momentos de dificuldade e pelo suporte e atenção durante o desenvolvimento.

5 "Se fosse fácil todos eram, se fosse perto todos iriam. Diego Tomé

6 RESUMO Diante da necessidade de mover uma aplicação legada para nuvem, o planejamento para efetuar esse trabalho é fundamental, porém a dificuldade da análise e do desenvolvimento pode tornar o processo mais custoso, desencorajando a ideia de prosseguir com a adaptação. Com base nessa necessidade, este trabalho teve como objetivo o desenvolvimento de um estudo de caso para a adaptação de uma aplicação que usa um banco de dados relacional PostgreSQL para um banco de dados NoSQL, constituindo um processo de migração que ajuda na análise e no desenvolvimento da adaptação para nuvem. A problemática partiu da necessidade de se adaptar softwares legados para a nuvem de uma forma que comprometa o mínimo possível a estrutura das tabelas e consultas já existentes, e como os bancos NoSQL podem se adaptar para resolver o problema. Neste trabalho foi feito uma análise e identificação dos pontos de interceptação e implementação da adaptação, além disso, foi demonstrado uma comparação entre os dois modelos no sentido de levantar as semelhanças e expor as diferenças entre consultas. Desta forma, através do estabelecimento dos pontos mais viáveis de interceptação dentro da arquitetura de um software e utilizando a abordagem de Bancos NoSQL orientado a documentos, chave/valor e colunas, foi proposto um processo de migração do banco e das consultas, como uma alternativa para adaptação a nuvem.. Palavras-chave: Computação em nuvem; Banco de Dados NoSQL; Migração de software.

7 LISTA DE FIGURAS Figura 1 Estrutura de uma tabela de um banco de Dados Relacional (FREITAS,2015) Figura 2 Exemplo de modelo chave/valor (FOWLER; SADALAGE, 2013) Figura 3 Exemplo de modelo voltado a colunas (FOWLER; SADALAGE, 2013) Figura 4 Exemplo de modelo Orientado A Grafos (Fonte: LIBERABLOGO,2015) Figura 5 Exemplo de modelo voltado a documentos (FOWLER; SADALAGE, 2013) Figura 6 Representação da estrutura da migração (Primária, 2015) Figura 7 Diagrama de Modelo relacional da aplicação (Primaria, 2015) Figura 8 Inserção de um objeto usuário (Primária, 2015) Figura 9 Exemplo de criação da tabela aluguel (Primária, 2015) Figura 10 Inserção do objeto filme (Primária, 2015) Figura 11 Incersão de um cliente em MongoDB (Primária, 2015) Figura 12 Consulta de um cliente com PostgreSQL (Primária, 2015) Figura 13 Consulta de um cliente com MongoDB (Primária, 2015) Figura 14 Consulta de um aluguel pendente (Primária, 2015) Figura 15 Representação dos dados de aluguel em MongoDB Figura 16 Modelagem da família coluna aluguel Figura 17 Consulta de alugueis por filme para o Cassandra

8 LISTA DE TABELAS Tabela 1- Modelos de Serviços em Nuvem Tabela 2 - Tipos de dados por Banco NoSQL Tabela 3 - Modelo de dados para cada Tecnologia Tabela 4 - Comparação dos CRUDs entre os Bancos de Dados... 41

9 LISTA DE SIGLAS E ABREVIATURAS NoSQL SGBDs SQL NIST SaaS ACID SGBD DDL DML JSON IDE CRUD DAO API Modelos de dados distintos do modelo relacional Sistemas de Gerenciamento de Bancos de Dados Structured Query Language Instituto Nacional de Padrões e Tecnologia dos Estados Unidos Software as a Service Atomicidade, Consistência, Isolamento e Durabilidade Sistemas de Gerenciamento de Banco de Dados Linguagem de Definição de Dados Linguagem de Manipulação de Dados JavaScript Object Notation Ambiente de desenvolvimento Integrado Create Read Update Delete Data Access Object Application Programming Interface

10 Sumário 1. INTRODUÇÃO Justificativa Objetivos Objetivo geral Objetivos Específicos Metodologia Organização do Trabalho FUNDAMENTAÇÃO TEÓRICA Computação em Nuvem Migração de Software Banco de Dados Relacional Banco de Dados NoSQL Armazenamento Por Chave/Valor Armazenamento Orientado A Colunas Armazenamento Orientado A Grafos Armazenamento Orientado A Documentos TRABALHOS RELACIONADOS ESTUDO DE CASO Descrição da Aplicação Análise da Aplicação para Migração Modelo Relacional em PostgreSQL Migração para o MongoDB Migração para o Cassandra Migração para o Dynamo DISCUSSÃO DOS RESULTADOS CONCLUSÃO REFERÊNCIAS... 44

11 11 1. INTRODUÇÃO A Computação em nuvem é um novo paradigma computacional que vem sendo trabalhado em diversas áreas como Redes de Computadores e Banco de Dados, devido a seus grandes benefícios como pagamento sob demanda, baixo investimento em infraestrutura física e alta escalabilidade de recursos. Embora existam várias alternativas propostas pelas empresas de computação em nuvem e bancos de dados em geral, as grandes corporações encontram dificuldades em aderir a tecnologia. Uma das grandes necessidades é a de migrar aplicações legadas, pois podem exigir muitas mudanças a nível de código o que pode levar a grandes problemas a nível de implementação, exigindo muito esforço dos desenvolvedores e aumenta o risco de introduzir novos erros (BESERRA et al., 2012). A migração é inerentemente complexa porque as decisões de migração devem levar em conta (e podem ser influenciadas por) vários fatores, muitas vezes conflitantes, tanto técnicos (por exemplo, esforço de adaptação, escalabilidade, segurança) quanto não técnicos (por exemplo, perda da governança sobre dados e aplicações, reputação do provedor, restrições legais) (KHAJEH-HOSSEINI et al., 2012; TRAN et al., 2011) A principal motivação para se adaptar um software já existente é manter o investimento anteriormente feito com as mudanças para um novo ambiente (V. ANDRIKOPOULOS et al.,2012). Neste sentido, é possível migrar toda a aplicação para a nuvem, utilizando a infraestrutura como serviço (IaaS),o que remete a arquitetura cliente servidor, ou apenas partes da aplicação, como serviços de arquivos, comunicação e banco de dados. Este trabalho aborda a migração parcial de aplicações, particularmente a persistência de dados inicialmente armazenados em um Sistema de Gerenciamento de Bancos de Dados (SGBD) relacional. A grande maioria dos sistemas de informação tradicionais utilizam um banco de dados relacional. Contudo, muitos dos desafios atuais, como alta quantidade de informações e milhões de usuários acessando leitura e escrita de dados, representam dificuldades para SGBDs relacionais, pois eles possuem problemas de evolução de esquema. Além disso, o que representava vantagem para o seu uso, como exigência de modelo de dados

12 12 fixo e integridade referencial, hoje já não está de acordo com as necessidades de mudança nos requisitos de negócio (VARDANYAN M., 2011). Por outro lado, tecnologias NoSQL (Not Only SQL) são bancos de dados escaláveis e horizontais, com alta escalabilidade e disponibilidade, que podem tratar grandes volumes de dados sem a necessidade de joins para relacionamento e SQLs para consulta, além do gerenciamento de dados não estruturados. Os SGBDs relacionais não possuem escalabilidade quando se considera distribuir os dados em uma grande quantidade de servidores(wei et al., 2009). Dessa forma, a utilização de bancos de dados NoSQL (não relacionais) traz uma abordagem mais natural e que melhor se adapta ao novo ambiente. Nesse trabalho pretende-se fazer um estudo de caso para migrar uma aplicação para três Tecnologias NoSQL. Desta forma, serão expostos os pontos positivos e negativos da migração, além da comparação entre as tecnologias e os ganhos observados. 1.1 Justificativa Desde a criação do primeiro Banco de Dados NoSQL tem se falado sobre suas vantagens sobre bancos de dados relacionais com relação à escalabilidade. Muitas empresas relatam que obtiveram sucesso na migração de bancos de dados relacionais para NoSQL, e confirmam que resolveram seus problemas de escalabilidade (Chang et al. 2006), mas ainda falta um melhor entendimento do contexto e dos limites desses bancos de dados. Os resultados de um estudo comparativo como o proposto é de suma importância pois ajuda desenvolvedores e arquitetos a decidirem se bancos de dados NoSQL são apropriados para os seus problemas, e caso sejam, decidir qual deles é o mais apropriado diante da necessidade de migração. 1.2 Objetivos Objetivo geral O objetivo principal alcançado foi o desenvolvimento de um estudo de caso para adaptar um software que utiliza um banco de dados relacional para três bancos NoSQL. Além disso, foi feito uma análise dos bancos de dados NoSQL atuais e as técnicas que os mesmos utilizam para se adaptar aos diversos

13 13 softwares, com a finalidade de expor as vantagens e desvantagens de cada técnica, o que possibilitou a identificação dos conjuntos das mesmas que melhor se adequaram ao cenário aqui reproduzido Objetivos Específicos Para se atingir o objetivo geral deste trabalho foram alcançados os seguintes objetivos específicos: 1. Estabelecer o software a ser utilizado para o estudo; 2. Analisar como as tabelas serão representadas em cada um dos bancos a serem migrados; 3. Determinar os pontos de interceptação e migração dentro da arquitetura da aplicação; 4. Implementar o processo de migração de uma mesma aplicação para cada um três dos bancos NoSQL escolhidos; 5. Destacar as semelhanças e diferenças do processo de migração aqui desenvolvido entre cada um dos três bancos. 1.3 Metodologia Em relação à finalidade, este trabalho pode ser classificado como um estudo de caso aplicado, tendo em vista que a aquisição de conhecimento resultou em uma proposta de migração. No que diz respeito aos objetivos, este pode ser considerado como exploratório, a qual proporciona o aprimoramento dos conceitos e familiarização com o problema, a fim de torná-lo explícito através de um exemplo de estudo. Para o desenvolvimento do trabalho, o seguinte roteiro foi seguido: O primeiro passo para o estudo foi a escolha da aplicação a ser utilizada. A princípio, foi estabelecido uma aplicação que utilizasse um banco de dados relacional contendo as 4 consultas básicas de Create, Select, Update e Delete, além disso foi necessária a existência de consultas mais aprimoradas com JOINs;

14 14 O segundo passo metodológico foi a análise do relacionamento das tabelas, no sentido de representar as consultas nos bancos de dados NoSQL sem comprometer a estrutura da aplicação; O terceiro passo consistiu em identificar os pontos de modificação dentro da aplicação e estabelecer a adequação para a extensão dos bancos NoSQL; O quarto passo tratou da execução da migração através da implementação das novas consultas e execução do software para analisar seu funcionamento; O quinto e último passo, consistiu na análise comparativa, onde foram expostas as diferenças entre as consultas de cada banco NoSQL entre si e o banco relacional anteriormente utilizado. Seguindo esses passos metodológicos, pode-se obter como resultado, a aplicação sendo executada da mesma forma que antes do processo, porém utilizando cada um dos três bancos NoSQL. 1.5 Organização do Trabalho Este trabalho está organizada da seguinte maneira: O Capítulo 2 reúne a fundamentação teórica que embasa toda a metodologia e aplicação desse trabalho. Iniciando por uma breve explanação dos conceitos em computação em nuvem, são abordados temas que remetem a vantagem de migrar um software para esse ambiente, além de um estudo paralelo entre bancos de dados relacionais e NoSQL, com a finalidade de expor suas características e as mudanças que virão ao adaptar uma aplicação. O Capítulo 3 traz uma discussão sobre vários trabalhos que se relacionam ao trabalho aqui proposto, destacando suas contribuições, embasamentos e reunindo pontos não discutidos em seus resultados, que serão abordados nesse trabalho. O Capítulo 4 descreve o estudo de caso de uma aplicação baseada no banco de dados relacional PostgreSQL e sua adaptação para outros três bancos de dados NoSQL(MongoDB, Cassandra e Dynamo). Neste

15 15 capítulo, será discutido o processo de migração, a metodologia proposta aplicada para o caso e os resultados gerados a partir da implementação desse processo. O Capítulo 5 desenvolve uma discussão acerca dos resultados alcançados na migração, discutindo as diferenças entre os três bancos NoSQL escolhidos, e como o relacionamento foi representado em um novo paradigma. O Capítulo 6 reúne a conclusão do estudo de caso, levantando a relação entre a metodologia e os resultados alcançados, além de apresentar possíveis trabalhos futuros.

16 2 FUNDAMENTAÇÃO TEÓRICA Nesta seção serão abordados os principais temas discutidos neste trabalho: Computação em Nuvens, migração de software, banco de dados relacionais e banco de dados NoSQL. 2.1 Computação em Nuvem 16 O termo "nuvem" foi pensado em 2006 por Eric Schimdt, o CEO da Google (SULTAN; BUNT-KOKHUSIS, 2012), embora as ideias fundamentais desse modelo tenham sido estabelecidas após alguns anos. A Computação em Nuvem está ligada à ampla disponibilidade de alta capacidade, redes de baixo custo, software avançado e hardware; além da adoção de arquiteturas orientadas a serviços. Embora existam inúmeras definições específicas (GROSSMAN, 2009), e na verdade uma gama de diferentes tipos de "nuvem", o Instituto Nacional de Padrões e Tecnologia dos Estados Unidos (NIST) fornece uma definição consistente, e que pode ser usada como ideia fundamental (MELL; GRANCE, 2011). NIST propõe que a computação em nuvem "é um modelo que permite o acesso de forma conveniente, a uma rede sob demanda e a uma reserva compartilhada de recursos computacionais configuráveis (por exemplo, redes, servidores, armazenamento, aplicações e serviços) que podem ser rapidamente alocados e liberados com mínimo de gerenciamento, esforço ou prestador de serviços de interação (MELL; GRANCE, 2011). Esse modelo é composto por 5 características principais: on-demand self-service: é a prestação unilateral de recursos de computação (por exemplo, o tempo de servidor, armazenamento de rede) conforme necessário, sem necessidade de intervenção do provedor de serviços; broad network access: caracteriza-se pelas capacidades que são acessados através de mecanismos padrão e por plataformas cliente heterogêneas (por exemplo, telefones celulares, tablets, notebooks e estações de trabalho); resource pooling: relaciona como os recursos de computação (por exemplo, armazenamento, processamento, memória e largura de banda de rede) são reunidos, pelo provedor, para servir a vários consumidores

17 17 usando um modelo multi-tenant. Geralmente, o cliente não tem controle ou conhecimento sobre a localização exata dos recursos disponibilizados, mas pode ser capaz de especificar o local em um nível mais alto de abstração (por exemplo, país, estado ou datacenter). rapid elasticity: descreve como as plataformas podem ser elasticamente provisionadas e liberadas, para escalar dependendo da demanda do consumidor. Os recursos disponíveis normalmente parecem ser ilimitados, do ponto de vista do consumidor; measured servisse: diz respeito a como Sistemas em nuvem automaticamente controlam e otimizam o uso dos recursos, aproveitando a capacidade de medição em um nível de abstração adequado para o tipo de serviço (por exemplo, armazenamento, processamento, largura de banda, e contas de usuários ativos). Existem três modelos de serviços que são relacionados na Tabela 1, onde cada modelo estabelece o serviço oferecido ao cliente e como ele pode ser abordado dentro de suas necessidades. Modelos Software como Serviço Plataforma como Serviço Infraestrutura como Serviço Fonte: Primária (2015) Tabela 1- Modelos de Serviços em Nuvem Descrição O consumidor utiliza as aplicações do provedor em execução em uma infraestrutura de nuvem. O consumidor implanta as aplicações de infraestrutura de nuvem criadas ou adquiridas por ele/ela, bibliotecas, serviços e ferramentas de suporte, e outros recursos de computação oferecidos pelo provedor. O consumidor é capaz de implantar e executar software arbitrário, que pode incluir sistemas operacionais e aplicações, para o armazenamento, redes e outros recursos computacionais disponibilizados pelo fornecedor. 2.2 Migração de Software

18 18 A maioria das aplicações corporativas possuem um custo de trabalho que varia no decorrer do tempo. Dessa forma, pode-se observar que o comportamento do usuário, por exemplo, tende a ser dependente da variação do tempo ou ainda, a cobertura da mídia pode levar a aumentar rapidamente a popularidade dos serviços prestados. Essas variações resultam frequentemente em falta ou excesso de provisionamento de recursos das aplicações (por exemplo, processamento ou capacidade de armazenamento). A computação em nuvem fornece meios para reduzir o provisionamento em excesso ou defasado, através de prestação de serviços elásticos. Desse modo, a conformidade com os acordos de nível de serviço tem de ser assegurada (IQBAL; DAILEY; CARRERA, 2009). Considerando-se os sistemas de software legado, há uma maneira em que as aplicações podem se beneficiar de tecnologias de computação em nuvem presentes. De acordo com Armbrust (2009), três diferentes funções podem ser distinguidas. Fornecedores de Software as a Service (SaaS), provedor de SaaS, e provedor de nuvem. Fornecedores de SaaS (usuários nuvem) oferecem serviços de software que estão sendo utilizados por usuários de SaaS. Para este efeito, os fornecedores de SaaS podem construir suas aplicações em cima de serviços oferecidos por provedores de cloud computing (fornecedores de nuvem). Softwares empresarias recém desenvolvidos podem ser projetados para a utilização de tecnologias de computação em nuvem. No entanto, os fornecedores de SaaS podem também considerar a possibilidade de conceder a responsabilidade de operação e manutenção de tarefas de um provedor de nuvem para um sistema de software já existente. Executando o software da empresa estabelecida em uma base de computação em nuvem geralmente envolve atividades de reengenharia extensas durante a migração. No entanto, em vez de recriar as funcionalidades de um sistema de software criado a partir do zero para ser compatível com o ambiente de um provedor de nuvem selecionado, uma migração permite que o provedor de SaaS possa reutilizar partes substanciais de um sistema (VAQUERO et al., 2009). 2.3 Banco de Dados Relacional

19 19 O banco de dados relacional ou modelo relacional, surgiu na década de 1970, quando Edgar Frank Codd aprimorou o modelo de banco de dados existente, fundamentando-se em conceitos de matemática, lógica de predicados e teoria dos conjuntos. A partir de 1980, vários sistemas implementaram suas teorias, o que possibilitou a criação de vários bancos relacionais conhecidos hoje, como MySQL, PostgreSQL, Oracle, dentre outros (ELMASRI; NAVATHE, 2011). De acordo com esse modelo, os dados são armazenados em estruturas de tabela, onde cada coluna denomina um atributo e cada linha uma tupla. Além disso, cada atributo possui um domínio, cuja função é definir o tipo e o tamanho que o mesmo possuirá (SILBERSCHATZ; KORTH; SUDARSHAN, 1999). Na Figura 1 é definida a estrutura de uma tabela em um banco de dados relacional. Figura 1 Estrutura de uma tabela de um banco de Dados Relacional (FREITAS,2015) Para identificação de cada tupla em uma tabela, existe um dado definido como chave primária, e para relacionar tabelas distintas e consequentemente suas tuplas, existe um dado denominado chave estrangeira. As chaves primárias têm a responsabilidade de associar um dado valor ao conjunto de dados da tupla, garantindo a unicidade da linha. Da mesma forma, a chave estrangeira garante que a relação representada entre as tabelas é única, através da definição de seu valor (ELMASRI; NAVATHE, 2011). No sentido de garantir a integridade dos dados, um banco de dados relacional deve obedecer a propriedade ACID (atomicidade, consistência, isolamento

20 20 e durabilidade). Esta propriedade é um conceito primário e importante para definição de SGBD (Sistemas Gerenciadores de Bancos de Dados Relacionais) (ELMASRI; NAVATHE, 2011). As propriedades ACID podem ser definidas da seguinte forma: Atomicidade diz respeito a tratar uma transação de forma atômica, ou seja, as transações são processadas de forma indivisível com a finalidade de garantir que todas as modificações são processadas em uma transação ou nenhuma é processada. A consistência garante que as modificações serão feitas se os dados da transação são coerentes e válidos, ou não efetua a execução. Isolamento é a característica que garante o acesso ao banco de dados de forma independente, isto é, dado duas transações que ocorrem ao mesmo tempo, essa propriedade garante que uma ocorrerá antes da outra. Já a durabilidade é a propriedade que garante que as transações finalizadas não serão perdidas, e que as alterações serão mantidas no banco de dados de forma permanente, ou até que sejam alteradas novamente. A Linguagem de Consulta Estruturada com a sigla em inglês SQL foi criada pela IBM Research, na década de 1970, como padrão para Sistemas Gerenciadores de Bancos de Dados Relacionais (SGBDR) e com os componentes de DDL (Linguagem de Definição de Dados) e DML (Linguagem de Manipulação de Dados) definidos (DATE, 2004). 2.4 Banco de Dados NoSQL No ano de 2009 surgiu uma solução em banco de dados para questões relacionadas à escalabilidade e processamento de grandes volumes de dados denominada NoSQL (Not Only SQL), rompendo algumas características dos bancos de dados relacionais baseados em SQL e ACID (VIEIRA, 2012). Características que dizem respeito à não necessidade de um esquema pré-definido, facilidade na distribuição de dados em diversos servidores, adaptação a novos requisitos, gerenciamento de dados não estruturados entre outros. Bancos de Dados NoSQL têm sido cada vez mais utilizados para superar a inflexibilidade dos bancos de dados relacionais no que diz respeito a dados

21 21 altamente heterogêneos, e para fornecer suporte aprimorado para consultas distribuídas e cache integrado (XIANG; HOU, 2010). Bancos de dados NoSQL não tem um esquema pré-definido que dita uma definição uniforme e fixa dos dados armazenados nas fileiras. Desta forma, os campos da base de dados podem ser modificados ao longo do tempo e podem adaptar-se a requisitos futuros. A tecnologia NoSQL pode ser classificada, da forma que gerenciam e armazenam seus dados, em quatro classes de divisão: Chave/Valor, orientado a documentos, orientado a colunas e orientado a grafos (EDLICH; FRIEDLAND, 2010) Armazenamento Por Chave/Valor O armazenamento de dados do tipo chave-valor é constituído por linhas e colunas assim como nos bancos de dados relacionais, embora seu armazenamento utilize somente duas colunas: a chave e o valor correspondente ao dado armazenado. Esse sistema funciona como uma array associativo, onde cada chave com valor único corresponde a um valor referenciado. Os valores podem ser de qualquer tipo, seja objeto, lista ou hash, garantindo assim as características do não uso de modelo fixo e armazenamento de dados sem esquema definido. A Figura 2 é um exemplo de modelo chave/valor. Figura 2 Exemplo de modelo chave/valor (FOWLER; SADALAGE, 2013) Esse tipo de gerenciamento de dados possui uma velocidade de consulta altíssima em relação a bancos de dados relacionais, e é utilizado para consultas rápidas. Foi desenvolvido para lidar com grandes massas de dados, como por

22 exemplo, armazenar dados de mercado na bolsa de valores. Como exemplo, os bancos SimpleDB e Dynamo utilizam essa tecnologia Armazenamento Orientado A Colunas Esse tipo de armazenamento é bem semelhante ao Chave/Valor, porém tem a característica de armazenar os dados por colunas. As colunas similares são armazenadas como colunas família com uma chave para linha correspondente. Funciona como uma coleção de um ou mais pares de chave/valor associados por características semelhantes. Cada linha possui colunas ou supercolunas, onde cada coluna contém uma tupla nome/valor, e uma supercoluna é constituída por colunas semelhantes. Cassandra e BigTable são exemplos de bancos de dados que utilizam esse conceito. A Figura 3 é um exemplo de modelo de armazenamento voltado a colunas. Figura 3 Exemplo de modelo voltado a colunas (FOWLER; SADALAGE, 2013) Armazenamento Orientado A Grafos

23 23 É um modelo complexo de armazenamento, caracterizado por armazenar objetos completos em grafos, diferente dos outros modelos, este já é estabelecido por representar os dados e seus esquemas na forma de um grafo dirigido e rotulado. Operações de consulta nesse tipo de banco utilizam conceitos de grafos, como vizinho, caminho e sub-grafos (ANGLES, 2008). Na Figura 4 um grafo que representa o armazenamento de pessoas e livros interligados, no banco Neo4J, que é um banco NoSQL orientado a grafos. Figura 4 Exemplo de modelo Orientado A Grafos (Fonte: LIBERABLOGO,2015) Armazenamento Orientado A Documentos Utiliza JSON (JavaScript Object Notation) como notação de registro nos documentos, e armazena seus dados como coleções de documentos, onde um documento é especificado como um objeto com identificador único e um conjunto de campos que podem ser strings, listas ou documentos aninhados. É totalmente flexível a novas alterações, adaptando-se a mudanças sem comprometer os dados no banco. As principais implementações que adotam esse modelo são o MongoDB e CouchDB. A Figura 5 é um exemplo de modelo de armazenamento voltado a documentos.

24 Figura 5 Exemplo de modelo voltado a documentos (FOWLER; SADALAGE, 2013) 24

25 25 3 TRABALHOS RELACIONADOS Diante do desenvolvimento dos Bancos de Dados NoSQL e dos ganhos em desempenho e novas funcionalidades proporcionados, a literatura reune vários trabalhos que desenvolvem análises de desempenho entre Bancos SQL e NoSQL (COOPER, 2010), comparações entre diferentes Bancos NoSQL (ABRAMOVA V.,2013) e estudos de migração de aplicações legadas para a nuvem (ANTAÑO A., 2014), (COSTA, 2014). Abramova (2013) realizou uma análise em que comparou os bancos NoSQL MongoDB e Cassandra simulando várias cargas de trabalho de leitura e escrita, com a finalidade de avaliar qual dos dois teria o melhor desempenho. Com essa perspectiva, destacou as diferenças obtidas com o crescimento do volume de dados e como cada uma das instâncias gerenciava seus recursos. Já Cooper (2010) desenvolveu um estudo comparativo de um benchmark aplicado ao MySQL e Cassandra, onde realizou experimentos para medir os ganhos de elasticidade e desempenho. Obteve resultados que possibilitaram uma avaliação dos benefícios de elasticidade e escalabilidade, destacando o comportamento dos sistemas de armazenamento com a variação do número de servidores alocados. A migração de um software é um processo que exige alguns cuidados, pois vários pontos devem ser analisados com cautela, para garantir que sua aplicação não interfira na estrutura existente. O modelo de persistência inicial, a flexibilidade dos dados e o destino, são pontos que devem ser considerados na análise para proporcionar uma adaptação adequada (ANTAÑO, 2014). Com o desenvolvimento de técnicas e processos de migração de software, Antaño (2014) ilustrou as necessidades de análise ao decidir-se pela migração desde o SQL ao NoSQL. Além disso, classificou as vantagens e desvantagens desse processo, e conceituou a ideia de como abordar o processo de migração, antes, durante e após sua execução. Em (COSTA, 2014) é desenvolvido um relato de experiência de uma migração parcial com banco de dados relacional para o banco NoSQL DynamoDB na nuvem. O relato descreve toda a metodologia desenvolvida para a migração, desde a nova modelagem das tabelas até as interceptações na arquitetura da aplicação. Os autores utilizam uma abordagem não intrusiva, que busca interceptar

26 26 os pontos de adaptação sem interferir diretamente no seu funcionamento e concluem que uma abordagem desse segmento pode ser reutilizada para muitas outras aplicações. Complementam seu trabalho, indicando que a migração de uma aplicação para nuvem pode ser implementada de forma parcial, sempre que apresentarem características que permitam que esse processo seja executado com benefícios para o projeto. Com uma abordagem diferente, este trabalho analisa a viabilidade de migrar uma aplicação para bancos NoSQL de características distintas, propondo uma metodologia intrusiva, analisando a viabilidade das conversões de modelo e compatibilidade das consultas.

27 27 4 ESTUDO DE CASO Com a finalidade de ilustrar os conceitos discutidos nesse trabalho, será exposto neste capítulo um estudo de caso sobre a migração de uma aplicação baseada em banco de dados relacional para três implementações NoSQL, com o propósito de estabelecer uma discussão a nível de implementação. Nesse sentido, foi escolhida uma aplicação que utiliza o Banco de Dados Relacional PostgreSQL, Java como linguagem de desenvolvimento e a IDE (Ambiente de desenvolvimento Integrado) Netbeans. Os Bancos NoSQL escolhidos para a migração foram MongoDB, Cassandra e Dynamo representando a classificação orientado a documento, colunas e chave/valor, respectivamente. Os passos para o desenvolvimento do estudo descrito na metodologia envolvem a escolha da aplicação, a análise do modelo relacional existente, a análise dos pontos de modificação, a migração para o modelo NoSQL do banco escolhido e a comparação entre as consultas, com a finalidade de expor os resultados do processo. 4.1 Descrição da Aplicação A aplicação utilizada consiste em uma Locadora de vídeos com as entidades Filme, Cliente, Usuário, Ator e Aluguel. Contém CRUDs (Create Read Update Delete) para todos as entidades além da apresentação de relatórios de rotina. Utiliza os padrões DAO (Data Access Object) e Factory para abstrair o acesso ao banco de dados e a conexão, respectivamente. Dessa maneira, ao analisar os pontos de alterações para a migração, foi definido que reutilizar os pontos de chamada do DAO e implementar novas classes desse tipo para cada banco NoSQL permitiria uma menor intrusão dentro do código existente. 4.2 Análise da Aplicação para Migração A proposta de adaptação utilizada para a migração consiste em criar uma classe DAO com as consultas e conexões de cada banco e comunicar com o Controller da aplicação. O interesse nessa proposta é o de permitir a extensão para cada um dos bancos de uma forma mais simples, e que não modifique a essência

28 28 da aplicação, no que diz respeito às solicitações de consulta, as lógicas de negócio da aplicação e instanciações de entidades, como pode ser observado na Figura 6, que ilustra a comunicação de cada banco de dados com a camada de controle. Figura 6 Representação da estrutura da migração (Primária, 2015) 4.3 Modelo Relacional em PostgreSQL O banco de dados PostgreSQL utiliza a maior parte do padrão SQL, além de ser compatível com o padrão ACID e ser transacional. O uso deste banco pela aplicação garantiu a representação de um SGBD SQL e será utilizado na comparação entre os bancos MongoDB, Cassandra e Dynamo. O modelo das entidades da aplicação está representado na Figura 7 como um diagrama de modelo relacional.

29 29 Figura 7 Diagrama de Modelo relacional da aplicação (Primaria, 2015) 4.4 Migração para o MongoDB A escolha do Banco MongoDB foi feita no sentido de representar os Bancos NoSQL do tipo orientado a documento. Para tanto, foi necessária a utilização do driver para Java fornecido pela DataStax, a biblioteca mongo.jar adicionada ao classpath do projeto e a instalação do banco MongoDB. Para conectar-se a um servidor MongoDB em uma aplicação Java, algumas classes são necessárias, dependendo da utilização. Os pacotes a serem considerado são com.mongodb com a classe principal MongoClient, responsável por conectar o cliente ao servidor de Banco de Dados, org.bson, que implementa as funcionalidades do objeto e da codificação BSON, e org.bson.types, cuja a finalidade é conter as implementações dos diferentes tipos de dados que podem ser armazenados no formato BSON, desde tipos primitivos até matrizes e estruturas aninhadas. Como citado anteriormente, o MongoDB utiliza documentos para armazenar seus dados, dessa forma, foi utilizado uma abstração desse conceito, proporcionado pelo driver para Java, para representar o modelo de dados da aplicação. O modelo de representação dos dados em documentos pode ser

30 comprovado com um exemplo de inserção de usuário na aplicação representado pela Figura Figura 8 Inserção de um objeto usuário (Primária, 2015) No exemplo apresentado na Figura 8, pode-se perceber que a chave do armazenamento no banco foi feita através do próprio id do cliente e que uma inserção trata-se na verdade de uma inclusão de um documento, com as associações de chave-valor equivalentes a cada linha. No PostgreSQL, como em qualquer outro banco do tipo relacional, o schema é composto por tabelas, views e procedures, além disso, cada uma das tabelas com uma estrutura comum para todas as linhas. Em contrapartida, MongoDB possui coleções, que podem ser comparadas as tabelas do PostgreSQL, porém cada coleção é composta por documentos que podem possuir estruturas diferentes. Dentre as diferenças entre PostgreSQL e MongoDB, pode-se destacar a existência em PostgreSQL de uma distinção entre comandos DDL(Linguagem de Definição dos Dados) e DML(Linguagem de Manipulação de Dados). Um exemplo de criação da tabela Aluguel, representando um comando DDL em Postgres é apresentado na Figura 9.

31 31 Figura 9 Exemplo de criação da tabela aluguel (Primária, 2015) Já, na inserção de um registro na tabela Filme em PostgreSQL, pode-se perceber a diferença na falta de definição de tipos no comando DML. A Figura 10 ilustra esta situação. Figura 10 Inserção do objeto filme (Primária, 2015) Essa distinção entre criar e popular dados em tabelas, não ocorre no MongoDB, visto que as coleções são criadas de forma instantânea quando um novo documento é inserido, salvo ou atualizado. Dessa forma, não existe diferença. Na Figura 11 a inserção de um cliente em MongoDB.

32 32 Figura 11 Incersão de um cliente em MongoDB (Primária, 2015) Para consultas, PostgreSQL utiliza dos vários níveis de complexidade do comando SELECT. Uma equivalência desse comando em MongoDB é o comando find(). Enquanto que, no primeiro são extraídas as linhas de uma tabela, no segundo são extraídos os documentos de uma coleção. Como pode ser observado nas Figuras 12 e 13 que representa a consulta de um cliente em ambos bancos.

33 33 Figura 12 Consulta de um cliente com PostgreSQL (Primária, 2015) A Figura 13 ilustra a consulta em MongoDB onde utiliza um documento contendo o nome do cliente para recuperar os outros dados do cliente solicitado. Figura 13 Consulta de um cliente com MongoDB (Primária, 2015)

34 34 De acordo com documentação de especificação, MongoDB não possui suporte para JOINs. Por outro lado, permite o uso de referências entre documentos de forma manual, quando salva o _id de um documento em outro, ou através da API (Application Programming Interface) DBRef, que permite que o campo _id de um determinado documento referencie um outro, permitindo que documentos localizados em várias coleções possam ser conectados de forma mais fácil em uma única coleção. Para utilizar na aplicação de estudo, foi implementado o método de agregação de referência. Dessa forma, a consulta que antes era representada em PostgreSQL como na Figura 14, passou a utilizar os valores do id do cliente e usuario, agregados na tabela aluguel. Figura 14 Consulta de um aluguel pendente (Primária, 2015) A relação antes existente no modelo relacional, é quebrada em um documento contendo dados redundantes, o id do cliente que antes relacionava as tabelas cliente e aluguel, passa a ser um valor agregado ao documento aluguel. Como pode ser observado na Figura 15, que representa os dados de um aluguel em documento JSON em MongoDB.

35 35 Figura 15 Representação dos dados de aluguel em MongoDB 4.5 Migração para o Cassandra O banco Cassandra foi escolhido como instância dos bancos orientados a coluna. Desenvolvido pela Apache Software Foundation, é um banco escrito em Java que possui características bem próximas aos bancos relacionais como a disposição em colunas e linhas. Por outro lado, apresenta diferenças em relação ao armazenamento, pois pode ser estruturado, semi estruturado ou ser constituído sem estrutura, além disso, foi criado com a finalidade de trabalhar um grande volume de dados e utiliza linguagem de consulta CQL(Cassandra Query Language). Para implementação da migração ao Cassandra, se fez necessário a instalação do banco e utilização do seu Driver para java. O conceito principal que envolve a conexão ao banco é o cluster, que diz respeito ao grupo de nós que irão armazenar os dados, no caso, nesse estudo será utilizado apenas um. O modelo dos dados é baseado nas consultas, dessa forma, se faz necessário entender como os dados serão recuperados para que se possa estabelecer a disposição das mesmas. Ele possui o modelo de família de colunas, equivalente a tabelas no SQL comum, nesse sentido, foi utilizado a linguagem CQL que traz as referência do modelo relacional, tratando família de colunas como tables. A modelagem feita no Cassandra é voltada para a necessidade das consultas da aplicação, dessa forma, a consulta do relatório de alugueis por filme, presente na aplicação desse estudo de caso, foi representada como uma família de colunas para possibilitar a consulta via CQL. A Figura 16 ilustra o armazenamento dos dados utilizados na consulta que traz as informações de um aluguel por filme.

36 36 Figura 16 Modelagem da família coluna aluguel. No PostgreSQL a consulta necessitava de pelo menos dois JOINs para obter os dados solicitados. A relação existente entre as tabelas, aluguel, cliente e filme precisou ser adaptada para corresponder a nova modelagem. Um vez que, uma primeira consulta foi executada para encontrar o filme_id correspondente ao título do filme, o próximo passo foi buscar os dados dos alugueis através do valor passado como parâmetro. A consulta está representada caracterizando o uso do CQL para consultar dados no Cassandra. Figura 17 Consulta de alugueis por filme para o Cassandra. na Figura 17,

37 37 As outras consultas básicas distinguem pouco das implementadas no PostgreSQL, já que a linguagem de consulta CQL tenta trazer uma ideia próxima entre os dois bancos, embora as mais complexas tendem a modificar o modelo relacional, desnormalizando as tabelas antes existentes, em famílias de colunas que atendam as necessidades da aplicação. Um ponto importante a salientar acerca da migração para o Cassandra, é que a divisão em tabelas no modelo relacional mantém uma coluna de um tipo único, com características semelhantes e que a representam. Enquanto no Cassandra os dados armazenados em uma família de colunas, não são necessariamente semelhantes, podendo ser armazenados juntos por requisitos da aplicação. 4.6 Migração para o Dynamo DynamoDB é um banco de dados NoSQL com o modelo de dados do tipo Chave/Valor, é mantido pela Amazon, conta com uma plataforma de serviço para gerenciar tabelas, e não possui esquema definido. Para utilizá-lo, se faz necessário a instalação do AWS toolkit, um plugin específico da Amazon que permite o desenvolvimento para sua plataforma de forma mais simples. As tabelas no DynamoDB são constituídas por itens, cada item representa uma coleção de atributos, onde cada atributo contém um par Chave/Valor. Assim como no PostgreSQL, as linhas são indexadas por uma chave primária, embora não permita o uso de JOINs, simula o relacionamento através de composição de chaves, utilizando dados de duas ou mais colunas para obter a informação desejada. O acesso via cliente ao DynamoDB é feito através da classe AmazonDynamoDBClient, onde seu parâmetro de início são as credencias configuradas no perfil de acesso a plataforma Amazon. A criação de tabelas no DynamoDB depende de um retorno vindo do AWS para ativar o seu uso, o objeto table da aplicação possui o método cujo retorno garante a informação de sucesso na criação. Em relação aos tipos de dados, DynamoDB não tem suporte ao tipo Data, que é um dos mais utilizados em armazenamento de dados, em contrapartida, podese utilizar String ou Number para representar datas, embora ainda necessite de

38 38 tratamento lógico para conversão. Na aplicação proposta, a tabela aluguel necessitava do armazenamento de duas datas, dessa forma, foi necessário utilizar a representação como Strings, fazendo a conversão a cada leitura ou escrita.

39 39 5. DISCUSSÃO DOS RESULTADOS Este capítulo reúne as informações obtidas no estudo de caso e determina as diferenças encontradas nos processos de migração para cada banco NoSQL. Além disso, expõe características de cada tecnologia e a comparação entre o modelo relacional e o NoSQL. Quanto à utilização de tipos de dados, as tecnologias mais flexíveis são MongoDB e Cassandra. Nesses bancos, o suporte a vários tipos de dados proporciona uma melhor correspondência para a migração, enquanto o DynamoDB possui menos flexibilidade, exigindo um trabalho maior no tratamento de dados na aplicação, convertendo e adaptando valores, como o tipo Data, que é um exemplo que não possui suporte. A Tabela 2 relaciona as três tecnologias com seus respectivos tipos de dados, destacando as diferenças de suporte aos tipos de dados para cada banco. Bancos MongoDB Cassandra DynamoDB Tabela 2 - Tipos de dados por Banco NoSQL Tipos de Dados Suportados String, integer, boolean, double, arrays, timestamp, object, null, symbol, date, object id, binary data, code. Ascii, bigint, blob, Boolean, conter, decimal, double, float, ine, int, text, timestamp, timeuuid, uuid, uuid, varchar, varint. Number, string, binary, boolean. A forma como os dados são representados e a modelagem em cada tecnologia utilizada no estudo de caso, permitiu com que fosse entendido as diferenças da representação em cada um dos bancos NoSQL. A Tabela 3 representa as estruturas de cada banco, destacando os nomes dados para cada estrutura comparando-os com a representação no PostgreSQL. Tabela 3 - Modelo de dados para cada Tecnologia PostgreSQL MongoDB Cassandra DynamoDB Base de dados Base de dados KeySpace Base de Dados Tabela Coleção Família de colunas TTabela Registro Documento Linha chave Item

40 40 A modelagem dos dados representou uma das tarefas mais importantes na migração, pois o processo de análise para sair de um modelo relacional normalizado a um sem normalização exigiu que fossem feitas adaptações, em sua maioria, baseadas nas consultas da aplicação. A tabela aluguel, por exemplo, foi representada em MongoDB como uma estrutura contendo referências para o cliente e o usuário. Já no Cassandra, era armazenada como uma linha chave, indexada pelo filme_id, com colunas de cliente_ids contendo as informações do aluguel. No DynamoDB, foi separada em uma tabela com as informações do aluguel, e outra com índices para a tabela de clientes e usuários. Cada tecnologia, representou um nível de dificuldade diferente na modelagem, onde o modelo chave/valor representado pelo DynamoDB, foi o mais simples de ser representado, e o MongoDB que é baseado em documentos, o mais complexo, por necessitar de consultas múltiplas para representar os JOINs do PostgreSQL. Em relação as consultas, Cassandra possui uma linguagem bem próxima ao SQL, o que facilitou no processo de migração, já o MongoDB e o DynamoDB utilizam conceitos diferentes, um objeto para acessar os documentos no MongoDB e objetos de especificaçñao de Queries no DynamoDB, tornando as consultas mais próximas de uma linguagem de programação e exigindo um prévio estudo da API da tecnologia. Os bancos DynamoDB e Cassandra apresentaram melhores resultados para adaptação das consultas e dados, enquanto o MongoDB exigiu mais mudanças na aplicação para garantir o funcionamento equiparado ao quando utilizava o banco relacional PostgreSQL. A estrutura das tabelas do PostgreSQL, pode ser melhor mantida no DynamoDB, exceto as que continham referencias, que precisaram ser divididas. A Tabela 4 expõe uma comparação entre as principais consultas da aplicação, demonstrando as correspondências de linguagem entre os Bancos de Dados Cassandra e PostgreSQL, e as diferenças em relação aos outros dois.

41 41 PostgreSQL MongoDB Cassandra DynamoDB SELECT id, nome, cpf, idade FROM cliente where cpf like? UPDATE usuario SET nome =?, login =?, senha =? WHERE id =? DELETE * FROM usuario WHERE id =? INSERT INTO filme(id, titulo, genero, classificacao, preco) VALUES (?,?,?,?,?) connection.getdb().getcollection("cliente").find(new Document("cpf", cpf)); connection.getdb().getcollecti on("usuario").updateone(new Document("_id", u.getid()), new Document( $set,new Document().append("nome", u.getnome()).append("login", u.getlogin()).append("senha", u.getsenha())); connection.getdb().getcollecti on("usuario").deletemany(new Document( _id,u.getid())) connection.getdb().getcollecti on("filme").insertone(new Document().append( titulo,f.g ettitulo()).append( genero,f. getgenero()).append( classific acao,f.getclassificacao()).ap pend( preco,f.getpreco())) SELECT * FROM cliente WHERE cpf=? UPDATE usuario SET nome =?, login =?, senha =? DELETE * FROM usuario WHERE id =? INSERT INTO filme(id, titulo, genero, classificacao, preco) VALUES (?,?,?,?,?) new QuerySpec().withKeyConditionExpressi on("id = :v_id".withvaluemap(new ValueMap().withString(":cpf",?)); new UpdateItemSpec().withPrim arykey( id,u.getid()).wi thupdateexpression("set #nome = :nome, #login = :login, #senha = :senha ).withnamemap(new NameMap().with( #nome, n ome ).with( #login, logi n ).with( #senha, senha )).withvaluemap(new ValueMap().withString( #n ome,u.getnome()).withstr ing( #login,u.getlogin() ).withstring( #senha,u.g etsenha())) new DeleteItemSpec().withPrimaryKey("Id", u.getid()).withreturnvalu es(returnvalue.all_old); new Item().withPrimarykey( id,f.getid()).withstring( titulo,f.gettitulo()).wi thstring( genero,f.getge nero()).withstring( class ificacao,f.getclassifica cao()).withstring( preco,f.getpreco()); Tabela 4 - Comparação dos CRUDs entre os Bancos de Dados

42 42 6. CONCLUSÃO A migração de aplicações para bancos NoSQL constitui um processo importante, dado os ganhos proporcionados por essas tecnologias, como velocidade de acesso e escalabilidade. Nesse estudo de caso, pode-se compreender um pouco mais dos modelos orientado a documentos, família de colunas e chave/valor, destacando pontos como modelagem baseada na necessidade da aplicação, e características de representação das consultas, que ajudam na escolha da tecnologia a ser utilizada e da necessidade de migração para o NoSQL. A ideia de migrar de forma intrusiva ainda representa um trabalho complexo, por necessitar de uma análise prévia de impacto nas modificações, embora as tecnologias aqui apresentadas, demonstraram um bom suporte para que fosse adaptado sem grandes mudanças. As características de cada tecnologia NoSQL apresentadas proporcionaram uma melhor compreensão desse modelo de banco de dados, o que ajuda no processo de escolha da melhor tecnologia para a sua necessidade. Além disso, a arquitetura de modificação utilizada, proporciona poucas mudanças no código-fonte, o que pode garantir a ocorrência de menos problemas em sua constituição. Nesse sentido, o trabalho desenvolvido contribui para uma melhor compreensão da migração de software, especificando ideias que podem ser aplicadas em outros sistemas legados, obtendo bons resultados em uma migração para um banco NoSQL na nuvem e representando uma alternativa para as pessoas que estudam a possibilidade de migrar sua aplicação. Como trabalhos futuros, existe a possibilidade de analisar o desempenho de cada banco NoSQL após a migração, comparando o tempo das consultas e tamanho do armazenamento. Além disso, ainda pode ser feito um estudo aplicado a migração de um banco NoSQL orientado a grafos, para comparar com os outros modelos utilizados nesse trabalho e desenvolver um conjunto de características que diferenciam cada modelo. Um outra alternativa, seria a de migrar uma aplicação que utiliza um Framework ORM como o Hibernate, analisando as possíveis interceptações e o comportamento após o processo de migração. Por fim,