CENTRO ESTADUAL DE DUCAÇÃO TECNOLÓGICA PAULA SOUZAfateclins.edu.br/.../WQnh8ilWnbEz4NgJKUzovaSCFY6x2snGnY8E3as… · 1 centro estadual de educaÇÃo tecnolÓgica paula souza faculdade

0

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA

PAULA SOUZA

FACULDADE DE TECNOLOGIA DE LINS PROF. ANTÔNIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA COM ÊNFASE EM

BANCO DE DADOS

CAMILA RIBEIRO DA SILVA

NATHAN FELYPE DELGADO SANTOS

ANÁLISE COMPARATIVA DE DESEMPENHO ENTRE OS

BANCOS DE DADOS POSTGRESQL E MYSQL

LINS/SP

2º SEMESTRE/2016

1

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA

PAULA SOUZA

FACULDADE DE TECNOLOGIA DE LINS PROF. ANTÔNIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA COM ÊNFASE EM

BANCO DE DADOS



ANÁLISE COMPARATIVA DE DESEMPENHO ENTRE OS BANCOS

DE DADOS POSTGRESQL E MYSQL

Trabalho de Conclusão de Curso apresentado à

Faculdade de Tecnologia de Lins “Prof. Antônio

Seabra”, como parte dos requisitos necessários

para obtenção do Título de Tecnólogo em Banco de

Dados.

Prof. Me. Adriano Bezerra

LINS/SP

2º SEMESTRE/2016

2



ANÁLISE COMPARATIVA DE DESEMPENHO ENTRE OS

BANCOS DE DADOS POSTGRESQL E MYSQL

Trabalho de Conclusão de Curso apresentado à

Faculdade de Tecnologia de Lins “Prof. Antônio

Seabra”, como parte dos requisitos necessários

para obtenção do Título de Tecnólogo em Banco de

Dados sob orientação do Prof. Me. Adriano

Bezerra.

Data de Aprovação: ____ / ____ / ______

_________________________________________________

Orientador Prof. Me. Adriano Bezerra

_________________________________________________

Prof. Me.

_________________________________________________

Prof. Me.

3

Dedico este trabalho, primeiramente, a

Deus, pela sabedoria concedida e a oportunidade

de estar realizando este estudo. Aos meus

familiares e amigos pelo incentivo e apoio nos

momentos difíceis. E a todos os professores qυе

foram tão importantes na minha vida acadêmica е

no desenvolvimento desta monografia.

Camila Ribeiro da Silva

4

Dedico este trabalho primeiramente a Deus

e a minha mãe que sempre me deu forças para

acreditar em mim e na palavra Dele, aos amigos e

a todos que me apoiaram neste trabalho.

Nathan Felype Delgado Dos Santos

5

AGRADECIMENTOS

Neste momento muito importante da minha vida, onde eu não achei que iria

chegar, gostaria de agradecer a Deus onde esteve comigo a minha vida toda,

protegendo e me dando sabedoria.

Agradeço ao Prof. Adriano Bezerra por ser nosso orientador, nos ajudando e

dando dicas sempre que precisamos.

Agradeço ao Prof. Alciano, mesmo não dando aulas mais na Fatec foi o nosso

primeiro orientador e o primeiro que acreditou neste trabalho.

Agradeço a minha família, por me ensinar valores da amizade e nunca desistir.

Em especial minha mãe e minha vó que eu não trocaria por nada nesse mundo.

Agradeço as melhores pessoas que eu pude conhecer nesses anos de estudo

Daiane Simião, Carolina Bicudo e Junior Barrionuevo, pessoas que mesmo distantes

estão no meu coração para sempre.

Agradeço ao Lucian Alves que sempre nos ajudou na parte de programação e

agora já faz parte da minha vida, obrigado por todas as explicações.

Agradeço a minha parceira Camila Ribeiro aonde vem comigo nessa batalha

todos esses anos, obrigado por sua paciência comigo nos meus momentos de crise.

Agradeço a todos que torceram para que esse dia chegasse muito obrigado.

Nathan Felype Delgado Santos

6

AGRADECIMENTOS

Neste momento tão especial agradeço primeiramente a Deus, pois ele é a base

de tudo.

Agradeço a minha família por ter acreditado e me apoiado do início ao fim.

Agradeço ao prof. Adriano Bezerra, pela orientação e as dicas importantíssimas

que nos deu para a elaboração desse estudo e ao longo do curso.

Agradeço ao prof. Alciano Augusto, que no início deste estudo fez parte como

uma peça importantíssima, por ter acreditado em nós para a realização do trabalho.

Agradeço ao meu amigo Lucian Alves pelas ajudas para a realização do estudo.

Agradeço a todos os professores que ao longo do curso tive o prazer de

conhecer.

Agradeço ao meu parceiro de projeto Nathan Delgado pela oportunidade de ter

feito este trabalho com ele.

Enfim, agradeço a todos os amigos que conheci ao longo do curso, que fizeram

parte da minha formação diretamente ou indiretamente, o meu muito obrigada.

Camila Ribeiro da Silva

7

RESUMO

Este trabalho visa avaliar o desempenho de dois gerenciadores de banco de dados:

MySQL e PostgreSQL, executando Avaliações de Desempenho de Insert, Update,

Delete e Select para observar o tempo de resposta de cada um dos SGBDs utilizando

o Apache JMeter. Baseado nestas Avaliações de Desempenho, este trabalho também

demonstra qual dos dois SGBDs é mais eficiente levando em conta o ambiente e as

condições definidas no cenário proposto.

Palavras-Chaves: Banco de Dados. PostgreSQL. MySQL. Avaliação de Desempenho.

8

ABSTRACT

This job aims to evaluate the performance of two database management systems:

MySQL and PostgreSQL, running Insert, Update, Delete and Select tests to observe

the response time of each DBMS using the Apache Jmeter. Based on these tests, this

job also demonstrate which of the two DBMS is the most efficient in each CRUD

category (Insert, Update, Delete e Select), considering the ambient and conditions

defined in the scenario proposed in this job.

Key-words: Database. PostgreSQL. MySQL. Performance evaluation.

9

LISTA DE ILUSTRAÇÕES

FIGURA 1.1 – Representação simplificada de um sistema de banco de dados ....... 18

FIGURA 1.2 - Estrutura de um banco de dados ........................................................ 23

FIGURA 2.1- Tabela do usuário no MySQL .............................................................. 30

FIGURA 2.2 - Interface do pgAdmin4 ....................................................................... 32

FIGURA 3.1 - Modelo de Dados Relacional .............................................................. 34

FIGURA 3.2 – Tabela de Clientes ............................................................................ 35

FIGURA 3.3 – Tabela de Marcas ............................................................................. 36

FIGURA 3.4 – Tabela de Produtos ............................................................................ 36

FIGURA 3.5- Tabela de Vendas Orig ....................................................................... 37

FIGURA 3.6- Tabela de Vendas ............................................................................... 38

FIGURA 3.7 - Interface JMeter ................................................................................. 40

FIGURA 4.1 - Avaliação de desempenho com Select ............................................... 42

FIGURA 4.2 - Avaliação de desempenho com Select Join ....................................... 43

FIGURA 4.3 - Avaliação de desempenho com Select, Join e Where ........................ 44

FIGURA 4.4 - Avaliação de desempenho Select com Join, Where e Sum ............... 45

FIGURA 4.5 - Avaliação de desempenho com Insert ................................................ 46

FIGURA 4.6 - Avaliação de desempenho de Insert com Join .................................. 47

FIGURA 4.7 - Avaliação de desempenho Insert com Join e Where .......................... 49

FIGURA 4.8 - Avaliação de desempenho de Delete ................................................. 50

FIGURA 4.9 - Avaliação de desempenho de Delete com Where .............................. 51

FIGURA 4.10 - Avaliação de desempenho Update .................................................. 52

FIGURA 4.11 - Avaliação de desempenho Update com Where ............................... 53

10

LISTA DE TABELAS

Tabela 1 - Avaliação de Desempenho com Selects ............................................... 54

Tabela 2 - Avaliação de Desempenho com Inserts ................................................ 55

Tabela 3 - Avaliação de Desempenho com Delete ................................................ 55

Tabela 4 - Avaliação de Desempenho com Update .............................................. 55

11

LISTA DE ABREVIATURAS E SIGLAS

BD – Banco de Dados

BDOO – Banco de Dados Orientados a Objeto

BSD – Berkely Software Distribution

CRUD – Creat, Read, Update, Delte

DBA – Administrador de Banco de Dados

IBM – International Business Machines

JDBC – Java Database Connectivity

MR – Modelo Relacional

ODM – Object Query Language

ODMG – Obejct Database Management Group

SGDB – Sistema de Gerenciamento de Banco de Dados

SQL- Structured Query Language

