TARCIZIO ALEXANDRE BINI APLICAC¸ ˜AO DO ALGORITMO DE KRUSKAL NA OTIMIZAC¸ ˜AO DE CONSULTAS COM M ´ULTIPLAS JUNC¸ ˜OES RELACIONAIS

APLICAC ¸ ˜ AO DO ALGORITMO DE KRUSKAL NA OTIMIZAC ¸ ˜ AO DE CONSULTAS COM M ´ ULTIPLAS

JUNC ¸ ˜ OES RELACIONAIS

Disserta¸c˜ ao apresentada como requisito par- cial ` a obten¸c˜ ao do grau de Mestre. Pro- grama de P´ os-Gradua¸c˜ ao em Inform´ atica, Setor de Ciˆ encias Exatas, Universidade Fed- eral do Paran´ a.

Orientador: Prof. Dr. Marcos Sfair Sunye.

CURITIBA

2009

APLICAC ¸ ˜ AO DO ALGORITMO DE KRUSKAL NA OTIMIZAC ¸ ˜ AO DE CONSULTAS COM M ´ ULTIPLAS

JUNC ¸ ˜ OES RELACIONAIS

Disserta¸c˜ ao apresentada como requisito par- cial ` a obten¸c˜ ao do grau de Mestre. Pro- grama de P´ os-Gradua¸c˜ ao em Inform´ atica, Setor de Ciˆ encias Exatas, Universidade Fed- eral do Paran´ a.

Orientador: Prof. Dr. Marcos Sfair Sunye.

CURITIBA

2009

APLICAC ¸ ˜ AO DO ALGORITMO DE KRUSKAL NA OTIMIZAC ¸ ˜ AO DE CONSULTAS COM M ´ ULTIPLAS

JUNC ¸ ˜ OES RELACIONAIS

Disserta¸c˜ ao aprovada como requisito parcial ` a obten¸c˜ ao do grau de Mestre no Programa de P´ os-Gradua¸c˜ ao em Inform´ atica da Universidade

Federal do Paran´ a, pela Comisso formada pelos professores:

Orientador: Prof. Dr. Marcos Sfair Sunye.

Departamento de Inform´ atica, UFPR Prof. Dr. Fabiano Silva

Departamento de Inform´ atica, UFPR, membro interno.

Prof. Dr. Eduardo Cunha de Almeida

Universit´ e de Nantes, UN, Fran¸ca, membro ex- terno.

Curitiba, 17 de abril de 2009

AGRADECIMENTOS

Agrade¸co primeiramente a Deus, por ter me dado a oportunidade, for¸cas e deter- mina¸c˜ ao para a realiza¸c˜ ao e conclus˜ ao do curso de mestrado.

A todos os professores do Departamento de Inform´ atica da Universidade Federal do Paran´ a, que trabalham constantemente pela qualidade do ensino oferecido pela institui¸c˜ ao.

Especialmente agrade¸co ao meu orientador, professor Marcos Sfair Sunye, por acreditar em meu potencial e sempre estar dispon´ıvel ` as orienta¸c˜ oes, dando dicas e sugest˜ oes para o melhor desenvolvimento do trabalho.

Aos familiares, de maneira especial meus pais, Angelo e Sofia, que me apoiaram nos momentos de maiores dificuldades. Palavras amigas, revigorantes ou simplesmente a torcida pelo meu sucesso, nunca faltaram. Sou imensamente grato.

Ao amigo Adriano Lange pela grande ajuda, paciˆ encia e tamb´ em os diversos esclarec- imentos e os conhecimentos repassados. Obrigado tamb´ em pela configura¸c˜ ao dos equipa- mentos utilizados e contribui¸c˜ oes na corre¸c˜ ao deste documento.

A empresa DHL tratores, na pessoa do Sr. Carlos Cesar Alves, que proporcionou condi¸c˜ oes para que eu pudesse realizar o curso de mestrado. Em especial aos amigos Deivison e Reginaldo pelo bom-humor e momentos de descontra¸c˜ ao muito importantes para mim.

A colega Pryscila Barvick Guttoski, que na medida do poss´ıvel procurou repassar seus conhecimentos a respeito dos assuntos pertinentes a esse trabalho, o qual foi iniciado por ela.

Aos integrantes do projeto GHI, que partilharam dia-a-dia, das dificuldades que en- contrei e dos ˆ exitos alcan¸cados.

Enfim, agrade¸co a todos aqueles que de uma forma ou outra, muitas vezes sem saber,

contribu´ıram para a realiza¸c˜ ao deste trabalho.

SUM ´ ARIO

LISTA DE FIGURAS v

LISTA DE TABELAS vi

RESUMO vii

ABSTRACT viii

1 INTRODUC ¸ ˜ AO 1

1.1 Motiva¸c˜ ao . . . . 2

1.2 Organiza¸c˜ ao da Disserta¸c˜ ao . . . . 4

2 BENCHMARK 5 2.1 Hist´ orico e Evolu¸c˜ ao dos Benchmarks de Banco de Dados . . . . 5

2.2 Benchmark TPC . . . . 7

2.2.1 TPC-APP . . . . 7

2.2.2 TPC-C . . . . 9

2.2.3 TPC-DS . . . . 10

2.2.4 TPC-E . . . . 12

2.2.4.1 Esquema do Banco de Dados TPC-E . . . . 12

2.2.4.2 Transa¸c˜ oes TPC-E . . . . 14

2.2.4.3 M´ etricas TPC-E . . . . 16

2.2.5 TPC-H . . . . 16

2.2.5.1 Esquema do Banco de Dados TPC-H . . . . 16

2.2.5.2 Fun¸c˜ oes TPC-H . . . . 18

2.2.5.3 M´ etricas TPC-H: . . . . 20

2.3 Benchmarks DBT . . . . 21

3 ALGORITMOS/ESTRAT´ EGIAS DE JUNC ¸ ˜ OES RELACIONAIS 23

3.1 Algoritmos Determin´ısticos . . . . 23

3.1.1 Programa¸c˜ ao Dinˆ amica . . . . 24

3.1.2 Algoritmo de Kruskal . . . . 25

3.2 Algoritmos Gen´ eticos . . . . 26

3.3 Algoritmos Aleat´ orios . . . . 27

4 POSTGRESQL 28 4.1 Hist´ orico . . . . 28

4.2 Processamento de Consultas . . . . 29

4.3 Otimiza¸c˜ ao de Consultas no PostgreSQL . . . . 30

4.3.1 Programa¸c˜ ao Dinˆ amica no PostgreSQL . . . . 31

4.3.2 Algoritmos Gen´ eticos no PotsgreSQL . . . . 33

4.3.3 Algoritmo de Kruskal no PotsgreSQL . . . . 34

4.3.3.1 A Fun¸c˜ ao Kruskal . . . . 34

4.3.3.2 O Gerador de Arestas da Fun¸c˜ ao Kruskal . . . . 35

5 METODOLOGIA EMPREGADA NOS EXPERIMENTOS E AN ´ ALISE DE RESULTADOS OBTIDOS 39 5.1 Ambiente Experimental . . . . 39

5.1.1 Hardware e Plataforma Operacional . . . . 39

5.1.2 SGBD PostgreSQL . . . . 39

5.1.3 Ferramentas para Avalia¸c˜ ao de Performance . . . . 40

5.1.3.1 Metodologia de Testes Baseada no Benchmark TPC-E . . 40

5.1.3.2 Metodologia de Testes Baseada no Benchmark TPC-H . . 41

5.2 Resultado dos Experimentos . . . . 43

5.2.1 Resultados Obtidos pela Metodologia de Testes Baseada no Bench- mark TPC-E . . . . 43

5.2.1.1 Tempo de Execu¸c˜ ao das Consultas . . . . 44

5.2.1.2 Tempo de Execu¸c˜ ao dos Algoritmos Otimizadores . . . . . 48

5.2.1.3 Custo dos Planos de Execu¸c˜ ao Gerados pelos Otimizadores 51 5.2.2 Resultados Obtidos pela Metodologia de Testes Baseada no Bench-

mark TPC-H . . . . 54 5.2.2.1 Tempo de Execu¸c˜ ao das Consultas . . . . 55 5.2.2.2 Tempo de Execu¸c˜ ao dos Algoritmos Otimizadores . . . . . 56 5.2.2.3 Custo dos Planos de Execu¸c˜ ao Gerados pelos Otimizadores 57 5.2.3 Discuss˜ ao sobre os Resultados . . . . 59

6 CONCLUS ˜ AO E TRABALHOS FUTUROS 60

APˆ ENDICES 62

A OTIMIZADOR KRUSKAL IMPLEMENTADO NO SGBD POST-

GRESQL 63

B CONSULTAS DESENVOLVIDAS E SUBMETIDAS A BASE DE DA-

DOS DO BENCHMARK TPC-E 70

C CONSULTAS DO BENCHMARK TPC-H SELECIONADAS PARA OS

EXPERIMENTOS REALIZADOS 75

REFERˆ ENCIAS BIBLIOGR ´ AFICAS 85

LISTA DE FIGURAS

2.1 Esquema do banco de dados TPC-App [33]. . . . 8

2.2 Esquema do banco de dados TPC-C [32]. . . . 9

2.3 Etapas da carga de trabalho TPC-DS . . . . 11

2.4 Modelo de fluxo de neg´ ocio TPC-E [34] . . . . 12

2.5 Esquema do banco de dados TPC-H 2.7.0 [35]. . . . 17

2.6 M´ etricas TPC-H [19] . . . . 20

4.1 Processamento de consultas no PostgreSQL [27] . . . . 29

4.2 Arvore de consulta suposta . . . . ´ 33

4.3 Pseudoc´ odigo do algoritmo de Kruskal implementado. . . . 36

4.4 Duas formas de gera¸c˜ ao de arestas para a mesma consulta. . . . 37

4.5 Log de erro apresentado na aplica¸c˜ ao servidor PostgreSQL . . . . 38

5.1 Tempo m´ edio de execu¸c˜ ao das consultas X n´ umero de rela¸c˜ oes . . . . 46

5.2 Tempos de execu¸c˜ ao da consulta Q5 X n´ umero da medi¸c˜ ao . . . . 46

