UNIVERSIDADE ESTADUAL DE MONTES CLAROS Centro de Ciências Exatas e Tecnológicas Departamento de Ciências da Computação Curso de Sistemas de Informação

DAYANE HELEN SANTOS DURÃES

ANÁLISE DE DESEMPENHO ENTRE OS BANCOS DE DADOS POSTGRESQL E FIREBIRD NA PLATAFORMA WINDOWS 2000

MONTES CLAROS - MG 2007

I

DAYANE HELEN SANTOS DURÃES

ANÁLISE DE DESEMPENHO ENTRE OS BANCOS DE DADOS POSTGRESQL E FIREBIRD NA PLATAFORMA WINDOWS 2000

Projeto Orientado de Conclusão de Curso apresentado ao Departamento de Ciências da Computação da Universidade Estadual de Montes Claros, como requisito parcial para a conclusão do curso de Sistemas de Informação, orientado pelo professor Ms. João Batista Mendes.

MONTES CLAROS - MG 2007

II

DAYANE HELEN SANTOS DURÃES

ANÁLISE DE DESEMPENHO ENTRE OS BANCOS DE DADOS POSTGRESQL E FIREBIRD NA PLATAFORMA WINDOWS 2000

Aprovada em 19 de Junho de 2007.

_________________________________ Prof. Ms. JOÃO BATISTA MENDES Orientador

_________________________________ Profª. CHRISTINE MARTINS DE MATOS Avaliadora

_________________________________ Profª. SÔNIA BEATRIZ DE OLIVEIRA E SILVA MAIA Avaliadora

MONTES CLAROS – MG 2007

III

AGRADECIMENTOS Em especial ao meu orientador João Batista Mendes pelos ensinamentos e dedicação, que foram importantes durante o desenvolvimento da pesquisa. À coordenadoria do curso de Sistemas de Informação E por ter disponibilizado pela saúde o e laboratório II para a realização dos testes. agradeço a Deus disposição que Ele me concedeu.

IV

RESUMO
Os Sistemas Gerenciadores de Bancos de Dados (SGBDs) oferecem grandes benefícios às organizações quando são projetados para realizar a tarefa proposta. Por isto, a escolha do sistema deve ser analisada com cautela, observando as vantagens e desvantagens de cada sistema. Um fator que é alvo de polêmica entre os usuários de bancos de dados é o desempenho que cada SGBD oferece. Para comparar o desempenho de sistemas é importante que benchmarks sejam feitos, e nesta linha de pesquisa o trabalho foi desenvolvido. Este trabalho apresenta uma análise da performance entre os bancos de dados PostgreSQL (versão 8.2) e Firebird (versão 1.5), na plataforma Windows 2000, com o intuito de ajudar os usuários de bancos de dados na escolha do melhor sistema para a sua aplicação. Para analisar os sistemas foram implementadas um conjunto de aplicações que fazem inserção e seleção em cada banco, executadas em cenários mono-usuário e multi-usuário. Ao final, percebeu-se que o sistema PostgreSQL apresenta um desempenho superior ao do Firebird em todas as operações.

V

SUMÁRIO

1 2 2.1 2.2

INTRODUÇÃO ............................................................................................9 SISTEMAS GERENCIADORES DE BANCOS DE DADOS (SGBDS) .....11 SISTEMAS DE BANCO DE DADOS ............................................................................. 11 POSTGRESQL ......................................................................................................................... 12

2.2.1 Descrição ........................................................................................................12 2.2.2 Histórico..........................................................................................................13 2.2.3 Características................................................................................................14 2.2.4 Arquitetura ......................................................................................................15 2.2.5 Exemplos ........................................................................................................16 2.3 FIREBIRD ................................................................................................................................... 16 2.3.1 Descrição ........................................................................................................16 2.3.2 Histórico..........................................................................................................17 2.3.3 Características................................................................................................17 2.3.4 Arquitetura ......................................................................................................18 2.3.5 Exemplos ........................................................................................................19 3 3.1 3.2 3.3 BENCHMARK...........................................................................................21 DESCRIÇÃO ............................................................................................................................. 21 ORIGEM ...................................................................................................................................... 22 EXEMPLOS ............................................................................................................................... 23

3.3.1 Benchmarks TPC............................................................................................23 3.3.2 Benchmark AS3AP e OSDB ...........................................................................25 4 4.1 4.2 4.3 5 5.1 5.2 5.3 6 PHP...........................................................................................................26 DEFINIÇÃO................................................................................................................................ 26 HISTÓRICO ............................................................................................................................... 27 SERVIDOR WEB APACHE................................................................................................ 28 TRABALHO DESENVOLVIDO.................................................................30 DETALHES DO CENÁRIO E CONFIGURAÇÕES ................................................. 30 BENCHMARK ........................................................................................................................... 31 STORED PROCEDURE ...................................................................................................... 35 RESULTADOS..........................................................................................37

5.3.1 Descrição ........................................................................................................35

VI

7

CONCLUSÕES E TRABALHOS FUTUROS ............................................40 REFERÊNCIAS BIBLIOGRÁFICAS .........................................................41

VII

LISTA DE FIGURAS

Figura 2.1 – Representação do Acesso ao Banco de Dados. ...................................12 Figura 4.1 – Ambiente de Análise dos SGBDs..........................................................29 Figura 5.1 – Estrutura da Tabela Alunos. ..................................................................30 Figura 5.2 – Função que Calcula o Tempo de Execução..........................................32 Figura 5.3 – Conexão do PHP e o Firebird. ..............................................................33 Figura 5.4 – Conexão do PHP e o PostgreSQL. .......................................................33 Figura 5.5 – Código da Consulta ao Banco de Dados. .............................................34 Figura 5.6 – Código da Stored Procedure para Inserção no Firebird. .......................35 Figura 5.7 – Código da Stored Procedure para Inserção no PostgreSQL.................35

VIII

LISTA DE TABELAS

Tabela 6.1 – Resultado dos Testes de Conexão.......................................................37 Tabela 6.2 – Resultado dos Testes de Inserção. ......................................................37 Tabela 6.3 – Resultado dos Testes de Seleção. .......................................................38 Tabela 6.4 – Resultado dos Testes de Inserção com Stored Procedure. .................39

9

1 INTRODUÇÃO