12

LISTA DE SÍMBOLOS

@ - Arroba

® - Registrado

™- Trade Mark

13

SUMÁRIO

INTRODUÇÃO ...................................................................................................... 15

1 CONCEITOS ...................................................................................................... 17

1.1 CONCEITOS DE BANCO DE DADOS ............................................ 17

1.1.1 História do Banco de Dados ............................................................................. 19

1.1.2 Por que usar Banco de Dados? ....................................................................... 20

1.1.3 Modelos de Banco de Dados ........................................................................... 20

1.2 MODELO RELACIONAL .............................................................................. 21

1.2.1 Bancos de Dados Orientados a Objeto ............................................................ 22

1.3 SISTEMAS DE GERENCIAMENTO DE BANCO DE DADOS ........... 24

1.3.1 SGBDs MAIS UTILIZADOS .............................................................................. 25

1.4 CONSULTAS .................................................................................................. 26

2 ANÁLISES DE BANCO DE DADOS ............................................................ 28

2.1 BANCO DE DADOS MYSQL ...................................................................... 28

2.1.1 Versão Utilizada no Projeto .............................................................................. 29

2.2 BANCO DE DADOS POSTGRESQL ........................................................ 30

2.2.1 Interfaces Com Usuário .................................................................................... 31

2.2.2 Interfaces de Terminal Interativo ...................................................................... 32

2.2.3 Interfaces de Linguagem de Programação ....................................................... 32

2.2.4 Tipos Nos PostgreSQL ..................................................................................... 33

3 DESENVOLVIMENTO DO TRABALHO ...................................................... 34

3.1 METODOLOGIA ............................................................................................ 34

3.2 GERAÇÃO DE DADOS ............................................................................... 35

3.3 HARDWARE UTILIZADO ............................................................................ 38

3.4 FERRAMENTA APACHE JMETER .......................................................... 39

3.4.1 Instalação do Apache JMeter ........................................................................... 39

3.5 INSTALAÇÃO E CONFIGURAÇÃO DOS BANCOS ............................. 40

4 AVALIAÇÃO DE DESEMPENHO E RESULTADOS ................................ 41

4.1 AVALIAÇÃO DE DESEMPENHO COM SELECT SIMPLES .............. 41

14

4.2 AVALIAÇÃO DE DESEMPENHO COM SELECT JOIN ....................... 42

4.3 AVALIAÇÃO DE DESEMPENHO COM SELECT, JOIN E WHERE . 43

4.4 AVALIAÇÃO DE DESEMPENHO COM SELECT, JOIN, WHERE E

SUM ......................................................................................................................... 44

4.5 AVALIAÇÃO DE DESEMPENHO COM INSERT ................................... 45

4.6 AVALIAÇÃO DE DESEMPENHO DE INSERT COM JOIN ................. 46

4.7 AVALIAÇÃO DE DESEMPENHO INSERT COM JOIN E WHERE ... 48

4.8 AVALIAÇÃO DE DESEMPENHO DE DELETE ...................................... 49

4.9 AVALIAÇÃO DE DESEMPENHO DE DELETE COM WHERE .......... 50

4.10 AVALIAÇÃO DE DESEMPENHO UPDATE ........................................ 51

4.11 AVALIAÇÃO DE DESEMPENHO UPDATE COM WHERE .............. 52

CONSIDERAÇÕES FINAIS ............................................................................... 54

REFERÊNCIAS BIBLIOGRÁFICAS ................................................................. 56

ANEXO A ................................................................................................................ 57

ANEXO B ................................................................................................................ 60

ANEXO C ............................................................................................................... 62

ANEXO D ............................................................................................................... 64

15

INTRODUÇÃO

Desde o fim do século passado a tecnologia vem sendo cada vez mais utilizada

nas empresas. Neste novo século, a informação passou a ser imprescindível, a

necessidade de empresas tomarem decisões cruciais, faz da informação seu bem

mais precioso. O volume de dados é cada vez maior e se torna indispensável escolher

um banco de dados que seja eficiente, robusto, e que atenda a todas as premissas de

um banco de dados (BD), pois fatores como a segurança, velocidade e desempenho

podem determinar o sucesso ou fracasso de uma empresa, segundo C.J Date (2008).

Este trabalho destaca dois bancos de dados conhecidos, o PostgreSQL e o

MySQL. Assim o presente trabalho tem como meta realizar uma análise comparativa

escolhendo alguns critérios de análise baseados em operações create, read, update

e delete (CRUD) que possam ser avaliados em ambos os bancos de dados escolhidos

e após a realização das Avaliações de Desempenho em um sistema computacional

comum a todos, demonstrar qual será mais eficiente levando-se em conta o ambiente

e as condições definidas.

O principal objetivo deste trabalho é apresentar uma comparação de algumas

características que os definem e que possam permitir a cada empresa escolher um

ou outro, ressaltando que esta análise não define qual é o melhor banco de dados e

sim fornece informações que devem ser consideradas ao escolher um sistema

gerenciador de banco de dados (SGBD).

Vale lembrar, que no mercado de banco de dados, existem também outras

opções de SGDB’s, como: Oracle, Firebird, DB2, MS SQL entre outros. Tem-se então

como objetivo, demonstrar como estes dois SGBD’s (PostgreSQL e MySQL), tratam

e manipulam suas informações, e também verificar o tempo de resposta em várias

consultas com um grande volume de dados, para um melhor e imparcial resultado.

A metodologia utilizada para o trabalho em questão consiste em inicialmente,

definir qual a base de dados utilizada bem como as versões dos SGBD’s escolhidos.

Para a base de dados, utilizamos a mesma base de dados com os mesmos

registros para que discrepâncias não venham a ocorrer nas Avaliação de

Desempenho realizadas.

As versões utilizadas foram as últimas versões disponibilizadas no mercado

que eram gratuitas.

16

Após estas definições foi realizado uma pesquisa bibliográfica com o objetivo

de definir quais seriam as consultas a serem desenvolvidas.

Foi realizada uma pesquisa com o intuído de encontrar e definir uma ferramenta

de análise e avaliação de desempenho para banco de dados. Com essa pesquisa

definimos por utilizar a ferramenta Apache Jmeter para a realização das análises de

desempenho entre os bancos de dados.

Para a realização das avaliações de desempenho, foi usado os mesmos

critérios nos dois SGBDs. Após a realização dos testes, foi feita uma análise que

permitiu definir qual o SGBD que apresentou melhor desempenho para o Banco de

Dados em questão. Sendo esta apresentada como resultado final das avaliações de

desempenho.

17

1 CONCEITOS

Neste capítulo serão apresentados conceitos de banco de dados, suas

definições e uma breve história sobre eles, da mesma forma mostrando o modelo

relacional e seus tipos de SGDB’s, dando visão maior aos BD usados neste trabalho

que são o MySQL e PostgreSQL.

1.1 CONCEITOS DE BANCO DE DADOS

Segundo C.J Date (2008) um banco de dados (BD) é basicamente um sistema

computadorizado de manutenção de registros. O BD por si só, pode ser considerado

um armário de arquivamento eletrônico; ou seja, um recipiente para coleção de

arquivos de dados computadorizados. Os usuários do sistema podem solicitar que o

sistema realize diversas operações envolvendo tais arquivos – por exemplo:

acrescentar novos arquivos ao bd;

inserir dados em arquivos existentes;

buscar dados de arquivos existentes;

excluir dados de arquivos existentes;

alterar dados em arquivos existentes;

remover arquivos existentes do bd.

A Figura .1 é uma imagem simplificada de um sistema de banco de dados, por

meio dela é possível visualizar que tal sistema envolve quatro componentes principais:

dados, hardware, software e usuários.

18

Figura 1.1 Representação simplificada de um sistema de banco de dados Fonte: DevMedia, 2015

Para C.J Date (2008) são expressões gerais que descrevem características das

entidades sobre as quais operam os algoritmos. Neste caso, os dados por si só

também não constituem informação, a menos que esta surja do adequado

processamento de dados.

Hardware

É a parte física de um computador, é formada pelos componentes eletrônicos,

como por exemplo, circuitos de fios e luz, placas, utensílios e qualquer outro material

em estado físico, que seja necessário para fazer com o que o computador funcione.

Software

É uma sequência de instruções escritas para serem interpretadas por um

computador com o objetivo de executar tarefas específicas. Também pode ser

definido como os programas que comandam o funcionamento de um computador.

Usuários

Segundo C.J Date (2008) existem 3 classes gerais de usuários:

19

programadores de aplicações – Responsáveis pela escrita de programas de

aplicações de dados em alguma linguagem de programação;

usuários finais – Que acessam o banco de dados interativamente, podendo

acessar o banco de dados por meio de uma das aplicações on-line ou, então,

