Utilização de Banco de Dados NoSql em Ambientes Corporativos

Transcrição

1 Utilização de Banco de Dados NoSql em Ambientes Corporativos Felipe S. Pereira, Hermes P. Borges, Helio Rubens, Sonia A. Santana Unitri Centro Universitário do Triângulo Avenida Nicomedes Alves dos Santos, Uberlândia MG Brasil Abstract. The relational database has secured its place in recent years and is present in nearly all applications that utilize a structure for data storage. But as the volume of data increases over time, it is necessary to search for new structures for storing information. As the volume of data, scalability, and distributed storage has become the relational model impractical in some situations. In this context, a new data storage paradigm, the NoSQL database. This article discusses the use of NoSQL in enterprise environments as a single structure database within a context. Among the exhibited models, is performed implementing a prototype application using the Cassandra database and discussed its viability. Resumo. O banco de dados relacional tem garantido seu espaço nos últimos anos e está presente em quase todas as aplicações que utilizam uma estrutura para armazenamento de dados. Mas conforme o volume de dados aumenta com o passar do tempo, faz-se necessário a busca de novas estruturas para armazenamento de informações. Assim como o volume de dados, a escalabilidade e o armazenamento distribuído tem tornado o modelo relacional inviável em algumas situações. Neste contexto, surge um novo paradigma de armazenamento de dados, o banco de dados NoSql. Este artigo aborda a utilização de NoSql em ambientes corporativos como única estrutura de banco de dados dentro de um contexto. Dentre os modelos expostos, é realizado a implementação de um protótipo de aplicativo utilizando o banco de dados Cassandra e discutido sua viabilidade. 1. Introdução Sistemas de grande porte necessitam que seus bancos de dados tenham capacidade de fornecer de maneira eficaz acesso a diversos usuários simultaneamente. Neste contexto, milhares de requisições em paralelo são enviadas ao banco de dados solicitando, alterando ou gravando alguma informação. Para suportar tal estrutura é preciso que os servidores de aplicação sejam robustos e com excelente desempenho. Mesmo utilizando vários servidores com altíssimo poder de processamento, em alguns aspectos os Banco de Dados Relacionais (BDR) não têm atendido de modo satisfatório, devido à imensa quantidade de

2 informações geradas. Aplicações que utilizam BDR comumente após grande volume de dados costumam apresentar alguma demora no tempo de resposta às aplicações. O grande volume de informações geradas por usuários conectados por todo o mundo demandou a criação de uma estrutura de banco de dados que fornecesse maior desempenho e escalabilidade para as aplicações. A partir desta necessidade, surgiu o conceito Not Only SQL (NoSql) de banco de dados. O conceito NoSql surgiu em 1998, mas começou a caminhar efetivamente em 2004 com a criação do Banco de Dados (BD) BigTable pela empresa Google. Logo depois as empresas Amazon, em 2007, e Facebook, em 2008, lançaram respectivamente os BDs Dynamo e Cassandra. A partir daí surgiram diversas soluções em BD NoSql, entre elas estão: CouchDB, MongoDB, Neo4J, InfoGrid, HBase e outros [IANNI, 2013]. Este trabalho objetiva analisar a viabilidade da utilização do NoSql em aplicações corporativas. Está estruturado conforme a seguir: A seção 2 apresenta os conceitos e visão geral a respeito dos bancos de dados NoSql e suas características. A seção 3 contextualiza a estrutura de banco de dados utilizada por ambientes corporativos, suas características e conceitos. A seção 4 apresenta as deficiências dos BDRs e as necessidades que motivam a utilização dos BD NoSql. A seção 5 apresenta a implementação de uma aplicação em um ambiente corporativo utilizando um dos bancos de dados NoSql apresentados anteriormente. 2. Conceitos e visão geral de NoSql Os BDs NoSql surgiram para solucionar problemas com aplicações que trabalham de maneira distribuída e com grandes cargas de dados. Não foram criados para eliminar os BDRs, e sim solucionar problemas em contextos que exijam maior necessidade de escalabilidade e disponibilidade de servidores de Bancos de Dados para as aplicações. Em outras palavras, o NoSql é um conceito alternativo ao Modelo Relacional para atender determinados nichos nos quais os BDRs apresentam limitações. Dentre as principais características dos BDs NoSql estão a desnormalização das informações e alto desempenho no armazenamento paralelo de dados em grande escala. Eles apresentam a capacidade de ser escalados horizontalmente, instalando servidores com menor capacidade de processamento um ao lado do outro. E assim conseguem tratar da leitura e escrita de uma enorme quantidade de dados. Segundo Ianni(2013), os BDs NoSql...permitem uma escalabilidade mais barata e menos trabalhosa, pois não exigem máquinas extremamente poderosas e sua facilidade de manutenção permite que um número menor de profissionais seja necessário. O processamento de dados distribuídos é possível através da utilização do conceito de MapReduce, que realiza o mapeamento dos dados para os servidores que irão processá-los e gerar um resultado [VIEIRA et. al., 2012]. Quanto ao tipo de controle de consistência, os BDs NoSql implementam o modelo Basically Available, Soft-state, Eventually consistency (BASE), que fornece à aplicação uma visão de que está disponível o tempo todo para consistência, o que não ocorre na realidade, realizando a consistência no momento adequado [QUICOLI, 2013].