A escolha de um Sistema Gerenciador de Banco de Dados (SGBD) dentre a grande diversidade disponível no mercado é uma tarefa delicada, devido à importância e responsabilidade que essa ferramenta representa por gerenciar uma das maiores riquezas de uma organização, que são as informações. Nesta tarefa, vários fatores devem ser considerados, tais como confiabilidade, integridade e segurança dos dados, suporte à linguagem de programação, interoperabilidade, conjunto de ferramentas do produto, dentro outros. Com o crescimento constante do volume de dados que os SGBDs gerenciam, e que muitas vezes estão armazenados remotamente, um fator que vem se destacando como ponto decisivo para escolha de um sistema é o desempenho. Sendo realmente uma questão de discussão entre os usuários de Banco de Dados o desempenho proporcionado pelo mesmo. Existe uma preocupação com qual sistema de banco de dados é melhor do que o outro diante de situações práticas, com qual sistema oferece tempos de resposta menores. Isto provoca o interesse em desenvolver trabalhos de análise entre os mesmos. No escopo de desempenho de sistemas de bancos de dados, este trabalho apresenta uma análise entre os bancos PostgreSQL (versão 8.2) e Firebird (versão 1.5), no Windows 2000, para auxiliar os usuários de bancos de dados quanto à escolha do SGBD mais adequado e solucionar a dúvida de como os sistemas Firebird e PostgreSQL se comportam em uma bateria de testes. O ambiente utilizado na análise é composto por um servidor de páginas Apache (versão 2.2), interagindo com a linguagem de programação PHP (versão 5.2), a qual irá interagir diretamente com os bancos de dados. A escolha destes sistemas é justificada pela habilidade apresentada em manipular grandes volumes de dados, por possuírem objetivos de projetos semelhantes (esses sistemas foram construídos para fazer tarefas de negócio críticas) e, principalmente, por serem sistemas de código aberto, que estão disponíveis para a comunidade utilizar.

10

O trabalho desenvolvido teve por objetivo apresentar o sistema com melhor performance, observar o comportamento de cada sistema de banco de dados numa aplicação desenvolvida em PHP, e validar as formas de comunicação de cada um com esta linguagem. Além de compreender o comportamento dos sistemas em ambientes mono-usuário e multi-usuário, e descrever algumas tecnologias de benchmarks presentes na literatura. Trabalhos similares a este foram desenvolvidos comparando os sistemas Firebird e o MySQL, ou o PostgreSQL e o MySQL. Mas o MySQL não deve ser confrontado com estes sistemas, pois foi projetado para aplicações Web e não para fazer tarefas complexas como no caso dos dois sistemas citados. Para apresentar esta análise, o material foi estruturado como segue: o capítulo 2 esclarece a finalidade dos Sistemas Gerenciadores de Banco de Dados (SGBDs) e expõe as características e evolução dos sistemas que serão avaliados. No capítulo 3 são discutidos os conceitos envolvendo avaliação de desempenho e benchmarks. O capítulo 4 faz uma explanação sobre a linguagem PHP e o servidor web Apache. O capítulo 5 descreve o ambiente construído para aplicação dos testes, a implementação do benchmark e as métricas avaliadas. Os resultados obtidos com os testes são apresentados no capitulo 6. O capítulo 7 apresenta as conclusões e perspectivas de trabalhos futuros.

11

2 SISTEMAS GERENCIADORES DE BANCOS DE DADOS (SGBDS)

Este capítulo esclarece a finalidade dos Sistemas Gerenciadores de Banco de Dados (SGBDs) e expõe as características e evolução dos sistemas que serão avaliados.

2.1 SISTEMAS DE BANCO DE DADOS

A informação é um elemento fundamental em toda atividade humana. Através dela decisões são tomadas, planejamentos e controles são feitos. Cavalcanti (1995) apresenta uma dinâmica interessante dos benefícios que a disponibilidade e agilização do fluxo de informações nas organizações acarretam. Mostrando que através da informação a empresa tenderá a ter as suas decisões mais rápidas e, muito provavelmente mais acertadas, gerando assim mais lucros, mais crescimento, mais empregos, possibilidade de maiores salários, contribuição para um aumento de poder aquisitivo da região onde está localizada, e uma melhor qualidade de vida. O Banco de Dados é um recurso que veio facilitar a busca de informações, eliminando os arquivos de papéis, integrando os dados de aplicações e fornecendo segurança. Com o objetivo de simplificar a criação e manutenção de um Banco de Dados surgiu os Sistemas Gerenciadores de Banco de Dados (SGBDs). Segundo Date (2000), os Sistemas de Banco de Dados tem a finalidade de gerenciar as informações de um banco de dados, que é um repositório para uma coleção de arquivos de dados computadorizados. Sendo assim, é uma camada que fica entre o banco de dados e os usuários, ou outros softwares que interagem com o SGBD, como mostrado na Figura 2.1.

12

Figura 2.1 – Representação do Acesso ao Banco de Dados.Fonte Própria

Um SGBD fornece aos usuários operações para inserir, alterar, excluir, obter e atualizar dados em um sistema, assegurando a integridade dos dados. Sua utilização traz inúmeras vantagens como: eficiência no acesso aos dados, redução do tempo de desenvolvimento de uma aplicação, acesso concorrente e rápido retorno, além da integridade e segurança dos dados.

2.2 POSTGRESQL

2.2.1 Descrição

O PostgreSQL é definido como um Sistema Gerenciador de Banco de Dados objeto-relacional, por apresentar características de um SGBD relacional e ainda, funcionalidades de orientação a objetos (POSTGRESQL GLOBAL DEVELOPMENT GROUP, 2005). Com 21 anos de desenvolvimento e uma combinação de esforços de uma grande comunidade de programadores espalhada pelo mundo, o PostgreSQL é um sistema de código aberto que está concorrendo com produtos comerciais como SQL Server e Oracle. Por se tratar de um código aberto, com licença BSD (Berkeley Software Distribution), o sistema possibilita o acesso, alterações e adaptações no código por seus próprios usuários, exigindo somente que o código licenciado mantenha suas informações de direitos autorais e licença. O PostgreSQL pode ser adquirido através de download do site: http://www.postgresql.org/.

13

2.2.2 Histórico

O PostgreSQL consiste em uma evolução do pacote Postgres, um projeto iniciado em 1986 na Universidade da Califórnia, em Berkeley, sob a liderança do professor Michael Stonebraker (extraído do site oficial do sistema1). O objetivo do projeto Postgres era criar um servidor de banco de dados relacional, tendo como base o projeto Ingres, também da Universidade de Berkeley. Foi patrocinado por algumas empresas e instituições de inteligência norte-americana como: DARPA (Defense Advanced Research Projects Agency), ARO (Army Research Office), NSF (National Science Foundation) e ESL, Inc. Como resultado do projeto desenvolvido, foi apresentada em 1987 a primeira versão de demonstração do sistema Postgres. Entretanto, esta versão mostrou uma limitação no sistema de regras. Na tentativa de melhorar o Postgres, o sistema de regras foi reprojetado e a versão 2 lançada em 1990. Posteriormente, foi adicionado suporte a múltiplos gerenciadores de armazenamento, um executor de comandos melhorado e um sistema de regras reescrito, surgindo a versão 3 em 1991. As versões seguintes do Postgres até a sua comercialização visaram à portabilidade e a confiabilidade. Em 1992, a Illustra Information Technologies (hoje, pertencente à IBM) comprou e comercializou a tecnologia Postgres. No ano seguinte, a empresa constatou que a manutenção e suporte do sistema exigiam um tempo que poderia ser aplicado em estudos sobre banco de dados, e observou ainda, uma grande expansão da comunidade de usuários. Diante deste cenário, a Illustra finalizou o projeto com a versão 4.2. Em 1994, o projeto foi reaberto por Andrew Yu e Jolly Chen, que aprimoraram sua implementação dando ênfase ao desempenho e a facilidade de manutenção. Foi adicionado um interpretador da linguagem SQL, seu código foi escrito em ANSI C e reduzido 25% em tamanho, surgindo assim o Postgres95. Segundo o site oficial do sistema postgresql, a performance do Postgres95 foi melhorada em até 50% em relação ao Postgres versão 4.2, pelo Wisconsin Benchmark. Além disso, algumas alterações no seu código merecem destaque como:
1