pode usar uma interface fornecida como parte integrante do software do

sistema;

administrador do banco de dados (DBA) – É a pessoa que toma decisões

estratégicas e de normas com relação aos dados da empresa, responsável pelo

controle geral.

1.1.1 HISTÓRIA DO BANCO DE DADOS

Furtado (2013) afirma que antigamente as empresas armazenavam dados em

fichas de papel que eram organizadas em arquivos físicos por meio de pastas. Extrair

informações e manter esses arquivos organizados era uma tarefa muito custosa. Além

disso, o acesso à informação dependia da localização geográfica dos arquivos. Enfim

esses arquivos físicos evoluíram para arquivos digitais. No início, cada entidade

(clientes, funcionários, produtos, etc.) era um arquivo de dados que eram

acompanhados de um “software simples” para manipular os dados do arquivo, esses

softwares permitiam realizar operações de cadastro, alteração, exclusão e consulta

nos arquivos digitais.

Segundo Furtado(2013), de fato melhorou bastante, principalmente a tarefa de

consulta de informações, porém os arquivos digitais eram ainda uma versão

melhorada dos arquivos físicos. Mas as entidades precisavam relacionar-se, por

exemplo, um produto é fornecido por um fornecedor, e com os arquivos digitais

relacioná-las não era uma tarefa muito trivial, os “softwares simples” para manipular

os arquivos digitais começaram a ficar “complexos” para permitir os relacionamentos

entre entidades. Então, na década de 60 a empresa IBM investiu fortemente em

pesquisas para solucionar estes problemas dos bancos de dados digitais primitivos.

Vários modelos de bancos de dados surgiram nesta época, dentre eles os modelos

hierárquicos e rede. Em junho de 1970, o pesquisador Edgar Frank “Ted” Codd da

IBM, mudou a história dos bancos de dados apresentando o modelo relacional no

artigo intitulado “A Relational Model of Data for Large Shared Data Banks”, onde o

20

autor apresentou uma forma de usuários sem conhecimento técnico armazenarem e

extraírem grandes quantidades de informações de um banco de dados.

Esse artigo foi o grande impulso para a evolução dos bancos de dados, a partir

do artigo de “Ted” Codd que os cientistas aprofundaram a ideia de criar o modelo de

banco de dados relacional.

1.1.2 POR QUE USAR BANCO DE DADOS?

Date (2008) afirma que em suma, um BD tem várias vantagens em relação aos

métodos tradicionais, baseados em papel. São citadas algumas vantagens logo

abaixo:

densidade: Não há necessidade de arquivos de papel, possivelmente

volumosos;

velocidade: A máquina pode obter e atualizar dados com rapidez. Em particular,

consultas podem ser respondidas com mais rapidez sem qualquer necessidade

de pesquisas manuais ou visuais demoradas;

menos trabalho monótono: Grande parte do tédio de manter arquivos à mão é

eliminada. As tarefas mecânicas são sempre feitas com melhor qualidade por

máquinas;

atualidade: Informações precisas e atualizadas estão disponíveis a qualquer

momento;

proteção: Os dados podem ser mais bem protegidos contra perda não

intencional e acesso ilegal;

As vantagens anteriores se aplicam com intensidade ainda maior a um

ambiente multiusuário, no qual o banco de dados provavelmente será muito maior e

mais complexo.

1.1.3 MODELOS DE BANCOS DE DADOS

Segundo Ramakrishnan e Gehrke (2008) o Modelo de banco de dados é uma

descrição dos tipos que estão armazenados em um banco de dados. Por exemplo,

pode informar que o banco armazena informações sobre produtos e que, para cada

produto, são armazenados seu código, preço e descrição. O modelo não informa quais

21

produtos estão armazenados, apenas que tipo de informações contém. Existem

quatro tipos estruturais de SGBDs: hierárquico, redes, relacional e orientado a objeto,

neste trabalho são utilizadas como referência os dois modelos que estão sendo

utilizados que são o modelo relacional e o modelo orientado a objeto.

1.2 MODELO RELACIONAL

Ramakrishnan e Gehrke (2008) afirma que o modelo relacional é um modelo

de dados, adequado a ser o modelo subjacente de um Sistema Gerenciador de Banco

de Dados (SGBD), que se baseia no princípio em que todos os dados estão guardados

em tabelas (relações). Toda sua definição é teórica e baseada na lógica de

predicados e na teoria dos conjuntos. O conceito foi criado por Edgar Frank

Codd em 1970, sendo descrito no artigo "Relational Model of Data for Large Shared

Data Banks". O modelo relacional foi o primeiro modelo de dados descrito

teoricamente, os bancos de dados já existentes passaram a ser conhecidos como

(modelo hierárquico, modelo em rede e modelo de listas invertidas). Modelo relacional

para gerência de bases de dados é um modelo de dados baseado em lógica e

na teoria de conjuntos.

Em definição simplificada, o modelo baseia-se em dois conceitos: conceito de

entidade e relação - Uma entidade é um elemento caracterizado pelos dados que são

recolhidos na sua identificação vulgarmente designado por tabela. Na construção da

tabela identificam-se os dados da entidade.

A atribuição de valores a uma entidade constrói um registro da tabela. A

relação determina o modo como cada registro de cada tabela se associa a registros

de outras tabelas. Historicamente ele é o sucessor do modelo hierárquico e do modelo

em rede. Estas arquiteturas antigas são até hoje utilizadas em alguns data

centers com alto volume de dados, onde a migração é inviabilizada pelo custo que ela

demandaria; existem ainda os novos modelos baseados em orientação ao objeto, que

na maior parte das vezes são encontrados como kits em linguagem formal. Hoje em

dia, os novos sistemas de base de dados são quase exclusivamente do tipo relacional.

Provavelmente o mais importante é poder mudar a estrutura de dados sem

alterações nas aplicações. Modelos relacionais oferecem flexibilidade estrutural, as

aplicações escritas para esse modelo são mais fáceis. Essa mesma flexibilidade

http://pt.wikipedia.org/wiki/Modelo_de_dados

http://pt.wikipedia.org/wiki/Modelo_de_dados

http://pt.wikipedia.org/wiki/Sistema_Gerenciador_de_Banco_de_Dados

http://pt.wikipedia.org/wiki/Sistema_Gerenciador_de_Banco_de_Dados

http://pt.wikipedia.org/wiki/Rela%C3%A7%C3%A3o_(matem%C3%A1tica)

http://pt.wikipedia.org/wiki/L%C3%B3gica_de_predicados

http://pt.wikipedia.org/wiki/L%C3%B3gica_de_predicados

http://pt.wikipedia.org/wiki/Teoria_dos_conjuntos

http://pt.wikipedia.org/wiki/Edgar_Frank_Codd

http://pt.wikipedia.org/wiki/Edgar_Frank_Codd

http://pt.wikipedia.org/wiki/1970

http://pt.wikipedia.org/wiki/Modelo_hier%C3%A1rquico

http://pt.wikipedia.org/wiki/Modelo_em_rede

http://pt.wikipedia.org/w/index.php?title=Modelo_de_listas_invertidas&action=edit&redlink=1

http://pt.wikipedia.org/wiki/L%C3%B3gica

http://pt.wikipedia.org/wiki/Teoria_de_conjuntos

http://pt.wikipedia.org/wiki/Modelo_hier%C3%A1rquico



http://pt.wikipedia.org/wiki/Data_center

http://pt.wikipedia.org/wiki/Data_center

http://pt.wikipedia.org/wiki/Orienta%C3%A7%C3%A3o_ao_objeto

22

estrutural permite-lhe recuperar conjuntos de dados que você não tinha previsto

precisar.

Agora uma breve descrição dos objetos que compõem um banco de dados do

tipo relacional, segundo Ramakrishnan e Gehrke (2008) :

tabelas: São os objetos que contém os tipos de dados e os dados reais;

Colunas ou Campos: Partes das tabelas que armazenam os dados

devem receber um tipo de dados e ter um nome único;

tipos de dados: Há vários tipos de dados para serem utilizados como:

caractere, número, data. Um único tipo de dados é atribuído a uma

coluna ou dentro de uma tabela;

procedimentos armazenados (storeds procedures): São macros em que

o código Transavt-Sql pode ser escrito e armazenado sob um nome;

gatilhos (triggers): Asseguram que regras de negócio e de integridade

sejam impostas ao banco de dados;

regras (rules): Atribuídas a colunas de modo que os dados que estão

sendo inseridos devem se adaptar aos padrões definidos;

chaves primárias ou Primary Key (PK): Embora não sejam objetos em

si, as chaves são essenciais para os bancos de dados relacionais.

Promove as características de unicidade das linhas, proporcionando

uma maneira de identificar de forma única cada item que você queira

armazenar;

chaves estrangeiras ou Foreign Key (FK): São colunas que fazem