5.3 Tempos de execu¸c˜ ao da consulta Q12 X n´ umero da medi¸c˜ ao . . . . 47

5.4 Valores m´ aximos de tempo de execu¸c˜ ao das consultas de acordo com o otimizador empregado . . . . 48

5.5 Tempo m´ edio de execucao dos otimizadores X n´ umero de rela¸c˜ oes . . . . . 50

5.6 Custo do plano de execu¸c˜ ao estimado para a consulta Q1 . . . . 51

5.7 Custo m´ edio estimado dos planos para as consultas X n´ umero de rela¸c˜ oes . 53

5.8 Valores m´ aximos de custos estimados para planos de execu¸c˜ ao de acordo

com o otimizador empregado . . . . 54

LISTA DE TABELAS

2.1 Benchmarks providos pelo TPC . . . . 7 2.2 Tabelas do benchmark TPC-E . . . . 13 2.3 N´ umero de Stream pelo Fator de Escala escolhido . . . . 19 4.1 Poss´ıveis solu¸c˜ oes para o n´ umero de rela¸c˜ oes mencionadas na consulta . . 32 5.1 Consultas do benchmark TPC-H utilizadas nos experimentos . . . . 42 5.2 Tempo m´ edio de execu¸c˜ ao das consultas - Base de dados do benchmark

TPC-E . . . . 45 5.3 Valores m´ aximo e m´ınimo obtidos pelo M´ odulo GEQO para o tempo de

execucao das consultas - Base de dados do benchmark TPC-E . . . . 47 5.4 Tempo m´ edio para execu¸c˜ ao dos algoritmos otimizadores - Base de dados

do benchmark TPC-E . . . . 49 5.5 Custo m´ edio de gera¸c˜ ao dos planos de execu¸c˜ ao - Base de dados do bench-

mark TPC-E . . . . 52 5.6 Custos m´ aximo e m´ınimo obtidos pelo M´ odulo GEQO para as consultas -

Base de dados do benchmark TPC-E . . . . 54 5.7 Tempo m´ edio de execu¸c˜ ao das consultas TPC-H pelos algoritmos de Pro-

grama¸c˜ ao Dinˆ amica e Kruskal . . . . 56 5.8 Tempo m´ edio para execu¸c˜ ao dos algoritmos de Programa¸c˜ ao Dinˆ amica e

Kruskal nas consultas TPC-H . . . . 57 5.9 M´ edia dos custos dos planos de execu¸c˜ ao gerados pelos algoritmos de Pro-

grama¸c˜ ao Dinˆ amica e Kruskal para consultas TPC-H . . . . 58

RESUMO

A busca por planos ´ otimos de execu¸c˜ ao de consultas em SGDBs relacionais ´ e cer-

tamente um problema da classe NP. Em virtude disso, a aplica¸c˜ ao de algoritmos de

programa¸c˜ ao dinˆ amica para esta finalidade fica restrita a certo limite de rela¸c˜ oes. Dessa

forma, v´ arios algoritmos foram propostos na tentativa de se encontrar planos aceit´ aveis

em tempo h´ abil e com baixo consumo de recursos. Dentre estas solu¸c˜ oes, podemos citar

os algoritmos gen´ eticos que apresentam a solu¸c˜ ao para o problema de otimiza¸c˜ ao de con-

sultas em tempo polinomial. Por´ em, por se tratar de um m´ etodo aleat´ orio, que exibe

muitas varia¸c˜ oes em seus resultados, planos de execu¸c˜ ao impratic´ aveis podem ser escol-

hidos. Neste trabalho apresentaremos o algoritmo de Kruskal em conjunto com algumas

regras de gera¸c˜ ao de sub-planos como alternativa para a gera¸c˜ ao de planos de execu¸c˜ ao

de consultas. Tal algoritmo apresenta vantagens como c´ odigo de implementa¸c˜ ao simples,

tempo de execu¸c˜ ao polinomial e espa¸co de busca reduzido. N´ os implementamos o algo-

ritmo de Kruskal no SGBD PostgreSQL, o que permitiu confrontar seus resultados com

o algoritmo de programa¸c˜ ao dinˆ amica em consultas simples ou algoritmos gen´ eticos em

consultas complexas. Para os testes de performance, nossa metodologia de avalia¸c˜ ao, to-

mou por base os benchmarks TPC-H e TPC-E. Os resultados obtidos demonstram que o

algoritmo de Kruskal aplicado a otimiza¸c˜ ao de consultas ´ e uma solu¸c˜ ao vi´ avel que exibe

bons resultados em consultas que apresentam m´ ultiplas jun¸c˜ oes.

ABSTRACT

The search for optimal plans in order to execute queries in relational DBMS is certainly an NP-complete problem. In virtue of this, the applicability of dynamic programming algorithms to the search of the optimal plans is restricted to a certain limit of relations.

Because of this problem, severals alternative algorithms were proposed in order to find

satisfactory plans in an acceptable time and with low consumption of resources. Among

these solutions, we can cite the genetic algorithms which that present the solution to

the queries optimization problem in polynomial time. However, it is a random method,

which displays many variations in their results, and impractical execution plans can be

chosen. This document presents the Kruskal’s algorithm together with some rules for

generation of sub-plans as an alternative to the query plan generation. This algorithm

has advantages as simple code implementation, polynomial run-time and reduced search

space. We implemented this algorithm in PostgreSQL DBMS, which allowed compare

their results with the dynamic programming in simple queries, or the genetic algorithm

in complex queries. In performance tests, our evaluation method based on benchmarks

TPC-H and TPC-E. The results show that Kruskal’s algorithm applied to the queries

optimization is a viable solution that shows good results for queries that have multiple

joins.

CAP´ ITULO 1 INTRODUC ¸ ˜ AO

Nas ´ ultimas d´ ecadas tornou-se fundamental o armazenamento, manipula¸c˜ ao e recu- pera¸c˜ ao de um n´ umero cada vez maior de informa¸c˜ oes. Em resposta a tais necessidades, surgiram os Sistemas Gerenciadores de Banco de Dados (SGBDs), os quais s˜ ao aplica¸c˜ oes que proporcionam mecanismos para gerir de forma eficiente e conveniente grande volume de informa¸c˜ oes.

Os primeiros modelos de banco de dados a surgirem foram o hier´ arquico e o de redes, nos quais os dados s˜ ao representados por uma cole¸c˜ ao de registros e os relacionamentos entre eles s˜ ao representados por links (ponteiros) [24]. Atualmente o mercado ´ e domi- nado por SGBDs que se baseiam no modelo relacional. Como caracter´ıstica marcante de tais aplica¸c˜ oes, temos o armazenamento dos dados em tabelas de nomes ´ unicos, tamb´ em chamadas de rela¸c˜ oes.

As Linguagens de Manipula¸c˜ ao de Dados (DMLs) viabilizam o acesso e manipula¸c˜ ao dos dados, de acordo com o modelo de dados apropriado. As DMLs procedurais exigem que o usu´ ario especifique quais dados s˜ ao necess´ arios e a forma de obtˆ e-los. Logo as DMLs n˜ ao procedurais permitem que o usu´ ario especifique apenas quais dados s˜ ao necess´ arios.

Uma consulta ´ e uma solicita¸c˜ ao para recupera¸c˜ ao de informa¸c˜ oes. A parte de uma DML respons´ avel pela recupera¸c˜ ao das informa¸c˜ oes solicitadas ´ e chamada de linguagem de consultas (query language) [24].

A Structured Query Language (SQL) ´ e um exemplo de DML n˜ ao procedural empregada nos SGBDs relacionais. Al´ em de ser classificada como “linguagem de consulta” o SQL fornece uma s´ erie de recursos como formas de definir e modificar a estrutura do banco de dados al´ em de especificar restri¸c˜ oes de seguran¸ca.

Devido ao seu alto grau de abstra¸c˜ ao, simplicidade e facilidade de uso, o SQL oculta

diversos detalhes de baixo n´ıvel. Dessa forma, uma simples consulta, pode ser decomposta

em uma seq¨ uˆ encia de opera¸c˜ oes f´ısicas baseadas na ´ algebra relacional, onde cada seq¨ uˆ encia apresenta varia¸c˜ oes de custos computacionais, como processamento e acesso a disco. Esta seq¨ uˆ encia de opera¸c˜ oes pode ser representada em uma estrutura de ´ arvore, chamada ´ arvore de execu¸c˜ ao da consulta, a qual apresenta a ordem das opera¸c˜ oes a serem executadas.

Um plano de execu¸c˜ ao ´ e uma seq¨ uˆ encia de passos seguidos pelo Sistema Gerenciador de Banco de Dados para a execu¸c˜ ao de uma consulta, determinando assim como os da- dos armazenados nas rela¸c˜ oes ser˜ ao acessados. Quanto maior o n´ umero de rela¸c˜ oes e jun¸c˜ oes referenciadas na consulta, maior a dificuldade da escolha do melhor plano de ex- ecu¸c˜ ao, devido ` a quantidade destes, aumentar exponencialmente. O processo de escolha do plano de execu¸c˜ ao mais eficiente para determinada consulta ´ e chamado de otimiza¸c˜ ao de consultas [21].

1.1 Motiva¸ c˜ ao

Quando falamos do processo de otimiza¸c˜ ao de consultas, devemos ter em mente que seu alvo principal ´ e a opera¸c˜ ao de jun¸c˜ ao, a qual representa alto custo computacional. Os SGBDs podem se utilizar de diversos algoritmos para determinar qual a melhor ordem de se realizar as jun¸c˜ oes, referenciadas pela consulta. Entre eles podemos citar os algoritmos de programa¸c˜ ao dinˆ amica, heur´ısticos e aleat´ orios.

Os algoritmos de programa¸c˜ ao dinˆ amica s˜ ao um dos m´ etodos mais tradicionais de otimiza¸c˜ ao. Sua t´ ecnica de buscas exaustivas gera todas as poss´ıveis ´ arvores de execu¸c˜ ao para determinada consulta. Baseado nas estimativas de custos, as ´ arvores que apresentam maiores custos n˜ ao s˜ ao inclu´ıdas no plano de execu¸c˜ ao final. Como resultado, tem-se a ´ arvore final de menor custo, considerada a ´ otima, sendo utilizada para recuperar as informa¸c˜ oes solicitadas pela query.

Os algoritmos de programa¸c˜ ao dinˆ amica ir˜ ao apontar a solu¸c˜ ao ´ otima, ou seja, a

´

arvore de execu¸c˜ ao que apresentar menor estimativa de custos. Por´ em, quando o n´ umero

de rela¸c˜ oes envolvidas na consulta ´ e elevado, o custo computacional necess´ ario ao ar-

mazenamento dos diversos sub-planos e processamento dos mesmos, em busca do ´ otimo,

pode tornar-se impratic´ avel.

Atualmente ´ e bastante comum em aplica¸c˜ oes gerenciais, a utiliza¸c˜ ao de consultas com- plexas ` as bases para a extra¸c˜ ao de informa¸c˜ oes estrat´ egicas. Tais consultas certamente envolvem um grande n´ umero de rela¸c˜ oes. Sendo assim, torna-se interessante o estudo de algoritmos que permitam a otimiza¸c˜ ao de consultas complexas, em um per´ıodo de tempo vi´ avel e que indiquem como resultado ao menos uma solu¸c˜ ao pr´ oxima a ´ otima.

