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

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, 4545 – 38.411-106 – Uberlândia – MG – Brasil
{felipesp.ads,sonia.ap.santana}@gmail.com, [email protected],
[email protected]
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
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].
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
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.
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.
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.
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
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. 103. Disponível em: http://www.devmedia.com.br/jpa-hibernate-ounosql-qual-utilizar-revista-java-magazine-103/24386. Acesso em 12/04/2013.
IANNI, V. “Introdução aos bancos de dados NoSQL”. Disponível
http://www.devmedia.com.br/introducao-aos-bancos-de-dados-nosql/26044.
Acesso em 02/04/2013.
em:
MIGUEL, S. B.; CARNEIRO, F. C. F. Repositório de Dados Relacional ou NoSQL?
“Revista
Java
Magazine”,
n.
114.
Disponível
em:
http://www.devmedia.com.br/repositorio-de-dados-relacional-ou-nosql-revistajava-magazine-114/27500#ixzz2QwZa877Z. Acesso em 02/04/2013.
NASCIMENTO, J. “ NoSql – você realmente sabe do que estamos falando?”.
Disponível em: http://imasters.com.br/artigo/17043/banco-de-dados/nosql-vocerealmente-sabe-do-que-estamos-falando/. Acesso em 23/04/2013.
NETO, A. C. D. Bancos de Dados Relacionais. “Revista SQL Magazine”, n. 86.
Disponível em: http://www.devmedia.com.br/bancos-de-dados-relacionais-artigorevista-sql-magazine-86/20401. Acesso em 09/04/2013.
QUICOLI, P. Desenvolvimento NoSql no Delphi XE 2. “Revista ClubeDelphi”, n. 138.
Disponível
em:
http://www.devmedia.com.br/revista-clubedelphi-138/23660.
Acesso em 05/08/2013.
VARDANYAN, M. “Escolhendo a ferramenta certa para o banco de dados NoSql”.
Disponível em: http://imasters.com.br/artigo/21781/banco-de-dados/escolhendo--aferramenta-certa-para-o-banco-de-dados-nosql/. Acesso em 15/04/2013.
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:
http://data.ime.usp.br/sbbd2012/artigos/pdfs/sbbd_min_01.pdf.
Acesso
em
01/04/2013.