referências as chaves primárias de outras tabelas;

índices: Podem ajudar os dados de modo que as consultas executem

mais rápido.

1.2.1 BANCOS DE DADOS ORIENTADOS A OBJETOS (BDOO)

Segundo Nassu e Setzer (1999) um Banco de Dados Orientado a Objeto é

basicamente um sistema em que a unidade de armazenamento é o objeto, utilizando

assim, o mesmo conceito das linguagens de programação orientadas a objetos.

Ainda segundo o autor a diferença fundamental é a persistência dos objetos,

ou seja, os objetos continuam a existir mesmo após o encerramento do programa.

23

De uma forma bem simples pode-se dizer que Banco Orientado a Objetos é

nada mais que a junção entre conceitos de OO com conceitos de SGBD, ou seja, ele

é todo baseado nos paradigmas da OO unido aos objetivos básicos dos SGBD.

Como podemos ver na Erro! Fonte de referência não encontrada. uma

estrutura de um banco de dados onde se vê armazenamento e organização dos dados

em um computador de modo que possam ser usados eficientemente, facilitando sua

buscas e modificação.

Figura 1.2 Estrutura de um banco de dados Fonte: Machado, 2010

Para Ramakrishnan e Gehrke (1999) os sistemas de banco de dados

orientados a objetos foram propostos como uma alternativa aos sistemas relacionais

e se destinam aos domínios de aplicação onde os objetos complexos desempenham

um papel fundamental.

A estratégia é fortemente influenciada pelas linguagens de programação

orientadas a objetos e pode ser entendida como uma tentativa de acrescentar

24

funcionalidade de SGBD em um ambiente de linguagem de programação. O Object

Database Management Group (ODMG) desenvolveu um modelo e uma linguagem

padrão, Object Data Model (ODM) e Object Query Language (OQL) respectivamente,

que são os equivalentes do padrão SQL para sistemas de banco de dados relacionais.

1.3 SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS (SGDB)

Ramakrishnan e Gehrke (2008), afirmam que a quantidade de informações que

estão disponíveis está literalmente explodindo, e o valor dos dados como um ativo

organizacional é amplamente reconhecido. Para obter a maior parte de seus grandes

e complexos conjuntos de dados, os usuários necessitam de ferramentas que

simplifiquem as tarefas de gerenciamento dos dados e a extração de informações

úteis de forma oportuna.

Caso contrário, os dados podem se tornar um passivo, cujo custo de aquisição

e gerenciamento excede em muito o valor por ele produzido. Um SGDB é um software

projetado para auxiliar a manutenção e utilização de vastos conjuntos de dados. A

necessidade de tais sistemas, assim como seu uso, tem crescido rapidamente, o uso

de um SGDB tem diversas vantagens sendo elas:

Independência de Dados: Os programas aplicativos não devem, idealmente,

ser expostos aos detalhes de representação e armazenamento de dados. O SGDB

provê uma visão abstrata dos dados que oculta tais detalhes.

Acesso Eficiente aos Dados: Um SGDB utiliza uma variedade de técnicas

sofisticadas para armazenar e recuperar dados eficientemente. Este recurso é

especialmente importante se os dados são armazenados em dispositivos de

armazenamento externo.

Integridade e Segurança dos Dados: Se os dados são sempre acessados por

meio do SGDB, ele pode forçar restrições de integridade. Por exemplo, antes de inserir

informações sobre o salário de um funcionário, o SGDB pode verificar se o orçamento

do departamento não está se excedendo. Além disso, ele pode forçar controles de

acesso que governam quais dados estão visíveis a diferentes classes de usuários.

Administração de Dados: Quando diversos usuários compartilham dados,

centralizar a administração dos dados pode oferecer melhorias significativas.

Profissionais experientes que compreendem a natureza dos dados sendo

gerenciados, e como os diferentes grupos de usuários utilizam, podem ser

25

responsáveis por organizar a representação dos dados para minimizar a redundância

e para realizar as sintonizações finas do armazenamento dos dados para garantir uma

eficiente recuperação.

Acesso Concorrente e Recuperação de Falha: Um SGDB planeja o acesso

concorrente aos dados de maneira tal que os usuários podem achar que os dados

estão sendo acessados por apenas um único usuário de cada vez. Além disso, o

SGDB protege os usuários dos efeitos e falhas do sistema.

Tempo Reduzido de Desenvolvimento de Aplicativo: Obviamente, o SGDB

suporta funções importantes que são comuns a vários aplicativos que acessam os

dados no SGDB. Isso em conjunto com uma interface de alto nível aos dados facilita

o desenvolvimento rápido de aplicativos. Os aplicativos de SGDB tendem a ser mais

robustos do que os aplicativos similares independentes porque muitas tarefas

importantes são tratadas pelo SGDB (e não precisam ser depuradas e testadas no

aplicativo.).

1.3.1 SGBDs MAIS UTILIZADOS

São vários os tipos de SGBDs disponíveis no mercado, sendo eles pagos ou

gratuitos.

Ramakrisshnan e Gehrke (2008) relatam que os SGBDs usam uma linguagem

para criar a base de dados, sendo que a mais utilizada é a SQL.

Em uma breve pesquisa realizada na internet podemos encontrar alguns dos

SGBDs mais utilizados:

SQLServer: Um dos maiores do mundo, sob licença da Microsoft;

FirebirdSQL: Possui código fonte aberto e roda na maioria dos sistemas

Unix;

Microsoft Access: É um Sistema Gerenciador de Banco de Dados que

acompanha o pacote Office da Microsoft. Este SGBD tem poucas

atribuições profissionais, sendo mais usado para aprendizagem, devido

à sua interface amigável;

mSQL: Sistema pequeno e que trabalha mais com o uso eficiente da

memória. Foi criado pela Hughes Technologies Pty Ltd.

MySQL: Trata-se de um software livre, com código fonte aberto;

26

PostgreSQL: Desenvolvido como projeto de código aberto.

Oracle: O Oracle é o principal banco de dados atualmente, sendo

responsável pelo armazenamento de boa parte das informações das

principais organizações ao redor do mundo. Oracle é um sistema de banco

de dados proprietário e, portanto, tem que ser adquirido com uma licença

comercial antes que possa ser usado.

1.4 CONSULTAS

As consultas são utilizadas para ver, alterar e analisar dados de diferentes

maneiras.

Segundo Nassu e Setzer (1999), o acesso a dados armazenados é feito

basicamente de duas formas. Uma é pela linguagem de programação, da qual utiliza

os OID dos objetos e a outra é por linguagem de consulta, em geral derivadas do SQL.

Ainda segundo Ramakrishnan e Gehrke (2003), toda consulta deve ter uma

cláusula SELECT, que especifica as colunas a serem mantidas no resultado, e uma

cláusula FROM, que especifica um produto cartesiano de tabelas. A cláusula opcional

WHERE especifica as condições de seleção nas tabelas mencionadas na cláusula

FROM.

Formato básico de uma consulta SQL:

SELECT lista-seleção

FROM lista-from

WHERE qualificação

Para Nassu e Setzer (1999) o acesso aos dados por meio de linguagem de

programação vem tentar resolver uma das principais críticas que os SGBD relacionais

sofrem que é o chamado “não casamento de impedâncias”.

Ainda segundo o autor, quando se utiliza uma linguagem de programação

qualquer para o desenvolvimento de uma aplicação, é necessário reestruturá-la para

que se possa interagir com as linguagens de consulta de banco de dados relacionais,

já que a única estrutura do modelo relacional é a relação. Isto também é valido para o

contrário, ou seja, assim que se obtém o resultado de uma consulta por meio da

https://pt.wikipedia.org/wiki/C%C3%B3digo_aberto

27

linguagem de consulta, é necessária uma adaptação dos dados para a estrutura da

linguagem de programação.

Quando se usa uma linguagem e um banco de dados de uma única estrutura,

este trabalho é poupado, implicando em diminuição de código e de tempo de

execução, além de possibilitar o compartilhamento de estruturas entre aplicações.

28

2 ANÁLISE DOS BANCOS DE DADOS

Neste capitulo serão apresentados os dois bancos de dados utilizados,

relatando sobre suas plataformas, versões e como foram criados.

2.1 BANCO DE DADOS MYSQL

Segundo o site infoescola, o MySQL surgiu a partir da necessidade da equipe

dos desenvolvedores David Axmark e Allan Larsson que criou o SGBD, de utilizar

algum mecanismo que permitisse a conexão de tabelas criadas na linguagem SQL

para um determinado fim. A princípio, o grupo utilizou o mSQL, mas logo se notou que

esta ferramenta não era rápida o suficiente para atender às necessidades do projeto.

O jeito foi criar uma solução própria.