3 Alguns dos BDs NoSql operam ou foram estruturados com características distintas, para diferenciá-las existem quatro modelos mais comuns, são eles [VARDANYAN, 2013]: Armazenamento Chave-Valor: Os BDs baseados neste modelo utilizam o conceito de uma chave e um valor, conhecida como tabela hash, para consistir os registros e garantir que não ocorra redundância. Armazenamento Column Families / Wide Column Store: Apesar de não conter o conceito de tabelas do modelo Entidade Relacionamento (ER), este modelo de BD armazena as informações em famílias de colunas. Neste conceito as linhas são ordenadas e agrupadas conforme seu contexto, daí a semelhança com tabelas do ER. É o modelo mais propício e com melhor desempenho a ambientes com grandes processamentos de dados distribuídos. Banco de Dados orientado a Documentos: O modelo é composto por documentos em vez de registros, onde estes normalmente são baseados em extensible Markup Language (XML) ou JavaScript Object Notation (JSON). Banco de Dados orientado a Grafos: Este modelo utiliza estrutura de grafo para armazenar as informações. As informações são classificadas e armazenadas como entidades, assim como, suas relações são estabelecidas por meio de relacionamentos. Em vez de tabelas com linhas e colunas, este modelo é flexível e pode ser escalado através de varias máquinas. A Figura 1 apresenta qual modelo é mais indicado para cada tipo de situação, tendo como referência quantidade e a complexidade das informações armazenadas. Figura 1. Situação ideal para cada modelo de BD [NASCIMENTO, 2010]. A melhor escolha por qual modelo de BD NoSql utilizar nas aplicações geralmente é definida de acordo com a quantidade das informações que se armazenará. Conforme ilustrado na Figura 1, até 90% dos casos de uso as aplicações podem ser

4 atendidas por BD diferente de NoSql. Quando a quantidade dessas informações é em grande escala e o crescimento constante, o NoSql se torna viável. A escolha do modelo de BD NoSql a ser utilizado terá variação em cada contexto, tendo como variáveis a quantidade e complexidade das informações armazenadas. É importante salientar que a aplicação pode trabalhar simultaneamente com BD relacional e NoSql. De maneira que o NoSql opere em cenários que manipulem grande escala de dados, pois este é estruturado para esta finalidade, e o BD relacional os demais cenários. 3. Estrutura convencional atualmente utilizada em ambientes corporativos Banco de Dados relacional é comumente o BD mais utilizado por atender à grande maioria das necessidades das aplicações. Entre privados e livres existem diversos BDR, alguns deles são: MySql, Oracle, SQLServer, DB2, Firebird, PostgreSQL. Os BDRs contam com grande suporte técnico de empresas e comunidades livres, e também possuem inúmeros profissionais capacitados a desenvolver aplicações neste ambiente. Se comparado a outros tipos, os BDRs lideram a utilização nos mais variados seguimentos de aplicações existentes. O armazenamento dos dados é realizado em tabelas com linhas e colunas identificadas por uma chave primária. Além desta chave pode ter uma ou mais colunas que identificam as informações daquela linha. Por meio das chaves pode-se fazer ligações entre outras tabelas, permitindo agrupar as informações com Joins entre as tabelas. Para a criação da estrutura dos BDRs é utilizada a linguagem Data Definition Language (DDL), para manipular as informações Data Manipulation Language (DML) e por fim para atribuir permissões dos usuários às tabelas criadas é utilizada a Data Control Language (DCL). É possível também a criação de índices que permitem uma forma mais rápida de buscar informações nas tabelas[neto, 2013]. Os principais pontos dos BDRs é que oferecem Atomicidade, Consistência, Isolamento e Durabilidade (ACID). Atomicidade garante que todas as informações serão processadas ou nada é feito, em caso de erro, todas as transações anteriores são desfeitas; Consistência das informações, ao iniciar uma manipulação nos dados e finalizá-la, a alteração nos dados devem estar consistentes no BD; Isolamento, as transações são realizadas individualmente sem dependerem um das outras internamente no BD; Durabilidade, após uma alteração ser realizada com sucesso ela não e mais desfeita [ARAUJO e GUIZZO, 2013]. 4. Deficiências do modelo relacional Desde que surgiu o modelo relacional, este passou por pequenas mudanças para acomodar as novas exigências de negócio e linguagens de programação. Algumas deficiências dos BDRs que dificilmente serão supridas devido sua arquitetura vêm motivando a utilização de uma arquitetura de banco de dados mais flexível, leve e escalável, chamada NoSql.