Pesquisas relacionadas a otimiza¸c˜ ao de consultas que envolvem m´ ultiplas jun¸c˜ oes est˜ ao recebendo aten¸c˜ ao especial por parte de desenvolvedores de SGBDs e projetistas de banco de dados. Dentre elas podemos citar a incorpora¸c˜ ao do algoritmo de Kruskal na gera¸c˜ ao de planos de execu¸c˜ ao de consultas, proposta esta realizada por Pryscila Barvick Guttoski em [21]. O algoritmo de Kruskal ´ e um algoritmo guloso utilizado na teoria de grafos para encontrar ´ arvores geradoras m´ınimas, formadas pelo conjunto de arestas que cont´ em todos os v´ ertices do grafo e cujo peso total das arestas ´ e minimizado.

A proposta de otimiza¸c˜ ao de consultas que utiliza o algoritmo de Kruskal, foi implan- tada no SGBD PostgreSQL [20] devido a sua vasta documenta¸c˜ ao, c´ odigo fonte aberto e capacidade para o tratamento de consultas complexas. Basicamente tal SGBD utiliza-se de duas t´ ecnicas para a gera¸c˜ ao dos planos de execu¸c˜ ao, sendo elas uma implementa¸c˜ ao de um algoritmo de programa¸c˜ ao dinˆ amica, neste documento chamado de Programa¸c˜ ao Dinˆ amica e o m´ odulo de algoritmos gen´ eticos GEQO (Genetic Query Optimization).

O m´ odulo GEQO ´ e acionado por padr˜ ao em consultas que envolvem mais de 11 rela¸c˜ oes na cl´ ausula from, ou seja, o mesmo ´ e empregado para a otimiza¸c˜ ao de consultas que envolvem m´ ultiplas jun¸c˜ oes. Por´ em, por se tratar de um m´ etodo de otimiza¸c˜ ao aleat´ orio o mesmo pode escolher e manter planos de execu¸c˜ ao impratic´ aveis, por isso seu desempenho n˜ ao ´ e considerado suficiente.

Outra problem´ atica referente a este otimizador diz respeito ao tempo de execu¸c˜ ao da

consulta e apresenta¸c˜ ao dos resultados. N˜ ao existe regularidade no per´ıodo de tempo

necess´ ario para o retorno das informa¸c˜ oes solicitadas pela consulta. Certa execu¸c˜ ao de

determinada query pode apresentar resultados em um per´ıodo de tempo baixo. Em outro

caso, tratando-se da mesma consulta, em um per´ıodo de tempo extremamente alto. Este

problema torna-se mais cr´ıtico a medida que o n´ umero de rela¸c˜ oes referenciadas pelas

consultas aumentam.

Este trabalho descreve o processo de avalia¸c˜ ao da performance do algoritmo de Kruskal empregado no processo de otimiza¸c˜ ao de consultas. Os testes desenvolvidos levam em con- sidera¸c˜ ao queries simples que envolvem um n´ umero baixo de rela¸c˜ oes e tamb´ em consultas complexas com m´ ultiplos relacionamentos. Sendo assim, desenvolvemos uma metodologia pr´ opria para realiza¸c˜ ao de tal avalia¸c˜ ao, a qual se baseia em benchmarks fornecidos pelo TPC (Transaction Processing Council ) [28]. O desenvolvimento de tal metodologia foi necess´ aria devido a ausˆ encia, nos benchmarks tradicionais, de consultas que envolvem um n´ umero muito elevado de rela¸c˜ oes. Al´ em disso, tais ferramentas buscam avaliar a perfor- mance do SGBD como um todo, n˜ ao apresentando resultados caracter´ısticos para an´ alise dos algoritmos otimizadores, como tempo de execu¸c˜ ao e custos estimados para os plano de execu¸c˜ ao gerados.

1.2 Organiza¸ c˜ ao da Disserta¸ c˜ ao

Este documento est´ a dividido em seis cap´ıtulos: No Cap´ıtulo 2 ´ e apresentada uma re-

