centro estadual de educação tecnológica paula souza
Propaganda
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 CAMILA RIBEIRO DA SILVA NATHAN FELYPE DELGADO SANTOS 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 CAMILA RIBEIRO DA SILVA NATHAN FELYPE DELGADO SANTOS 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 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 DAD OS (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 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 objetorelacional 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 4000 Tempo Médio de Resposta (milissegundos) 3500 3346 3326 3000 2500 MySQL 2000 PostgreSQL 1500 1000 500 0 SGBDs 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 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. 16000 Tempo Médio de Resposta (milissegundos) 14000 13842 12000 10000 MySQL 8000 5407 6000 PostgreSQL 4000 2000 0 SGBDs 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. 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 WHERE vendas.idprod = 10 ORDER BY vendas.id; 44 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 JOIN cliente ON (cliente."ID" = vendas."IDCLI") JOIN produto ON (produto."ID" = vendas."IDPRODUTO") JOIN marca ON (marca."ID" = produto."IDMARCA") WHERE vendas."IDPRODUTO" = 10 ORDER BY vendas."ID"; Na Figura 4.3 pode-se visualizar a comparação do tempo de resposta de cada SGBD em milissegundos e, também, o seu intervalo de confiança. 7000 6172 Tempo Médio de Resposta (milissegundos) 6000 5000 4000 MySQL 3000 PostgreSQL 2000 1000 510 0 SGBDs 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. Para fazer essa requisição no MySQL, o seguinte comando SQL foi executado no jMeter: 45 SELECT produto.nome, marca.nome, SUM(vendas.quantidade) FROM vendas JOIN produto ON produto.id = vendas.idprod JOIN marca ON marca.id = produto.idmarca WHERE vendas.datavenda BETWEEN '2016-01-01' AND '2016-12-31' GROUP BY vendas.idprod ORDER BY produto.nome; Para fazer esta mesma requisição no PostgreSQL, o seguinte comando SQL foi executado no jMeter: SELECT produto."NOME", marca."NOME", SUM(vendas."QUANTIDADE") FROM vendas JOIN produto ON (produto."ID" = vendas."IDPRODUTO") JOIN marca ON (marca."ID" = produto."IDMARCA") WHERE vendas."DATAVENDA" BETWEEN '2016-01-01' AND '2016-12-31' GROUP BY produto."NOME", marca."NOME" ORDER BY produto."NOME"; Na Figura 4.4 pode-se visualizar a comparação do tempo de resposta de cada SGBD em milissegundos e, também, o seu intervalo de confiança. Tempo Médio de Resposta (milissegundos) 3000 2500 2440 2000 1407 1500 MySQL PostgreSQL 1000 500 0 SGBDs 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. 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'); Para fazer esta mesma requisição no PostgreSQL, o seguinte comando SQL foi executado no jMeter: INSERT INTO VENDAS ("IDPRODUTO", "IDCLI", "QUANTIDADE", "DATAVENDA") VALUES (19, 6, 8, '2016-06-12'); Na Figura 4.5 pode-se visualizar a comparação do tempo de resposta de cada SGBD em milissegundos e, também, o seu intervalo de confiança. Tempo Médio de Resposta (milissegundos) 1200 974 1000 800 MySQL 600 PostgreSQL 400 200 49 0 SGBDs 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”. 47 Para fazer essa requisição no MySQL, o seguinte comando SQL foi executado no jMeter: INSERT INTO relatorio 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: INSERT INTO relatorio 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."IDPRODUTO") JOIN marca ON (marca."ID" = produto."IDMARCA") ORDER BY vendas."ID"; Na Figura 4.6 pode-se visualizar a comparação do tempo de resposta de cada SGBD em milissegundos e, também, o seu intervalo de confiança. Tempo Médio de Resposta (milissegundos) 18000 16535 16000 14000 12685 12000 10000 MySQL 8000 PostgreSQL 6000 4000 2000 0 SGBDs Figura 4. 6 Avaliação de Desempenho de Insert com Join. Fonte: Elaborado pelos autores, 2016. 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”. Para fazer essa requisição no MySQL, o seguinte comando SQL foi executado no jMeter: INSERT INTO relatorio 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 WHERE cliente.nome = 'Guilherme Andrade' ORDER BY vendas.datavenda; Para fazer esta mesma requisição no PostgreSQL, o seguinte comando SQL foi executado no jMeter: INSERT INTO relatorio 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."IDPRODUTO") JOIN marca ON (marca."ID" = produto."IDMARCA") WHERE cliente."NOME" = 'Guilherme Andrade' ORDER BY vendas."ID"; Na Figura 4.7 pode-se visualizar a comparação do tempo de resposta de cada SGBD em milissegundos e, também, o seu intervalo de confiança. 49 1600 Tempo Médio de Resposta (milissegundos) 1459 1400 1200 1000 774 800 MySQL PostgreSQL 600 400 200 0 SGBDs 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. Para fazer essa requisição no MySQL, o seguinte comando SQL foi executado no jMeter: DELETE FROM vendas; Para fazer esta mesma requisição no PostgreSQL, o seguinte comando SQL foi executado no jMeter: DELETE FROM VENDAS; Na Figura 4.8 pode-se visualizar a comparação do tempo de resposta de cada SGBD em milissegundos e, também, o seu intervalo de confiança. 50 4000 Tempo Médio de Resposta (milissegundos) 3520 3500 3000 2500 MySQL 2000 PostgreSQL 1500 1000 500 73 0 SGBDs 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. Para fazer essa requisição no MySQL, o seguinte comando SQL foi executado 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" 51 AND cliente."NOME" = 'Carlos Oliveira' AND produto."NOME" = 'Caixas de Som'; Na Figura 4.9 pode-se visualizar a comparação do tempo de resposta de cada SGBD em milissegundos e, também, o seu intervalo de confiança. Tempo Médio de Resposta (milissegundos) 1400 1294 1200 1000 800 MySQL PostgreSQL 600 400 296 200 0 SGBDs 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. Para fazer essa requisição no MySQL, o seguinte comando SQL foi executado 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'; 52 Na Figura 4.10 pode-se visualizar a comparação do tempo de resposta de cada SGBD em milissegundos e, também, o seu intervalo de confiança. 45000 Tempo Médio de Resposta (milissegundos) 40264 40000 35000 30000 25000 MySQL 20000 PostgreSQL 15000 10000 3066 5000 0 SGBDs 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. Para fazer essa requisição no MySQL, o seguinte comando SQL foi executado no jMeter: UPDATE vendas, cliente, produto SET vendas.idcli = cliente.id, vendas.idprod = produto.id, WHERE cliente.nome 'Microondas'; = vendas.datavenda = '2016-07-15' 'Marina Rocha' AND produto.nome = 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."IDPRODUTO" = v."IDCLI" WHERE JOIN produto cliente."NOME" = ON produto."ID" 'Marina Rocha' = AND produto."NOME" = 'Microondas'; Na Figura 4.11 pode-se visualizar a comparação do tempo de resposta de cada SGBD em milissegundos e, também, o seu intervalo de confiança. 2500000 Tempo Médio de Resposta (milissegundos) 2139489 2000000 1500000 MySQL PostgreSQL 1000000 500000 16132 0 SGBDs Figura 4. 11 Avaliação de Desempenho Update Com Join e Where Fonte: Elaborado pelos autores, 2016. 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 Select simples Select com Join PostgreSQL 3326 ms 5407 ms MySQL 3346 ms 13842 ms 55 Select com join e Where 6172 ms Select com Join, Where e 1407 ms Sum 510 ms 2440 ms Fonte: Elaborado pelos autores, 2016. Tabela 2 - Avaliação de Desempenho com Inserts Analise PostgreSQL Insert simples 974 ms Insert com Join 16535 ms Insert com join e Where 1458 ms MySQL 49 ms 12685 ms 774 ms Fonte: Elaborado pelos autores, 2016. Tabela 3 - Avaliação de Desempenho com Delete Analise PostgreSQL Delete simples 3520 ms Delete com Where 1294 ms MySQL 73 ms 295 ms Fonte: Elaborado pelos autores, 2016. Tabela 4 - Avaliação de Desempenho com Update Analise PostgreSQL Update simples 40264 ms Update com Where 00:16 min MySQL 3066 ms 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-dosbancos-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 de resposta, a partir das amostras coletadas. 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 realizados. Cada avaliação foi executada 10 vezes, para se obter a média do tempo de resposta, a partir das amostras coletadas. 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 realizados. Cada avaliação foi executada 10 vezes, para se obter a média do tempo de resposta, a partir das amostras coletadas. 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