5 Os BDRs possuem um alto custo de escalabilidade, que pode ser feita de duas formas, horizontal e vertical. A escalabilidade horizontal pode ser feita particionando a estrutura de dados de acordo com alguns critérios estabelecidos, embora com mais dificuldade se comparado ao NoSql. A escalabilidade vertical pode ser feita aumentando a capacidade de processamento do servidor, onde e necessário um gasto alto com a compra de equipamentos cada vez mais sofisticados e robustos. À medida que o número de usuários se propaga pode chegar o momento em que não se torna mais viável aumentar a capacidade de processamento do servidor. Sendo assim, o problema transfere dos servidores para o banco de dados, que não suporta tantas conexões simultâneas. Em busca de performance, serão iniciadas alterações na aplicação/bd como retirada de Chaves Primárias, criação de Índices e Views, assim como, tentativas de reduzir os Joins [MIGUEL e CARNEIRO, 2013]. No geral, os BDRs atendem bem a aplicações de pequeno, médio e grande porte, porém não foram criados para armazenar dados de forma distribuída e suportar um alto processamento de informações exigido por algumas aplicações. Algumas soluções de BDRs até possuem suporte a processamento de dados distribuídos, mas não atendem com a mesma eficácia que se tem em seu modelo relacional. Pois em grande número de servidores (horizontalmente) se torna inviável devido à complexidade e baixo desempenho encontrados. Devido a esta característica relacional o escalonamento deve ser feito de forma vertical, ou seja, aumentando a capacidade de processamento (hardware) do servidor. E muitas vezes chegando ao limite do hardware sem ter a performance esperada. Para situações como estas o processamento e armazenamento de dados distribuídos se torna indispensável. 5. Implementando o NoSql em ambiente coorporativo Como ambiente para implementação optou-se por um aplicativo que registra ocorrências de funcionários em uma corporação. Mesmo conhecendo que para este ambiente o modelo relacional atenderia de melhor maneira, será avaliada a implementação utilizando uma distribuição do NoSql baseado nos seguintes critérios: Tempo de desenvolvimento Suporte especialista Facilidade na manutenção dos dados via interface Integridade O aplicativo abordado terá como recursos um cadastro de pessoas da corporação, seu respectivo cargo e função, e também um histórico de ocorrências como faltas, advertências e atestados. Como linguagem de programação optou-se pelo Personal Home Page (PHP), por ser uma tecnologia web, gratuita e de grande utilização pelo mercado. Quanto ao banco de dados optou-se pelo NoSql Cassandra por ser case de sucesso, em contexto parcial, em algumas grandes empresas como facebook e twiter. Cassandra também oferece como recurso Cassandra Query Language (CQL) e também é isento de licença.

6 Como no conceito NoSql não existem relacionamentos entre tabelas. O Cassandra armazena os dados no formato de chave-valor em famílias de colunas. A Figura 2 representa a estrutura inicial do banco de dados criado para a aplicação. Figura 2. Estrutura do banco de dados da aplicação. A parte gráfica do aplicativo é uma tela para cada família de colunas, ou seja, Função, Histórico e Funcionário. Quanto às informações que não necessitam cadastros (como tipo de pessoa, tipo do histórico) os possíveis valores para estes atributos ficaram no código do PHP. Tendo como tipo de pessoa os valores (ATENDENTE e GERENTE) e como tipo de histórico os valores (ATESTADO, FALTA e ELOGIO). Referente aos históricos e funções, a cada inserção de um novo valor é criado em tempo de execução uma coluna nova. Na Figura 3 é apresentado um exemplo de criação das estruturas das super colunas, neste caso o código corresponde a super conluna função: Figura 3. Estrutura da super coluna função.