vis˜ ao a respeito dos principais benchmarks relacionados ` a ´ area de banco de dados, servindo

de embasamento te´ orico para a melhor compreens˜ ao do leitor, a respeito das ferramentas

de avalia¸c˜ ao de desempenho utilizadas em nossos experimentos. No Cap´ıtulo 3 apresen-

tamos os principais algoritmos para a realiza¸c˜ ao de jun¸c˜ oes relacionais. O Capitulo 4

descreve o SGBD PostgreSQL, dando aten¸c˜ ao especial aos algoritmos de otimiza¸c˜ ao de

consultas e tamb´ em a implementa¸c˜ ao do algoritmo de Kruskal neste SGBD. O Cap´ıtulo

5 apresenta a descri¸c˜ ao da metodologia para avalia¸c˜ ao de desempenho dos algoritmos

otimizadores e tamb´ em descreve os resultados obtidos pelos experimentos. Finalmente o

Cap´ıtulo 6 apresenta as conclus˜ oes obtidas com a elabora¸c˜ ao deste trabalho.

CAP´ ITULO 2 BENCHMARK

Existe uma grande quantidade de SGBDs dispon´ıveis no mercado. Alguns s˜ ao desen- volvidos para a execu¸c˜ ao de consultas complexas, outros para executar um grande n´ umero de transa¸c˜ oes simples por segundo. Para auxiliar na escolha e avalia¸c˜ ao dos produtos, s˜ ao desenvolvidos benchmarks de performance. Os mesmos s˜ ao utilizados para mensurar, de acordo com padr˜ oes pr´ e-estabelecidos, determinados produtos, ou realizar comparativos entre estes. Os benchmarks buscam ser port´ aveis, f´ aceis de serem entendidos e como re- sultados, apresentam na sua maioria, a performance ou a raz˜ ao entre o custo do sistema avaliado e a performance do mesmo, levando em considera¸c˜ ao a quantidade de transa¸c˜ oes executadas por unidade de tempo [22].

Na pr´ oxima se¸c˜ ao ser´ a apresentado um hist´ orico a respeito das principais ferramentas de benchmark aplicadas a banco de dados, assim como suas metodologias. Isso servir´ a de embasamento te´ orico para melhor compreens˜ ao desse trabalho, no que diz respeito a forma de avalia¸c˜ ao da performance dos algoritmos de otimiza¸c˜ ao de consultas empregados no SGBD PostgreSQL.

2.1 Hist´ orico e Evolu¸ c˜ ao dos Benchmarks de Banco de Dados

A avalia¸c˜ ao de performance de SGBDs, ´ e uma atividade que sempre gerou muitas controv´ ersias. Antes de surgirem benchmarks propostos por organiza¸c˜ oes reconhecidas, as ferramentas de avalia¸c˜ ao e compara¸c˜ ao de desempenho eram criadas e mantidas pelas pr´ oprias empresas desenvolvedoras de SGBDs, afetando assim, a credibilidade e a impar- cialidade dos resultados.

Dessa forma, em 1983 foi apresentado por David Dewitt, acadˆ emico da Universidade

de Wisconsin, o primeiro benchmark a adotar uma metodologia cient´ıfica na avalia¸c˜ ao de

SGBDs, batizado de Wisconsin [4]. O mesmo tinha o objetivo de testar a performance dos

operadores relacionais presentes em consultas simples e tamb´ em complexas. Tornou-se popular por se tratar do primeiro sistema de avalia¸c˜ ao imparcial de produtos de banco de dados, identificando os mesmos pelos seus nomes. Por´ em, segundo [4], os resultados apresentados eram controversos e n˜ ao condiziam com a realidade dos sistemas da ´ epoca.

Em abril de 1985, no artigo “A Measure of Transaction Processing Power” [1], foi proposto o benchmark DebitCredit, o qual teve seu desenvolvimento motivado devido aos planos de um grande banco inserir suas mil agencias, dez mil caixas autom´ aticos e dez milh˜ oes de clientes em um sistema on-line [5]. A estrutura do benchmark apresentava uma base de dados bastante simples, com apenas trˆ es rela¸c˜ oes: agencia, ATM’s (caixas autom´ aticos) e clientes. Tamb´ em era composta por uma carga de trabalho que buscava simular as transa¸c˜ oes (dep´ osito, saque) de um cliente em uma institui¸c˜ ao banc´ aria.

Ap´ os a publica¸c˜ ao do DebitCredit teve inicio uma “guerra de benchmarks ” provida pelos desenvolvedores de SGBDs. Isso ocorria quando um desenvolvedor A perdia em avalia¸c˜ ao de desempenho para um desenvolvedor B. Mediante especialistas, o desem- penho do produto do desenvolvedor A era melhorado, superando o outro produto e assim sucessivamente.

O termo “Benchmarketing ” ficou bastante conhecido, sendo usado para designar o processo de divulga¸c˜ ao de resultados de benchmark das empresas. Geralmente quem re- alizava esta atividade era o departamento de marketing ou empresa especializada. Na maioria das vezes apenas os resultados em que o sistema tinha melhor desempenho eram demonstrados e seus pontos negativos eram omitidos. Dessa forma, os resultados apre- sentados eram vistos como duvidosos, havendo a clara necessidade da cria¸c˜ ao de uma entidade independente e neutra para cria¸c˜ ao de benchmarks confi´ aveis.

Sendo assim, fundada por Omri Serlin, nasceu em Agosto de 1988 o TPC (Transaction

Processing Performance Council) [28] uma organiza¸c˜ ao sem fins lucrativos que objetiva

definir o processamento de transa¸c˜ oes e benchmarks de bancos de dados. A descri¸c˜ ao das

metodologias e benchmarks desenvolvidos pelo TPC ser˜ ao detalhados na pr´ oxima se¸c˜ ao.

2.2 Benchmark TPC

O TPC oferece um conjunto de testes para avalia¸c˜ ao de desempenho de produtos, baseando-se em quesitos como integridade, confiabilidade e consistˆ encia. Com exigˆ encias rigorosas, seus benchmarks levam em considera¸c˜ ao aplica¸c˜ oes reais com transa¸c˜ oes co- muns ao mundo dos neg´ ocios. Seu objetivo n˜ ao ´ e a realiza¸c˜ ao direta de testes, mas apontar padr˜ oes de medi¸c˜ ao de sistemas computacionais com resultados apresentados em quantidades de opera¸c˜ oes realizadas em minutos ou segundos. Empresas como Microsoft, IBM, Oracle, Sun, HP entre outras, tem seus produtos de hardware e software avaliados por benchmarks.

Na Tabela 2.1 s˜ ao apresentados os principais benchmarks providos pelo TPC, assim como seus respectivos anos de desenvolvimento e aplica¸c˜ oes. A classifica¸c˜ ao como obsoleto ou n˜ ao ´ e estipulada pelo desenvolvedor [28].

Benchmaks TPC Obsoletos Ano de Desenvolv. Aplica¸ c˜ ao

TPC-A 1989 OLTP

TPC-B 1990 Carga de trabalho

TPC-D 1995 Suporte a Decis˜ ao

TPC-R 1999 Suporte a Decis˜ ao

TPC-W 1999 Transa¸c˜ oes WEB

Benchmaks TPC N˜ ao Obsoletos Ano de Desenvolv. Aplica¸ c˜ ao

TPC-APP 2004 Servidor Aplica¸c˜ oes/WEB

TPC-C 1992 OLTP

TPC-H 1999 Suporte a Decis˜ ao

TPC-E 2007 OLTP

TPC-DS Em desenvolvimento Suporte a Decis˜ ao

Tabela 2.1: Benchmarks providos pelo TPC

Nas pr´ oximas se¸c˜ oes ser˜ ao descritos os benchmarks TPC classificados como “n˜ ao ob- soletos”. Ter˜ ao foco especial os benchmarks TPC-E e TPC-H, uma vez que foram empre- gados nos experimentos descritos posteriormente neste documento.

2.2.1 TPC-APP

Criado em 2005, o benchmark TPC-App simula um ambiente de com´ ercio eletrˆ onico

de uma livraria, no qual os clientes realizam a aquisi¸c˜ ao de livros e as encomendas s˜ ao

entregues no endere¸co especificado. Para isso a ferramenta de testes conta com uma base de dados composta por oito rela¸c˜ oes, podendo ser verificadas na Figura 2.1.

Figura 2.1: Esquema do banco de dados TPC-App [33].

O TPC-App ´ e composto por um servidor de aplica¸c˜ oes e um benchmark de servi¸cos web com uma carga de trabalho que simula atividades de um servidor de transa¸c˜ oes business-to-business (transa¸c˜ oes eletrˆ onicas realizadas entre empresas) em um ambiente 24X7, ou seja, com funcionamento 24 horas, 7 dias por semana [29].

O ambiente de com´ ercio eletrˆ onico proposto ´ e composto por m´ ultiplas transa¸c˜ oes web

as quais possuem um tempo definido para retornar respostas. O TPC-App apresenta

duas m´ etricas como resultado. A primeira ´ e a SIPS (Web Service Interaction per Second

/ per Application Server System), a qual mede a quantidade de transa¸c˜ oes de servi¸cos

web processadas por segundo por sistema. A segunda m´ etrica “Total SIPS”, apresenta o

n´ umero total de SIPS de toda a entidade testada, associando isto ao pre¸co por SIPS.

2.2.2 TPC-C

Benchmark composto por uma carga de trabalho, que tem por objetivo a simula¸c˜ ao de um ambiente OLTP (On-Line Transaction Processing) no qual ocorrem muitas transa¸c˜ oes curtas que realizam consultas e tamb´ em pequenas atualiza¸c˜ oes na base de dados [9]. O ambiente proposto procura simular as transa¸c˜ oes efetuadas por uma empresa atacadista que produz, comercializa e distribui os seus produtos. Esta empresa mostra-se distribu´ıda geograficamente com suas vendas em distritos e armaz´ ens. ` A medida que a mesma cresce, torna-se necess´ ario a cria¸c˜ ao de novos armaz´ ens, sendo que cada um mant´ em informa¸c˜ oes de cem mil produtos vendidos pela companhia. Baseado no n´ umero de armaz´ ens ´ e definido o tamanho da organiza¸c˜ ao. Cada distrito atende a trˆ es mil clientes.

Figura 2.2: Esquema do banco de dados TPC-C [32].

A estrutura do banco de dados do benchmark TPC-C pode ser visualizada na Figura 2.2. A mesma ´ e constitu´ıda por nove tabelas, as quais s˜ ao carregadas com dados antes do in´ıcio dos testes especificados. Os n´ umeros presentes nas entidades representam a cardinalidade das tabelas, ou seja, a quantidade de registros das mesmas. Dependendo da entidade, este n´ umero deve ser multiplicado por “W” que ´ e a quantidade de itens de dados presentes na tabela WAREHOUSE. Os n´ umeros pr´ oximos aos relacionamentos indicam a cardinalidade dos mesmos.

S˜ ao definidas cinco transa¸c˜ oes pelo benchmark TPC-C, as quais s˜ ao submetidas a es-

trutura do banco de dados descrita anteriormente. Cada transa¸c˜ ao apresenta um conjunto

de opera¸c˜ oes que devem ser executadas com sucesso para que um commit seja efetuado.

Dessa forma as transa¸c˜ oes podem ser vistas como unidades de trabalho, com opera¸c˜ oes realizadas de forma atˆ omica [16]. A seguir s˜ ao apresentadas as transa¸c˜ oes que comp˜ oem a carga de trabalho do TPC-C:

• Transa¸ c˜ ao New Order : realiza o registro de uma opera¸c˜ ao de compra de um cliente. Esta transa¸c˜ ao ´ e efetuada com alta freq¨ uˆ encia, impondo carga m´ edia ao sistema atrav´ es de opera¸c˜ oes de leitura e escrita. Trata-se de uma das principais transa¸c˜ oes do benchmark.

• Transa¸ c˜ ao Payment: efetua o registro de pagamento de uma conta, onde ´ e at- ualizado o credito do cliente, refletindo o pagamento nas tabelas WAREHOUSE e DISTRICT. Transa¸c˜ ao composta por opera¸c˜ oes de leitura-escrita de peso-leve e executada com alta freq¨ uˆ encia durante a realiza¸c˜ ao dos testes.

• Transa¸ c˜ ao Order-Status: consiste da consulta de informa¸c˜ oes referentes ` a ´ ultima compra realizada por um cliente. Essa transa¸c˜ ao faz acesso aos dados da tabela CUS- TOMER por meio de uma chave n˜ ao-prim´ aria. Trata-se de uma opera¸c˜ ao somente- leitura, com baixa freq¨ uˆ encia de execu¸c˜ ao e que imp˜ oem uma carga moderada ao sistema.

• Transa¸ c˜ ao Delivery : consiste no processamento em lote de 10 novos pedidos.

Transa¸c˜ ao composta por opera¸c˜ oes de leitura e escrita na base de dados, possui baixa freq¨ uˆ encia de execu¸c˜ ao, impondo carga moderada ao sistema.

• Transa¸ c˜ ao Stock Level : esta transa¸c˜ ao determina entre os itens vendidos recente- mente, quais est˜ ao com estoque abaixo de um determinado valor limite. Composta por opera¸c˜ ao somente-leitura, com baixa freq¨ uˆ encia de execu¸c˜ ao, imp˜ oe ao sistema uma pesada carga de trabalho.

2.2.3 TPC-DS

O TPC-DS ´ e o ´ unico benchmark provido pelo TPC que se encontra em fase de desen-

volvimento. Esta ferramenta busca modelar um sistema de suporte a decis˜ oes composto

por consultas (99 templates de consultas distintas) e manuten¸c˜ ao de informa¸c˜ oes (12 opera¸c˜ oes de manuten¸c˜ ao de dados). As consultas apresentam vari´ aveis de liga¸c˜ ao per- mitindo que recebam valores diferentes, simulando uma carga de trabalho multiusu´ ario e concorrente.

O ambiente prop˜ oem as seguintes caracter´ısticas segundo [31]:

• Examinar grandes volumes de dados;

• Dar respostas a quest˜ oes do mundo-real dos neg´ ocios;

• Executar consultas complexas que envolvem diversos requerimentos operacionais;

• Gerar atividade intensa no servidor de dados atrav´ es de processamento e acesso a disco;

• Por meio de fun¸c˜ oes de manuten¸c˜ ao, sincronizar-se com fonte de dados de sistemas OLTP.

A carga de trabalho do TPC-DS ´ e dividida em trˆ es etapas: Carga de dados no banco;

execu¸c˜ ao de consultas e manuten¸c˜ ao de dados [14]. A fase de execu¸c˜ ao de consultas

´ e realizada duas vezes intercaladas por uma etapa de manuten¸c˜ ao de dados, conforme ilustra a Figura 2.3

Figura 2.3: Etapas da carga de trabalho TPC-DS

O benchmark TPC-DS modela uma empresa que gerencia, vende e distribui seus pro- dutos. Utiliza-se do modelo de neg´ ocio de uma grande companhia que possui m´ ultiplas lojas em todo o pa´ıs e tamb´ em vende seus produtos atrav´ es de cat´ alogos e da Internet.

De acordo com [31], a seguir est˜ ao alguns dos processos representados pelo TPC-DS:

• Armazenar registro de aquisi¸c˜ oes de clientes;

• Alterar pre¸cos de acordo com promo¸c˜ oes;

• Criar p´ aginas web dinˆ amicas;

• Manuten¸c˜ ao do invent´ ario;

• Manuten¸c˜ ao de perfil de clientes.

2.2.4 TPC-E

Este benchmark ´ e composto por um conjunto de transa¸c˜ oes on-line de m´ ultiplos tipos (somente-leitura e intensas atualiza¸c˜ oes), que buscam simular as atividades de uma aplica¸c˜ ao OLTP atual. Durante a escrita deste documento a vers˜ ao corrente do TPC-E era a 1.6.0. A carga de trabalho e o esquema do banco de dados retratam as opera¸c˜ oes necess´ arias no contexto do ambiente de uma empresa de corretagem de a¸c˜ oes, realizando intera¸c˜ oes entre seus clientes, o mercado de a¸c˜ oes e a bolsa de valores [23], conforme ilustra a Figura 2.4.

Figura 2.4: Modelo de fluxo de neg´ ocio TPC-E [34]

2.2.4.1 Esquema do Banco de Dados TPC-E

O banco de dados sint´ etico definido pelo TPC-E ´ e composto por um conjunto de 33 rela¸c˜ oes, que s˜ ao organizadas em quatro categorias descritas e visualizadas na Tabela 2.2.

A gera¸c˜ ao de informa¸c˜ oes na base de dados ´ e efetuada pelo componente EgenLoader, um

execut´ avel bin´ ario que por padr˜ ao gera esta carga de dados no SGBD Microsoft SQL

Server.

Categoria Tabela Descri¸ c˜ ao ACCOUNT_PERMISSION

CUSTOMER CUSTOMER_ACCOUNT

CUSTOMER_TAXRATE Tabelas que cont´ em

Cliente HOLDING informa¸c˜ oes relacionadas

HOLDING_HISTORY aos clientes.

HOLDING_SUMMARY WATCH_ITEM

WATCH_LIST BROKER

CASH_TRANSACTION CHARGE

COMMISSION_RATE Tabelas que cont´ em informa- Corretora SETTLEMENT ¸c˜ oes relacionadas ` a empresa