Por volta de 1979 na companhia suíça TcX, nascia o MySQL criado por Michael

Widenius.

Michael desenvolveu um banco de dados chamado UNIREG, sendo rescrito

em várias linguagens desde então. Em 1994, a empresa TcX começou o

desenvolvimento de aplicações baseadas na Web, tendo como base o banco

UNIREG, porém esse banco possuía muito "overhead" para obter sucesso em uma

aplicação para geração de páginas dinâmicas na Web. Então a empresa TcX

começou a procurar por outro banco o mSQL, uma ferramenta baseada em SQL, mas

com características pobres, não possuindo por exemplo suporte a índices, e com

desempenho inferior ao UNIREG. Foi então que o desenvolvedor do banco UNIREG

contatou David Hughes criador do mSQL (para saber do interesse dele em unir os

dois bancos).

Sendo positivo o interesse de David, a empresa TcX resolveu desenvolver um

novo banco, mas mantendo ao máximo a compatibilidade com mSQL. Os

desenvolvedores da empresa TcX foram espertos o suficiente para não reinventar o

que já estava bem feito, eles construíram um servidor baseado na estrutura que já

estava montada do UNIREG e utilizaram um grande número de utilitários escritos para

mSQL e fizeram API's para o novo servidor praticamente iguais ao mSQL.

Como resultado usuários do mSQL que decidissem mudar para o novo servidor

da TcX, teriam apenas que fazer pequenas e simples mudanças nos códigos

existentes.

29

O site infoescola relata que em maio de 1995, definitivamente, a primeira

versão do MySQL foi lançada. Um dos parceiros da TcX sugeriu a distribuição do

servidor na Internet, o objetivo disso era a utilização de um modelo pioneiro

desenvolvido por Aladdin Peter Deutsche.

O resultado foi uma maior flexibilidade em sem "copyright", que fez do MySQL

mais difundido gratuitamente do que mSQL.

O MySql está em constante desenvolvimento. Embora seja um dos bancos de

dados mais utilizados no mundo, ainda se encontram alguns bugs, que são resolvidos

com atualizações frequentes.

O MySQL é protegido por uma licença de software livre. Este banco de dados

é muito utilizado para sites e programas de cadastro de lojas.

Algumas das vantagens do Mysql em relação a outros bancos de dados do

mesmo porte: ele tem uma maior facilidade para programação, tem funções mais

simples, pode ser totalmente modificado, entre outras.

Alguns competidores do MySQL são: Oracle, PostgreSQL, SQLServer e

Firebird. Entre estes, o único banco de dados de grande porte totalmente free e

com código fonte aberto é o MySQL.

Por ter código aberto, facilita sua edição para as necessidades do usuário.

2.1.1 VERSÃO UTILIZADA NO PROJETO

Para a realização do trabalho foi utilizado o MySQL Workbench 6.3, lançado

em (2016-06-13).

Em relação ás versões anteriores estão nova versão tem como aprimoramento

a migração de dados rápida. Esta é outra maneira de transferir dados de um servidor

MySQL para outro durante a execução de uma migração, e complementa as soluções

existentes. A premissa é usar um script gerado no servidor de origem para criar um

despejo que você passa para o computador de destino para executar a importação.

Isso evita a necessidade de tráfego de todos os dados no MySQL Workbench, ou ter

uma conexão de rede permanente entre os servidores. Em vez disso, o despejo e

restauração é executada à velocidade máxima usando a chamada de dados de carga

para a importação MySQL. O assistente de migração cria automaticamente todos os

scripts necessários para todas as plataformas e servidores suportados. O script

30

gerado cria um arquivo Zip autossuficiente que devem ser copiados para o servidor

de destino. Você descompactá-lo e executar o script fornecido para executar a

importação de dados.

A Erro! Fonte de referência não encontrada..1 mostra a interface do usuário

quando ele abre o MySQL, é nesta área que o usuário irá construir suas tabelas e

popular seu BD

Figura 2.1 Tabela do usuário no MySQL Fonte: Elaborado pelos autores, 2016

2.2 BANCO DE DADOS POSTGRESQL

Schnaitter e Gavin (2012), afirmam que o PostegreSQL é um SGDB objeto-

relacional de código fonte aberto, descendente do sistema Postgres desenvolvido pelo

professor Michael Stonebraker. Seu nome “Postegres” é derivado do bancos de dados

relacional pioneiro em estudos também desenvolvido por Stonebraker na universidade

de Califórnia. O PostegreSQL é compatível com diversos aspectos do SQL:2003 e

oferece recursos como:

Consultas complexas;

Chaves estrangeiras;

Triggers (Códigos de SQL armazenados dentro do BD);

Views;

31

Integridade transacional;

Pesquisa de texto;

Replicação de dados limitada.

Outro aspecto notável do PostgreSQL é que, semelhante com o MySQL, é um

dos dois sistemas mais utilizados de BD relacional de código fonte aberto, a licença

desse BD é a licença Berkeley Software Distribution (BSD) que dá permissão a

qualquer um para usar, modificar de distribuir o código e a documentação para

qualquer finalidade gratuitamente.

Segundo Schnaiter e Gavin (2012), o PostgreSQL pode ser executado

praticamente em todas as plataformas operacionais do tipo Unix, Linus e Apple

Macintosh OSX, as versões anteriores desse BD podem ser executadas no Microsoft

Windows, no ambiente Cygwin que oferece uma emulação para Linux no Windows.

Atualmente o PostgreSQL é usado para desenvolver várias aplicações de

pesquisas e produção, dentre elas estão o sistema PostGIS para informações

geográficas e também é considerado uma ferramenta educacional em várias

universidades, um sistema que evolui por meio de contribuições de uma comunidade

com 1.000 desenvolvedores.

2.2.1 INTERFACES COM O USUÁRIO

A distribuição padrão vem com ferramentas da linha de comandos para

administrar o BD, porém existe grande quantidade de ferramentas comercias e

gráficas de administração e projeto de código fonte aberto, os desenvolvedores de

software também podem acessar o PostgreSQL por meio de um conjunto abrangente

de interfaces de programação.

A figura 2.2 abaixo mostra a interface do pgAdmin4, ferramenta utilizada para

a administração do PostgreSQL, pois ela permite fazer todas as tarefas necessárias

de administração do banco de dados.

32

Figura 2.2 Interface do pgAdmin4 Fonte: Elaborado pelos autores, 2016.

2.2.2 INTERFACES DE TERMINAL INTERATIVO

O principal cliente de terminal interativo é a psql, nomeado em função da Shell

Unix e que permite a execução de comandos SQL no servidor, além de várias outras

operações. Alguns de seus recursos mais utilizados são:

Variáveis: A psql oferece recursos de substituição de variáveis;

Interpolação de SQL: O usuário pode substituir variáveis psql em

instruções SQL normais, colocando um caractere de dois pontos na

frente do nome da variável;

Edição da linha de comando: A psql usa a biblioteca para realizar a

edição de linha de forma conveniente, com suporte para conclusão.

2.2.3 INTERFACES DE LINGUAGEM DE PROGRAMAÇÃO

Oferecendo interfaces nativas para ODBC e JDBC para a maioria das

linguagens de programação incluindo C, C++, PHP, Perl, Tcl/Tk. ECPG, Python e

Ruby.

Sua biblioteca admite execução síncrona e assíncrona de comandos SQL e

instruções preparadas com interface reentrante e seguras para thread, os parâmetros

33

de conexão da biblioteca podem ser configurados de várias maneiras flexíveis, como

definir variáveis de ambientes, inserir configurações em um arquivo local e criar

entradas de um servidor.

2.2.4 TIPOS NO POSTGRESQL

Abraham Silberschats relata que o PostgreSQL possui suporte para vários tipos

fora do padrão, úteis somente para domínios de aplicação específicos. Os usuários

podem definir novos tipos com o comando create type, isso inclui novos tipos básicos

de baixo nível.

Os tipos de PostgreSQL podem ser das seguintes categorias:

Tipos básicos: são conhecidos como tipos de dados abstratos, são os

módulos que encapsulam estado e um conjunto de operações, eles são

implementados abaixo do nível SQL, normalmente em uma linguagem

como C;

Tipos compostos: correspondem a linhas de tabela, eles são uma lista

de nomes de campo e seus respectivos tipos básicos, esse tipo é criado

implicitamente sempre que uma tabela é criada;

Domínios: é definido ao associar um tipo básico com uma restrição a

qual os valores do tipo devem atender. Um domínio também pode ter um

valor padrão opcional cujo significado é semelhante ao valor padrão de

uma coluna de uma tabela comum;

Tipos enumerados: um tipo enumerado é basicamente uma lista fixa de

valores nomeados, no PostgreSQL é possível converter os tipos

enumerados para a representação textual de seus nomes;

34