7 A Figura 4 apresenta o exemplo de inserção de registro na estrutura criada: Figura 4. Inserindo registro na estrutura da super coluna função. O tempo de desenvolvimento em NoSql se torna mais oneroso se comparado com uma aplicação utilizando um BD relacional, o controle das chaves e alguns valores ficam por conta da aplicação, pois não dispomos de recursos como IDs autoincremento, triggers e funções, o que torna o código mais complexo e difícil de ser desenvolvido. Para BDs relacionais é possível encontrar frameworks capazes de gerar telas completas com insert, delete e update o que possibilita uma maior rapidez de desenvolvimento. Quanto ao suporte, como o Cassandra é mantido pela Apache, este suporte não possui custos. Por outro lado, caso necessite é preciso recorrer a comunidade livre ou à fundação Apache Cassandra. Não se tem no mercado de trabalho profissionais certificados, nem meio para certificação dos mesmos, as informações disponibilizadas pelo site oficial do Cassandra estão disponíveis somente me inglês. Existe pouco conteúdo aprofundado disponível na internet para pesquisa se comparado aos BDs Oracle, MySql e outros já mais difundidos no mercado. O client, neste caso o Cassandra-Gui, utilizado para manutenção oferece poucos recursos para manipulação dos dados e estrutura do banco de dados. Não possui suporte a linguaguem CQL, linguagem nativa, onde é possível realizar comandos como select e update parecidos com a linguagem utilizada no BD relacional. Não existem ferramentas alternativas como PLSql-developer (Oracle) ou Workbench(MySql) que possuem diversas utilidades que facilitam na momento de criação do BD ou na manutenção das informações nele armazenadas. Como o NoSql não oferece ACID, a integridade dos dados fica comprometida. As informações são armazenadas em linhas, e assim, não é possível realizar join entre as mesmas. O que torna a extração dos dados mais difícil e menos precisa. O NoSql está mais focado em simplesmente armazenar a informação sem a criação de chaves e verificação de valores. Para as grandes corporações, quanto mais informações se têm maior é o valor agregado a elas. Através das informações diversas estratégias podem ser traçadas. Em aplicações corporativas as informações necessitam de maior controle para cada registro gerado ou alterado no banco de dados, também é necessário garantir que a informação permaneça consistente conforme foi inserida ou manipulada. 6. Conclusão Os BDs NoSql estão sendo utilizado cada vez mais em softwares que necessitam armazenar uma grande quantidade de informações, estas informações são simplesmente

8 gravadas para uma consulta posterior. Em aplicações corporativas ele ainda esta por desejar, pois não oferece um bom controle das informações e formas de alterar e tratar os dados com a mesma eficiencia dos Bancos de dados relacionais. Em caso de possíveis falhas em transações, os bancos de dados relacionais oferecem uma boa gama de recursos para corrigir e evitar que dados sejam perdidos. A quantidade de profissionais conhecedores e de material para estudo de NoSql ainda é pequena, enquanto os Bancos relacionais estão bem difundidos nas empresas e entre os profissionais de Tecnologia da Informação. Assim a utilização de NoSql em softwares coorporativos se torna inviável, pois necessitam de um excelente controle de informações, e a sua massa de dados não atige tamanhos gigantescos como ocorre em aplicações como facebook e twitter para justificar o uso do NoSql como Banco de dados de toda a aplicação, a velocidade para desenvolvimento de aplicações utilizando a arquitetura relacional é superior e oferece mais recursos de controle e manipulação da informação resultando em uma confiabilidade maior nos dados gravados, ressaltando que é possível utilizar as duas arquiteturas de banco de dados no mesmo software, como estudo posterior é sugerido a criação de framework capaz de gerir uma aplicação em NoSql. Referências ARAUJO, E.C., GUIZZO, G. JPA/Hibernate ou NoSql, qual utilizar?. Revista Java Magazine, n Disponível em: Acesso em 12/04/2013. IANNI, V. Introdução aos bancos de dados NoSQL. Disponível em: Acesso em 02/04/2013. MIGUEL, S. B.; CARNEIRO, F. C. F. Repositório de Dados Relacional ou NoSQL? Revista Java Magazine, n Disponível em: Acesso em 02/04/2013. NASCIMENTO, J. NoSql você realmente sabe do que estamos falando?. Disponível em: Acesso em 23/04/2013. NETO, A. C. D. Bancos de Dados Relacionais. Revista SQL Magazine, n. 86. Disponível em: Acesso em 09/04/2013. QUICOLI, P. Desenvolvimento NoSql no Delphi XE 2. Revista ClubeDelphi, n Disponível em: Acesso em 05/08/2013. VARDANYAN, M. Escolhendo a ferramenta certa para o banco de dados NoSql. Disponível em: Acesso em 15/04/2013.

9 VIEIRA, M. R., et al. Bancos de Dados NoSQL: Conceitos, Ferramentas, Linguagens e Estudos de Casos no Contexto de Big Data. In: Simpósio Brasileiro de Bancos de Dados, 2012, São Paulo. Disponível em: Acesso em 01/04/2013.