TRADE corretora e aos corretores.

TRADE_HISTORY TRADE_REQUEST

TRADE_TYPE COMPANY

COMPANY_COMPETITOR DAILY_MARKET

EXCHANGE Tabelas que cont´ em informa- FINANCIAL ¸c˜ oes relacionadas ao mercado

Mercado INDUSTRY financeiro como dados sobre

LAST_TRADE t´ıtulos negociados, compa-

NEWS_ITEM nhias entre outros.

NEWS_XREF SECTOR SECURITY

ADDRESS Tabelas que cont´ em informa- STATUS_TYPE ¸c˜ oes referenciadas pelas

Dimens˜ ao TAXRATE tabelas de fatos.

ZIP_CODE

Tabela 2.2: Tabelas do benchmark TPC-E

O tamanho do banco de dados como um todo assim como a vaz˜ ao de transa¸c˜ oes executadas depende da cardinalidade da tabela CUSTOMER. Dessa forma as rela¸c˜ oes que comp˜ oem o banco de dados s˜ ao classificadas em trˆ es conjuntos distintos conforme [34]:

• Tabelas Fixas: apresentam sempre as mesmas cardinalidades, independente do tamanho da base de dados e de sua vaz˜ ao.

• Tabelas Escalonadas: tem suas cardinalidades relacionadas a cardinalidade da

tabela CUSTOMER. Durante a execu¸c˜ ao das transa¸c˜ oes estipuladas pelo bench- mark, os dados armazenados nestas tabelas podem ser alterados, por´ em seus taman- hos permanecem constantes.

• Tabelas Progressivas: possuem suas cardinalidades iniciais relacionadas ` a tabela CUSTOMER, mas durante a execu¸c˜ ao das transa¸c˜ oes do benchmark aumentam seu tamanho.

2.2.4.2 Transa¸ c˜ oes TPC-E

O benchmark TPC-E realiza a execu¸c˜ ao de um conjunto de transa¸c˜ oes (doze no total), as quais efetuam inser¸c˜ oes, atualiza¸c˜ oes e exclus˜ oes de informa¸c˜ oes na base de dados.

Dez transa¸c˜ oes apresentam a carga de trabalho do benchmark, procurando manter o am- biente simples e f´ acil de ser executado. Logo a transa¸c˜ ao Data-Maintenance simula atualiza¸c˜ oes administrativas em tabelas que n˜ ao s˜ ao alteradas pelas dez transa¸c˜ oes j´ a mencionadas. Por fim a transa¸c˜ ao Trade-Cleanup provˆ e a “limpeza” de opera¸c˜ oes pen- dentes na base de dados. As transa¸c˜ oes definidas pelo benchmark TPC-E s˜ ao descritas brevemente a seguir de acordo com [34].

• Broker-Volume: tal transa¸c˜ ao busca emular o processamento efetuado pela cor- retora para apresentar o desempenho de v´ arios corretores. Pode ser associada a gera¸c˜ ao de um relat´ orio gerencial com informa¸c˜ oes de volume de corretores.

Transa¸c˜ ao do tipo somente-leitura.

• Customer-Position : esta transa¸c˜ ao obt´ em o perfil do cliente resumindo sua situa¸c˜ ao atual, tomando por base os valores correntes de mercado para seus ativos.

Transa¸c˜ ao do tipo somente-leitura.

• Market-Feed : emula o processo de monitoramento da atividade corrente do mer-

cado, representando o processo efetuado pela corretora para disponibilizar o pre¸co

atualizado dos ativos. Trata-se de uma transa¸c˜ ao do tipo leitura/escrita.

• Market-Watch: transa¸c˜ ao que emula o processo de monitoramento global do mercado, permitindo ao cliente verificar a tendˆ encia atual (alta ou baixa) dos ativos informados. Transa¸c˜ ao do tipo somente-leitura.

• Security-Detail : busca emular o processo de acesso a informa¸c˜ oes detalhadas sobre um ativo em particular. Trata-se de uma transa¸c˜ ao do tipo somente-leitura.

• Trade-Lookup: transa¸c˜ ao que emula o processo de recupera¸c˜ ao de informa¸c˜ oes por um cliente ou corretor, que respondam a quest˜ oes sobre um conjunto de opera¸c˜ oes.

Como exemplo, a an´ alise geral do mercado, a an´ alise de desempenho de um ativo em determinado per´ıodo de tempo, entre outros. Trata-se de uma transa¸c˜ ao do tipo somente-leitura.

• Trade-Order : esta transa¸c˜ ao emula o processo de compra ou venda de um ativo por um cliente, corretor ou terceiro autorizado. Trata-se de uma transa¸c˜ ao do tipo leitura/escrita.

• Trade-Result: transa¸c˜ ao que emula o processo de conclus˜ ao de uma opera¸c˜ ao no mercado de a¸c˜ oes. As informa¸c˜ oes sobre as opera¸c˜ oes s˜ ao armazenadas para eventuais consultas de hist´ orico. Trata-se de uma transa¸c˜ ao do tipo leitura/escrita.

• Trade-Status: efetua o processo de atualiza¸c˜ ao do status de um conjunto partic- ular de opera¸c˜ oes. Trata-se de uma opera¸c˜ ao do tipo somente-leitura.

• Trade-Update: esta transa¸c˜ ao emula o processo para a realiza¸c˜ ao de pequenas atualiza¸c˜ oes ou corre¸c˜ oes em um conjunto de opera¸c˜ oes, por exemplo, quando um cliente ou corretor, analisa um conjunto de opera¸c˜ oes que precisam ser editadas para corre¸c˜ ao. Trata-se de uma opera¸c˜ ao do tipo leitura/escrita.

• Data-Maintenance : esta transa¸c˜ ao representa o processo de manuten¸c˜ ao peri´ odica de dados estat´ısticos, por exemplo, a atualiza¸c˜ ao do e-mail de um cliente.

Trata-se de uma transa¸c˜ ao do tipo leitura/escrita executada com baixa freq¨ uˆ encia.

• Trade-Cleanup : transa¸c˜ ao utilizada para cancelar opera¸c˜ oes pendentes na base de dados. Transa¸c˜ ao do tipo leitura/escrita, executada somente uma vez antes do in´ıcio do benchmark.

2.2.4.3 M´ etricas TPC-E

O benchmark TPC-E especifica as seguintes m´ etricas prim´ arias, publicadas nos resul- tados oficiais dos testes de performance:

• Taxa de Vaz˜ ao: representa a quantidade de transa¸c˜ oes Trade-Result execu- tadas por segundo durante a realiza¸c˜ ao do teste. Tal m´ etrica ´ e expressa em tpsE (transa¸c˜ oes por segundo).

• Pre¸ co/Desempenho: esta m´ etrica representa o custo do sistema que est´ a sendo avaliado;

• Data de Disponibilidade: representa quando os produtos avaliados estar˜ ao dispon´ıveis no mercado.

2.2.5 TPC-H

O TPC-H ´ e uma metodologia de benchmark empregada na avalia¸c˜ ao de sistemas de apoio a decis˜ ao. ´ E composto por consultas de neg´ ocio onerosas e altera¸c˜ oes simultˆ aneas de dados, submetidas a um conjunto de dados pr´ e-estabelecidos. Estas consultas tˆ em car- acter´ısticas ad-hoc, uma vez que as vari´ aveis que as comp˜ oem, tˆ em seus valores alterados a cada execu¸c˜ ao, fazendo com que as consultas n˜ ao se repitam. Esta metodologia n˜ ao tem o objetivo de modelar um segmento de mercado em espec´ıfico, mas apresentar atividades que sejam comuns a diversos [30].

2.2.5.1 Esquema do Banco de Dados TPC-H

At´ e o inicio da escrita deste documento a vers˜ ao corrente do TPC-H era a 2.7.0. A

mesma apresenta uma estrutura de oito tabelas sendo divididas em: tabelas de fatos e

tabelas dimensionais. As tabelas dimensionais armazenam informa¸c˜ oes que descrevem os elementos do neg´ ocio, podendo ser descri¸c˜ oes textuais que auxiliar˜ ao na tomada de decis˜ oes. As tabelas dimensionais s˜ ao CUSTOMER, NATION, PART, PARTSUPP, RE- GION, SUPPLIER. As tabelas de fatos no TPCH s˜ ao LINEITEM e ORDERS, as quais armazenam medi¸c˜ oes a respeito do neg´ ocio al´ em de conter chaves para as tabelas de di- mens˜ oes. Essas tabelas apresentam uma grande quantidade de registros comparados com as dimensionais.

A Figura 2.5 compreende a estrutura do banco de dados criada pelo benchmark TPC- H, apresentando suas tabelas e os relacionamentos entre os atributos.

Figura 2.5: Esquema do banco de dados TPC-H 2.7.0 [35].

A gera¸c˜ ao dos dados para todas as tabelas pode ser realizada em arquivo texto ou dire-

tamente no banco de dados, por meio da ferramenta dbgen (database generator ) fornecida

pelo TPC. O Fator de Escala (FS) estipulado, determinar´ a o tamanho da base de dados

a ser gerada, devendo obedecer a um conjunto pr´ e-definido de valores (1, 10, 30, 100, 300, 1.000, 3.000, 10.000, 30.000, 100.000). Ao definirmos este parˆ ametro como 1 (menor tamanho poss´ıvel) ser´ a criada uma base de dados de 1 gigabyte, sendo isto equivalente para a escolha dos demais Fatores de Escala [35].

O TPC disponibiliza um aplicativo chamado qgen (query generator ), o qual efetua a gera¸c˜ ao de vinte e duas consultas pr´ e-estabelecidas e distintas. As consultas possuem natureza ad-hoc, uma vez que os parˆ ametros submetidos ` as mesmas s˜ ao desconhecidos (se alteram durante as execu¸c˜ oes) assim como a sua ordem de execu¸c˜ ao. Outra caracter´ıstica das consultas ´ e o alto grau de complexidade e a capacidade de acesso a grande quantidade de dados armazenada no banco.