3 DESENVOLVIMENTO DO TRABALHO Neste capitulo será apresentado o desenvolvimento do projeto com a

metodologia utilizada, a ferramenta de avaliação de desempenho utilizada nos dois

bancos de dados e sua instalação, o hardware da máquina utilizada e a instalação

dos bancos.

3.1 METODOLOGIA

Para a realização desta pesquisa, elaborou-se um banco de dados que simula

de maneira simplificada um sistema de vendas.

A Figura 3.1 exibe este modelo, mostrando como as tabelas se relacionam bem

como as respectivas colunas e, consequentemente, os tipos delas. Assim, pode-se

verificar como o banco de dados utilizado neste projeto foi elaborado fisicamente.

Figura 3.1 Modelo de dados Relacional Fonte: Elaborado pelos autores, 2016.

35

O modelo de dados representado na Figura 3.1, representa um sistema de vendas de

uma maneira simplificada. Neste modelo, clientes e produtos (com suas respectivas

marcas) podem ser cadastrados, ambos se relacionando na tabela de vendas que

armazena quem comprou o que, quando e em qual quantidade. Além disso, a tabela

relatório, que não se relaciona com nenhuma outra, existe apenas para receber os

dados gerados dos inserts com join.

3.2 Geração de dados

Para popular as tabelas de cliente, produto e marcas, foram inseridas

manualmente 20 registros em cada uma das tabelas. As figuras abaixo representam

esses registros:

Figure 3.2 -TABELA DE CLIENTES. FONTE: Elaborado pelos autores, 2016.

36

Figure 3.3 -TABELA DE MARCAS. FONTE: Elaborado pelos autores, 2016.

Figure 3.4 -TABELA DE PRODUTOS. FONTE: Elaborado pelos autores, 2016.

Para popular a tabela de vendas foi utilizado um algoritmo implementado em

linguagem Java que gera automaticamente um milhão de registros com dados

aleatórios: um cliente aleatório comprando um produto aleatório em uma quantidade

37

aleatória em uma data aleatória. A chave primária dessas vendas é o único dado não

gerado aleatoriamente pois é próprio SGBD que define automaticamente seu valor.

Esse algoritmo foi executado uma única vez e os dados gerados foram

inseridos em uma tabela chamada "vendas_orig". Essa tabela tem exatamente a

mesma estrutura da tabela "vendas" e foi usada com o propósito de armazenar os

dados primeiramente gerados pelo algoritmo em Java para eventuais recuperações

de dados que precisaram ser feitos durante as avaliações de desempenho.

Na implementação do algoritmo, foi gerado uma ferramenta de teste que,

depois que qualquer execução que altere os registros da tabela de vendas (um

comando Update ou Delete, por exemplo), essa tabela é atualizada com os valores

iniciais recebendo uma cópia de todos os registros da tabela "vendas_orig".

Figure 3.5 -TABELA DE VENDAS ORIG. FONTE: Elaborado pelos autores, 2016.

A tabela "vendas_orig" garante a integridade dos dados, mantendo-os

exatamente como foram gerados pelo algoritmo. Nenhuma requisição SQL realizadas

neste trabalho foi executada na tabela "vendas_orig", e sim, na tabela "vendas", que

possui sempre uma cópia exata dos registros da tabela "vendas_orig" antes de

qualquer nova execução.

38

Figure 3.6 -TABELA DE VENDAS. FONTE: Elaborado pelos autores, 2016.

3.3 Hardware utilizado

O hardware utilizado tanto como servidor do banco de dados, quanto o cliente

que faz as requisições de avaliação, foi um computador com as seguintes

características:

• microcomputador Portátil da marca Dell, modelo inspiron 5000;

• sistema operacional Windows 10 64 bits;

• memória RAM de 4GB DDR3 1600;

• processador intel ® core ™ i5-4210U @ 1.70GHz 2.40GHZ;

• disco rígido de 1TB 5400 RPM.

3.4 Ferramenta Apache JMeter

Para realizar as Avaliação de Desempenho de tempo de resposta, utilizou-se a

ferramenta Apache JMeter 3.0.

39

A ferramenta JMeter desktop foi desenvolvida para a realização de testes de

desempenho e estresse em aplicações cliente/servidor, tais como aplicações Web

(Apache JMeter, 2013).

O JMeter foi desenvolvido utilizando a linguagem Java e licenciada sob os

termos da “Apache License, Version 2.0”. Esta ferramenta foi primeiramente utilizada

para realizar testes em aplicações web, mas tem expandido suas funcionalidades,

podendo realizar Avaliações em Bancos de Dados via JDBC, LDAP, JMS e E-mail –

POP3 e IMAP (Apache JMeter, 2013).

Como o JMeter é desenvolvido 100% em Java, é possível rodá-lo em qualquer

sistema operacional que tenha uma implementação Java compatível (FAPEG, 2013).

3.4.1 Instalação do Apache JMeter

Um pré-requisito para a instalação da ferramenta JMeter é a instalação da JVM

1.6 ou versão mais nova.

Para instalar o JMeter o Java deve estar instalado. Caso não esteja, é

necessário realizar o download do JDK no site da Oracle e fazer a sua instalação.

Além disso é necessário mapiar o JAVA_HOME.

A versão mais recente da ferramenta JMeter pode ser encontrada no site