http://www.postgresql.org/

14

• •

inclusão de um programa de terminal interativo chamado psql; o sistema de arquivos Inversão e o sistema de regras no nível de instância foram removidos; foi acrescentado ao código fonte um tutorial introduzindo as

funcionalidades da linguagem SQL e do Postgres95;

subconsultas podiam ser simuladas por meio de funções SQL definidas pelo usuário; funções de agregação foram reimplementadas; foi adicionado suporte à cláusula GROUP BY nas consultas; acrescentado uma nova biblioteca cliente, a libpgtcl, para suporte a clientes baseados no Tcl, e novos comandos Tcl ao interpretador pgtclsh para interfacear programas Tcl com o servidor Postgres95.

• • •

Em 1996, o nome Postgres95 foi modificado para PostgreSQL, com o intuito de representar sua origem (Postgres) junto com a capacidade SQL. Sua versão foi iniciada em 6.0, para manter uma seqüência dos números das versões desde o projeto Postgres. Além de um novo nome, o projeto recebeu algumas melhorias, onde citamos:
• •

os tipos usuais foram aperfeiçoados; flexibilidade através da inclusão de funções como: restrição, gatilho, subconsulta e padrão no servidor.

Atualmente, está disponibilizada a versão 8.2 do sistema PostgreSQL.

2.2.3 Características

O PostgreSQL segue a padronização SQL (Strutured Query Language), uma linguagem de interface para SGBD. Possui uma ferramenta texto chamada psql, para receber os comandos SQL e uma interface gráfica chamada PGAdmin para tornar mais fácil e intuitivo o uso do SGBD. O sistema possibilita também a manipulação dos dados armazenados através de camadas ODBC e JDBC ou com acesso nativo na linguagem C. Dada estas

15

características, é possível desenvolver aplicações complexas para a manipulação de dados armazenados no PostgreSQL, usando qualquer linguagem de programação, como C/C++, Delphi, Java, Perl, PHP, Python, Visual Basic, e outras (NETO, 2003). São listadas a seguir as principais características do sistema PostgreSQL:

pode ser executado em vários sistemas operacionais, como Windows, Mac OS X, Linux e outras variantes de Unix; suporta os tipos SQL padrão: int, smallint, real, double, precision, char(N), varchar (N), date, time, timestamp, interval, e apresenta também uma extensão denominada POSTGIS, que possibilita o armazenamento de dados espaciais (ponto, linha, polígono, coleções geométricas e outros objetos); pode ser estendido pelo usuário através da inclusão de novos tipos de dados, funções, operadores, funções de agregação, métodos de índice e linguagens procedurais; oferece: controle de simultaneidade multiversão, chaves estrangeiras, gatilhos, visões, integridade transacional, técnicas de segurança (backup, espelhamento de discos, cluster), herança e polimorfismo.

2.2.4 Arquitetura

O PostgreSQL utiliza o modelo cliente-servidor. Uma sessão consiste na cooperação entre dois processos: o processo servidor, chamado postmaster, que recebe conexões das aplicações clientes com o banco de dados e executa ações no banco em nome dos clientes, e o processo cliente (postgres), que deseja executar operações de banco de dados (POSTGRESQL GLOBAL DEVELOPMENT GROUP, 2005). O servidor PostgreSQL pode tratar várias conexões simultâneas de clientes, sendo iniciado um processo filho para cada conexão (thread independente do postmaster). Deste ponto em diante, o cliente e o processo filho se comunicam sem interferência do processo postmaster original. Portanto, o postmaster está sempre

16

em execução aguardando por novas conexões dos clientes, enquanto os clientes e suas threads associadas surgem e desaparecem. A comunicação entre o postmaster e os processos filhos (postgres) acontece por meio de IPC (interprocess communication) e são utilizadas variáveis globais para gerenciar o acesso aos recursos do sistema.

2.2.5 Exemplos

Casos de uso como o DETRAN - PR, Embrapa - Empresa Brasileira de Pesquisa Agropecuária, Companhia do Metropolitano de São Paulo, Shannon Medical Center e Mohawk Software mostram que grandes empresas adotaram o sistema PostgreSQL (POSTGRESQL GLOBAL DEVELOPMENT GROUP, 2005).

2.3 FIREBIRD

2.3.1 Descrição

O Firebird é um sistema de manutenção de bases de dados sustentado pelo trabalho voluntário de um grupo de desenvolvedores e pela Fundação FireBird. O sistema Firebird está disponível no site http://firebird.sourceforge.net/ para download. E por ser um projeto de código aberto, os usuários podem contribuir implementando novos recursos e corrigindo erros.

17

2.3.2 Histórico