2.2.5.2 Fun¸ c˜ oes TPC-H

Depois de alimentada a base de dados e de posse das consultas, podem ser submetidas as fun¸c˜ oes de manipula¸c˜ ao de dados e os testes que comp˜ oem o benchmark TPC-H, descritos abaixo, conforme [19]:

• RF1 (Refresh Function 1 ): fun¸c˜ ao que realiza a inser¸c˜ ao de registros nas maiores tabelas que comp˜ oem a estrutura do banco de dados gerado, ou seja, as tabelas OR- DERS e LINEITEM. A quantidade de tuplas inseridas equivale a 0,1% da quantidade total de tuplas das tabelas.

• RF2 (Refresh Function 2 ): fun¸c˜ ao que realiza a exclus˜ ao de registros nas tabelas ORDERS e LINEITEM. A quantidade de tuplas exclu´ıdas equivale a 0,1 % da quan- tidade total de tuplas das tabelas.

• Power: teste composto pela execu¸c˜ ao da fun¸c˜ ao RF1 procedida do grupo das vinte e duas consultas mais a fun¸c˜ ao RF2.

• Throughput: teste compreendido pela execu¸c˜ ao de v´ arias sess˜ oes compostas pelas

vinte e duas consultas. Essas sess˜ oes s˜ ao chamadas de query-streams sendo que

para cada uma, ´ e necess´ aria a execu¸c˜ ao de um par de fun¸c˜ oes de atualiza¸c˜ ao (RF1 e

RF2). A seq¨ uˆ encia de fun¸c˜ oes de atualiza¸c˜ ao ´ e chamada de update-stream. A quan- tidade de query-streams que devem ser submetidas depende diretamente do Fator de Escala estipulado no momento da cria¸c˜ ao da base de dados. Isto ´ e especificado pelo benchmark conforme ilustra a Tabela 2.3.

• Performance: utiliza-se de informa¸c˜ oes dos testes Power e Throughput, apresen- tando aspectos referentes a capacidade de processamento de consultas.

Fator de Escala N´ umero de Streams

1 2

10 3

30 4

100 5

300 6

1000 7

3000 8

10000 9

30000 10

100000 11

Tabela 2.3: N´ umero de Stream pelo Fator de Escala escolhido

Sempre que executada uma fun¸c˜ ao de inser¸c˜ ao de dados (RF1) deve ser executada a respectiva (RF2) para a exclus˜ ao de informa¸c˜ oes. Dessa forma garante-se que a quantidade de dados armazenadas no banco continuar´ a a mesma. Os testes Power e Throughput podem ser mais bem compreendidos ao se verificar a Figura 2.6.

O teste Power fornece dados necess´ arios ao c´ alculo do Power@Size que ´ e obtido a partir da m´ edia geom´ etrica do tempo decorrido para a execu¸c˜ ao de todas as vinte e duas consultas e das fun¸c˜ oes RFs [35], por meio da equa¸c˜ ao 2.1:

T P C-HP ower@Size = 3600 ∗ SF

24

q Q i=22

i=1 QI(i, 0) ∗ Q j=2

j=1 RI(j, 0)

(2.1)

Na qual:

SF: ´ e o valor do Fator de Escala;

QI: ´ e o intervalo de tempo em segundos de cada consulta;

Figura 2.6: M´ etricas TPC-H [19]

RI: ´ e o intervalo de tempo em segundos de cada fun¸c˜ ao de atualiza¸c˜ ao.

O teste Throughput fornece dados para o c´ alculo do Throughput@Size, que ´ e definido como a raz˜ ao do total de n´ umeros de consultas pelo tempo decorrido durante a medi¸c˜ ao, sendo calculado pela equa¸c˜ ao 2.2:

T P C-HT hroughput@Size = (S ∗ 22 ∗ 3600)/T s ∗ SF (2.2) Na qual:

S: ´ e a quantidade de query-streams de consultas, valor ligado diretamente ao Fator de Escala descrito na Tabela 2.1;

Ts: ´ e o intervalo de medi¸c˜ ao;

SF: ´ e o valor do Fator de Escala.

2.2.5.3 M´ etricas TPC-H:

Os c´ alculos descritos anteriormente fornecer˜ ao dados utilizados para o c´ alculo das principais m´ etricas que comp˜ oem o benchmark TPC-H, as quais ser˜ ao descritas a seguir:

• Metrica Query-por-Hora : composta pela combina¸c˜ ao das m´ etricas Power e

Throughput como mostra a equa¸c˜ ao 2.3:

QphH@Size = p

P ower@Size ∗ T hroughput@Size (2.3)

• M´ etrica Pre¸ co-desempenho: ´ e tido como a m´ edia do pre¸co total do sistema, dividido pela m´ etrica Query-por-Hora, como apresentado na equa¸c˜ ao 2.4:

T P C -HP rice-per-QphH @Size = $/QphH@Size (2.4)

• Disponibilidade do sistema: per´ıodo de tempo em que o sistema est´ a acess´ıvel e dispon´ıvel aos clientes.

Conforme descrito em [8] o SGBD PostgreSQL apresenta deficiˆ encia na execu¸c˜ ao de algumas consultas fornecidas pelo TPC-H, acarretando em demora excessiva para apre- senta¸c˜ ao de resultados. Como a reescrita de consultas ´ e proibida pelo TPC-H, tem-se a alternativa de empregar o benchmark DBT3 apresentado em se¸c˜ oes adiante.

2.3 Benchmarks DBT

A Linux Foundation (www.linux-foundation.org) ´ e um cons´ orcio sem fins lucrativos, que tem como objetivo auxiliar a padroniza¸c˜ ao e prote¸c˜ ao da plataforma Linux. Fundada em Janeiro de 2007 a partir da fus˜ ao da OSDL (Open Source Development Labs) com o FSG (Free Standards Group), a Linux Foundation oferece uma su´ıte de testes baseada nos benchmarks TPC. Tais ferramentas buscam automatizar a realiza¸c˜ ao dos testes, auxiliando na cria¸c˜ ao e popula¸c˜ ao da base de dados e gera¸c˜ ao de relat´ orios de desempenho exibidos nos resultados.

Os benchmarks providos pela Linux Foundation, tamb´ em chamados de DBT, n˜ ao devem ter ser resultados comparados aos obtidos pelo TPC, uma vez que estes devem cumprir a normas de auditoria rigorosas para ter seus resultados publicados. A seguir s˜ ao descritas brevemente as cargas de trabalho DBT:

O Toolkit Database Test 2 (DBT-2) simula uma carga de trabalho baseada no bench-

mark TPC-C. Caracteriza-se por um conjunto de transa¸c˜ oes curtas que realizam altera¸c˜ oes

ou consultas em uma quantidade pequena de tuplas. Tal ferramenta pode ser aplicada a SGBDs como PostgreSQL, MySQL ou SAP-DB.

O kit de testes DBT-3 baseia-se no benchmark TPC-H, buscando ser mais flex´ıvel e f´ acil de ser utilizado. Abaixo, os principais diferenciais do DBT3 em rela¸c˜ ao ao TPC-H:

• N˜ ao apresenta a m´ etrica Pre¸co-desempenho;

• Pode-se estipular Fatores de Escala diferentes dos pr´ e-estabelecidos pelo TPC-H;

• Permite a reescrita de consultas, o que ´ e proibido no benchmark TPC;

• N˜ ao ´ e realizado o teste de ACID (Atomicidade, Consistˆ encia, Isolamento e Durabil- idade);

Uma caracter´ıstica importante para a n˜ ao compara¸c˜ ao de resultados obtidos pelo benchmark TPC-H e a ferramenta DBT3, deve-se ao fato do TPC divulgar valores (pre¸cos) dos produtos utilizados nas avalia¸c˜ oes, o que n˜ ao ´ e feito pelo DBT3.

O Toolkit Database Test 4 (DBT-4) baseia-se no benchmark TPC-App vers˜ ao 1.1, o qual procura simular um ambiente transacional business-to-business composto por um servidor de aplica¸c˜ oes e uma carga de trabalho de servi¸cos web.

Por fim, o Toolkit Database Test 5 (DBT-5) simula o ambiente de uma empresa de