(http://jmeter.apache.org/). Para a sua utilização, é necessário descompactar o

arquivo no diretório em que será instalado (FAPEG, 2013). A Figura 3.7 apresenta a

interface do JMeter.

40

Figura 3.7 Interface JMeter. Fonte: Elaborados pelos autores, 2016.

Para a realização deste trabalho, o JMeter foi instalado com as configurações

padrões.

3.5 INSTALAÇÃO E CONFIGURAÇÃO DOS BANCOS

Para a realização deste trabalho de Avaliação de desempenho, os bancos de

dados MySQL e PostgreSQL, foram instalados com suas configurações padrões, sem

nenhuma alteração.

41

4 AVALIAÇÃO DE DESEMPENHO E RESULTADOS

Neste capitulo serão apresentados os resultados das avalições de desempenho

realizadas em ambos SGBD’s. Para garantir a isonomia das avaliações de

desempenho, a mesma quantidade e conteúdo de registros foram inseridos antes que

qualquer avaliação. Esses registros são:

20 marcas;

20 produtos, cada um associado à uma marca diferente;

20 clientes;

1.000.000 de vendas aleatórias (um cliente aleatório comprando um

produto aleatório numa quantidade aleatória numa data aleatória),

geradas automaticamente por um algoritmo de inserção de dados feito

em Java;

A tabela “relatorio” não contém registros.

Para esse conjunto de dados inseridos previamente nos bancos, dá-se o nome

de “estado original do banco de dados”. Todos os testes foram executados nos bancos

em seus estados originais, ou seja, toda vez que algum comando SQL modifica algum

dado do banco, voltava-se o banco de dados para seu estado original antes da

execução da próxima avaliação de desempenho.

4.1 AVALIAÇÃO DE DESEMPENHO COM SELECT

Esta avaliação de desempenho faz um select na tabela de vendas retornando

um milhão de registros. Para fazer esta requisição, tanto para o SGBD MySQL quanto

para o PostgreSQL, foi usado o seguinte comando SQL no jMeter:

SELECT * FROM vendas;

Na Figura 4.1 pode-se visualizar a comparação do tempo de resposta de cada

SGBD em milissegundos e, também, o seu intervalo de confiança.

42

Figura 4. 1 Avaliação de Desempenho com Select Fonte: Elaborado pelos autores, 2016.

4.2 AVALIAÇÃO DE DESEMPENHO COM SELECT JOIN

Para realizar esta avaliação de desempenho foi executado um Select que faz a

junção da tabela vendas com a tabela de clientes, produtos e marcas. O resultado

deste comando exibe, respectivamente, o id da venda, o nome do cliente, o nome do

produto, o nome da marca, a quantidade vendida e a data da venda, retornando

também um milhão de registros.

Para fazer essa requisição no MySQL, o seguinte comando SQL foi executado

no jMeter:

SELECT vendas.id, cliente.nome, produto.nome, marca.nome,

vendas.quantidade, vendas.datavenda

FROM vendas

JOIN cliente ON cliente.id = vendas.idcli

JOIN produto ON produto.id = vendas.idprod

JOIN marca ON marca.id = produto.idmarca

ORDER BY vendas.id;

Para fazer esta mesma requisição no PostgreSQL, o seguinte comando SQL

foi executado no jMeter:

SELECT vendas."ID", cliente."NOME", produto."NOME",

marca."NOME", vendas."QUANTIDADE", vendas."DATAVENDA"

FROM vendas

3346 3326

0

500

1000

1500

2000

2500

3000

3500

4000

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

43

JOIN cliente ON (cliente."ID" = vendas."IDCLI")

JOIN produto ON (produto."ID" = vendas."IDPRODUTO")

JOIN marca ON (marca."ID" = produto."IDMARCA")

ORDER BY vendas."ID";

Na Figura 4.2 pode-se visualizar a comparação do tempo de resposta de

cada SGBD em milissegundos e, também, o seu intervalo de confiança.

Figura 4.2 Avaliação de Desempenho com Select Join. Fonte: Elaborado pelos autores, 2016.

4.3 AVALIAÇÃO DE DESEMPENHO COM SELECT, JOIN E WHERE

Esta Avaliação de Desempenho foi realizada com um comando que exibe os

mesmos campos citados na Avaliação de Desempenho anterior, porém retorna

apenas os resultados cujo o id do produto é igual a 10. Neste caso, a requisição

retorna 50442 registros.


no jMeter:



FROM vendas




WHERE vendas.idprod = 10

ORDER BY vendas.id;

13842

5407

0

2000

4000

6000

8000

10000

12000

14000

16000

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

44

Para fazer esta mesma requisição no PostgreSQL, o seguinte comando SQL foi executado no jMeter:



FROM vendas




WHERE vendas."IDPRODUTO" = 10




Figura 4. 3 Avaliação de Desempenho com Select, Join e Where Fonte: Elaborado pelos autores, 2016.

4.4 AVALIAÇÃO DE DESEMPENHO COM SELECT, JOIN, WHERE, SUM

Nesta Avaliação de Desempenho foi executado um comando Select que exibe

o nome do produto junto com sua respectiva marca e a soma de todas as vendas

efetuadas de cada produto no ano de 2016.


no jMeter:

510

6172

0

1000

2000

3000

4000

5000

6000

7000

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

45

SELECT produto.nome, marca.nome, SUM(vendas.quantidade)

FROM vendas



WHERE vendas.datavenda BETWEEN '2016-01-01' AND '2016-12-31'

GROUP BY vendas.idprod

ORDER BY produto.nome;


SELECT produto."NOME", marca."NOME", SUM(vendas."QUANTIDADE")

FROM vendas



WHERE vendas."DATAVENDA" BETWEEN '2016-01-01' AND '2016-12-31'

GROUP BY produto."NOME", marca."NOME"

ORDER BY produto."NOME";



Figura 4. 4 Avaliação de Desempenho Select Com Join, Where e Sum. Fonte: Eladorado pelos autores, 2016.

4.5 AVALIAÇÃO DE DESEMPENHO COM INSERT

Nesta Avaliação de Desempenho foi executado um comando insert que insere

um registro na tabela vendas.

2440

1407

0

500

1000

1500

2000

2500

3000

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

46

Para fazer essa requisição no MySQL, o seguinte comando SQL foi executado no

jMeter:

INSERT INTO VENDAS (IDPROD, IDCLI, QUANTIDADE,

DATAVENDA)VALUES (19, 6, 8, '2016-06-12');


INSERT INTO VENDAS ("IDPRODUTO", "IDCLI", "QUANTIDADE",

"DATAVENDA") VALUES (19, 6, 8, '2016-06-12');



Figura 4. 5 Avaliação de Desempenho com Insert Fonte: Elaborado pelos autores, 2016.

4.6 AVALIAÇÃO DE DESEMPENHO DE INSERT COM JOIN

Para a realização desta Avaliação de Desempenho foi executado um Insert que

pega o resultado do Select executado na Avaliação de Desempenho 4.2 e insere os

um milhão de registros retornados na tabela “relatorio”.

49

974

0

200

400

600

800

1000

1200

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

47


no jMeter:

INSERT INTO relatorio



FROM vendas




ORDER BY vendas.id;





FROM vendas







Figura 4. 6 Avaliação de Desempenho de Insert com Join. Fonte: Elaborado pelos autores, 2016.

12685

16535

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

48

4.7 AVALIAÇÃO DE DESEMPENHO INSERT COM JOIN e WHERE

Nesta Avaliação de Desempenho o comando executado faz a mesma

requisição da Avaliação de Desempenho anterior, com a diferença da cláusula where

que limita os resultados apenas às vendas feitas pelo cliente chamado Guilherme

Andrade. O resultado dessa requisição é a inserção de 49.915 registros na tabela

“relatório”.


no jMeter:




FROM vendas




WHERE cliente.nome = 'Guilherme Andrade'

ORDER BY vendas.datavenda;





FROM vendas




WHERE cliente."NOME" = 'Guilherme Andrade'




49

Figura 4. 7 Avaliação de Desempenho Insert Com Join e Where. Fonte: Elaborado pelos autores, 2016.

4.8 AVALIAÇÃO DE DESEMPENHO DE DELETE

Para esta Avaliação de Desempenho foi executado um comando que delete

que exclui todos os um milhão de registros da tabela vendas.


no jMeter:

DELETE FROM vendas;


DELETE FROM VENDAS;



774

1459

0

200

400

600

800

1000

1200

1400

1600

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

50

Figura 4. 8 Avaliação de Desempenho de Delete Fonte: Elaborado pelos autores, 2016.

4.9 AVALIAÇÃO DE DESEMPENHO DE DELETE COM WHERE

Nesta Avaliação de Desempenho fo executado um comando delete que exclui

apenas as vendas de Caixas de Som feitas para o cliente Carlos Oliveira. Esta

requisição exclui 2.506 registros da tabela vendas.


no jMeter:

DELETE vendas

FROM vendas

INNER JOIN cliente ON vendas.idcli = cliente.id

INNER JOIN produto ON vendas.idprod = cliente.id

WHERE cliente.nome = 'Carlos Oliveira'

AND produto.nome = 'Caixas de Som';

Para fazer esta mesma requisição no PostgreSQL, o seguinte comando SQL foi executado no jMeter: DELETE FROM vendas

USING cliente, produto

WHERE vendas."IDCLI" = cliente."ID"

AND vendas."IDPRODUTO" = produto."ID"

73

3520

0

500

1000

1500

2000

2500

3000

3500

4000

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

51

AND cliente."NOME" = 'Carlos Oliveira'

AND produto."NOME" = 'Caixas de Som';



Figura 4. 9 Avaliação de Desempenho de Delete com Where. Fonte: Elaborado pelos autores, 2016.

4. 10 AVALIAÇÃO DE DESEMPENHO UPDATE

Para a realização desta Avaliação de Desempenho foi executado um comando

update que atualiza todos os um milhão de registros da tabela vendas, alterando todos

os campos do registro, exceto a sua chave primária.


no jMeter:

UPDATE vendas SET idproduto = 2, idcli = 12, quantidade =

50, datavenda = '2016-09-07';

Para fazer esta mesma requisição no PostgreSQL, o seguinte comando SQL foi executado no jMeter: UPDATE VENDAS SET "IDPRODUTO"=2, "IDCLI"=12, "QUANTIDADE"=50,

"DATAVENDA" = '2016-09-07';

296

1294

0

200

400

600

800

1000

1200

1400

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

52



Figura 4. 10 Avaliação de Desempenho Update Fonte: Elaborado pelos autores, 2016.

4.11 AVALIAÇÃO DE DESEMPENHO UPDATE COM WHERE

Nesta Avaliação de Desempenho foi executado um comando update que

atualiza todos os um milhão de registros da tabela vendas, alterando todos os campos

do registro, exceto a sua chave primária. Para atender às condições da cláusula

where, o banco de dados precisa consultar as tabelas de cliente e produto.


no jMeter:

UPDATE vendas, cliente, produto SET vendas.idcli = cliente.id,

vendas.idprod = produto.id, vendas.datavenda = '2016-07-15'

WHERE cliente.nome = 'Marina Rocha' AND produto.nome =

'Microondas';

3066

40264

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

53

Para fazer esta mesma requisição no PostgreSQL, o seguinte comando SQL

foi executado no jMeter:

UPDATE vendas

SET "IDCLI" = cliente."ID", "IDPRODUTO" = produto."ID",

"DATAVENDA" = '2011-03-20'FROM vendas AS v JOIN cliente ON

cliente."ID" = v."IDCLI" JOIN produto ON produto."ID" =

v."IDPRODUTO" WHERE cliente."NOME" = 'Marina Rocha' AND

produto."NOME" = 'Microondas';



Figura 4. 11 Avaliação de Desempenho Update Com Join e Where Fonte: Elaborado pelos autores, 2016.

16132

2139489

0

500000

1000000

1500000

2000000

2500000

SGBDs

Tem

po

Méd

io d

e R

esp

ost

a (m

iliss

egu

nd

os)

MySQL

PostgreSQL

54

CONSIDERAÇÕES FINAIS

As avaliações de desempenho realizadas neste trabalho objetivaram analisar o

tempo de resposta de cada um dos SGBD’s na realização da mesma tarefa. De todas

as avaliações de desempenho realizadas, alguns merecem destaque pela

considerável diferença de tempo de resposta entre os SGBDs.

O primeiro é o SELECT com JOIN (Figura 4.2) onde o PostgreSQL foi mais

eficiente realizando a requisição de Avaliação de Desempenho com 5407

milissegundos a menos do que o MySQL.

Já na Avaliação de Desempenho que adiciona uma cláusula WHERE a esse

mesmo SELECT com JOIN (Figura 4.3), a situação se inverte. Enquanto que o MySQL

realiza a requisição em 510 milissegundos, o PostgreSQL demora 6172 milissegundos

para realizar a mesma tarefa.

Na Avaliação de Desempenho do INSERT com JOIN (Figura 4.6) o MySQL

executou a tarefa 3950 milissegundos mais rápido que o PostgreSQL. No DELETE

simples (Figura 4.8), enquanto que o MySQL excluiu todos os um milhão de registros

da tabela instantaneamente (73 milissegundos), o PostgreSQL demorou 3520

segundos.

Contudo, as maiores diferenças são encontradas nas Avaliação de

Desempenho com UPDATE. Na Avaliação de Desempenho de UPDATE simples

(Figura 4.10), o PostgreSQL demorou 37198 milissegundos a mais que o MySQL para

atualizar os um milhão de registros da tabela vendas. Quando a atualização deste

mesmo um milhão de registros precisava consultar as tabelas de produto e cliente

para atender a cláusula WHERE, a diferença do tempo de resposta entre os SGBDs

foi a mais alta constatada pelas Avaliações de Desempenhos: O MySQL completou a

tarefa em 16132 milissegundos enquanto que o PostgreSQL levou 2139489

milissegundos para realizar a requisição.

Fazendo-se uma análise dos tempos de resposta separados por DML (Insert,

Update, Delete, Select), obtemos estes dados representados na tabela abaixo:

Tabela1 - Avaliação de Desempenho com Selects

Analise PostgreSQL MySQL

Select simples 3326 ms 3346 ms

Select com Join 5407 ms 13842 ms

55

Select com join e Where 6172 ms 510 ms

Select com Join, Where e Sum

1407 ms 2440 ms

Fonte: Elaborado pelos autores, 2016.

Tabela 2 - Avaliação de Desempenho com Inserts


Insert simples 974 ms 49 ms

Insert com Join 16535 ms 12685 ms

Insert com join e Where 1458 ms 774 ms Fonte: Elaborado pelos autores, 2016.

Tabela 3 - Avaliação de Desempenho com Delete


Delete simples 3520 ms 73 ms

Delete com Where 1294 ms 295 ms Fonte: Elaborado pelos autores, 2016.

Tabela 4 - Avaliação de Desempenho com Update


Update simples 40264 ms 3066 ms

Update com Where 00:16 min 35:39 min Fonte: Elaborado pelos autores, 2016.

Logo, pode-se concluir que o PostgreSQL se sobressaiu em relação ao MySQL

nas requisições de Select, porém nas demais avaliações de desempenho (Insert,

Delete e Update) o MySQL se mostrou mais eficiente ao executar as tarefas em menos

tempo.

Vale ressaltar mais uma vez que tal conclusão é válida dentro do contexto

apresentado neste trabalho, ou seja, considerando-se as versões dos SGBDs, a

ferramenta de Avaliação de Desempenho utilizada, o hardware e o sistema

operacional no qual os servidores foram executados durante a realização das

avaliações de desempenho e, portanto, podem não representar a realidade de outros

cenários.

56

REFERÊNCIAS BIBLIOGRÁFICAS

DATE, C.J. Introdução a sistemas de banco de dados. 8. ed. São Paulo: Campus, 2008. RAMAKRISHNAN, R.; GEHRKE, J. Sistemas de gerenciamento de banco de dados. 3. ed. São Paulo: McGrawHill, 2008. COUGO, P. Modelagem conceitual e projeto de banco de dados. 3. ed. Rio de Janeiro: Campus, 1997. NASSU, E. A.; SETZER, V.W. Banco de dados orientados a objetos. 12. ed. São Paulo: Edgard Blucher, 1999. SILBERSCHATZ, A. et. al. Sistema de banco de dados. 6. ed. São Paulo: Campus, 2012. FURTADO, G. A História dos bancos de dados. Dicas de Programação, São Paulo, 2013. Disponível em:<http://www.dicasdeprogramacao.com.br/a-historia-dos-bancos-de-dados> Acesso em: 27 out. 2016. LUIS blog. Principais tipos de bancos de dados. 2007-2015. Disponível em: < http://www.luis.blog.br> Acesso em: 03 set. 2015. GOMES, E. H. Sistemas Gerenciador de Banco de Dados. Disciplina de Banco de Dados. Cubatão, 2013. Disponível em: <http://ehgomes.com.br/disciplinas/bdd/> Acesso em: 11 mai. 2015. ORACLE. Manual de configuração da versão 6.3. Ano. Disponível em: <http://www.oracle.com/manual> Acesso em: 30 nov. 2015.

JMETER. Apache JMeter. Disponível em: <http://jmeter.apache.org/>. Acesso em: 10 set. 2016. TANENBAUM, A. S. Computer Networks. Tradução Vandenberg D. de Souza. 4. ed. Rio de Janeiro: Elsevier, 2003.

SILVA, S. R. Oracle Database10g. 1. ed. São Paulo: Érica Ltda, 2013.

INFOESCOLA.MYSQL. Ano. 2006 – 2016. Disponível em: <http://www.infoescola.com/informatica/mysql/> Acesso em: 07 dez 2016.

57

ANEXO A – PRINTS DAS TELAS DE AVALIAÇÃO DE DESEMPENHO COM SELECT

Neste anexo A, veremos prints das avaliações de desempenho com SELECT

realizados. Cada avaliação foi executado 10 vezes, para se obter a média do tempo

de resposta, a partir das amostras coletadas.

Anexo A. 1 Avaliação de Desempenho Select no MySQL

Anexo A. 2 Avaliação de Desempenho Select no PostgreSQL

58

Anexo A. 3 Avaliação de Desempenho Select com Join no MySQL

Anexo A. 4 Avaliação de Desempenho Select com Join no PostgreSQL

Anexo A. 5 Avaliação de Desempenho Select com Join e Where no MySQL

59

Anexo A. 6 Avaliação de Desempenho Select com Join e Where no PostgreSQL

Anexo A. 7 Avaliação de Desempenho Select com Join, Where e Sum no MySQL

Anexo A. 8 Avaliação de Desempenho Select com Join, Where e Sum no PostgreSQL

60

ANEXO B – PRINTS DAS TELAS DE AVALIAÇÃO DE DESEMPENHO INSERT

Neste anexo B, veremos prints das avaliações de desempenho INSERTT

realizados. Cada avaliação foi executada 10 vezes, para se obter a média do tempo


Anexo B. 1 Avaliação de Desempenho Insertno MySQL

Anexo B. 2 Avaliação de Desempenho Insert no PostgreSQL

Anexo B. 3 Avaliação de Desempenho Insert Com Join no MySQL

61

Anexo B. 4 Avaliação de Desempenho Insert com Join no PostgreSQL

Anexo B. 5 Avaliação de Desempenho Insert com Join e Where no MySQL

Anexo B. 6 Avaliação de Desempenho Insert com Join e Where no PostgreSQL

62

ANEXO C – PRINTS DAS TELAS DE AVALIAÇÃO DE DESEMPENHO DELETE

Neste anexo C, veremos prints das avaliações de desempenho DELETE



Anexo C. 1 Avaliação de Desempenho com Delete no MySQL

Anexo C. 2 Avaliação de Desempenho Delete no PostgreSQL

Anexo C. 3 Avaliação de Desempenho Delete com Where no MySQL

63

Anexo C. 4 Avaliação de Desempenho Delete com Where no PostgreSQL

64

ANEXO D – PRINTS DAS TELAS DE AVALIAÇÃO DE DESEMPENHO UPDATE

Neste anexo D, veremos prints das avaliações de desempenho UPDATE



Anexo D. 1 Avaliação de Desempenho com Update no MySQL

Anexo D. 2 Avaliação de Desempenho com Update no PostgreSQL

Anexo D. 3 Avaliação de Desempenho Update com Join e Where no MySQL

65

Anexo D. 4 Avaliação de Desempenho Update com Join e Where no PostgreSQL

Documents

CENTRO ESTADUAL DE DUCAÇÃO TECNOLÓGICA PAULA SOUZAfateclins.edu.br/.../WQnh8ilWnbEz4NgJKUzovaSCFY6x2snGnY8E3as… · 1 centro estadual de educaÇÃo tecnolÓgica paula souza faculdade