O sistema Firebird é oriundo do projeto Groton, iniciado em 1985 por uma equipe de engenheiros da DEC (Digital Equipament Corporation). A idéia era desenvolver um Sistema Gerenciador de Bancos de Dados Relacional que oferecesse benefícios não encontrados nos sistemas existentes. O Groton passou por várias alterações, sendo renomeado em 1986 como Interbase 2.0 e introduzido algumas características como: acesso nativo a driver JDBC, commit automático de duas fases, sombreamento do banco de dados, replicação, tratamento de blob´s e sistema de eventos. No ano de 2000, a Borland, empresa fabricante do Interbase, decidiu disponibilizar o código do Interbase versão 6.0 (as versões subseqüentes são proprietárias e pagas). Em virtude deste acontecimento, alguns programadores se reuniram para analisar e melhorar o código do sistema, fazendo parte da equipe: Ann Harrison e Jim Starkey, idealizador do Interbase. Como resultado do trabalho dessa equipe surgiu o Firebird, um sistema gerenciador de banco de dados estável e seguro, projetado para fazer transações financeiras e tarefas de negócio críticas (extraído do site: http://www.firebird.com.br/wiki/). Atualmente encontra-se em testes a versão 2.1 (Alpha). No Brasil, o grupo FireBase oferece suporte gratuito na solução de problemas e dúvidas.

2.3.3 Características

O sistema Firebird oferece um conjunto de características importantes como: utiliza o padrão ANSI SQL-92, está disponível para os principais sistemas operacionais (Windows, Linux, Solaris, MacOS), suporte a stored procedures e triggers, replicação, integridade referencial entre tabelas, backups incrementais,

18

transações

compatível

com

ACID

(Atomicidade,

Consistência,

Isolamento,

Durabilidade), UDF (User Defined Functions) e SubSelects. Além disso, o Firebird apresenta pouca ocupação de espaço em disco (10,33 Mb) e utiliza pouca memória em situações normais de uso. As opções mais conhecidas de ambiente gráfico do Firebird são o IBExpert, IBOConsole e Firebird Workbench.

2.3.4 Arquitetura

As modificações no código do Interbase 6.0 para a criação do Firebird não afetaram a sua arquitetura baseada em processos. Foi mantida a arquitetura Classic, desenvolvida para a versão 4.0 do Interbase. No modelo Classic, cada conexão inicia um processo de servidor com um cache de banco de dados. A disputa entre os processos para acessar o banco é solucionada por um outro processo, que permanece sempre em execução garantindo aos clientes o travamento de recursos do banco (IBPHOENIX, 2002). Posteriormente foi implementada uma nova arquitetura para o Firebird, a SuperServer. Utilizando o recurso de threads, esta arquitetura eliminou os processos separados para cada cliente. Agora, várias threads compartilham um único processo de servidor, que é capaz de reconhecer todos os clientes que estão conectados. Enquanto que na Classic, cada processo no servidor conhece somente a sua conexão. Os benefícios do modelo SuperServer são grandes. Foi melhorada a performance e integridade do banco, afinal só um processo de servidor passa acessá-lo. A existência deste único processo desencadeia vários ganhos no sistema. Como foi eliminada a criação de um processo para cada cliente conectado, junto deixa de existir o cache das páginas do banco na memória do processo, e conseqüentemente não existem dados duplicados armazenados no sistema. O modelo SuperServer usa um único espaço de cache para todas as ligações de cliente. Por isso, o processo cliente não abre diretamente o arquivo de banco de

19

dados, sendo cada conexão recebida por uma thread e utilizado uma thread especializada para gerenciar o acesso concorrente aos dados. Com menos sobrecarga e utilizando menos recursos por conexão de clientes que a arquitetura Classic, a SuperServer possibilitou ao Firebird servir de modo mais eficiente um grande número de clientes concorrentes. A configuração Classic é utilizada em sistemas operacionais que não executam aplicações multi-thread e em algumas situações específicas indicada para máquinas com mais de um processador. Já o modelo Embedded, ou embarcado, é um servidor Firebird completo que não necessita de instalação. Possibilita criar aplicativos com o Firebird adicionado de forma transparente, eliminando a alternativa de ter que instalar o Firebird para acessar a sua base de dados. Essa versão veio facilitar o processo de distribuição de programas, pois a execução já é suficiente para o acesso ao banco. No quesito segurança, a arquitetura Embedded não implementa nenhum mecanismo de autenticação, a senha é ignorada. Ideal para distribuição de catálogos eletrônicos, programas com acesso a dados não compartilhado e versões de demonstração. Portanto, encontramos o servidor Firebird em três versões: Classic Server, SuperServer (que veio substituir o modelo Classic) e o Embedded, que é uma solução para os problemas de distribuição do sistema e não uma evolução da arquitetura visando descartar a anterior, como no caso da Classic e SuperServer.

2.3.5 Exemplos

Na seqüência são listadas algumas empresas que usam o Firebird em seus softwares, extraído do site da FireBase:
• • • •

CAEMA – Cia. de Águas e Saneamento do Estado do Maranhão; CEAL – Companhia Energética de Alagoas; CODECA – Cia. de Desenvolvimento de Caxias do Sul; Copervale;

20

• •

SBC – Sociedade Brasileira de Computação; MultiBank S/A.

21

3 BENCHMARK

Este capítulo define os conceitos relacionados à avaliação de desempenho e benchmarks, onde são descritos os principais benchmarks usados para analisar Sistemas Gerenciadores de Banco de Dados.

3.1 DESCRIÇÃO

A avaliação de um sistema computacional abrange desde aspectos funcionais, como desempenho e sistema operacional suportado, até aspectos sócioculturais, como adaptação do usuário a ferramenta (SILVA, 2004). Segundo Svobodova (1976), a finalidade da avaliação de desempenho de um sistema é verificar a efetividade com que os recursos de hardware são utilizados para atender aos objetivos do software. Esta avaliação pode ser classificada como Comparativa, quando o desempenho do sistema é avaliado mediante o desempenho de outro sistema, ou Analítica, quando o sistema é avaliado com vários parâmetros de carga e de configuração do próprio sistema. Um benchmark consiste em um padrão de testes para medir ou avaliar algo, sendo utilizado também para analisar o desempenho de um sistema. Pode ser implementado como uma instrução, um programa ou uma seqüência de pedidos de interações com um componente de software. Os programas de benchmark efetuam um número de operações pré-definidas (carga de trabalho) e apresenta um resultado em algum formato (métrica), que relata o comportamento do sistema (PIRES; NASCIMENTO; SALGADO, 2006). (quantas cargas de trabalho por unidade de tempo foram medidas). Segundo Gray (1993), um benchmark deve atender os seguintes critérios:

As

métricas podem calcular a velocidade para completar a carga de trabalho ou vazão

relevância: As medidas verificadas deverão descrever funcionalidade e expectativa de desempenho acerca do produto submetido ao benchmark.

22

É necessário especificar com clareza o domínio da utilização da ferramenta e as operações a serem submetidas;

portabilidade: Na elaboração de um benchmark, as definições e os termos utilizados devem estar em um nível de abstração que permita transportá-lo para as implementações de diferentes ferramentas. Portanto, não deve haver privilégio na utilização de um contexto que seja particular a uma determinada abordagem. O objetivo desta consideração é tornar o benchmark aplicável a uma gama maior de ferramentas a serem avaliadas; escalabilidade: O padrão das medições deve atender a pequenos ou grandes sistemas, independente do nível de complexidade dos mesmos. Fatores como monoprocessamento ou multiprocessamento, clock e tamanhos de memórias não devem tornar as medidas inconsistentes, nem influenciar na aplicabilidade do benchmark; simplicidade: Os critérios definidos no benchmark devem ser simples e de fácil compreensão. Porém, a relevância das métricas não deve ser negligenciada. Medidas muito simples podem não refletir boas características de julgamento de uma ferramenta. No entanto, se for definido um conjunto de métricas muito complexas e de difícil assimilação pela comunidade interessada nos resultados, poderá ocorrer uma perda de credibilidade do benchmark.

3.2 ORIGEM

Desde 1970, estudos dentro de empresas são realizados com o objetivo de aumentar os rendimentos. Estas análises eram feitas através da identificação interna de pessoas ou departamentos que melhores resultados obtiveram, ou identificação de modelos a seguir dentro das suas concorrentes para disseminar na empresa.

23

Mas é no final dos anos 80 que surge o termo benchmarking, derivado da palavra benchmark, que significa uma marca feita por agrimensor, indicando um ponto em uma linha de nível, um padrão ou um ponto de referência. Esse termo sugere um processo estruturado de investigação de oportunidades de melhorias internas e um processo de aprendizagem, onde são esforços de mudança para melhorar o desempenho de acordo com as conclusões do estudo. O benchmarking surgiu como uma ferramenta para a qualidade, com o objetivo de gerar vantagem competitiva.

3.3 EXEMPLOS

Existem várias implementações de benchmarks para realizar medidas de desempenho, nos mais diversos sistemas, como servidores WEB, SGBDs, aplicações gráficas, entre outros. Como exemplo, pode-se citar: benchmarks para banco de dados (AS3AP, DBT-2, OSDB, TPCC-UVA, TPC, Wiscosin, 007) e benchmarks para arquiteturas de CPUs (SPEC 95, SPEC 2000). A seguir são descritos os principais benchmarks utilizados para avaliar Sistemas Gerenciadores de Banco de Dados.

3.3.1 Benchmarks TPC

Com o objetivo de definir benchmarks para avaliar o processamento de transações e banco de dados, surgiu em 1988 o TPC (Transaction Process Council). O TPC é um consórcio sem fins lucrativos, que realiza avaliações em ambientes diferentes e publica relatórios de benchmarks denominados: TPC-C, TPC-H, TPC-W

24

e TPC-App. O conjunto de transações que compõem os testes é o que diferencia os diversos relatórios TPCs (TPC, 2004). O Benchmark TPC-C é utilizado para avaliar Sistemas Gerenciadores de Banco de Dados (SGBDs). É definida uma carga de processamento de transações on-line que simula as atividades encontradas em um ambiente de aplicações complexas, caracterizado por:
• • • • • •

execução simultânea de múltiplos tipos de transações; múltiplas sessões; entrada / Saída de disco significantes; integridade da transação (propriedade ACID); distribuição não-uniforme de acessos aos dados; banco de Dados consistindo de muitas tabelas, com uma grande variedade de tamanhos, atributos e relacionamentos; concorrência no acesso aos dados.

A métrica de desempenho definida é uma taxa medindo o número de transações efetivadas com sucesso por minuto (tpmC). Múltiplas transações são utilizadas para simular a atividade do negócio. Já o TPC-H avalia o suporte da base de dados para um sistema de apoio a decisões, Data Warehouse (MACHADO, 2004). É analisado o desempenho do banco de dados no processamento de grandes quantidades de dados convencionais, através de consultas que simulam a atividade real, como perguntas sobre épocas de promoções, lucro possível, entre outros. O TPC-W avalia as atividades de um servidor WEB, simulando um comércio eletrônico pela Internet. Atualmente foi substituído pelo TPC-App, que abrange todas as características e possibilidades de negócio dos servidores Web, como por exemplo, capacidade de conexões e gerenciamento de transações (TPC-APP, 2005).

25

3.3.2 Benchmark AS3AP e OSDB
As características do AS3AP (TURBYFILL, 1992) que o destaca são: a amplitude na medição do desempenho das principais funcionalidades de um banco de dados, e a variação de tipos de carga de trabalho aplicados. O AS3AP é estruturado em módulos, sendo cada módulo responsável por testar uma funcionalidade, podendo inclusive, os módulos serem executados em conjunto. O OSDB (Open Source Database Benchmark) é um benchmark de código aberto baseado no AS3AP. Criado com o intuito de avaliar a taxa de I/O (input/output) e o poder de processamento da plataforma GNU Linux/Alpha, o OSDB apresenta algumas diferenças em relação ao AS3AP, como quantidade de métricas retornadas e número de módulos. Enquanto a avaliação dos resultados gerados pelo AS3AP baseia-se em uma única métrica (tamanho máximo do banco de dados suficiente para completar o teste em menos de 12 horas), o OSDB possibilita a comparação através de outras métricas: tempo de resposta das consultas e número de linhas retornadas por segundo (PIRES; NASCIMENTO; SALGADO, 2006).

26

4 PHP

Este capítulo discorre sobre o conceito e evolução da linguagem PHP, e apresenta o servidor web Apache.

4.1 DEFINIÇÃO

A comunicação na Web utiliza o modelo cliente/servidor, que consiste na interação de dois componentes: o cliente HTTP, que solicita arquivos (páginas) ao servidor, e o servidor HTTP, que disponibiliza as informações requeridas. Este processo de comunicação utiliza o protocolo de transferência HTTP (HyperText Transfer Protocol), que padroniza o modo de envio e recebimento de dados garantindo independência de plataforma (KINOSHITA, 2001). As informações (páginas) que o servidor disponibiliza, podem se apresentar estáticas, quando apresentam sempre o mesmo conteúdo e não permitem a interação com o usuário, ou dinâmicas, quando são geradas em tempo de execução (on-line) em resposta a uma solicitação do usuário. Para gerar páginas dinâmicas na Web são usados programas auxiliares denominados Scripts Web, que são processados na plataforma do servidor. Scripts Web são responsáveis pela interação entre o banco de dados e o servidor Web. Entre as opções de ferramentas (Scripts Web) que podem ser usadas para a geração de páginas dinâmicas está o PHP (Hypertext Preprocessor). O PHP é uma linguagem de criação de scripts, cujo código é inserido dentro do código HTML, e processado no servidor, sendo retornado para o cliente apenas HTML (KINOSHITA, 2001). Os produtos patenteados nesse nicho do mercado são o ASP (Active Server Pages) da Microsoft, o Coldfusion da Allaire e o JSP (Java Server Pages) da Sun. Uma característica importante do PHP para este trabalho é o grande número de banco de dados suportados como: Adabas D, dBase, Empress, FilePro, Firebird,

27

Informix, Interbase, mSQL, MySQL, Oracle, PostgreSQL, Sybase, Velocis, dentre outros. Além disso, o PHP é compatível com várias plataformas, podendo ser utilizado tanto em Windows como em Linux. Este produto pode ser adquirido através do site oficial: http://www.php.net, sem custo de licença.

4.2 HISTÓRICO

O desenvolvimento da linguagem PHP (Personal Home Page) começou em 1994 com Rasmus Lerdorf, engenheiro de software. A criação deste script Web foi estimulada pelo interesse de Rasmus em ter informações sobre quem acedia à sua página pessoal. Buscando melhorias no projeto PHP, foi adicionado ao pacote: o FI e suporte a mSQL, sendo lançada à versão 2.0 com o nome de PHP/FI, em 1995. O FI (Form Interpreter) usava interpretação automática de variáveis vindas de formulário e sintaxe embutida no HTML, possibilitando aos usuários desenvolver simples aplicativos dinâmicos para Web (extraído do site oficial1). Em 1997, devido à extensão que o PHP estava atingindo, uma equipe de desenvolvimento assumiu o projeto PHP, seguindo o modelo de código-fonte aberto com contribuições de desenvolvedores e usuários em todo o mundo. Assim, Zeev Suraski e Andi Gutmans, programadores israelenses, reescreveram o PHP, aproveitando parte do código do PHP/FI, lançando em 1998 a versão 3.0. O PHP 3.0 oferecia aos usuários uma infra-estrutura sólida para diversos bancos de dados, suporte a novos protocolos de Internet e APIs, suporte à sintaxe para orientação a objetos, mas sua principal característica era a capacidade de extensibilidade. Na versão 4.0, implantada em 2000, foram incluídos suporte para muitos servidores Web, sessões HTTP, buffer de saída, maneiras mais seguras de

1

http://www.php.net/

28

manipular input de usuários e um melhoramento da performance. O PHP 4.0 também foi criado por Suraski e Gutmans, que basearam na tecnologia Zend. A melhora da performance desta versão foi devido à mudança do procedimento do PHP 3.0, que analisava e executava o código ao mesmo tempo. No PHP 4.0, todo o código é compilado e convertido em byte code, e posteriormente processado pelo Zend Engine. No ano de 2002, a versão 4.3.0 do PHP incluiu inovações como: suporte a streams (camada de entrada e saída de arquivos e de rede), CLI (Interface de Linha de Comando) e a biblioteca GD (tratamento de imagens). A versão 5.0 do PHP foi disponibilizada em julho de 2004, trazendo como destaque a orientação a objetos totalmente reescrita e funcionalidades como SimpleXML, SOAP e MySQLi. Atualmente o PHP está na versão 5.2.3.

4.3 SERVIDOR WEB APACHE

Um servidor Web corresponde a um programa que está sempre em execução esperando por requisições realizadas a partir do “cliente” e responsável pelo retorno dos dados solicitados. O mercado oferece mais de 500 servidores Web, que diferenciam pelo tipo de distribuição, desempenho, suporte técnico e módulos disponíveis. Dentro destas várias opções de ferramentas, encontra-se o Servidor Apache. Implementado pela equipe The Apache Team em 1995, o Apache é hoje um líder no segmento de servidores Web. Esta posição de destaque é justificada nas características que o Apache apresenta como: livre distribuição e facilidade do processo de instalação, disponível para várias plataformas (Windows, Unix Like, Solaris, Sun), suporte à utilização de protocolos de transferência de arquivos com segurança e grande flexibilidade (extraído do site: http://www.apache.org/). Além destas qualidades, a facilidade de configuração do PHP com o servidor Apache foi um ponto importante para a escolha do mesmo.

29

O ambiente utilizado neste estudo para análise dos SGBDs é composto pelo servidor Apache interagindo com a linguagem PHP, a qual irá acessar os bancos de dados, como ilustra a figura 4.1.

Figura 4.1 – Ambiente de Análise dos SGBDs.

30

5 TRABALHO DESENVOLVIDO

Neste capítulo são descritos o ambiente construído para aplicação dos testes, a implementação do benchmark e as métricas avaliadas.

5.1 DETALHES DO CENÁRIO E CONFIGURAÇÕES

Para analisar o desempenho de cada banco, primeiramente, foi criado um banco de dados com o nome Unimontes contendo uma tabela denominada Alunos, com a estrutura similar à apresentada na Figura 5.1.

MATRICULA

NOME

CONTROLE

Figura 5.1 – Estrutura da Tabela Alunos.

O campo MATRICULA é um campo auto-incremento de números inteiros e seqüenciais, que foi construído no Firebird criando um Generator através do comando CREATE GENERATOR. função gen_id() é chamada. Para esse mesmo resultado, no PostgreSQL foi criada uma seqüência através do comando CREATE SEQUENCE, que é incrementada toda vez que a função nextval é chamada. O campo NOME é do tipo VARCHAR e o campo CONTROLE é do tipo BIGINT, que está recebendo um valor aleatório. Em seguida foi desenvolvido um conjunto de aplicações (carga de trabalho do benchmark) que fazem as seguintes operações:
• • •

Este campo é incrementado toda vez que a

inserção de 10.000 registros na tabela Alunos; seleção de 1.000 alunos da base; inserção de 100.000 alunos;

31

seleção de 10.000 alunos desta base.

Os testes foram aplicados em dois ambientes diferentes, o primeiro foi o mono-usuário, composto por uma aplicação cliente que realizou as operações de inserção e seleção sobre cada um dos SGBDs. O segundo ambiente foi composto por 05 (cinco) estações clientes, que realizaram operações de inserção e consulta de dados em cada sistema. Para análise de desempenho foi considerada a métrica: tempo de resposta em segundos. Em cada cenário as aplicações foram executadas 10 (dez) vezes e coletados os tempos resultantes das operações. Com estes resultados foi calculado o tempo médio que cada SGBD utiliza para execução das operações. O ambiente de análise foi implementado em uma máquina com processador AMD Atlhon 2000, com 512 Megabytes de memória RAM e disco rígido de 40 Gigabytes. Todos os testes foram realizados no Laboratório II do Centro de Ciências Exatas e Tecnológicas da Universidade Estadual de Montes Claros – UNIMONTES.

5.2 BENCHMARK

A aplicação de análise consiste em o PHP receber um pedido de inserção ou consulta ao banco de dados, gravar em uma variável o tempo em que esta consulta foi requisitada, solicitar ao SGBD a execução da mesma e guardar o tempo após a execução do pedido. Com os dois pontos de tempo coletados, calcula-se a diferença entre eles e como resultado tem-se o tempo gasto na realização da consulta. A Figura 5.2 apresenta o código que calcula o tempo da execução de uma tarefa.

32

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?php function tempo() { list($usec,$sec)=explode(" ",microtime()); return((float)$usec + (float)$sec); } $inicio=tempo(); echo "Aqui são incluídos os pedidos de acesso ao SGBD <br>"; $fim=tempo(); $tempoexec=($fim-$inicio); ?> echo "<p>Operação realizada em $tempoexec segundos </p>";
Figura 5.2 – Função que Calcula o Tempo de Execução.

A função tempo, compreendida entre a linha 3 e a linha 7, retorna o tempo atual em segundos. Esta função utiliza uma outra função chamada microtime() (PHP,2005), que retorna uma string “msec sec” onde sec é o tempo atual medido no número de segundos desde a Era Unix (0:00:00 January 1,1970 GMT), e msec é a parte em microssegundos. A função microtime() está disponível somente em Sistemas Operacionais que suportam a chamada gettimeofday() (obtém a hora local). A função explode() divide a string retornada pela função microtime() em duas partes, que são somadas e retornada pela função tempo(). Na linha 9 a função tempo() é chamada e o retorno (tempo atual em segundos) atribuído a variável $inicio. Em seguida, são incluídas todas as operações que acessam ao banco de dados (carga de trabalho), e só após a execução destas operações a variável $fim recebe o tempo atual, representado na linha 13. Com isso conseguimos o tempo de duração das operações (métrica) através da diferença entre a variável $fim e $inicio, apresentado na linha 15. A conexão do PHP e o Firebird foi realizada pela função ibase_connect(), disponibilizada pelo PHP, que recebe como parâmetros a localização do banco de dados (nesta análise, Unimontes), o nome do usuário (SYSDBA) e a senha (masterkey), como ilustrado na Figura 5.3. A conexão é encerrada pela função ibase_close().

33

$conexao = ibase_connect('localhost:c:/Arquivos de programas/Firebird/Firebird_1_5/bin/Unimontes.gdb', 'SYSDBA','masterkey'); if($conexao){ echo '<p>Conexão realizada com sucesso!!!</p>'; ibase_close($conexao); } else { echo '<p>Falha na conexão.</p>'; }
Figura 5.3 – Conexão do PHP e o Firebird.

E para conectar o PHP e o PostgreSQL foi utilizada a função pg_connect, a qual é disponibilizada pelo PHP para esse SGBD, e a função pg_close() para fechar a conexão. A Figura 5.4 mostra o trecho do código, em PHP, utilizado para realizar a conexão ao PostgreSQL.

$conexao = pg_connect("host =127.0.0.1 dbname=unimontes port=5432 user=postgres password=post"); if($conexao){ echo '<p>Conexão realizada com sucesso!!!</p>'; pg_close($conexao); } else { echo '<p>Falha na conexão.</p>'; }
Figura 5.4 – Conexão do PHP e o PostgreSQL.

O aplicativo que executa a consulta de 1.000 e 10.000 registros nos bancos de dados utilizou uma variável chamada $mat, que recebe um valor randômico entre 1 e o tamanho da base de dados consultada. Representando assim todos os valores do campo Matrícula existentes no banco de dados. Observe a linha 4 no trecho do código de consulta apresentado na Figura 5.5. Neste exemplo estão sendo selecionados 10.000 registros em uma base de 100.000 (Firebird).

34

1 2 3 4 5

$quant=10000; echo "<b>Matrícula - Nome - Controle</b><br>" for($i=0; $i<$quant; $i++){ $mat=rand(1,100000); $busca = "SELECT Matricula,Nome,Controle FROM Alunos WHERE Matricula=$mat"; 6 $retorno = ibase_query($conexao,$busca);
7 8 9 10

}

while ($linha = ibase_fetch_row($retorno)){ echo "$linha[0] - $linha[1] - $linha[2]<br>";} }
Figura 5.5 – Código da Consulta ao Banco de Dados.

Na linha 1 do código apresentado acima, a variável $quant recebe o número de registros a ser selecionado no banco de dados. A seleção ocorre na linha 6, sendo retornado a variável $retorno o registro com campo da matrícula igual ao valor gerado pela função rand(). As linhas 8 e 9 imprimem o resultado da seleção na tela. O aplicativo que executa a inserção dos registros no banco de dados utiliza uma variável também chamada de $quant, que recebe nesta pesquisa o valor 10.000 ou 100.000, representando o número de registros a serem inseridos. E utiliza o comando for, usando a variável de controle que é incrementada a cada execução até atingir o valor igual a $quant. O desempenho dos SGBDs pode ser melhorado com a utilização de Stored Procedures. Foi desenvolvida uma aplicação de inserção para testar o desempenho dos sistemas utilizando este recurso. A seção 5.3 apresenta uma explicação sobre Stored Procedure baseada no trabalho de Huth (2002). As Figuras 5.6 e 5.7 apresentam os códigos de criação de stored procedure nos sistemas Firebird e PostgreSQL, respectivamente.

35

CREATE PROCEDURE insercao (quant BIGINT) AS DECLARE VARIABLE i BIGINT; BEGIN i = 0; WHILE (i<quant) DO BEGIN INSERT INTO Alunos(Matricula,Nome,Controle) VALUES (gen_id(gen_alunos_id,1), ‘Dayane Helen’, 3); i = (i+1); END END;
Figura 5.6 – Código da Stored Procedure para Inserção no Firebird.

CREATE OR REPLACE FUNCTION insercao (BIGINT) RETURNS void AS $$ DECLARE i BIGINT; BEGIN i := 0; WHILE (i<$1) LOOP INSERT INTO Alunos(Matricula,Nome, Controle) VALUES (nextval(‘alunos_matricula_seq’), ‘Dayane Helen’,3); i := (i+1); END LOOP; END; $$ LANGUAGE plpgsql;
Figura 5.7 – Código da Stored Procedure para Inserção no PostgreSQL.

5.3 STORED PROCEDURE

5.3.1 Descrição

Uma Stored Procedure (SP) é formada por uma ou mais instruções SQL agrupadas e armazenadas no SGBD. Para criar uma Stored Procedure são escritos dois códigos diferentes, um código é a stored procedure que será armazenada no SGBD e o outro é o aplicativo que fará a chamada da stored procedure definida.

36

Normalmente uma SP é utilizada quando são encontradas funções ou tarefas que são executadas várias vezes. A seguir são expostos alguns benefícios da sua utilização:

melhora o desempenho em ambientes cliente/servidor, pois reduz o tráfego de informações na rede. Com a utilização de Stored Procedure todo o processamento é transferido ao servidor, que devolve à aplicação somente os registros resultantes, reduzindo também a utilização de memória e acesso a disco na estação cliente; o ciclo de desenvolvimento de uma aplicação é reduzido através da reutilização de códigos. Ao colocar uma função, que é muito utilizada em ambientes de aplicações para banco de dados, em uma stored procedure, possibilitamos o compartilhamento deste módulo com vários usuários e aplicações; facilidade de manutenção e administração. Como a Stored Procedure está no servidor, a sua alteração é válida para todos os usuários e aplicações que a utilizam; stored Procedures são mais eficientes do que comandos SQL, que precisam ser compilados e otimizados pelo SGBD a cada execução. Esta característica não é notável em estações que usam bancos de dados locais, mas é bem clara quando observado um ambiente de múltiplos bancos de dados e vários usuários concorrentes.

37

6 RESULTADOS

A Tabela 6.1 apresenta o tempo médio que a aplicação leva para realizar a conexão com cada banco.
Ambiente Mono-Usuário FIREBIRD POSTGRESQL 0.019 seg. 0.020 seg. Ambiente Multi-Usuário FIREBIRD POSTGRESQL 0.025 seg. 0.027 seg.

CATEGORIA Conexão

Tabela 6.1 – Resultado dos Testes de Conexão.

Foi observado que os dois sistemas apresentam desempenhos muito próximos na categoria conexão. Entretanto, nos testes de inserção de 10.000 registros e 100.000 registros, o PostgreSQL mostrou resultados superiores, apresentados na Tabela 6.2 (melhores tempos em negrito). Os valores apresentados na tabela não indicam que o PostgreSQL obteve um melhor tempo de resposta do que o Firebird em todas as execuções da aplicação de inserção. Indicam que a maioria dos resultados foi favorável ao PostgreSQL. É necessário destacar que dentre os tempos coletados houve tempos do Firebird superiores a alguns tempos do PostgreSQL. Isto porque, por exemplo, no teste de inserção de 10.000 registros monousuário, os tempos coletados do Firebird estavam entre 14.60 e 21.08, e os tempos do PostgreSQL estavam entre 14.29 e 15.51. Então, houve tempos do Firebird menores que tempos do PostgreSQL, mas na média o PostgreSQL foi superior.
Ambiente Mono-Usuário FIREBIRD POSTGRESQL 17.53 seg. 3.03 min. 14.88 seg. 2.31 min. Ambiente Multi-Usuário FIREBIRD POSTGRESQL 1.38 min. 12.15 min. 57.33 seg. 9.42 min.

CATEGORIA Inserção de 10.000 registros Inserção de 100.000 registros

Tabela 6.2 – Resultado dos Testes de Inserção.

38

O tempo que cada SGBD levou para realizar a seleção de 1.000 registros em uma base de 10.000 cadastrados e a seleção de 10.000 registros em uma base de 100.000 é mostrado na Tabela 6.3.
Ambiente Mono-Usuário FIREBIRD POSTGRESQL 1.92 seg. 20.18 seg. 0.99 seg. 9.93 seg. Ambiente Multi-Usuário FIREBIRD POSTGRESQL 6.39 seg. 1.59 min. 1.47 seg. 23.82 seg.

CATEGORIA Consulta de 1.000 registros (10.000) Consulta de 10.000 registros (100.000)

Tabela 6.3 – Resultado dos Testes de Seleção.

Na categoria consulta o sistema Firebird também mostrou ser mais lento do que o PostgreSQL. Esta diferença é perceptível principalmente no ambiente multiusuário na consulta de 10.000 registros. É importante relembrar que estes valores são uma média em uma amostragem de 10 tempos coletados, mas o interessante nesta categoria é que foi observado que mesmo o pior tempo de resposta do PostgreSQL ainda é superior ao melhor tempo de resposta do Firebird. Por exemplo, nos testes de consulta de 1.000 registros no ambiente mono-usuário, o maior tempo do PostgreSQL dentre os 10 (dez) foi 1.13 segundos e o menor tempo do Firebird foi 1.44 segundos. No teste de consulta de 10.000 registro, no ambiente multi-usuário, o maior tempo de uma estação no PostgreSQL (não a média entre as cinco) foi de 34 segundos e no Firebird o menor tempo foi de 1.24 minutos. O que permite validar com segurança que o sistema PostgreSQL foi superior ao Firebird nos testes de seleção. Na Tabela 6.4 é apresentada a diferença do tempo de resposta de um sistema utilizando stored procedure. O desempenho foi melhorado consideravelmente, mantendo o melhor desempenho do sistema PostgreSQL.

39

CATEGORIA Inserção com Stored Procedure 10.000 registros Inserção com Stored Procedure 100.000 registros

Ambiente Mono-Usuário FIREBIRD POSTGRESQL 5.24 seg. 0.95 seg.

Ambiente Multi-Usuários FIREBIRD POSTGRESQL 35.81 seg. 1.96 seg.

1.49 min.

6.88 seg.

8.52 min.

58.98 seg.

Tabela 6.4 – Resultado dos Testes de Inserção com Stored Procedure.

40

7 CONCLUSÕES E TRABALHOS FUTUROS

A finalidade desta análise foi apresentar um comparativo de desempenho entre os SGBDs PostgreSQL e Firebird na plataforma Windows 2000. Os testes revelaram que o desempenho do PostgreSQL é superior ao do Firebird nas operações de inserção e consulta. Particularmente nas operações de consulta, o PostgreSQL se sobressaiu, onde foi observado que mesmo o pior tempo de resposta do PostgreSQL ainda é superior ao melhor tempo de resposta do Firebird. As próximas pesquisas incluem novos testes envolvendo joins entre duas ou mais tabelas, bem como implementação de novas operações, como por exemplo atualizações e exclusões de dados. É interessante também realizar novos testes utilizando bases de dados com tamanhos significativos (10 Gb, 20 Gb). Finalizando, as atividades futuras também compreendem a aplicação desta pesquisa envolvendo outros bancos de dados livres, bem como trabalhar com banco de dados proprietários, como o SQL Server, Oracle ou BD2. Até porque todos os sistemas citados já dispõem de uma versão freeware para avaliação.

41

REFERÊNCIAS BIBLIOGRÁFICAS
APACHE. "The Apache Software Foundation". Disponível em: <http://www.apache.org/>. Acesso em: 09 de Outubro de 2006. CAVALCANTI, E.P. “Revolução da Informação: Algumas Reflexões”. Caderno de Pesquisa em Administração, São Paulo, V.1, Nº. 1, 1995. DATE, C.J. “Introdução a Sistemas de Bancos de Dados”. Rio de Janeiro: Ed. Campus, 2000. GRAY, J. “The Benchmark Handbook for Database and Transaction Processing Systems”. Morgan Kaufmann, 2 ed., 1993. HUTH, G. “Um Modelo para o Gerenciamento de Banco de Dados SQL através de Stored Procedure”. Universidade Federal de Santa Catarina, 2002. IBPHOENIX.“Comparando a Arquitetura Classic e Superserver do Firebird”. Equipe IBPhoenix – Tradução: Paulo Vaz, 2002. Disponível em: <http://www.comunidade-firebird.org/>. Acesso em: 03 de Maio de 2007. KINOSHITA, V.G. “Banco de Dados Via Web: uma Análise Comparativa”. Universidade Federal de Lavras, 2001. MACHADO, F. N. R. “Tecnologia e Projeto de Data Warehouse”. São Paulo: Érica, 2004. NETO, A.P. “PostgreSQL: Técnicas Avançadas – Versões Open Source 7.x” 2ª ed. São Paulo: Editora Érica, 2003. PHP. "PHP: Hipertext Preprocessor". Disponível em: <http://www.php.net/>. Acesso em: 09 de Outubro de 2006. PIRES, C.S.; NASCIMENTO, R.O.; SALGADO, A.C. “Comparativo de Desempenho entre os Bancos de Dados de Código Aberto”. Universidade Federal de Pernambuco (UFPE), 2006. POSTGRESQL GLOBAL DEVELOPMENT GROUP. “Tutorial do PostgreSQL 8 / Official Documentation”. Tradução: Halley Pacheco de Oliveira. Rio de Janeiro, 2005. Disponível em: <http://www.postgresql.org/>. Acesso em: 10 de Dezembro de 2006. SILVA, F.P. “Um Benchmark para Sistemas de Gerenciamento de Workflow”. Universidade Federal do Rio de Janeiro (UFRJ), 2004. SVOBODOVA, L. “Computer Performance Measrement and Evaluation Methods: Analysis and Applications”. Elsevier Scientific Publishing Company, 1976.

42

TPC. "Transaction Processing Performance Council", 2004. Disponível em: <http://www.tpc.org/>. Acesso em: 09 de Fevereiro de 2007. TPC-APP. “TPC Benchmark App (Application Server) Especification Version 1.1.1”. Disponível em <http://www.tpc.org/tpc_app/spec/TPC-App_V1.1.1.pdf>. Acesso em: 09 de Fevereiro de 2007. TURBYFILL, C.; ORJI, C.; BITTON, D. “AS3AP: An ANSI SQL Standard Scalable and Portable Benchmark for Relational Database Systems”. The Benchmark Handbook for Database and Transaction Processing, Chapter 4. Morgan Kaufman, 1992.

Sign up to vote on this title
UsefulNot useful