corretagem de a¸c˜ oes, com atividades de uma aplica¸c˜ ao OLTP atual. Sua carga de tra-

balho ´ e semelhante ao benchmark TPC-E. Desenvolvido pelo mestrando Rilson Oscar do

Nascimento, em parceria com a Linux Foundation, o kit de testes teve sua apresenta¸c˜ ao

publicada no artigo Dbt-5: A fair usage open-source tpc-e implementation for perfor-

mance evaluation of computer systems [17]. Tal ferramenta pode ser executada apenas na

aplica¸c˜ ao PostgreSQL, por´ em pode ter seu funcionamento estendido para outros SGBDs.

CAP´ ITULO 3

ALGORITMOS/ESTRAT´ EGIAS DE JUNC ¸ ˜ OES RELACIONAIS

Proporcionar respostas r´ apidas aos comandos estipulados pelos usu´ arios ´ e uma tarefa cr´ıtica desempenhada pelo SGDB. Este fato est´ a diretamente relacionado ` a otimiza¸c˜ ao de consultas, que ´ e a atividade de escolha do plano mais eficiente para a execu¸c˜ ao de determinada query em bancos de dados relacionais.

Segundo [21], a defini¸c˜ ao de uma boa estrat´ egia de avalia¸c˜ ao de express˜ oes com jun¸c˜ oes, pode ser realizada por meio de algoritmos eficientes para a execu¸c˜ ao de tais jun¸c˜ oes e de algoritmos que determinem a ordem em que as jun¸c˜ oes devem ser realizadas. Consultas SQL que fazem referˆ encia a um elevado n´ umero de rela¸c˜ oes, resultam em diversas formas de realizar as jun¸c˜ oes entre as mesmas. Avaliar todas as solu¸c˜ oes poss´ıveis em busca da

´

otima, ou seja, determinar a seq¨ uˆ encia de jun¸c˜ oes com menor custo ´ e uma tarefa que exige grande recurso computacional.

Neste cap´ıtulo ser˜ ao abordadas diversas classes de algoritmos que apresentam solu¸c˜ oes para o problema de otimiza¸c˜ ao de consultas em banco de dados relacionais, apontando suas vantagens e desvantagens.

3.1 Algoritmos Determin´ısticos

Os algoritmos determin´ısticos apresentam como caracter´ıstica marcante a constru¸c˜ ao

da solu¸c˜ ao para problemas atrav´ es de uma sequˆ encia finita de passos. Para isso, pode-

se utilizar de buscas exaustivas ou da aplica¸c˜ ao de determinada heur´ıstica [15]. Seu

tempo de execu¸c˜ ao ´ e fixo e apresentar´ a resultados idˆ enticos quando aplicado diversas vezes

sobre a mesma entrada de dados. A seguir ser´ a apresentado um algoritmo determin´ıstico

cl´ assico que se utiliza da tecnica de programa¸c˜ ao dinˆ amica, onde discutiremos aspectos

relacionados a sua utiliza¸c˜ ao na otimiza¸c˜ ao de consultas em bases de dados relacionais.

3.1.1 Programa¸ c˜ ao Dinˆ amica

A t´ ecnica de programa¸c˜ ao dinˆ amica geralmente ´ e aplicada a problemas de otimiza¸c˜ ao que apresentam muitas solu¸c˜ oes poss´ıveis. Sua metodologia procura dividir o problema apresentando diversas solu¸c˜ oes para os subproblemas (m´ etodo de dividir e conquistar). O objetivo ´ e encontrar uma solu¸c˜ ao ´ otima, a qual ´ e composta por um valor ´ otimo (m´ aximo ou m´ınimo). Cada subproblema ´ e resolvido apenas uma vez pelo algoritmo, sendo sua resposta gravada em uma tabela, para evitar recalcular a solu¸c˜ ao, cada vez que o mesmo for encontrado [3].

Proposto pela primeira vez como estrat´ egia de busca na otimiza¸c˜ ao de consultas no SYSTEM-R por Sellinger et al. [10], a programa¸c˜ ao dinˆ amica atualmente ´ e empregada em v´ arios SGBDs. Sua execu¸c˜ ao inicia-se com a gera¸c˜ ao do plano de acesso, no qual est˜ ao contidos todas as formas de acesso ` as rela¸c˜ oes mencionadas na consulta, como por exemplo, varredura seq¨ uencial ou por meio de ´ındices presentes nas rela¸c˜ oes. Em uma segunda fase, de posse do plano de acesso, o algoritmo procura todas as formas de unir duas rela¸c˜ oes, onde o plano de menor custo ´ e escolhido. A mesma fase ´ e repetida, com base em seus resultados, buscando agora, a melhor forma de efetuar a jun¸c˜ ao entre trˆ es rela¸c˜ oes. Esta rotina ´ e executada at´ e que todas as rela¸c˜ oes mencionadas na consulta sejam inclu´ıdas no plano de execu¸c˜ ao. Os planos que apresentam custos elevados n˜ ao s˜ ao inclu´ıdos no plano ´ otimo. O mais barato ´ e escolhido como o plano a ser executado.

Um algoritmo de programa¸c˜ ao dinˆ amica certamente ir´ a apontar a solu¸c˜ ao ´ otima quando empregado no processo de otimiza¸c˜ ao de consultas. Por´ em apresenta alto custo computacional ao deparar-se com queries que envolvam um n´ umero elevado de rela¸c˜ oes, acima de 10 a 15 mencionadas na consulta, segundo [3]. Como resultado, a utiliza¸c˜ ao de mem´ oria torna-se elevada, devido ` a necessidade do armazenamento de solu¸c˜ oes parciais.

O processamento requerido para cria¸c˜ ao e avalia¸c˜ ao de todos os planos poss´ıveis aumenta

exponencialmente de acordo com o n´ umero de rela¸c˜ oes existentes na consulta, podendo

tornar-se impratic´ avel. De acordo com [25], a escolha de planos para otimiza¸c˜ ao de per-

formance de consultas em banco de dados relacional ´ e um problema NP-completo. Assim,

a t´ ecnica de programa¸c˜ ao dinˆ amica ´ e restrita a determinado limite de rela¸c˜ oes quando

utilizada para otimizar consultas.

Devido a estas caracter´ısticas, motivou-se o desenvolvimento de algoritmos de otimiza¸c˜ ao como forma de indicar uma solu¸c˜ ao pr´ oxima a ´ otima em tempo polinomial.

Como exemplo, podemos citar os algoritmos heur´ısticos, gulosos e aleat´ orios, os quais s˜ ao utilizados para otimizar consultas que apresentam um grande n´ umero de rela¸c˜ oes encontrando solu¸c˜ oes sub-´ otimas em um espa¸co de tempo aceit´ avel.

3.1.2 Algoritmo de Kruskal

O algoritmo de Kruskal foi apresentado em 1956 pelo pesquisador Joseph B.

Kruskal [13] como solu¸c˜ ao ao problema da ´ arvore de custos total m´ınima, a qual deve ser formada pelo conjunto de arestas de peso m´ınimo de um grafo, selecionadas sucessi- vamente a partir de seus pesos.

Tido com algoritmo guloso, a cada itera¸c˜ ao busca selecionar a aresta que possuir menor peso, adicionando-a em um subgrafo. Caso sejam encontradas arestas de mesmo custo, a escolha ´ e feita aleatoriamente. Como restri¸c˜ ao imposta, tem-se a escolha de arestas que n˜ ao formem um ciclo entre os v´ ertices do grafo. O algoritmo se encerra quando todos os v´ ertices que comp˜ oem o grafo foram adicionados ao subgrafo, ou seja, todos os v´ ertices do grafo est˜ ao presentes na ´ arvore geradora m´ınima [3].

O algoritmo de Kruskal pode ser empregado na solu¸c˜ ao aproximada do problema do caixeiro viajante, no qual se busca encontrar a trajeto mais curto para a visita de todas as cidades. Na mesma linha de racioc´ınio, o algoritmo de Kruskal pode ser aplicado em diversas ´ areas como transporte, telecomunica¸c˜ oes, processamento de imagens, entre outras, buscando a redu¸c˜ ao de custos diversos.

Este algoritmo pode ser aplicado ` a otimiza¸c˜ ao de consultas, conforme [2], uma vez que

o plano de execu¸c˜ ao ´ otimo pode ser representado por uma ´ arvore geradora m´ınima de um

grafo. As rela¸c˜ oes mencionadas na consulta s˜ ao representadas como v´ ertices do grafo. As

arestas representam poss´ıveis jun¸c˜ oes entre as rela¸c˜ oes, sendo que seus pesos s˜ ao baseados

nos custos para realiza¸c˜ ao de tais jun¸c˜ oes. O c´ alculo dos custos leva em considera¸c˜ ao

atributos como cardinalidade e seletividade, por exemplo, obtidos estatisticamente pelo

SGBD. O algoritmo de Kruskal realizar´ a primeiramente as jun¸c˜ oes entre rela¸c˜ oes que possuem menor custo, reduzindo desta forma o custo das jun¸c˜ oes seguintes que envolvem rela¸c˜ oes mais custosas e maiores.

3.2 Algoritmos Gen´ eticos

Os algoritmos gen´ eticos (GA - Gen´ etic Algorithm ) foram propostos por John Holland e acadˆ emicos da Universidade de Michigan como um m´ etodo de otimiza¸c˜ ao heur´ıstica de buscas, baseado no processo de sele¸c˜ ao natural e gen´ etica [7]. Uma caracter´ıstica marcante dessa classe de algoritmos ´ e que os mesmos n˜ ao trabalham com uma ´ unica solu¸c˜ ao, mas com um conjunto que ´ e chamado de popula¸c˜ ao. Tais solu¸c˜ oes s˜ ao representadas por strings (cromossomos) compostas por caracteres (genes) que podem possuir uma s´ erie de valores [15]. A representa¸c˜ ao de um cromossomo ´ e realizada por codifica¸c˜ ao seq¨ uencial, num´ erica ou bin´ aria, sendo esta a mais utilizada.

