FACULDADE DE TECNOLOGIA DE SÃO JOSÉ DOS CAMPOS
FELIPE GUSTAVO DE SOUSA ISSA
ESTUDO COMPARATIVO ENTRE BANCO DE DADOS
RELACIONAIS E BANCO DE DADOS NoSQL
NA UTILIZAÇÃO POR APLICAÇÕES DE BUSINESS INTELLIGENCE
SÃO JOSÉ DOS CAMPOS
2011
FELIPE GUSTAVO DE SOUSA ISSA
ESTUDO COMPARATIVO ENTRE BANCO DE DADOS
RELACIONAIS E BANCO DE DADOS NoSQL
NA UTILIZAÇÃO POR APLICAÇÕES DE BUSINESS INTELLIGENCE
TRABALHO
DE
GRADUAÇÃO
APRESENTADO À FACULDADE DE
TECNOLOGIA DE SÃO JOSÉ DOS
CAMPOS,
COMO
PARTE
DOS
REQUISITOS NECESSÁRIOS PARA A
OBTENÇÃO
DO
TÍTULO
DE
TECNÓLOGO EM BANCO DE DADOS.
Orientador: Fernando Masanori Ashikaga
SÃO JOSÉ DOS CAMPOS
2011
FELIPE GUSTAVO DE SOUSA ISSA
ESTUDO COMPARATIVO ENTRE BANCO DE DADOS
RELACIONAIS E BANCO DE DADOS NoSQL
NA UTILIZAÇÃO POR APLICAÇÕES DE BUSINESS INTELLIGENCE
TRABALHO
DE
GRADUAÇÃO
APRESENTADO À FACULDADE DE
TECNOLOGIA DE SÃO JOSÉ DOS
CAMPOS,
COMO
PARTE
DOS
REQUISITOS NECESSÁRIOS PARA A
OBTENÇÃO
DO
TÍTULO
DE
TECNÓLOGO EM BANCO DE DADOS.
________________________________________________________________
CARLOS AUGUSTO LOMBARDI GARCIA
________________________________________________________________
JULIANA FORIN PASQUINI MARTINEZ
________________________________________________________________
FERNANDO MASANORI ASHIKAGA
___/___/___
DATA DE APROVAÇÃO
‘O único lugar aonde o êxito chega antes do trabalho é no dicionário’.
Vidal Sassoon
I
AGRADECIMENTOS
Agradeço a minha família, que sempre me apoiou nos momentos difíceis, aos
professores, sempre dedicados à sua missão de educar, e aos amigos e colegas de
curso, que estiveram comigo nos últimos três anos.
II
RESUMO
Bancos de dados são amplamente utilizados em diversas áreas da sociedade. Eles
são parte essencial do controle do negócio de diversas empresas, pois elas possuem
grandes quantidades de dados financeiros e estratégicos sobre seus clientes e
colaboradores, e estes dados precisam ser gravados de alguma forma.
Conforme as empresas aderem à informatização, a quantidades de dados
armazenados tende a crescer, e com isso o desempenho das aplicações de banco de
dados tende a cair. Existem novos modelos de bancos de dados, que foram criados com
o intuito de resolver estes problemas, e um desses novos modelos é o NoSQL.
Este trabalho tem como objetivo fazer um estudo comparativo entre banco de dados
Relacionais e NoSQL, e identificar qual é mais adequado para utilização em uma
aplicação de BI (Business Inteligence).
Palavras Chave: banco de dados colunar, banco de dados relacional, estudo
comparativo, NoSQL.
III
ABSTRACT
Databases are largely used in several areas of the society. They are an essential part
of many companies, because they have a large amount of financial and strategic data
about their clients and employees, and this data need to be saved somehow.
As the companies goes into informatization, the amount of data they store grow up,
and the performance of the database applications tends to decrease. There are new
model of databases, that were created in order to solve this problems, and one of this
models is the NoSQL.
This paper has the objective of doing a comparative study between relational and
NoSQL databases, and to identify witch on is more suitable for a Business Intelligence
Aplication.
Keywords: column oriented databases, relational databases, comparative study,
NoSQL
IV
LISTA DE ABREVIATURAS E SIGLAS
ACID - Atomicidade, Consistência, Isolamento e Durabilidade
API - Application Programming Interface (Interface de Programação de Aplicações)
BI - Business Intelligence
DW - Data Warehouse
GPL - General Public License
SGDB - Sistema Gerenciador de Banco de Dados
MB - Megabyte
Modelo ER - Modelo Entidade Relacionamento
SQL - Structured Query Language (Linguagem de Consulta Estruturada)
TB - Terabyte
TI - Tecnologia da Informação
NoSQL – Modelos de dados distintos do modelo relacional
V
ÍNDICE DE FIGURAS
Figura 1 - Alguns dos principais SGDBs em uso ............................................................. 6
Figura 2 - A mesma informação armazenada em diversos arquivos ................................ 7
Figura 3 - Esquema do banco de dados de uma instituição bancária ............................ 12
Figura 4 - Um esquema normalizado ............................................................................. 13
Figura 5 - Tabelas que representam a tabela 3de forma normalizada ............................ 16
Figura 6 - Tabela Key/Value .......................................................................................... 19
Figura 7 - Um documento............................................................................................... 20
Figura 8 - Pentaho .......................................................................................................... 26
Figura 9 - Pentaho .......................................................................................................... 26
Figura 10 - Modelo dimensional do data warehouse...................................................... 31
Figura 11 - Comparativo do desempenho na primeira querie ........................................ 39
Figura 12 - Gráfico comparativo do desempenho da segunda querie ............................ 40
Figura 13 - Gráfico comparativo do desempenho na terceira querie ............................. 41
Figura 14 - Gráfico comparativo do desempenho na quarta querie ............................... 42
Figura 15 - Comparativo do uso de memória na primeira querie................................... 46
Figura 16 - Comparativo do uso de memória na segunda querie ................................... 47
Figura 17 - Gráfico comparativo do uso de memória na terceira querie ........................ 48
Figura 18 - Comparativo do uso de memória na quarta querie ...................................... 49
Figura 19 - Comparativo da alocação dos dados em disco ............................................ 50
Figura 20 - Análise comparativa do desempenho com 1000MB de memória total ....... 52
Figura 21- Quantidade de memória livre durante a execução dos testes com 1000MB de
memória total .................................................................................................................. 53
Figura 22 - Análise comparativa do desempenho com 500MB de memória total ........ 54
Figura 23- Quantidade de memória livre durante a execução dos testes com 500BM de
memória total .................................................................................................................. 55
VI
ÍNDICE DE TABELAS
Tabela 1 - Tabela Relacional Alunos ............................................................................. 10
Tabela 2 - Tabela aluno com as linhas desordenadas ..................................................... 11
Tabela 3 - Tabela de livros não normalizada.................................................................. 15
Tabela 4 - Diferença entre sistemas operacionais e analíticos ....................................... 25
Tabela 5 - Análise comparativa do desempenho na primeira querie .............................. 38
Tabela 6 - Análise comparativa do desempenho na segunda querie .............................. 39
Tabela 7 - Análise comparativa do desempenho na terceira querie ............................... 41
Tabela 8 - Análise comparativa do desempenho na quarta querie ................................. 42
Tabela 9 - Análise comparativa do uso de cpu na primeira querie................................. 43
Tabela 10 - Análise comparativa do uso de cpu na segunda querie ............................... 44
Tabela 11 – Análise comparativa do uso de cpu na terceira querie ............................... 44
Tabela 12 - Análise comparativa do uso de cpu na quarta querie .................................. 45
Tabela 13 - Análise comparativa do uso de memória na primeira querie ...................... 46
Tabela 14 - Análise comparativa do uso de memória na segunda querie....................... 46
Tabela 15 – Análise comparativa do uso de memória na terceira querie ....................... 48
Tabela 16 - Análise comparativa do uso de memória na quarta querie .......................... 49
Tabela 17 - Análise comparativa da alocação em disco ................................................. 50
Tabela 18 - Análise comparativa do desempenho com 1000MB de memoria total ....... 51
Tabela 19 – Análise comparativa da memória livra com 500MB de memória total ...... 52
Tabela 20 – Análise comparativa do desempenho com 500MB de memória total ........ 53
Tabela 21 – Análise comparativa da memória livre com 500mb de memória total ....... 54
VII
SUMÁRIO
1
Introdução ................................................................................................. 1
1.1
Motivação .......................................................................................................... 1
1.2
Problema ............................................................................................................ 2
1.3
Proposta de solução ........................................................................................... 2
1.4
Organização do Trabalho ................................................................................... 3
2
Revisão de literatura de banco de dados. .................................................. 4
2.1
Definição ............................................................................................................ 4
2.2
Aplicações do sistema gerenciador de banco de dados ..................................... 5
2.3
Finalidade dos sistemas de banco de dados ....................................................... 6
2.4
Modelo de Dados ............................................................................................... 8
2.4.1
Modelo Relacional ...................................................................................... 8
2.4.2
Modelo de entidade / relacionamento ......................................................... 9
2.4.3
Modelo de dados orientado a objetos ......................................................... 9
2.5
Bancos de dados Relacionais ............................................................................. 9
2.5.1
Estrutura básica......................................................................................... 10
2.5.2
Chaves ...................................................................................................... 11
2.5.3
Normalização ............................................................................................ 12
2.5.4
ACID ........................................................................................................ 14
2.6
Banco de Dados Orientados a objetos ............................................................. 14
2.6.1
2.7
Banco de dados NoSQL ................................................................................... 17
2.7.1
Armazenamento Key/Value ..................................................................... 18
2.7.2
Armazenamento de documentos............................................................... 19
2.7.3
Armazenamento de grandes colunas ........................................................ 20
2.7.4
Bancos de dados Orientados a coluna ...................................................... 21
3
Business Intelligence .............................................................................. 22
3.1
Business Intelligence ....................................................................................... 22
3.2
Definição .......................................................................................................... 23
3.2.1
3.3
4
Tipos de dados complexos........................................................................ 15
Objetivos de uma aplicação de BI ............................................................ 24
Pentaho............................................................................................................. 25
Ferramentas Utilizadas............................................................................ 27
VIII
4.1
Mysql ............................................................................................................... 27
4.2
LucidDB........................................................................................................... 28
4.3
Apache JMeter ................................................................................................. 28
4.4
Monitor de Desempenho do Windows ............................................................ 28
4.5
Oracle Virtual Box ........................................................................................... 29
5
Proposta de solução................................................................................. 30
5.1
Sistemas Gerenciadores de Banco de dados utilizados para estudo ................ 30
5.2
Definição da aplicação analisada ..................................................................... 30
5.2.1
Definição do modelo de dados ................................................................. 31
5.3
Definição do ambiente de teste ........................................................................ 32
5.4
Definição dos testes ......................................................................................... 32
5.5
Definição dos critérios analisados ................................................................... 33
5.5.1
Desempenho ............................................................................................. 33
5.5.2
Utilização de CPU .................................................................................... 34
5.5.3
Uso de memória ........................................................................................ 34
5.5.4
Alocação das tabelas em disco ................................................................. 34
5.5.5
Desempenho utilizando menor quantidade memória RAM ..................... 34
5.6
Definição dos softwares utilizados .................................................................. 35
5.6.1
Apache JMeter .......................................................................................... 35
5.6.2
Monitor de desempenho do Windows ...................................................... 35
5.6.3
Oracle Virtual Box.................................................................................... 36
6
Resultados Encontrados .......................................................................... 37
6.1
Resultados Encontrados ................................................................................... 37
6.1.1
Análise comparativa do desempenho ....................................................... 37
6.1.2
Análise comparativa da utilização de CPU .............................................. 43
6.1.3
Análise comparativa da utilização de memória ........................................ 45
6.1.4
Análise comparativa da alocação das tabelas em disco ............................ 50
6.1.5
Desempenho utilizando menos memória RAM........................................ 51
7
Considerações finais ............................................................................... 56
7.1
Contribuições e Conclusões ............................................................................. 56
7.2
Trabalhos Futuros ............................................................................................ 57
8
Referencias Bibliográficas ...................................................................... 58
9
Apêndice ................................................................................................. 61
9.1
Apêndice 1: Tabelas do modelo de dados ....................................................... 61
IX
9.2
Apendice 2: Scrips das buscas efetuadas nos bancos de dados ....................... 62
1
1
Introdução
1.1
Motivação
A utilização de sistemas computadorizados aumentou consideravelmente a
quantidade de informação que as companhias possuem, dados estes que vão desde
informações sobre seus clientes, como histórico de compras, páginas da web acessadas,
preferências e dados da empresa, como controle de estoque, controle do sistema de
recursos humanos, financeiro e controle da produção (Leavitt, 2010).
Grandes empresas da área de tecnologia da informação, como é o caso da
Google, precisam lidar com enormes quantidades de dados diariamente. Estima-se que,
no ano de 2009, cerca de 20 Petabytes (1024 Terabytes, que podem ser utilizados para
armazenar 13.3 anos de conteúdo de vídeo de alta definição) de informação fossem
processados diariamente pela Google. Estimativas apontam que seria possível
armazenar todo o conhecimento escrito da humanidade (a partir do início da escrita, em
todas as línguas) em 50 petabytes, e apenas uma empresa de tecnologia é responsável
pelo processamento de 2/5 desta quantidade de dados (HLIP, 2009).
O Ebay, empresa americana de comércio eletrônico, possui um Data Warehouse
(DW) de 5 petabytes, que é utilizado para armazenar dados sobre seus clientes, produtos
e as transações realizadas em sua plataforma (Teradata, 2008).
Para armazenar esta grande quantidade de informação, é necessário um banco de
dados que além de possuir grande capacidade de armazenamento, consiga desempenhar
suas funções sem perda de desempenho.
A rede de relacionamentos Twitter, onde os usuários se comunicam com
mensagens de até 140 caracteres, recentemente anunciou que irá migrar sua base de
dados de Mysql para o banco de dados Cassandra, um banco de dados NoSQL. Um dos
motivos que levaram a troca do banco de dados foi a dificuldade de administrar a base
de dados, que está em constante crescimento (Mynosql, 2010).
Para auxiliar a visualização de todos estes dados, sistemas de Business
Intelligence (BI) analisam as informações armazenadas e, utilizando-se de análise
computadorizada, fornecem conclusões desse processo de modo a facilitar a
compreensão humana, utilizando gráficos e outras ferramentas de resultados interativos.
2
Os bancos de dados relacionais dominaram o mercado de armazenamento de
dados por muitos anos. Através das propriedades ACID (Atomicidade, Consistência,
Isolamento, Durabilidade), que será explicada adiante, oferecem um ambiente de
armazenamento favorável a pequenas e médias empresas. Com o crescimento da
quantidade de dados armazenados no banco, se faz necessário distribuir a base de dados.
Os bancos relacionais não estão bem preparados para esta distribuição, e perdem
desempenho no tratamento de requisições do usuário. A rede social Facebook, por
exemplo, utiliza para o seu datawarehouse um banco que não é relacional. O volume de
dados que esta aplicação gera diariamente é de aproximadamente 15 Terabytes
(CPMBC, 2009; FHH, 2009).
Enquanto bancos de dados relacionais armazenam os dados linha por linha em
disco, um banco de dados colunar, por exemplo, armazena os dados por colunas,
fazendo com que apenas os dados necessários sejam lidos, e não todos os dados no
banco (MT10AADW, 2010). O maior banco comercial existente, da Google, também é
colunar, denominado Bigtable.
1.2
Problema
Identificar, entre a metodologia relacional e a colunar, qual é mais adequada
para utilização por uma aplicação de Business Inteligence (BI).
1.3
Proposta de solução
Fazer um estudo comparativo entre banco de dados Relacionais e NoSQL, e
identificar qual é mais adequado para utilização em uma aplicação de BI.
3
1.4
Organização do Trabalho
Este Trabalho está organizado da seguinte forma:
Capítulo 2: Revisão de literatura de banco de dados
Capítulo 3: Revisão de literatura de Business Intelligence
Capítulo 4: Ferramentas utilizadas
Capítulo 5: Proposta de solução
Capítulo 6: Resultados e conclusões encontrados
Capítulo 7: Considerações finais
Capítulo 8: Referências bibliográficas.
4
2
Revisão de literatura de banco de dados.
Este capítulo apresentará a definição de banco de dados, seu funcionamento, os
modelos de armazenamento de dados, e apresentação dos principais modelos de bancos
de dados.
Este capítulo está organizado como segue: A seção 2.1 define o conceito de
banco de dados, a seção 2.2 apresenta as aplicações de um sistema gerenciador de banco
de dados, a seção 2.3 lista as finalidades do sistema de banco de dados, a seção 2.4
apresenta os modelos de dados. A seção 2.5 se destina a explicar os conceitos básicos de
bancos de dados Relacionais, a seção 2.6 apresenta os banco de dados Orientados a
Objetos, e a seção 2.7 destina-se a introduzir os bancos de dados NoSQL.
2.1
Definição
Um banco de dados pode ser definido como uma coleção de dados que possuem
um relacionamento entre si. Para que este conjunto de dados seja considerado um banco
de dados, é necessário que algumas regras sejam observadas:
•
Ser um conjunto de dados com um significado no contexto. Uma
disposição desordenada de dados não pode ser considerada um banco de dados.
•
Sua finalidade é o armazenamento de dados para um propósito
específico. Deve possuir um conjunto pré definido de usuários e aplicações.
•
Representa um aspecto do mundo real, também chamado de minimundo,
onde qualquer alteração no minimundo irá refletir nos dados armazenados no banco
(MACHADO, 2008).
Os sistemas de gerenciamento de banco de dados (SGBD) são projetados para
lidar com grandes quantidades de informações. Dentre suas funções, se destacam a
definição de estruturas de armazenamento de dados, mecanismos de controle de acesso
aos dados, manipulação de informações, compartilhamento de dados entre diversos
usuários e certificar que os dados se mantenham íntegros (SILBERSCHATZ, 2006).
5
2.2
Aplicações do sistema gerenciador de banco de dados
Bancos de dados são amplamente utilizados em diversas áreas da sociedade.
Seguem alguns exemplos de empresas e a finalidade para o qual o banco de dados é
utilizado:
Linhas aéreas: reservas e informações de horários, armazenamento de
•
informações sobre os vôos, aeronaves, funcionários, clientes e fornecedores. As
empresas aéreas foram umas das primeiras a utilizar banco de dados distribuídos entre
várias localidades;
Finanças: armazenar informações sobre valores imobiliários, vendas e
•
compras de instrumentos financeiros (ações, títulos, créditos, dívidas, etc). Também
para armazenar informações de instituições bancárias, seus clientes e movimentações de
suas contas;
Indústria: para gerenciamento de cadeia de suprimentos, controle da
•
produção em suas unidades, estoque de itens em armazéns e lojas, além de controle dos
setores de recursos humano e financeiro;
Transações de cartão de crédito: registrar e controlar compras com
•
cartões de crédito e geração de faturas mensais.
Como mostra a listagem anterior, os bancos de dados são parte essencial do
controle do negócio de diversas empresas, motivo pelo qual as empresas fornecedoras
de sistemas de banco de dados estão entre as maiores empresas do mundo, como a
Oracle, que possui os bancos de dados Oracle e Mysql, e fazem parte da linha de
produtos
de
empresas
mais
diversificadas,
como
a
Microsoft
e
a
IBM
(SILBERSCHATZ, 2006).
A figura 1 mostra os principais sistemas gerenciadores de banco de dados
existentes atualmente.
6
FIGURA 1- ALGUNS DOS PRINCIPAIS SGDBS EM USO
2.3
Finalidade dos sistemas de banco de dados
Os sistemas de banco de dados surgiram como opção aos métodos antigos de
gerenciamento de dados em computadores. Nos sistemas antigos, os dados eram
armazenados em arquivos do sistema operacional, que era responsável por criar um
ambiente para acesso, manipulação e controle destes arquivos.
Para cada interação que fosse efetuada entre o sistema e o arquivo era necessário
executar um programa específico do sistema operacional que fornecia aquela função.
Conforme funcionalidades eram adicionadas ao banco de dados (novas regras de
negócio), a criação de novos programas era necessária para lidar com estas requisições
(SILBERSCHATZ, 2006).
O armazenamento de informações em um sistema de arquivos apresenta diversas
desvantagens, dentre as quais se destacam:
•
Redundância e inconsistência de dados: como a manutenção do sistema é
efetuada por diversos programadores, cada um utiliza uma metodologia e,
conseqüentemente, os vários arquivos onde os dados são armazenados possuem
estruturas diferentes. Além disso, a mesma informação pode estar armazenada em mais
de um arquivo, como mostra a figura 2, onde a informação do produto fica armazenada
no arquivo do sistema de produção, no sistema de vendas e no sistema de compras. Essa
redundância de dados pode levar a divergência, visto que não há nenhum mecanismo
que controle se ambos os registros possuem o mesmo valor, além do custo de
armazenamento que esta informação duplicada possui.
7
FIGURA 2 - A MESMA INFORMAÇÃO ARMAZENADA EM DIVERSOS ARQUIVOS
•
Dificuldade de acesso a dados: ambientes de armazenamento de arquivos
não foram criados para executar tarefas de banco de dados, como extração de uma
determinada informação de um determinado arquivo. Para cada necessidade de consulta
ao sistema de dados é necessário que o programador escreva uma aplicação para efetuar
esta busca, o que torna a recuperação de dados uma tarefa difícil.
•
Problemas de integridade: os valores armazenados no banco de dados
devem ser condizentes com a regra de negócio do cliente. Por exemplo, em uma
aplicação que controla as vendas de uma loja, a quantidade vendida de um item e o
saldo deste item não podem assumir valores negativos. Para que esta condição seja
cumprida, é necessário que um código de verificação seja incluído na aplicação. Porém,
quando novas regras de negócios são adicionadas, é difícil mudar os programas para
implementá-las, principalmente se as novas regras envolvem itens que possuem regras
distintas das já existentes (SILBERSCHATZ, 2006).
•
Anomalias no acesso concorrente: para favorecer o desempenho das
aplicações, os sistemas de banco de dados devem oferecer acesso concorrente aos dados
armazenados. Porém, com esta funcionalidade, é possível que a interação das ações
concorrentes levem os dados a um estado de inconsistência. Considere uma aplicação
bancária. Ao checar o saldo, a aplicação verifica que o saldo atual é R$100,00. Quase
simultaneamente, duas operações de cobrança são efetuadas nesta conta, sendo a
8
primeira cobrança no valor de R$80,00 e a segunda de R$50,00. Considerando que a
operação de cobrança consiste em checar o saldo, diminuir o valor cobrado e salvar o
novo saldo da conta, a execução das operações irá deixar o registro com um valor
inconsistente (R$20,00 ou R$50,00 de saldo, dependendo de qual terminar sua execução
por último).
•
Problemas de atomicidade: Os sistemas de computadores estão sujeitos a
falhas, como qualquer outro dispositivo. Considere um programa bancário que efetue a
transferência de R$100,00 de uma conta A para uma conta B. Se ocorrer uma falha
durante este procedimento, é possível que o valor transferido fosse retirado da conta A,
porém não creditado na conta B. Os sistemas de banco de dados devem ser capazes de
oferecer operações atômicas, isto é, deve ocorrer em sua totalidade ou não ocorrer. É
difícil garantir a atomicidade de operações em um sistema de arquivos.
Estas e outras dificuldades impulsionaram o desenvolvimento de sistemas de
banco de dados, para resolver as dificuldades anteriormente citadas e oferecer o
ambiente ideal para armazenamento de dados (SILBERSCHATZ, 2006).
2.4
Modelo de Dados
O modelo de dados de um Banco de dados é a forma de descrever os dados, seus
relacionamentos, sua semântica e restrições de consistência. O modelo de dados
descreve o projeto do banco nas formas física, lógica e de view (SILBERSCHATZ,
2006).
2.4.1 Modelo Relacional
Este modelo utiliza tabelas para representar os dados e os relacionamentos
existentes entre as várias instâncias destas tabelas. Cada tabela possui diversas colunas,
que são os atributos desta entidade que serão armazenados.
O modelo de dados relacional é o modelo de dados mais utilizado, e a grande
maioria dos SGDBs atuais é baseada no modelo relacional (SILBERSCHATZ, 2006).
9
2.4.2 Modelo de entidade / relacionamento
Este modelo é baseado na filosofia de que o banco de dados é baseado em uma
percepção do mundo real, que é formado por vários objetos básicos, as entidades, e os
relacionamentos existentes entre estas entidades (SILBERSCHATZ, 2006).
Cada alteração nos atributos deste objeto no mundo real irá ocasionar em uma
alteração nos dados armazenados no banco de dados, pois o dado armazenado é a
representação, em bits, daquele objeto, e deve sempre possuir os dados mais atualizados
(MACHADO, 2008).
2.4.3 Modelo de dados orientado a objetos
Este modelo pode ser visto como um modelo ER (Entidade / Relacionamento)
mais avançado. Ele adiciona ao modelo ER as funções de encapsulamento, métodos
(funções) e identidade de objeto (SILBERSCHATZ, 2006).
2.5
Bancos de dados Relacionais
Os bancos de dados relacionais utilizam a metodologia de prover um meio de
descrever o dado apenas com sua estrutura natural, isto é, sem impor estruturas
adicionais com propósitos de otimização computacional. Outra vantagem desta
abordagem é a boa fundamentação em consistência de relacionamentos e redundância
de dados (CODD, 1970).
10
2.5.1 Estrutura básica
Um banco de dados relacional é formado por várias tabelas, cada uma com um
nome único atribuído. Considere a tabela Alunos (tabela 1). Ela possui 4 cabeçalhos de
coluna: Matrícula, Nome aluno, Curso e Telefone. Segundo a normatização do modelo
relacional, chamaremos estes cabeçalhos de atributos. Para cada atributo, há um
conjunto de valores que são permitidos de serem armazenados nesta coluna. Este
conjunto é chamado de domínio desse atributo.
Para o atributo Nome Aluno, por exemplo, o domínio do atributo é o conjunto de
todos os alunos que fazem parte da instituição que registra seus alunos nesta tabela, já
para o atributo Matrícula, o domínio do campo é o número de registro deste aluno na
instituição, o atributo Curso possui como domínio os nomes dos cursos que a instituição
ministra e, para o atributo, Telefone o domínio é o conjunto de valores que representa o
telefone da residência dos alunos desta instituição. Qualquer linha desta tabela precisa
consistir em um conjunto de 4 elementos (a1, a2, a3 e a4), onde a1 é a Matrícula (e está
no domínio D1), a2 é o Nome do aluno (e está no domínio D2), a3 é o nome do curso
(domínio d3) e a4 o número do telefone (que está no domínio D4) da entidade
representada.
Portanto, todo registro de alunos conterá apenas subconjuntos dos
conjuntos possíveis para cada atributo da tabela. Portanto, conta é um subconjunto de:
D1 x D2 x D3 x D4
Em geral, uma tabela de N atributos é um subconjunto de:
D1 x D2 x ... x Dn-1 x Dn
Matrícula
Nome do Aluno
Curso
Telefone
312412
João da Silva
Letras
3531-1345
312413
Maria de Sousa
Física
3412-5312
312414
Rita de Cássio
Matemática
1324-1224
312415
José dos Santos
Física
6124-8972
312416
Paulo Nascimento
Computação
3551-6377
TABELA 1 - TABELA RELACIONAL ALUNOS
A disposição das linhas em uma tabela é irrelevante, pois uma tabela é um
conjunto de registros. Portanto, quer os registros estejam listados em ordem, como na
tabela 1, ou estejam desordenadas, como na tabela 2, ambas as tabelas são idênticas,
visto que possuem os mesmos registros.
11
Matrícula
Nome do Aluno
Curso
Telefone
312413
Maria de Sousa
Física
3412-5312
312414
Rita de Cássio
Matemática
1324-1224
312416
Paulo Nascimento
Computação
3551-6377
312415
José dos Santos
Física
6124-8972
312412
João da Silva
Letras
3531-1345
TABELA 2 - TABELA ALUNO COM AS LINHAS DESORDENADAS
É exigido que, para todos os registros da tabela, os domínios dos atributos sejam
atômicos. Para que um domínio seja considerado atômico ele deve ser formado apenas
por elementos indivisíveis. Por exemplo, o conjunto dos números inteiros é um domínio
atômico, porém o conjunto de todos os conjuntos de números inteiros não é atômico,
pois o subconjunto é composto por diversos números inteiros. Esta exigência é
necessária pois, apesar de Nome do Aluno e Curso serem ambos armazenados como
conjunto de caracteres no esquema físico (armazenamento em arquivo), no nível lógico
(onde são representadas as tabelas) a lógica do negócio impõe que o Nome do Aluno e o
nome do curso sejam de conjuntos distintos (SILBERSCHATZ, 2006).
2.5.2 Chaves
É preciso ter um modo de identificar como as linhas dentro de uma tabela são
identificadas e distinguidas umas das outras. Essa identificação é feita utilizando seus
atributos, ou seja, os valores de um registro precisam ser criados de modo que possam
identificar unicamente aquela linha da tabela. Em outras palavras, nenhuma linha em
uma tabela pode ter todos os valores para todos seus atributos.
O termo chave primária é utilizado para identificar o atributo que foi escolhido
pelo projetista do banco de dados para identificar unicamente os registros que são
armazenados em uma determinada tabela. Uma chave é propriedade de toda a tabela, e
não de um registro em específico. Nenhum registro pode ter o mesmo valor no atributo
chave primária de uma determinada tabela do banco de dados.
Os atributos chaves devem ser selecionados com cuidado. O nome de uma
pessoa nunca deve ser utilizado como atributo chave, pois podem existir mais de uma
pessoa que possui aquele nome. Os identificadores únicos devem nunca ou raramente
12
mudar, o que torna o endereço de uma pessoa uma má escolha de atributo chave,
diferentemente dos identificadores normalmente gerados pelas empresas para identificar
os registros, que dificilmente serão alterados.
Um esquema de tabela t1 pode ter entre seus atributos a chave primária de outra
tabela, digamos t2. Este atributo é chamado de chave estrangeira de t1, referenciando t2.
Por exemplo, no esquema da Figura 3, o atributo nome_agência na tabela conta é uma
chave estrangeira desta tabela, que referencia a outra tabela do esquema, a agência. Em
qualquer conjunto de registros do banco de dados, para cada linha existente na tabela
conta, é necessário que nome_agencia possua uma referência a um registro válido da
tabela agência (SILBERSCHATZ, 2006).
Na figura 3, é representado um esquema de uma instituição bancária. As chaves
primárias de cada entidade são apresentadas antes dos outros atributos, na caixa cinza.
FIGURA 3 - ESQUEMA DO BANCO DE DADOS
DE UMA INSTITUIÇÃO BANCÁRIA (SILBERSCHATZ,2006)
2.5.3 Normalização
Um método que deve ser considerado ao planejar um banco de dados relacional
é um processo conhecido como normalização. Ele tem por objetivo gerar um esquema
de tabelas que permita armazenar informações sem redundância desnecessária, ao
mesmo tempo permitindo recuperar informações facilmente.
Para entender a necessidade da utilização deste processo durante a criação do
esquema do banco de dados, discutiremos o que pode acontecer de errado no projeto. A
13
propriedade indesejável que um projeto de banco de dados pode ter é a repetição
desnecessária de informações.
Considere que o Aluno “João da Silva”, da figura 4, se matricule para um novo
curso na instituição de ensino e uma nova matrícula seja gerada para registro deste novo
aluno no curso. É desejável que não aja repetição de informações no projeto do banco
de dados, pois isto aumenta o custo de armazenamento e dificulta a tarefa de atualização
dos dados. Suponha que o número do telefone deste aluno seja alterado. Esta alteração
deve refletir nas duas linhas, sendo mais custosa nesta tabela do que em uma tabela
normalizada.
Aplicando a normatização a este projeto, o atributo curso fica independente do
registro do aluno, evitando a repetição de informações desnecessárias, conforme mostra
a figura 4. Nota-se que os dados representados são os mesmos (com adição do registro
do novo curso do aluno 312412), porem sem a duplicação desnecessária de dados
(SILBERSCHATZ, 2006).
FIGURA 4-UM ESQUEMA NORMALIZADO
14
2.5.4 ACID
Uma parte importante dos bancos de dados relacionais é a propriedade ACID,
que faz parte de seu núcleo. ACID é um acrônimo derivado da primeira letra das
seguintes propriedades: Atomicidade, Consistência, Isolamento e Durabilidade.
Atomicidade é a capacidade do banco de dados permitir que as operações sejam
efetuadas com sucesso no banco de dados, ou nenhuma delas será efetuadas.
Consistência é a propriedade que garante que as transações isoladas (sem
qualquer outra transação executando simultaneamente) preserva a consistência do banco
de dados.
Isolamento é a propriedade que garante que caso duas transações sejam
executadas simultaneamente, o sistema deve garantir que cada transação seja executada
sem estar ciente das outras transações existentes no sistema.
A durabilidade garante que após uma transação ser completada com sucesso, as
mudanças que ela efetuou no banco de dados persistem, mesmo em caso de falha no
sistema (SILBERSCHATZ, 2006).
2.6
Banco de Dados Orientados a objetos
Bancos de dados relacionais se provaram bastante adequados para aplicações
empresariais, principalmente no ramo bancário. Entretanto, ele não é adequado para
todos os tipos de aplicações. Novas aplicações, que envolvem modelagem complexa de
dados (que não se adaptam bem a modelagem em tabelas), agora requerem serviços que
normalmente são associados com sistemas de bancos de dados: persistência, transações
atômicas, controle de acesso, estabilidade de dados, etc.
Para exemplificar, considere uma aplicação utilizada por uma empresa
aeronáutica. A aplicação auxilia tanto na especificação quanto na parte de design das
aeronaves. Objetos físicos não se adaptam bem a modelos tabulares, ou modelos
relacionais. Em particular, uma aeronave requer muitas partes duplicadas, e cada uma
necessitaria de um identificador único para ser armazenado em um modelo relacional.
Além disso, as relações representando partes diferentes da aeronave que são
15
praticamente similares iriam requerer esquemas independentes e separados. Finalmente,
o design completo requer centenas de milhares de partes e acesso direto a cada parte
deste design se torna impraticável.
Bancos de dados orientados à objetos são uma tentativa de resolver estas
dificuldades (assim como outras), e ainda manter as vantagens dos sistemas de banco de
dados. Em uma entidade composta de várias partes é possível ter acesso direto a um de
seus componentes, ao invés de associar explicitamente um identificador único a cada
uma de suas partes e criar uma tabela extra de relacionamento. Além disso,
programadores podem manipular entidades do banco de dados em qualquer nível de
abstração, através da extensão dos tipos de dados conhecidos pelo banco. Isso é
importante pois significa que o programador não necessita transformar o tipo de dado da
aplicação para facilitar sua persistência no banco (HOROWITZ, 1991).
2.6.1 Tipos de dados complexos
Considere, por exemplo, uma aplicação para biblioteca, onde as seguintes
informações são armazenadas para cada um dos livros:
•
Titulo
•
Lista de Autores
•
Editora
•
Conjunto de palavras-chaves
Considerando os atributos acima, alguns possuirão domínios não atômicos.
•
Autores: Um livro pode ter mais de um autor, que seria representado por
um array (uma lista).
•
Conjunto de palavras-chaves: Quando um conjunto de palavras chaves é
armazenado para um livro, é esperado que seja possível recuperar todos os livros que
compõem determinado tema (palavra-chave).
Título
Autor
Editora
Conjunto Palavras Chaves
Compiladores
[Smith, Jones]
Ática
[análise, programação]
Redes
[Jones, Frick]
Globo
[internet, web]
TABELA 3 - TABELA DE LIVROS NÃO NORMALIZADA
16
A tabela 3 representa a tabela com os dados dos livros desta biblioteca. Para
simplificar, consideraremos que o nome do livro é único e capaz de identificar cada
registro da tabela, sendo a chave primária da mesma.
FIGURA 5- TABELAS QUE REPRESENTAM A
TABELA 3DE FORMA NORMALIZADA
A figura 5 mostra o modelo do banco de dados normalizado. Embora ele possa
ser representado sem a utilização de tabelas alinhadas, o uso dessas relações leva a um
modelo mais fácil de entender. O usuário ou o programador de um sistema de
recuperação de informações pensam no livro como sendo um objeto que possui
conjunto de autores, como o modelo da tabela 3, não como o modelo normalizado da
figura 5. O projeto normalizado exige que as consultas usem junções de várias relações,
enquanto o projeto não normalizado torna muitos tipos de consultas mais fáceis
(SILBERSCHATZ, 2006).
17
2.7
Banco de dados NoSQL
O termo NoSQL foi utilizado pela primeira vez no ano de 1998, por Carlo
Strozzi, para identificar bancos de dados de código aberto que não possuíam interface
SQL (linguagem universal de manipulação de dados, utilizada pelos bancos de dados
relacionais). Este novo conceito é totalmente distinto do modelo relacional, e seria mais
apropriadamente chamado de NoRelacional, porém o nome NoSQL, adotado, possui um
efeito melhor (NVRSDQEF, 2010).
Bancos de dados não relacionais, incluindo hierárquicos, gráficos e orientados a
objetos estão em uso desde os anos 60. Entretanto, novos tipos de bancos de dados não
relacionais estão sendo desenvolvidos, como os bancos colunares. Diferentes bancos de
dados NoSQL tem diferentes abordagens, porém o que todos eles possuem em comum é
que não são relacionais. A principal vantagem de um tipo de dados não relacional é que,
diferente da abordagem tradicional, eles lidam bem com dados desestruturados, tais
como emails, dados multimídia e dados provenientes de mídias sociais (Leavitt, 2010).
Além disso, a necessidade de melhorar o desempenho dos bancos de dados, e
diminuir os custos de armazenamento e processamento de informações impulsionaram o
desenvolvimento desta nova metodologia de banco de dados. O NoSQL lida bem com
distribuição horizontal, ou seja, consegue ser distribuído entre várias estações para
armazenamento de maiores quantidades de dados, e estes novos servidores não precisam
ser de alto desempenho (NVRSDQEF, 2010).
Esta nova abordagem é principalmente utilizada por empresas da web 2.0, com
quantidades gigantescas de dados e infra-estrutura, como a Google e a Amazon. Eles
desenvolveram Big Table e Dynamo, ambos bancos de dados NoSQL (Leavitt, 2010).
De fato, um dos grandes utilizadores desta metodologia é a Google, que utiliza
computadores de pequeno e médio porte para armazenagem e distribuição de dados,
com utilização mais eficiente dos recursos e mais econômica.
O armazenamento de dados destes bancos evoluiu conforme a necessidade da
aplicação, com diferentes modelos de dados e capacidades. Os elementos básicos
podem ser considerados “objetos”, “documentos” ou “registros”. Apesar dessas
variações, podemos considerar como essência deste sistema:
•
A não existência de um esquema pré definido. Os dados podem possuir
qualquer número de atributo de qualquer tipo. A falta de um esquema global facilita o
18
desenvolvimento de um banco de alta disponibilidade, pois não é necessário desativar o
banco para efetuar alterações no esquema.
•
Estes sistemas possuem uma API (Interface de Programação de
Aplicações) de buscas simples, o que, diferente dos bancos relacionais, encoraja buscas
simples, sem necessidade de grandes uniões de tabelas.
•
A escalabilidade proporcionada pelos nós da rede. Diferente dos bancos
de dados relacionais, que utilizam as propriedades ACID, bancos NoSQL promovem
uma “consistência eventual”, ou garante a consistência dentro de um único objeto (ou
documento ou registro).
•
Esta metodologia também permite alta disponibilidade, que é necessária
para fazer com a que a escalabilidade entre diversas máquinas seja utilizável. Isto é
alcançado através da identificação de falhas e de recuperação utilizando cópias de nós
espelhos.
A escalabilidade destes bancos tem seu preço: a aplicação deve poder operar
com menores níveis de consistência garantida, sem transações que afetem vários
registros. Estes bancos de dados são populares entre aplicações da web 2.0 pois estes
programas normalmente operam com baixa (se houver) necessidade de consistência,
sendo possível o suporte a decisão com dados mais antigos (Cattel, 2010).
Os bancos de dados NoSQL são subdivididos pelo seu núcleo, ou seja, como ele
lida com as informações que armazena. Os principais tipos de núcleo são: Key/Value
Store, Document Store e Wide Columns Store (NVRSDQEF, 2010).
2.7.1 Armazenamento Key/Value
Este modelo de armazenamento de dados é considerado o mais simples, o
conceito é de uma chave e um valor que é armazenado por esta chave. Devido a sua
simplicidade, é o modelo que possuir maior escalabilidade (NVRSDQEF, 2010).
Esta abordagem pode ser considerada um HashTable gigante (um mapa ou
dicionário, dependendo da linguagem de programação). As buscas podem ser efetuadas
apenas pelo valor da chave (WCS, 2010).
19
O banco de dados SimpleDB, da Amazon, é uma implementação desta
metodologia. Ele prove funções de indexação de informações e buscas na web 2.0. Ele
possui uma interface simples para persistência de dados e acesso (Leavitt, 2010).
FIGURA 6- TABELA KEY/VALUE (TERMEHCHY,2010)
Na figura 6 podemos observar um exemplo de tabela Key/Value. Este modelo de
banco de dados é bastante utilizado para aplicações para grandes aplicações de Web
Service. As chaves (Keys) são únicas, e cada uma aponta para um conjunto de valores
(Termehchy, 2010).
2.7.2 Armazenamento de documentos
Este modelo armazena e organiza os dados como uma coleção de documentos,
ao invés de tabelas estruturadas, com campos e valores predefinidos para cada registro.
Com este tipo de banco de dados, o programador é livre para adicionar quantos campos
forem necessários de qualquer comprimento ao documento (WCS, 2010).
As buscas em modelo de armazenamento de documentos podem ser efetuadas
pelo valor de suas chaves ou por qualquer um dos valores contidos dentro de seu
documento, como buscas por XPath ou métodos “query by example” (WCS, 2010).
O banco de dados CouchDB, da Apache Software Foundation, é um exemplo
desta metodologia, escrito em Erlang e open source, que pode ser acessado por qualquer
browser (Leavitt, 2010).
20
FIGURA 7- UM DOCUMENTO (SIEERA,2004)
A figura 7 demonstra uma rede de metrô e um documento utilizado para buscas
de rotas nesta rede. Nota-se que cada atributo possui a tag inicial e final. Todo o
documento fica entre a tag inicial <Subway> e a tag final </Subway> (Sieera, 2004)
2.7.3 Armazenamento de grandes colunas
Este tipo de armazenamento é baseado no documento “BigTable: A distributed
Storage System for Structured data”(Chang, 2006). Vários projetos, além do próprio
BigTable, implementam este conceito. Estes bancos de dados suportam um grande
número de colunas por linhas, permitindo buscas pelos valores das colunas, colunas que
contém lista de valores e/ou sub-colunas e linhas com variáveis de coluna (WCS, 2010).
Esta metodologia tem como principal banco o “Big Table”, da Google. Várias
aplicações desta companhia utilizam seu banco de dados NoSQL para armazenar seus
dados. Dentre estas aplicações, destaca-se o Google Analytics, um programa que tem
21
como finalidade auxiliar webmasters a analisar o acesso a seu website. Através desta
ferramenta, o webmaster consegue inferir diversos dados a respeito dos visitantes do
website. Duas das principais tabelas utilizadas por esta aplicação utilizam banco de
dados NoSQL: A tabela de ‘clicks brutos (raw click table)’ e a tabela de sumário, que
juntas possuem aproximadamente 220TB de informações são armazenadas com este
modelo de dados criado pelo Google (Chang, 2006).
2.7.4 Bancos de dados Orientados a coluna
Em uma arquitetura orientada a colunas, o valor de cada coluna (atributo) é
armazenado em seqüência, aumentando a performance da leitura de uma única coluna.
Com este modelo de armazenamento, o banco de dados carrega em memória apenas os
valores das colunas que serão utilizados, evitando preencher a memória com dados que
não serão utilizados.
Há duas formas que os bancos de dados colunares podem utilizar CPU para
diminuir a utilização do disco rígido. Primeiro, eles podem codificar os dados para uma
forma mais compacta (transformar os dados em bytes, ao invés de armazena-los em sua
forma nativa). Em segundo lugar,em um armazenamento colunar, é mais simples para
comprimir N valores, cada um de um tamanho K bits, em um espaço N * K bits
(Stonebraker, 2005).
22
3
Business Intelligence
Este capítulo apresentará a definição de Business Intelligence, o objetivo dessa
aplicação e irá fazer uma breve introdução à suíte de BI Pentaho.
Este capítulo está organizado como segue: A seção 3.1 introduz o conceito de
Business Intelligence, a seção 3.2 define uma aplicação de BI e a seção 3.3 apresenta o
aplicativo Pentaho.
3.1
Business Intelligence
Na ultima década a área de Tecnologia da Informação (TI) ganhou grande
importância nas empresas, a ponto de alguns especialistas estimarem que
aproximadamente metade do capital aplicado pelas empresas tem como destino o
departamento de TI. O crescimento de grandes empresas deste setor, tal como SAP,
Oracle, Microsoft, IBM, Cisco e Dell, entre outras, comprova o grande investimento das
companhias neste setor.
Grande parte deste investimento foi destinado a sistemas que permitam o
controle das operações diárias, e a geração de relatórios mais freqüentes e volumosos.
Estes sistemas tornam estas empresas ricas em dados, porém pobres em informação. Em
outras palavras, apesar de possuírem uma grande base de dados, falta a estas
companhias ferramentas para tornar estes dados em informações úteis, necessárias para
melhorar a produção e aumentar os lucros da companhia.
Business Intelligence (BI) é a resposta a esta necessidade. Quando bem
implementado, aplicações de BI tem um enorme potencial para aumentar a renda e
melhorar o controle da companhia sobre si mesma, através das informações
armazenadas (WILLIAMS, 2007).
23
3.2
Definição
Business Intelligence pode ser definido como um conjunto de modelos
matemáticos e métodos de análise que através da análise sistemática de dados, resulta
em informações e conhecimento útil na tomada de decisão (VERCELLIS, 2009).
BI combina produtos, tecnologias e métodos para organizar informações chaves
que os gerentes necessitam para melhorar os lucros e o desempenho. Mais amplamente,
BI é a inteligência e análise de negócios dentro do contexto dos processos chaves que
levam a decisões e ações que resultam em um melhor desempenho para a empresa. Isto
envolve informações de mercado e análise que é:
•
Utilizada em um contexto dos processos empresariais chaves;
•
Suporta decisão e comportamento;
•
Levam a melhores desempenhos dos negócios.
Para empresas, o foco primário é o aumento de receitas e/ou reduzir custos,
através da melhora da performance e aumento do lucro. Para o setor público, o foco
primário é servir aos cidadãos, lidar com suas restrições e usar os recursos disponíveis
sabiamente para servir aos objetivos do governo (WILLIAMS, 2007).
As metodologias de BI são interdisciplinares e amplas, abrangendo diversos
domínios de aplicações. Elas se preocupam com a representação e organização do
processo de tomada de decisão; com a coleta e armazenamento de dados com o
propósito de facilitar o processo de decisão; com modelos matemáticos para otimização
e mineração de dados, além de auxiliar operações de busca e de estatísticas; e
finalmente, estão ligadas a diversos domínios de aplicação, tal como marketing,
logística, finanças, serviços, e administração pública (VERCELLIS, 2009).
Estas aplicações tendem a promover uma abordagem racional e científica para o
gerenciamento de companhias e organizações complexas. Mesmo o uso de planilhas
eletrônicas, tais como o Microsoft Excel, para avaliação dos efeitos resultantes na
variação da taxa de desconto, apesar de sua simplicidade, requer na parte de toma de
decisão uma representação básica dos fluxos financeiros (VERCELLIS, 2009).
Uma aplicação de BI oferece informações de tomada de decisão e conhecimento
derivado de processamento de dados, através da aplicação de modelos matemáticos e
algoritmos. Em alguns casos, estas aplicações podem consistir apenas de cálculos totais
24
e porcentagens, enquanto análises mais desenvolvidas fazem o uso de modelos
avançados de otimização, aprendizagem indutiva e previsão (VERCELLIS, 2009).
Os usuários de uma aplicação de BI observam o desenvolver da companhia. Eles
contabilizam, através da ferramenta, o número de vendas por semana, comparam estas
vendas com as das semanas anteriores, observam as tendências dos consumidores e suas
reclamações. Usuários de um DW (Data Warehouse) praticamente não lidam com dados
isolados (uma única linha de registro do banco). Na verdade, seus questionamentos
normalmente fazem com que centenas de milhares de linhas de uma tabela sejam
buscadas e compactadas em um conjunto de respostas. Além disso, os questionamentos
que são feitos à ferramenta estão mudando constantemente (KIMBALL, 2002).
3.2.1 Objetivos de uma aplicação de BI
Os objetivos que devem ser alcançados com a implantação de uma aplicação de
BI na empresa são:
•
Tornar a informação da organização de fácil acesso. O conteúdo da
aplicação de BI deve ser de fácil entendimento, de modo que o usuário consiga
compreender os dados que constam na ferramenta, não apenas o desenvolvedor
(KIMBALL, 2002).
•
A informação deve ser apresentada consistentemente. As informações
disponibilizadas na aplicação devem vir de várias fontes dentro da mesma organização,
ser compactada e disponibilizada aos usuários apenas quando for de utilidade para o
mesmo (KIMBALL, 2002).
•
A aplicação deve ser adaptativa e preparada para mudanças. As
necessidades do usuário, do negócio, da companhia estão sujeitas a alteração com o
passar do tempo. A aplicação deve ser projetada de modo a estar preparada para estas
mudanças necessárias para adaptar a aplicação à necessidade da empresa (KIMBALL,
2002)
•
As informações devem ser armazenadas em um ambiente seguro. A
aplicação deve controlar o acesso a informações confidencias da companhia, e permitir
25
que apenas usuários devidamente autorizados possuam acesso aos dados crucias da
empresa (KIMBALL, 2002)
Como ilustrado anteriormente, aplicações de auxílio a decisão precisam além de
auxiliar na parte estratégica do negócio, gerar informações em um tempo hábil, além de
garantir que estas informações apenas estejam disponíveis à aqueles que necessitem
utilizá-la.
Operacional
Analítico
Propósito
Executar um processo
Avaliar um processo
Estilo iteração
Insert, update, delete, query
Query
Escopo iteração
Transação individual
Agregação
Padrão query
Previsível e estável
Imprevisível
Foco temporal
Atual
Atual e histórico
Otimização
Update concorrente
Query
Projeto
ER na 3FN
Star Schema ou Cubo
Conhecido como
OLTP
Data Warehouse
TABELA 4 - DIFERENÇA ENTRE SISTEMAS OPERACIONAIS
E ANALÍTICOS (ADAMSON, 2010)
A tabela 4 mostra que, enquanto sistemas cujo objetivo é o suporte a operação se
focam na execução de um processo, baseando-se principalmente em transações
individuais, sistemas analíticos tem como propósito avaliar um processo, e esta
avaliação é feita principalmente utilizando-se a agregação. Esta mudança de paradigma
abre oportunidades para diferentes modelos de dados serem utilizados pelo sistema de
BI (Adamson, 2010).
3.3
Pentaho
Pentaho é uma poderosa suite de BI que oferece diversas ferramentas: análise de
dados, geração de relatórios, mineração de dados entre outras. Esta aplicação de BI é
open source, ou seja, seu uso é gratuito e os desenvolvedores são livres para estudar e
modificar seu código fonte (Bouman, 2009).
26
FIGURA 8- PENTAHO
FIGURA 9- PENTAHO
Conforme pode ser observado nas figuras 8 e 9, a utilização de uma aplicação de
BI fornece, por meio de ferramentas gráficas, meios da equipe estratégica da empresa
compreender os dados armazenados e tomar decisões importantes a respeito do
planejamento futuro.
27
4
Ferramentas Utilizadas
Este capítulo tem como objetivo apresentar as ferramentas que serão utilizadas
durante a execução dos testes comparativos.
Este capítulo está organizado como segue: a seção 4.1 apresenta o banco de
dados relacional Mysql, a seção 4.2 apresenta o banco de dados colunar LucidDB, a
seção 4.3 apresenta o software para medição de desempenho JMeter, a seção 4.4
apresenta o software Medidor de desempenho do Windows e a seção 4.5 apresenta o
software de virtualização Oracle Virtual Box.
4.1
Mysql
A versão 5.5 do Mysql introduziu uma arquitetura com melhorias de
desempenho e de escalabilidade. Estas são algumas das melhorias que foram
disponibilizadas a partir desta versão:
•
Melhoria de desempenho em ambientes Windows
•
Melhoria do controle de concorrência de threads
•
Controle da taxa de I/O (Escrita / Leitura) global das threads
•
Controle do uso de alocação de memória do sistema operacional
Grande parte das melhorias que ocorreram na arquitetura do Mysql tem como
objetivo uma performance mais transparente e ganhos de escalabilidade em plataformas
heterogenias,
especificamente
em
hardwares
multi-CPU/core,
arquiteturas
de
processamento paralelo (WNM, 2011).
O SGDB relacional Mysql, que é de propriedade de Oracle, foi escolhido por ser
um dos bancos de dados mais utilizados no mundo, devido a sua alta performance,
confiabilidade e facilidade de uso, além de este banco de dados ser compatível com
mais de 20 plataformas de software, incluindo Linux, Windows, Mac Os, Solaris, entre
outros (Mysql, 2011).
28
4.2
LucidDB
LucidDB é, até o presente momento, o primeiro e único banco de dados de
código aberto construído especificamente para ser utilizado por aplicações de Business
Intelligence e Data Warehousing. Seus componentes foram construídos com os
requerimento de alta performance, flexibilidade, e um sofisticado processo de buscas
(LucidDB, 2011).
4.3
Apache JMeter
Apache JMeter é uma ferramenta open source disponibilizada pela Apache
Foundation, e seu objetivo é efetuar testes de comportamento e performance em
aplicações. Ele pode ser utilizado para testes em recursos dinâmicos e estáticos
(arquivos, servlets, objetos Java, Bancos de dados, etc) (JMeter, 2011).
Este aplicativo será utilizado pois é open source e ser um dos softwares mais
utilizados para análise de aplicações.
4.4
Monitor de Desempenho do Windows
O Monitor de Desempenho do Windows é um snap-in do Console de
Gerenciamento Microsoft (MMC) que fornece ferramentas para analisar o desempenho
do sistema. A partir de seu console, pode-se monitorar o desempenho de aplicativo e
hardware em tempo real, personalizar que dados deseja coletar nos logs, definir limites
para alertas e ações automáticas, gerar relatórios e exibir os dados do desempenho
passado de várias maneiras.
O Monitor de Desempenho do Windows combina varias funcionalidades, tais
como incluir Logs e Alertas de Desempenho, Supervisor de Desempenho de Servidor e
Monitor de Sistema. Ele fornece uma interface gráfica para a personalização dos
Conjuntos de Coletores de Dados e Sessões de Rastreamento de Eventos (Microsoft,
2011).
29
Este software será utilizado visto que é nativo do Windows, e o mesmo possuir
todas as funcionalidades que serão necessárias para análise das aplicações durante o
teste.
4.5
Oracle Virtual Box
VirtualBox é um produto de virtualização que pode ser utilizado para fins
corporativos ou pessoais. Alem de ser uma ferramenta com diversas funcionalidades e
um produto de alta performance, é atualmente a única solução profissional que é
disponibilizada gratuitamente sobre a licença GPL (General Public License)
(VirtualBox, 2011).
Este software de virtualização foi escolhido pois o mesmo é gratuito, e possui
uma interface simples e prática, principalmente para configuração do ambiente virtual.
30
5
Proposta de solução
Este capítulo tem como objetivo definir quais critérios serão considerados na
comparação entre os bancos de dados relacionais e NoSQL, e explicá-los.
Este capítulo está organizado como segue: A seção 5.1 define os Sistemas
Gerenciadores de Banco de dados utilizados para estudo, a seção 5.2 define a aplicação
analisada, a seção 5.3 apresenta o ambiente de teste, a seção 5.4 define os testes que
serão efetuados, a seção 5.5 apresenta os critérios que serão analisados em cada teste, e
a seção 5.6 Definição dos softwares utilizados para execução e coleta de dados durante
os testes.
5.1
Sistemas Gerenciadores de Banco de dados utilizados para estudo
Para realização do estudo comparativo entre banco de dados relacionais e
NoSQL na utilização por aplicações de Business Intelligence, foram selecionados dois
SGDB’s: os banco de dados relacional Mysql e o banco colunar LucidDB.
Será utilizada a última versão estável de cada um dos bancos de dados, a saber:
Mysql versão 5.5.9 e LucidDB versão 0.9.3.
5.2
Definição da aplicação analisada
Será utilizada a aplicação WCM (World Class Movies), uma aplicação de
licença GPL para execução dos testes comparativos entre os bancos de dados.
A aplicação WCM é uma aplicação fictícia criada pela equipe do Pentaho para
demonstração do sistema. Por ter uma grande base de dados e que contempla dados de
todo o processo de venda de um produto, esta aplicação será utilizada para efetuar o
teste comparativo entre os bancos de dados.
A WCM é uma empresa de locação e venda de DVDs, cujo mercado é formado
pelas mais diversas classes sociais e faixa etárias. O sistema de locação / venda é
31
inovador, pois a transação é considerada uma locação caso o cliente devolva o filme
após um período de tempo determinado, porém se ultrapassar este período é considerada
como uma venda.
A empresa iniciou suas atividades em Abril de 2000, e os dados de transações
contemplam dados de todos os portais que fazem parte da aplicação. Além dos dados de
vendas, a WCM também possui dados básicos sobre os filmes, como gênero, dados dos
atores e diretores dos filmes (Bouman, 2009).
5.2.1 Definição do modelo de dados
Será utilizado o modelo de dados do Data Warehouse da própria WCM para
execução dos testes comparativos. A Figura 10 mostra o diagrama entidade –
relacionamento das tabelas utilizadas. Os atributos das tabelas foram omitidos, visto que
algumas tabelas possuem mais de 100 atributos. No Apêndice 1 há uma explicação
sobre as tabelas que compõem este modelo de dados.
FIGURA 10 - MODELO DIMENSIONAL DO DATA WAREHOUSE
32
5.3
Definição do ambiente de teste
Os testes serão efetuados em um Notebook DELL, com as seguintes
configurações:
•
3Gb de Memória RAM
•
Processador Pentium Dual Core T4200 – 2.00GHz
•
120GB HD
•
Sistema operacional Windows 7 Professional
Para garantir condições idênticas de testes para ambos os bancos de dados, a
execução dos testes será efetuada em máquinas virtuais, e cada máquina virtual terá a
seguinte configuração:
•
Sistema operacional Windows XP Service Pack 2
•
10Gb de HD.
•
1.5Gb de memória RAM.
Em cada máquina virtual serão instalados apenas os softwares básicos
necessários para execução dos testes e funcionamento do banco de dados sendo
analisado. Será executado o script de inserção de dados da empresa WCM em ambos os
bancos de dados. Não haverá nenhuma otimização de dados nas tabelas, ou seja, as
tabelas serão criadas apenas com seus atributos comuns, sem adição de nenhum índice.
As imagens podem ser disponibilizadas para futuros trabalhos baseados no presente
estudo.
5.4
Definição dos testes
Serão efetuados 4 queries (buscas) na base de dados, e cada uma destas buscas
será repetida 200 vezes, e será utilizado para comparação a média dos resultados. As
buscas que serão efetuadas irão simular consultas que podem ser efetuadas por um
usuário comum de um sistema de Business Intelligence.
33
Os testes serão efetuados seqüencialmente, ou seja, a segunda busca só iniciará
após a busca anterior ter sido executada 200 vezes, e assim sucessivamente até o final
do teste.
Durante a execução de cada querie serão coletados os dados necessários para
posterior análise dos critérios definidos na seção 5.4.
Serão efetuadas as seguintes buscas no banco de dados:
•
Qual gênero de filme gerou mais receitas no ano de 2008?
•
Como o lucro está evoluindo com o tempo?
•
Qual horário do dia os consumidores fazem mais locações?
•
Quão efetivas foram as promoções no ano de 2008?
No apêndice 2 pode ser encontrado o script utilizado para execução das buscas
acima em ambas as bases de dados.
5.5
Definição dos critérios analisados
Durante a busca, serão coletados dados para análise e comparação dos bancos de
dados de acordo com os critérios que seguem.
5.5.1 Desempenho
Para comparação do desempenho, será considerado o tempo mínimo, máximo e
a média do tempo necessário para as aplicações obterem os dados solicitados. Será
considerado o banco de dados com melhor performance aquele que possuir o menor
tempo médio de resposta.
34
5.5.2
Utilização de CPU
Para comparação da utilização de CPU, será considerado a % de utilização do
processador durante o processamento da requisição. Será considerado o banco de dados
com o melhor uso de CPU aquele que utilizar a menor % de ciclos da CPU para
processar a querie.
5.5.3 Uso de memória
Para comparação do uso de memória, será considerada a quantidade de memória,
em MB, livre durante o processamento da requisição. Será considerado o banco de
dados com o melhor uso de memória aquele que a utilizar em menor quantidade durante
o processamento da requisição.
5.5.4 Alocação das tabelas em disco
Para comparação da alocação em disco, serão executadas queries nos metadados
(dados sobre dados dos bancos de dados), a fim de se determinar o espaço em disco
utilizado para armazenar os dados. Será considerado o banco de dados com melhor
alocação em disco aquele que utilizar a menor quantidade para armazenamento das
tabelas.
5.5.5 Desempenho utilizando menor quantidade memória RAM
Serão realizados dois testes adicionais para verificação do comportamento dos
bancos de dados com diferentes quantidades de memória RAM disponível. No primeiro
teste, a quantidade de memória total será de 1000mb, enquanto que no segundo a
35
quantidade total será de 500mb. Neste teste serão efetuadas apenas 100 buscas da
primeira querie (“Gênero com maior receita em 2008”), para verificar se houve alguma
diferença no desempenho e na quantidade de memória livre (em % do total) em relação
ao teste original, onde as máquinas possuíam 1500mb de memória total.
5.6
Definição dos softwares utilizados
Durante a execução dos testes, serão utilizados os softwares que seguem para
coleta de dados para posterior análise comparativa entre os SGDBs escolhidos.
5.6.1 Apache JMeter
Será programado no JMeter para que cada uma das queries sejam executadas
200 vezes simultaneamente via JDBC. O JMeter irá salvar os dados de desempenho de
cada querie em um arquivo de log, para análise posterior.
5.6.2 Monitor de desempenho do Windows
O Aplicativo monitor de desempenho do Windows será utilizado para salvar os
dados referentes à utilização de CPU e memória durante a execução dos testes.
O monitor de desempenho será programado para obter a % de utilização da CPU
e a quantidade (em megabytes) de memória livre no sistema a cada 15 segundos. Os
dados obtidos serão armazenados em um arquivo de log para posterior análise.
36
5.6.3 Oracle Virtual Box
Será utilizado o Aplicativo Oracle VirtualBox para criação dos ambientes
virtuais onde serão realizados os testes definidos anteriormente.
37
6
Resultados Encontrados
Este capítulo tem como objetivo apresentar os resultados encontrados na análise
comparativa dos sistemas de banco de dados relacional e NoSQL na utilização por uma
aplicação de Business Inteligence.
Este capítulo está organizado como segue: A seção 6.1 apresenta os resultados
encontrados durante a execução dos testes.
6.1
Resultados Encontrados
Após a execução das queries em ambas as bases de dados, foram encontrados os
seguintes resultados.
6.1.1 Análise comparativa do desempenho
Os itens que seguem mostram os resultados encontrados durante a análise
comparativa do o desempenho das aplicações durante a execução dos testes. Neste
critério foi analisado o tempo mínimo necessário para o banco de dados fornecer o
resultado esperado, o tempo máximo necessário para o banco de dados retornar os dados
e o tempo médio necessário para os banco de dados enviarem os dados solicitados.
Todos os resultados apresentados estão em Milissegundos.
A diferença entre os valores apresentados foi calculada utilizando-se a seguinte
fórmula: (Resultado com maior tempo / resultado com menor tempo) -1.
38
6.1.1.1 “Gênero com maior receita em 2008”
Na análise comparativa de desempenho da primeira querie, foram obtidos os
resultados que podem ser observados na tabela 5.
Tempo
Tempo
Tempo
Mínimo
Máximo
Médio
Mysql
23569
33033
25312
LucidDB
3851
4669
4014
Diferença
512,02%
607,50%
530,67%
TABELA 5 - ANÁLISE COMPARATIVA DO DESEMPENHO NA PRIMEIRA QUERIE
Conforme pode ser observado na tabela 5 e na figura 11, o banco de dados
LucidDB possui um desempenho superior que seu adversário, o banco de dados Mysql,
em todas as queries efetuadas, em todos os quesitos. No tempo mínimo, ou seja, o
melhor desempenho do banco de dados, a diferença entre os softwares analisados chega
a ser superior a 500%. Nos campos tempo máximo (o pior desempenho do banco de
dados para obtenção do resultado), a superioridade do banco de dados LucidDB para
apresentação dos resultados é ainda maior, visto que há uma diferença de 600% entre os
bancos de dados.
Já no tempo médio, que leva em conta uma média simples (soma-se todos os
resultados e divide-se por 200), nota-se que, em média, a diferença entre os sistemas
chega a 530%, que é uma quantia considerável, visto que esperar 25 segundos para se
obter um relatório é uma quantia de tempo muito grande, enquanto que a espera média
de 4 segundos já é aceitável.
A figura 11 mostra os resultados da tabela 5 em forma de gráfico, para melhor
análise dos resultados apresentados.
39
FIGURA 11 - COMPARATIVO DO DESEMPENHO NA PRIMEIRA QUERIE
Conforme pode ser observado na figura 11, a performance do banco de dados
LucidDB manteve-se praticamente constante ao longo do tempo, enquanto a
performance do Mysql foi bastante instável, havendo picos onde o resultado era
apresentado com mais lentidão.
6.1.1.2 “Evolução do lucro”
Os dados coletados durante a execução da segunda querie podem ser observados
na tabela 6.
Tempo
Tempo
Tempo
Mínimo
Máximo
Médio
24748
27128
25549
LucidDB 2233
2774
2338
Diferença 1008,28%
877,94%
992,72%
Mysql
TABELA 6 - ANÁLISE COMPARATIVA DO DESEMPENHO NA SEGUNDA QUERIE
40
FIGURA 12 - GRÁFICO COMPARATIVO DO DESEMPENHO DA SEGUNDA QUERIE
Analisando os dados que compõem a tabela 6 e da figura 12, podemos observar
que o desempenho do banco de dados LucidDB foi novamente superior ao de seu
adversário, o Mysql. O menor tempo do sistema NoSQL foi mais de 1000% mais lento
que seu adversário, e no maior tempo houve uma diferença de 877% entre as
performances.
No tempo médio, que contempla o resultado das 200 buscas efetuadas, a
performance do LucidDb foi 990% superior ao Mysql, apresentando um tempo médio
de 2338 ms, contra um tempo médio de 25549 ms.
Novamente observamos que o desempenho do banco de dados LucidDB foi
praticamente constante ao longo do tempo, e que o desempenho do Mysql foi mais
constante durante esta busca, se comparado com o resultado que este banco obteve no
item 6.1.1.1.
6.1.1.3 “Horário com maior número de locações”
Seguem, na tabela 7 e na figura 13, os dados referente a análise de performance
de ambos os bancos de dados durante execução da terceira querie.
41
Tempo
Tempo
Tempo
Mínimo
Máximo
Médio
29820
37518
30512
LucidDB 2273
3999
2402
Diferença 1211,92%
838,18%
1170,45%
Mysql
TABELA 7 - ANÁLISE COMPARATIVA DO DESEMPENHO NA TERCEIRA QUERIE
FIGURA 13 - GRÁFICO COMPARATIVO DO DESEMPENHO NA TERCEIRA QUERIE
Conforme podemos observar na tabela 7 e na figura 13, o desempenho do banco
de dados LucidDB foi novamente superior ao seu adversário, o banco de dados Mysql.
Nos três requisitos (Tempo mínimo, Tempo máximo e Tempo médio), a
performance do banco de dados NoSQL foi significativamente superior ao banco de
dados relacional, obtendo diferenças significativas (1211%,
838% e 1170%,
respectivamente).
6.1.1.4 “Efetividade das promoções”
Na tabela 8 e na figura 14, podem ser observados os dados de desempenho dos
bancos de dados durante a última querie.
42
Tempo
Tempo
Tempo
Mínimo
Máximo
Médio
16825
19264
17300
LucidDB 2494
5192
2599
Diferença 574,62%
271,03%
565,65%
Mysql
TABELA 8 - ANÁLISE COMPARATIVA DO DESEMPENHO NA QUARTA QUERIE
FIGURA 14 - GRÁFICO COMPARATIVO DO DESEMPENHO NA QUARTA QUERIE
Conforme pode ser observado na tabela 8 e na figura 14, apesar de a diferença
entre os bancos de dados em ambos os requisitos serem menores nesta querie que nas
três buscas anteriores, o banco de dados NoSQL ainda possui uma grande vantagem
sobre o banco relacional.
Os tempos mínimo e médio de busca do LucidDB ainda são significativamente
superiores que o do banco Mysql, porem a diferença entre o tempo máximo, embora
ainda seja superior (271% de diferença), a diferença é mais acentuada do que aquela que
foi identificada nas queries anteriores (607%, 877% e 838% respectivamente).
A análise do gráfico que contempla todos os resultados mostra que apenas as
primeiras buscas do LucidDB ficaram fora do padrão de tempo apresentado, enquanto o
banco de dados Mysql obteve sua performance mais constante nesta querie do que nas
três anteriores, embora tenha um pico entre as queries 64 e 73.
43
6.1.2 Análise comparativa da utilização de CPU
Os itens a seguir mostram os resultados encontrados durante a análise
comparativa da utilização de CPU pelas duas aplicações durante a execução dos testes.
Neste critério foi analisado apenas o uso médio de CPU dos processos.
A diferença entre os dados analisados foi calculada utilizando-se a seguinte
formula: Maior utilização de CPU – Menor utilização de CPU.
6.1.2.1 “Gênero com maior receita em 2008”
A tabela 9 mostra os resultados encontrados referente ao uso de CPU na primeira
querie.
Média
Mysql
99,94%
LucidDB 99,98%
Diferença 0,04%
TABELA 9 - ANÁLISE COMPARATIVA DO USO DE CPU NA PRIMEIRA QUERIE
Conforme podemos observar na tabela 9, a utilização de CPU por ambas as
aplicações é praticamente idêntica, a diferença (0,04%) é praticamente nula.
Analisando este gráfico podemos notar que o processador é o elemento limitante
nas buscas em ambos os bancos de dados.
6.1.2.2
“Evolução do lucro”
Na tabela 10, podemos observar a utilização média de CPU durante a execução dos
testes.
44
Média
Mysql
100,00%
LucidDB 100,00%
Diferença
0,00%
TABELA 10 - ANÁLISE COMPARATIVA DO USO DE CPU NA SEGUNDA QUERIE
Conforme observamos na tabela 10, a utilização de CPU de ambos os sistemas de
banco de dados foi idêntica nesta busca, sem distinção do modelo de dados utilizado.
6.1.2.3
“Horário com maior número de locações”
Na tabela 11 podemos observar os dados de uso de CPU durante a execução da
terceira querie.
Média
Mysql
100,00%
LucidDB 100,00%
Diferença
0,00%
TABELA 11 – ANÁLISE COMPARATIVA DO USO DE CPU NA TERCEIRA QUERIE
Conforme podemos observar na tabela 11, a utilização de CPU de ambos os
sistemas de banco de dados foi idêntica nesta busca, sem distinção do modelo de dados
utilizado.
6.1.2.4
“Efetividade das promoções”
Na tabela 12, podemos observar as dados referente a utilização de CPU na quarta
querie.
45
Média
Mysql
99,98%
LucidDB 100,00%
Diferença
0,02%
TABELA 12 - ANÁLISE COMPARATIVA DO USO DE CPU NA QUARTA QUERIE
Conforme podemos observar na tabela 12, nesta querie houve uma pequena
diferença na utilização de CPU (0,02%) entre os bancos de dados, porem esta diferença
é praticamente inexistente, e não podemos concluir nada com base apenas nela.
6.1.3
Análise comparativa da utilização de memória
Os itens que seguem mostram os resultados encontrados durante a análise
comparativa da utilização de memória pelos bancos de dados NoSQL e relacional
durante a execução dos testes. Neste critério foi analisada a quantidade de memória
livre. Foram coletados os seguintes dados: quantidade mínima de memória livre,
quantidade máxima de memória livre e média da quantidade de memória livre durante a
execução dos testes.
A diferença entre os dados analisados foi calculada utilizando-se a seguinte
fórmula: (resultado com maior utilização de memória / resultado com menor utilização
de memória) - 1.
6.1.3.1
“Gênero com maior receita em 2008”
A tabela 13 apresenta os dados referente a quantidade livre durante a execução da
primeira querie.
Menor
Maior
Média
LucidDB
557
707 593,3333
Mysql
860
1013 917,1543
Diferença 54,40% 43,28%
54,58%
46
TABELA 13 - ANÁLISE COMPARATIVA
DO USO DE MEMÓRIA NA PRIMEIRA QUERIE
FIGURA 15 - COMPARATIVO DO USO DE MEMÓRIA NA PRIMEIRA QUERIE
Conforme podemos verificar na tabela 13 e na figura 15, a quantidade de memória
livre durante a execução do teste do banco de dados Mysql é maior do que a quantidade
de memória livre durante a execução do banco de dado adversário, o LucidDB.
Podemos notar que, em média, o banco de dados Mysql possui 54% a mais de
memória livre que o banco de dados NoSQL.
6.1.3.2
“Evolução do lucro”
A tabela 14 apresenta os dados referentes ao uso de memória durante a segunda
querie pelas aplicações.
Menor
Maior
Média
LucidDB
574
604 589,7188
Mysql
837
893 873,3578
Diferença 45,82% 47,85%
48,10%
TABELA 14 - ANÁLISE COMPARATIVA DO USO DE MEMÓRIA NA SEGUNDA QUERIE
47
FIGURA 16 - COMPARATIVO DO USO DE MEMÓRIA NA SEGUNDA QUERIE
Conforme podemos verificar na figura 16 e na tabela 14, a quantidade de memória
livre durante a execução do banco de dados relacional é maior que a de seu adversário,
o banco de dados NoSQL.
Verificamos que, em média, o banco de dados Mysql aloca 48% a menos de
memória que o banco LucidDB, deixando esta memória disponível para outros
aplicativos. Podemos observar na figura 16 que diferença entre os bancos é constante,
tanto no menor uso, quanto no maior e na média.
6.1.3.3
“Horário com maior número de locações”
A Tabela 15 apresenta os dados comparativos entre os bancos de dados LucidDB e
Mysql durante o teste comparativo.
48
Menor
Maior
Média
LucidDB
556
571 567,3125
Mysql
857
893 874,5577
Diferença 154,14% 156,39% 154,16%
TABELA 15 – ANÁLISE COMPARATIVA
DO USO DE MEMÓRIA NA TERCEIRA QUERIE
FIGURA 17 - GRÁFICO COMPARATIVO DO USO DE MEMÓRIA
NA TERCEIRA QUERIE
Conforme podemos observar na tabela 15, novamente observamos que o banco de
dados relacional possui uma quantidade maior de memória disponível que seu
adversário, conforme tendência observada nos itens 6.1.3.1 e 6.1.3.2.
A análise da figura 17 mostra que a diferença de memória disponível se mantém
constante nos 3 critérios observados (menor, maior e média).
49
6.1.3.4
“Efetividade das promoções”
A tabela 16 e a figura 18 mostram os dados referente a quantidade de memória
disponível na ultima querie.
Menor
Maior
Média
LucidDB
547
560
Mysql
818
893 871,4701
Diferença 49,54% 59,46%
555,2
56,97%
TABELA 16 - ANÁLISE COMPARATIVA DO USO DE MEMÓRIA NA QUARTA QUERIE
FIGURA 18 - COMPARATIVO DO USO DE MEMÓRIA NA QUARTA QUERIE
Conforme podemos observar na Tabela 16, o banco de dados Mysql possui uma
maior quantidade de memória disponível durante sua execução, conforme tendência já
observada anteriormente.
A figura 18 nos mostra que, novamente, a diferença entre a quantidade de memória
disponível durante a execução dos testes entre os bancos de dados se manteve
praticamente constante nos 3 critérios analisados.
50
6.1.4
Análise comparativa da alocação das tabelas em disco
A tabela 17 apresenta os dados referente a análise comparativa da uso de disco para
alocação dos dados de ambos os SGDBs. Os dados apresentados encontra-se em
MegaBytes (MB).
A diferença entre o tamanho das tabelas foi calculada utilizando-se a seguinte
formula: (Tabela com maior tamanho / Tabela com menor tamanho) -1.
Tamanho Total das tabelas
(MB)
Mysql
251,74
LucidDb
145,65
Diferença
72,84%
TABELA 17 - ANÁLISE COMPARATIVA DA ALOCAÇÃO EM DISCO
FIGURA 19 - COMPARATIVO DA ALOCAÇÃO DOS DADOS EM DISCO
Conforme podemos observar na tabela 17 e na figura 19, o banco de dados
LucidDB utiliza melhor o disco para alocação dos dados, visto que o banco de dados
Mysql utiliza 72% a mais de espaço em disco para alocar os mesmos dados.
51
6.1.5
Desempenho utilizando menos memória RAM
A diferença entre os tempos foi calculada utilizando-se a mesma formula utilizada
anteriormente, na seção 5.1.1 (Resultado com maior tempo / resultado com menor
tempo) -1.
6.1.5.1
“Análise comparativa do desempenho dos bancos com 1000mb de
memória total”
A tabela 18 mostra os dados de desempenho dos bancos de dados quando a memória
total do sistema foi reduzida para 1000MB.
Máxima Mínima Média
LucidDB 16761
3581
4170
Mysql
23466
24602
28840
Diferença 72,07%
555,29% 589,98%
TABELA 18 - ANÁLISE COMPARATIVA
DO DESEMPENHO COM 1000MB DE MEMORIA TOTAL
Conforme podemos observar, ambos os bancos de dados tiveram uma piora em sua
performance máxima (4669 e 33033 anteriormente, para os bancos LucidDB e Mysql,
respectivamente).
A figura 20 mostra a evolução do tempo de resposta ao longo da execução das
queries. Podemos notar que após a primeira busca, o tempo de resposta diminui
significativamente e é comparável ao resultado obtido utilizando 1500MB de memória
RAM.
52
FIGURA 20 - ANÁLISE COMPARATIVA DO DESEMPENHO
COM 1000MB DE MEMÓRIA TOTAL
6.1.5.2
Análise comparativa da quantidade de memória livre com 1000mb
de memória total
A tabela 19 mostra os dados referente a quantidade de memória livre(em MB)
obtidos durante a execução do teste.
Máxima
Mínima
Média
LucidDB
342
149
189
Mysql
600
504
546
Diferença 75,44%
238,26% 188,86%
TABELA 19 – ANÁLISE COMPARATIVA
DA MEMÓRIA LIVRA COM 500MB DE MEMÓRIA TOTAL
Conforme podemos observar na tabela 19, durante a execução dos testes pelo banco
de dados Mysql, a quantidade de memória livre é maior que a quantidade de memória
livre durante a execução dos testes no banco LucidDB, conforme tendência já observada
no item 6.1.3.
A figura 21 nos mostra a diferença entre os bancos de dados graficamente,
ilustrando a grande diferença que existe entre os bancos na utilização de memória.
53
FIGURA 21- QUANTIDADE DE MEMÓRIA LIVRE
DURANTE A EXECUÇÃO DOS TESTES COM 1000MB DE MEMÓRIA TOTAL
6.1.5.3
Análise comparativa do desempenho dos bancos com 500mb de
memória total
A tabela 20 apresenta os dados de desempenho dos bancos de dados quando a
memória foi diminuída para 500MB.
Máxima
LucidDB
30479
Mysql
30961
Mínima
3564
Média
4213,15
24104 25366,99
Diferença 101,58% 676,32% 602,09%
TABELA 20 – ANÁLISE COMPARATIVA
DO DESEMPENHO COM 500MB DE MEMÓRIA TOTAL
Conforme podemos observar na tabela 20, o tempo máximo de resposta do banco
de dados LucidDB teve um aumento considerável, enquanto o tempo máximo do Mysql
sofreu pouca alteração. O tempo mínimo e a média de cada banco de dados não
sofreram diferenças significativas.
54
FIGURA 22 - ANÁLISE COMPARATIVA DO DESEMPENHO
COM 500MB DE MEMÓRIA TOTAL
Conforme podemos observar na figura 22, o tempo inicial do banco LucidDB foi
superior ao banco de dados Mysql com esta quantidade de memória disponível ,porem
nas outras buscas os resultados apresentados foram semelhantes a aqueles apresentados
anteriormente.
6.1.5.4
Análise comparativa da quantidade de memória livre com 1000mb
de memória total
A tabela 21 mostra os dados referente a quantidade de memória livre (em MB)
obtidos durante a execução do teste.
Máxima
LucidDB
Mysql
Mínima
Média
45
2
20
192
75
118
Diferença 426,67% 3750,00% 602,41%
TABELA 21 – ANÁLISE COMPARATIVA
DA MEMÓRIA LIVRE COM 500MB DE MEMÓRIA TOTAL
55
Conforme podemos observar na tabela 21, a quantidade de memória livre durante a
execução dos testes no banco de dados LucidDB é inferior a quantidade de memória
livre durante a execução do banco relacional, em todos os critérios comparados.
A figura 23 mostra a diferença encontrada na tabela 21 graficamente. Conforme
podemos observar, a diferença do uso de memória entre os bancos é muito grande,
conforme já observado anteriormente (itens 6.1.3 e 6.1.5.2)
FIGURA 23- QUANTIDADE DE MEMÓRIA LIVRE DURANTE A EXECUÇÃO DOS
TESTES COM 500BM DE MEMÓRIA TOTAL
56
7
Considerações finais
Este trabalho efetuou a análise comparativa de banco de dados relacionais e NoSQL
na utilização por aplicações de Business Intelligence.
Este capítulo está dividido como segue: A seção 7.1 apresenta as contribuições e
conclusões e a 7.2 apresenta os trabalhos futuros.
7.1
Contribuições e Conclusões
As contribuições deste trabalho são:
a) Estudo comparativo do desempenho dos bancos de dados LucidDB e Mysql
com diferentes quantidades de memória RAM disponíveis, durante
consultas utilizadas por aplicações de Business Intelligence.
b) Comparação da utilização de CPU pelos bancos de dados LucidDB e Mysql
durante consultas utilizadas por aplicações de Business Intelligence.
c) Comparação da quantidade de memória utilizada pelos bancos de dados
LucidDB e Mysql durante consultas utilizadas por aplicações de Business
Intelligence.
d) Comparação do espaço em disco utilizado pelos bancos de dados Mysql e
LucidDB para alocação dos mesmos dados.
A partir destas contribuições, pode-se concluir que:
a)
O banco de dados LucidDB apresenta um melhor desempenho que o
banco de dados Mysql no caso de teste estudado.
b)
O banco de dados Mysql utiliza uma menor quantidade de memória
RAM que o banco de dados LucidDB, e que ambos trabalham bem com pouca
memória.
c)
Ambos os bancos de dados utilizam a capacidade máxima de CPU
disponível, não havendo diferença nesse quesito.
d)
O banco de dados LucidDB armazena os dados em disco de forma mais
eficiente, pois possui uma menor alocação de disco para os mesmos dados.
57
As seguintes experiências foram obtidas:
a)
Criação e configuração de ambiente virtual.
b)
Instalação, configuração e utilização de um banco de dados sem interface
gráfica (LucidDB)
c)
7.2
Utilização dos metadados dos bancos de dados Mysql e LucidDb
Trabalhos Futuros
As contribuições alcançadas com este Trabalho não encerram as pesquisas
relacionadas a comparação de bancos de dados Relacionais e NoSQL, mas abrem
oportunidades para alguns trabalhos futuros:
a) Comparação de outras bases de dados
b) Comparação utilizando um hardware mais potente
c) Comparação do banco de dados NoSQL na utilização em aplicações que
não seja de Business Intelligence.
d) Comparação dos bancos em outros sistemas operacionais (Linux, Solaris)
58
8
Referencias Bibliográficas
Bouman, R.; Dongen, J. V. Pentaho Solutions.
WileyPublishing,Inc, 2009. ISBN 978-0-470-48432-6.
1st.
ed.
Indianapolis:
WCS: Wide-Columns-Sore. 2010. Disponível em: <http://bluesoft.wordpress.com/tag/
wide-columns-store/>. Acesso em: 24 maio. 2011.
Cattel, R. Relational Databases, Object Databases, Key-Value Stores, Document Stores,
and Extensible Record Stores: A Comparison. ODBMs. 2010. Disponível em
<http://www.odbms.org/download/Cattell.Dec10.pdf>. Acesso em: 12 jun. 2011.
Chang, F; Dean, J; Ghemawatt, S; Hsieh, W C B;, Deborah A. W. M; Chandra, T;
Fikes, A Gruber, R. E. Bigtable: A Distributed Storage System for Structured Data,
2006. - OSDI '06 Proceedings of the 7th USENIX Symposium on Operating Systems
Design and Implementation - Volume 7
Codd, E. F. A relational model of data for large shared data Banks. Comunications of
the ACM, v.13, e.6, Junho 1970.
CPMBC: Cloudera presents the MapReduce bull case. 2009. Disponível em:
<http://www.dbms2.com/2009/04/15/cloudera-presents-the-mapreduce-bull-case/>.
Acesso em: 24 maio. 2011.
FHH:
Facebook,
Hadoop,
and
Hive.
2009.
Disponível
em:
<http://www.dbms2.com/2009/05/11/facebook-hadoop-and-hive/>. Acesso em: 24 maio
2011.
HLIP:
How
Large
Is
a
Petabyte.
2009.
Disponível
<http://gizmodo.com/5309889/what-is-a-petabyte/>. Acesso em: 24 maio. 2011.
em:
Horowitz, M. L. An Introduction to Object-Oriented Databases and Databases Systems,
1991. Disponível em: <http://reports-archive.adm.cs.cmu.edu/anon/itc/CMU-ITC103.pdf>. Acesso em: 24 maio. 2011.
JMeter, 2011. Disponível em: <http://jakarta.apache.org/jmeter/>. Acesso em: 17 jul.
2011.
59
Kimball, R.; Ross, M. The Data WareHouse Toolkit. 2ª Edição. New York: Wiley
Computer Publishing, 2002. ISBN 0-471-20024-7.
Leavitt, N. Will NoSQL Databases Live Up to Their Promise? 2010. Computer, 12.
ISSN: 0018-9162, pg. 12 – 14
LucidDB, 2011. Disponível em <http://www.luciddb.org/>. Acesso em: 24 maio. 2011.
Machado, F. N.R. Banco de dados: Projeto e implementação. Brasil: Editora Erica,
2008. ISBN 978-85-365-0019-5.
Microsoft,
2011.
Disponível
em
<http://technet.microsoft.com/ptbr/library/cc749154(WS.10).aspx/>. Acesso em: 17 jul. 2011.
Mynosql. 2010. Disponível em <http://nosql.mypopescu.com/post/407159447/
cassandra-twitter-an-interview-with-ryan-king/>. Acesso em: 24 maio, 2011.
Mysql, 2011. Disponível em; <http://www.mysql.com/why-mysql/white-papers/>.
Acesso em: 24 maio. 2011.
NVRSDQEF: NoSQL, você realmente sabe do que estamos falando?, 2010. Disponível
em
<http://imasters.com.br/artigo/17043/
bancodedados/nosql_voce_realmente_sabe_do_que_estamos_falando/>. Acesso em: 24
maio. 2011.
Sieera, J. L; Fernándes-Valmayor, A.; Fernándes-Majon, B.; Navarro, A.. ADDS: A
Document-Oriented Approach for Application Development. Journal of Universal
Computer Science, Volume 10, pages 1302-1324, 2004.
Silberschatz, A.; Korth, H.. F., Sudarshan, S. Sistema de banco de dados, Rio de
Janeiro: Editora Elsevier, 2006. ISBN: 978-85-352-1107-8.
Stonebraker, M.; Abadi, D. J.; Batkin, A.; Chen, X; Cherniack, M.; Ferreira, M.; Lau,
E.; Lin, A.; Madden, S.; O’Neil, E.; O’Neil, P.; Rasin, A.; Tran, N.;Zdonik, S. C-Store:
A Column-oriented DBMS. 2005 - VLDB '05 Proceedings of the 31st international
conference on Very large data bases. ISBN:1-59593-154-6
60
MT10AADW: My Top 10 Assertions About Data Warehouses, 2010. Disponível em
<http://cacm.acm.org/blogs/blog-cacm/98136-my-top-10-assertions-about-datawarehouses/fulltext/> Acesso em: 24 maio. 2011.
Teradata,
2008.
Disponível
em:
<http://www.teradata.com/t/newsrelease.aspx?id=6375/>. Acesso em: 24 maio. 2011.
Termehchy, A.; Winslett, M. Keywords Search Over Key-Value Stores. ACM, 2010.
ISBN: 978-1-60558-799-8.
Vercellis, C. Bussiness Intelligence: Data mining and Optimization for Decision
Making, 1ª Edição. John Wiley & Sons Ltd, 2009. ISBN978-0-470-51138-1
VirtualBox, 2011. Disponível em: <http://www.virtualbox.org/> Acesso em 10 jul.
2011.
Williams, Steve. Williams, Nancy. “The profit impacto of Business Intelligence”.
Morgan Kaufmann Publishers, 2007. ISBN-13:978-0-12-372499-1
WNM: “What’s New in MySQL 5.5: Performance and Scalability”. Disponível em
<http://www.mysql.com/why-mysql/white-papers/mysql-wp-whatsnew-mysql-55.php>
Acesso em: 10 jul. 2011.
61
9
9.1
Apêndice
Apêndice 1: Tabelas do modelo de dados
Tabela dim_time: É a tabela dimensional que possui os registros com todas as horas
existentes em um dia.
Tabela dim_date: É a tabela dimensional que possui os dados de datas (sem hora),
que alem de possuir a data em si, possui dados adicionais, como se é feriado, se é final
de semana, o ano fiscal, etc.
Tabela dim_customer: É a tabela dimensional onde são armazenados os dados dos
consumidores da aplicação.
Tabela dim_order_status: É a tabela dimensional que armazena os possíveis estados
dos pedidos dos clientes.
Tabela dim_promotion: É a tabela dimensional que armazena os dados referentes as
promoções criadas pela empresa WCM.
Tabela dim_warehouse: É a tabela dimensional onde ficam armazenados os dados
sobre os armazéns da WCM.
Tabela dim_website: É a tabela dimensional onde ficam armazenados os dados
sobre os vários sites que compõem a aplicação WCM.
Tabela dim_dvd_release: É a tabela dimensional onde ficam armazenados os dados
sobre os DVD’s que são comercializados pela WCM.
Tabela dim_demography: É a tabela dimensional que relaciona o grupo
demográfico que um determinado cliente faz parte. Exemplo: entre 15 e 20 anos de
idade, do sexo masculino e que ganha
entre 10.000 e 20.000 doláres por ano (este
é um registro da tabela). È utilizada para separar os clientes em grupos.
Tabela dim_zipcensus: É a tabela dimensional que armazena os dados dos códigos
postais (os ‘ceps’ dos clientes) e os dados de localização destes locais.
Tabela fact_orders: É a tabela onde ficam armazenados os dados das
locações/compras dos clientes, e o contexto (dimensões) que estas compras ocorreram.
62
9.2
Apendice 2: Scrips das buscas efetuadas nos bancos de dados
Seguem abaixo as questões que o bancos de dados deveriam responder e os scripts
utilizados para execução das mesmas:
Qual gênero de filme gerou mais receitas no ano de 2008?
select sum(fo.revenue), ddr.dvd_release_genre, dd.year4
from fact_orders fo, dim_dvd_release ddr, dim_date dd
where fo.local_order_date_key=dd.date_key and
fo.dvd_release_key=ddr.dvd_release_key and dd.year4='2008'
group by dd.year4, ddr.dvd_release_genre;
Como o lucro está evoluindo com o tempo?
select sum(fc.revenue), dd.year4 from fact_orders fc, dim_date dd
where fc.local_order_date_key=dd.date_key
group by dd.year4
order by dd.year4;
Qual horário do dia os consumidores fazem mais locações?
select sum(fc.revenue), dt.time_hour from fact_orders fc, dim_time dt
where fc.local_order_time_key=dt.time_key
group by dt.time_hour
order by dt.time_hour;
Quão efetivas foram as promoções no ano de 2008?
select sum(fc.revenue), dp.promotion_key
from fact_orders fc, dim_promotion dp, dim_date dd
where fc.promotion_key=dp.promotion_key
and fc.local_order_date_key=dd.date_key
and dd.year4='2008'
group by dp.promotion_key
order by dp.promotion_key;