O algoritmo gen´ etico se inicia gerando aleatoriamente a primeira popula¸c˜ ao de in- div´ıduos, com um tamanho fixo de cromossomos, os quais podem ser decodificados para uma solu¸c˜ ao do problema. De acordo com o fitness, que ´ e o grau de adapta¸c˜ ao de um individuo ao ambiente, os cromossomos s˜ ao escolhidos (Sele¸c˜ ao) a partir da popula¸c˜ ao para se tornarem “pais”. A reprodu¸c˜ ao ocorre entre pares de cromossomos havendo a recombina¸c˜ ao dos mesmos (Crossover ) produzindo descendentes. Certa fra¸c˜ ao da pop- ula¸c˜ ao pode ser escolhida aleatoriamente, para ter um gene ou um pequeno conjunto desses alterados (Muta¸c˜ ao). A nova popula¸c˜ ao criada torna-se a nova gera¸c˜ ao e o pro- cesso ´ e repetido [12]. Essas itera¸c˜ oes s˜ ao realizadas at´ e que sejam observadas melhorias na qualidade da popula¸c˜ ao, ou o n´ umero de gera¸c˜ oes pretendidas seja alcan¸cado ou quando a solu¸c˜ ao desejada for encontrada. As t´ ecnicas descritas anteriormente permitem a cria¸c˜ ao de indiv´ıduos com um grau de fitness maior, ou seja, com melhor adapta¸c˜ ao que seus ancestrais [26].

Como alternativa ` as buscas exaustivas, os algoritmos gen´ eticos podem representar

uma solu¸c˜ ao para o problema de otimiza¸c˜ ao de consultas em tempo polinomial. Por´ em,

por se tratar de um m´ etodo aleat´ orio existe a possibilidade do algoritmo apresentar como

resultado a escolha de planos de execu¸c˜ ao impratic´ aveis. Al´ em disso, outra desvantagem dos algoritmos gen´ eticos refere-se ` a necessidade de realizar muitas avalia¸c˜ oes sobre os valores de fitness para escolha dos cromossomos que ir˜ ao se reproduzir.

3.3 Algoritmos Aleat´ orios

Os algoritmos aleat´ orios tamb´ em chamados de randˆ omicos, atualmente s˜ ao emprega- dos em diversas ´ areas como criptografias, verifica¸c˜ ao de impress˜ oes digitais entre outras.

As primeiras publica¸c˜ oes sobre sua utiliza¸c˜ ao datam da d´ ecada de 70, usados para a identifica¸c˜ ao de n´ umeros primos.

Uma caracter´ıstica marcante dos algoritmos aleat´ orios ´ e apresentar varia¸c˜ oes nos seus resultados, como por exemplo, o seu tempo de processamento durante as execu¸c˜ oes, mesmo que sejam fornecidos valores de entrada idˆ enticos. Isso ocorre porque o algoritmo realiza escolhas aleat´ orias, podendo estas, serem guiadas por um gerador de n´ umeros aleat´ orios [11].

Consultas SQL que envolvem um grande n´ umero de rela¸c˜ oes resultando em um espa¸co de busca com tamanho significativo, podem ser otimizadas por algoritmos aleat´ orios.

Estes algoritmos apresentam solu¸c˜ oes bastante pr´ oximas ` a ´ otima, escolhendo em m´ edia

bons planos de execu¸c˜ ao. Segundo [15] a classe de algoritmos aleat´ orios vˆ e as solu¸c˜ oes

para o problema como pontos no espa¸co de buscas. Esses pontos s˜ ao conectados por

meio de arestas que representam as transforma¸c˜ oes ocorridas em uma solu¸c˜ ao, originando

outra solu¸c˜ ao. As transforma¸c˜ oes ocorrem aleatoriamente segundo regras previamente

estabelecidas. O algoritmo se encerra quando n˜ ao ´ e mais poss´ıvel realizar transforma¸c˜ oes

ou quando um tempo limite pr´ e-definido ´ e atingido [21].

CAP´ ITULO 4 POSTGRESQL

Neste cap´ıtulo ser´ a apresentado o SGBD PostgreSQL, onde concentraremos nosso estudo em seu m´ odulo de otimiza¸c˜ ao de consultas, respons´ avel pela gera¸c˜ ao de planos de execu¸c˜ ao. Tal SGBD foi escolhido por apresentar seu c´ odigo fonte dispon´ıvel e aberto, permitindo altera¸c˜ oes e inclus˜ oes de funcionalidades. Outro fator determinante para esta escolha, deve-se ao fato de que neste trabalho realizaremos o aprimoramento e avalia¸c˜ ao do algoritmo de Kruskal como otimizador de consultas simples e complexas. Dessa forma ser´ a dado continuidade aos trabalhos propostos por Pryscila Barvick Guttoski [21] que se utilizaram do SGBD PostgreSQL.

4.1 Hist´ orico

O PostgreSQL ´ e um SGBD objeto relacional de c´ odigo fonte aberto desenvolvido pela Universidade da Calif´ ornia [20]. Surgiu em 1977 com o nome de Ingres, sofrendo diversas altera¸c˜ oes at´ e o ano de 1985 quando se iniciou o projeto Pos-Ingres, devido

`

a necessidade de cria¸c˜ ao de um novo SGBD. Em 1986 sua equipe de desenvolvimento lan¸cou a documenta¸c˜ ao base do sistema Postgres, sendo que no ano seguinte uma vers˜ ao operacional de demonstra¸c˜ ao j´ a estava dispon´ıvel. Em 1989 um grupo de usu´ arios j´ a fazia utiliza¸c˜ ao de sua primeira vers˜ ao.

Em 1994 com o nome Postgres95, o mesmo recebeu o interpretador da linguagem SQL e teve sua vers˜ ao distribu´ıda na Internet. Em 1996 recebeu o nome de PostgresSQL para manter o padr˜ ao com suas vers˜ oes anteriores sendo apresentada a 6.0.

Tido como o maior SGBD de c´ odigo-fonte aberto, disponibiliza recursos como cont-

role de concorrˆ encia, stored procedures, vis˜ oes (views), chaves prim´ arias (primary keys),

chaves estrangeiras (foreign keys), gatilhos (triggers) entre outros. Quando se executam

transa¸c˜ oes de leitura e escrita, busca-se resguardar as propriedades ACID dando maior

confiabilidade ` a aplica¸c˜ ao e informa¸c˜ oes armazenadas. Outra caracter´ıstica marcante ´ e a sua portabilidade, uma vez que existem vers˜ oes dispon´ıveis para a plataforma Windows, Linux, Solaris entre outras [26].

O PostgresSQL implementa os padr˜ oes SQL ANSI, 92, 96 e 99, sendo que as declara¸c˜ oes desta linguagem s˜ ao divididas em duas categorias de acordo com suas fun- cionalidades: DDL(Linguagem de Defini¸c˜ ao de Dados) e DML (Linguagem de Manip- ula¸c˜ ao de Dados) [18]. A DDL tem por objetivo a cria¸c˜ ao e modifica¸c˜ ao da estrutura do banco de dados compreendendo comandos como CREATE TABLE, ALTER USER, DROP INDEX. Logo a DML busca fazer a manipula¸c˜ ao das informa¸c˜ oes armazenadas no SGBD utilizando para isso comandos como SELECT, UPDATE, DELETE e INSERT.

4.2 Processamento de Consultas

O processamento de consultas no PostgreSQL ´ e composto pelas etapas detalhadas a seguir, conforme [26, 8, 27] e ilustradas na Figura 4.1.

Figura 4.1: Processamento de consultas no PostgreSQL [27]

• Primeiramente ´ e estabelecida a conex˜ ao entre a aplica¸c˜ ao (front-end ) e o servidor

PostgreSQL (back-end ). Em seguida a aplica¸c˜ ao poder´ a transmitir comandos ao

servidor ficando no aguardo dos resultados.

• E realizada uma verifica¸c˜ ´ ao sint´ atica dos comandos transmitidos ao servidor pelo analisador (parse), gerando como sa´ıda a ´ arvore de an´ alise (parse tree), utilizando-se apenas de regras fixas da estrutura sint´ atica do SQL. Nesta etapa n˜ ao h´ a possibili- dade da compreens˜ ao da estrutura semˆ antica das opera¸c˜ oes.

• Logo ap´ os ´ e realizada a escrita da ´ arvore de an´ alise gerada na etapa anterior, onde por exemplo, consultas que envolvem views passam a acessar as tabelas base por meio da cl´ ausula from. Tamb´ em s˜ ao feitas verifica¸c˜ oes para se constatar se as rela¸c˜ oes, seus atributos e fun¸c˜ oes mencionadas na consulta est˜ ao presentes no banco de dados. Como resultado desta etapa, tem-se a ´ arvore de consultas (query tree).

• Tomando por base a ´ arvore de consultas, o planejador/otimizador do PostgreSQL cria um plano de execu¸c˜ ao para a consulta. Um comando SQL pode ser executado de diversas formas para a obten¸c˜ ao do mesmo resultado, cabendo ao otimizador de comandos a escolha do plano de execu¸c˜ ao que aparenta ser o mais r´ apido. O otimizador utiliza-se de estruturas chamadas paths as quais indicam formas para re- alizar as buscas nas tabelas ou em jun¸c˜ oes entre as mesmas. Depois de determinado o caminho, tido como de menor custo pelo otimizador, ´ e gerada a ´ arvore de plano (plan tree) com informa¸c˜ oes para a execu¸c˜ ao da consulta.

• A plan tree ser´ a processada recursivamente pelo Executor de modo a recuperar o conjunto de linhas solicitado pela consulta, retornando os resultados ` a aplica¸c˜ ao.

4.3 Otimiza¸ c˜ ao de Consultas no PostgreSQL

O SGBD PostgreSQL utiliza-se do algoritmo de Programa¸c˜ ao Dinˆ amica e do m´ odulo

de algoritmo gen´ etico GEQO (Genetic Query Optimization) para a gera¸c˜ ao de planos de

execu¸c˜ ao (levando-se em considera¸c˜ ao o menos custoso). Dessa forma, baseando-se em

um modelo de custos, o PostgreSQL define para cada opera¸c˜ ao a ser realizada, um valor

num´ erico o qual indica a quantidade de recursos necess´ arios para a sua execu¸c˜ ao. Tal

valor num´ erico ´ e expresso em unidades arbitr´ arias de acesso a disco e processamento [26],

por exemplo.