Professor: Aparecido Disciplina: Recuperao de Informao Mtodos de Otimizao SQL em Banco de Dados

4 BN Ronaldo Boscatto Marcelo Rosalem Daminello

08 39

52051-0 52143-5

25/05/2004

INDCE
1. Otimizao da Consulta 1.1. 1.2. Introduo Um exemplo simples 03 04

2. O processo de Otimizao: Panorama 2.1. Estgios do Processo global de otimizao 2.1.1. 2.1.2. 2.1.3. 2.1.4. Ordenao da consulta em determinada representao interna Converso forma padro Escolha dos procedimentos de baixo nvel 05 05 06 08 09 10 13 14 16 18 19 21 22 23 25 26 28 29

3. Estimativa do custo de acessos usando ndices 4. Estratgia de Juno 4.1. 4.2. 4.3. 4.4. 4.5. Interao Simples Juno por Intercalao Uso de um ndice Juno com Hashing Juno Tripla

Gerao de planos de consulta e escolha do melhor

5. Estratgia de Juno para prcessadores paralelos 5.1. 5.2. Juno Paralela Juno Mltipla em duto (PIPELINED)

6. Otimizao Fsica 8. Bibliografia

7. Estrutura do Otimizador de Consultas

25/05/2004

1.
1.1. Introduo

Otimizao da Consulta

A otimizao da consulta apresenta tanto um desafio como uma oportunidade; um desafio para os sistemas relacionais: um desafio porque, a otimizao necessria - pelo menos nos ambientes de grande porte - , a inteno sendo que o sistema tenha um desempenho aceitvel; uma oportunidade porque precisamente uma das foras da abordagem relacional o fato de, dado o alto nvel semntico das expresses relacionais, esta otimizao factvel em primeiro lugar. Num sistema no-relacional, ao contrrio, onde as solicitaes do usurio so expressas em nvel semntico inferior, toda otimizao deve ser feita manualmente pelo usurio humano. Num sistema assim, o usurio, no o sistema, quem decide que operaes a nvel de registro so necessrias e em que sequncia devem ser executadas - e, se o usurio tomar a deciso errada, no h nada que o sistema possa fazer para melhorar a situao.

Em consequncia, a vantagem da otimizao no se restringe ao fato dos usurios se preocuparem quanto a melhor expressar suas consultas. Pelo contrrio, h uma possibilidade real de que o otimizador o faa melhor que o programador humano, porque o otimizador pode ter informaes disponveis - em relao, por exemplo, aos valores de dados correntes - que o programador pode no ter, e capaz de avaliar uma gama maior de alternativas do que o programador seria capaz de fazer. O objetivo geral do otimizador, pois, escolher uma estratgia para avaliar uma dada expresso relacional. E, mais importante, em geral no h nenhuma garantia de que a estratgia escolhida para a implementao da consulta seja realmente "tima", qualquer que seja o padro desta medida; pode ocorrer que seja, mas em geral tudo o que se sabe de certo que a estratgia "otimizada" um aperfeioamento da verso original no otimizada.

25/05/2004

1.2.

Um exemplo simples
Comeamos com um exemplo simples que ilustra a necessidade ( e tambm um pouco de

potencial) de otimizao. Consideremos a consulta "Obter nomes de fornecedores que forneam a pea P2", para o qual a formulao em SQL possvel seria: SELECT DISTINCT S.SNAME FROM S,SP WHERE S.S# = SP.S# AND SP.P# = 'P2' ;

Suponhamos que o banco de dados contenha 100 fornecedores e 10.000 expedies, das quais apenas 50 relativas pea P2. Ento a seqncia de eventos seria a seguinte: 1.Computar o produto cartesiano das relaes S e SP. Este passo envolve a leitura de 10.100 tuplas, mas produz uma relao que consiste apenas em 100 * 10.000 = 1.000.000 de tuplas (e em escrever estas 1.000.000 de tuplas de volta no disco). 2.Restringir o resultado do Passo 1 como especificado pela clusula WHERE. Este espao envolve a leitura de 1.000.000 de tuplas, mas produz uma relao que consiste em apenas 50 tuplas (que podemos presumir que sero mantidas na memria central). 3.Projetar o resultado do Passo 2 sobre SNAME de forma a produzir o resultado final desejado(50 tuplas no mximo).

O procedimento seguinte equivale ao primeiro descrito acima (no sentido de que produz o mesmo resultado final)mas que obviamente mais eficiente: 1.Restringir a relao SP apenas s tuplas da pea P2. Este passo envolve a leitura de 10.000 tuplas, mas produz uma relao consistindo em apenas 50 tuplas, que presume-se, sero mantidas na memria principal. 2.Fazer a juno do resultado do Passo 1 relao S sobre S#. Este passo envolve a recuperao de apenas 100 tuplas. O resultado contm 50 tuplas (ainda na memria principal). 3.(O mesmo que o 'Passo 3 anterior). Projetar o resultado do Passo 2 sobre SNAME para produzir o resultado final desejado (50 tuplas no mximo).

25/05/2004

Se concordarmos em tomar o nmero de E/S de tuplascomo medida para o nosso desempenho ,(na prtica so as E/S de pgina que contam, no as E/S de tupla) fica claro que o segundo desses procedimentos cerca de 200 vezes melhor do que o primeiro. Seria melhor ainda Passo1 seria reduzido de 10.000 para apenas 50, outro aperfeioamento bastante expressivo). E, naturalmente, inmeros outros aperfeioamentos so possveis. O exemplo anterior, por mais simples que parea, sufiente para dar uma idia de como necessria a otimizao. Fornece , tambm, uma primeira idia sobre os tipos de aperfeioamentos que podem ser possveis na prtica. Na prxima seo, apresentamos como o problema na sua generalidade pode ser dividido em diversos nmeros de problemas mais ou menos independentes. Esta abordagem sistemtica serve como estrutura dentro das estratgias e tcnicas individuais de otimizao, como descrevem e explicam as duas sees que vm a seguir. se a relao SP fosse indexada ou tivesse acesso hash sobre P#__ o nmero de tuplas lidas no

2.
2.1.

O Processo de Otimizao: Panorama

Estgios do processo global de otimizao :

2.1.1. Ordenao da consulta em determinada representao interna O primeiro passo do processo de consulta convert-la numa representao interna, eliminando, assim, as consideraes puramente de nvel externo e, assim, abrindo o caminho para os estgios subseqentes do processo de otimizao. Levanta-se, obviamente, a questo: sobre o que o formalismo deveria basear-se a representao interna? Qualquer que seja o escolhido, deve ser rico o suficiente para representar todas as consultas possveis na linguagem de consulta de sistema. Deve tambm ser o mais neutro possvel, no sentido de que no prejudicar as opes subseqentes de otimizao. A forma interna usada, tipicamente, um tipo de rvore de sintaxe abstrata ou rvore de consulta. Por exemplo, a figura abaixo, mostra uma possibilidade de representao de rvore de consulta para a consulta do prximo exemplo.

25/05/2004

Resultado projeto (SNAME) restrio (SP.P # = ' P2 ' juno (S.S # = SP.S # ) / / \ \ | | |

SP

usa um dos formalismos j conhecidos - a saber, a lgebra relacional ou clculo relacional. Uma rvore de consulta como da figura anterior, pode ser considerada apenas como verso codificada de determinada expresso de um dos dois formalismos. Para assentarmos nossas idias, partimos do princpio, neste caso, de que o formalismo a lgebra especificamente. A expresso algbrica da consulta da figura anterior poderia ser :

Para nossos objetivos, contudo, mais conveniente assumirmos que a representao interna

( (S JOIN SP) WHERE P # = ' P2 ' ) [SNAME] 2.1.2. Converso forma padro A maioria das linguagens permite que as consultas mais simples sejam expressas em diversas maneiras, distintas apenas superficialmente. Por exemplo, mesmo uma consulta simples como aquela discutida acima - (Obter nomes de fornecedores que forneam a pea P2) - pode ser expressa em pelo menos sete maneiras aparentemente diferentes em SQL. O prximo passo no processamento da consulta deve ser converter a representao interna numa forma padro equivalente, com o objetivo de se eliminar estas distines superficiais e (mais importante) descobrir a representao mais eficiente do que a original , de uma forma especfica.

25/05/2004

Procedemos , pois, transformao do resultado do Estgio 1 numa forma equivalente, porm mais eficiente, usando certas regras de transformao bem definidas. Um exemplo importante desta regra de transformao aquele que permite que qualquer predicado de restrio seja convertido em seu predicado equivalente numa forma normal conjuntiva - isto , um predicado que consista em um conjunto de comparao simples conectada apenas por Ors. Por exemplo, a clusula WHERE: WHERE p OR ( q AND r ) pode ser convertida na forma WHERE (p OR q) AND (p OR r ) A forma conjuntiva normal interessante por inmeras razes. Por exemplo, o algoritmo de decomposio da consulta usado em INGRES necessita que o predicado de entrada da consulta seja de forma conjuntiva normal, por motivos que ficaro claros logo a seguir. Eis outro exemplo da regra de transformao: A expresso algbrica

(A JOIN B) WHERE restriction-on-B pode ser transformada em sua expresso algbrica equivalente, porm mais eficiente (A JOIN (B WHERE restriction-on-B) ) De forma mais genrica, a expresso (A JOIN B) WHERE restriction-on-A AND restriction-on-B equivalente expresso (A WHERE restriction-on-A) JOIN (B WHERE restriction-on-B)

Foi esta a regra que estvamos usando - taticamente - no exemplo introdutrio. Exemplo simples, e este exemplo demonstrou claramente porque conveniente este tipo de transformao. Damos abaixo trs exemplos destas regras.

Dada uma determinada expresso que seja suscetvel de transformao de acordo com uma das outras trs.

25/05/2004

Uma seqncia de restries pode combinar-se numa restrio nica; i.e., a expresso (A WHERE restriction-1) WHERE restriction-2 equivalente expresso A WHERE restriction-1 AND restriction-2 Numa seqncia de projees, todas, menos a ltima, podem ser ignoradas; i.e., a expresso (A [attribute-list-1]) [attribute-list-2] equivale expresso A [attribute-list-2]

Uma restrio de uma projeo equivalente a uma projeo de uma restrio; i.e., a expresso

(A [ attribute-list-1] ) WHERE restriction-1 equivale expresso (A WHERE restriction-1) [ attribute-list-1]

Diferentes tipos de transformao tambm so possveis durante este estgio de processamento de consulta. Por exemplo, o predicado transformar-se na forma mais simples A.F1 > 3 (substituindo uma juno e uma restrio por (esta converso realizada no DB2. Nesta ltima NOT (p1 AND p2) , pode ser convertido sua A.F1 > B.F2 AND B.F2 = 3 , pode

uma simples restrio).Dessa forma, o predicado forma equivalente (NOT p1) OR (NOT p2)

verso, fica claro que, se o predicado p1 for avaliado como falso, ento no h necessidade de avaliar-se o predicado p2. 2.1.3. Escolha dos procedimentos de baixo nvel Tendo convertido a representao interna da consulta numa forma (padro) mais desejvel, o otimizador deve ento decidir como avaliar a consulta transformada representada pela forma convertida. Neste estgio, consideraes como a existncia de ndices ou outros percursos de acesso, distribuio de valores de dados armazenados, agrupamento fsico de registros etc. vo ter sua participao.

25/05/2004

A estratgia bsica considerar a expresso da consulta como a especificao de sries de operaes (a nveis comparativos) de nvel inferior (juno , restrio etc.), com uma certa independncia entre elas. Para cada operao deste tipo, o otimizador ter avaliado para a mesma um conjunto de procedimentos de implementao pr-definido, de nvel inferior. Por exemplo, haver um conjunto de procedimentos para a implementao de operao de restrio - uma para o caso em que a restrio seja uma condio de igual num campo nico, uma onde o campo da restrio seja indexado, uma onde no indexado mas o dado fisicamente agrupado no campo da restrio, e assim sucessivamente. Cada procedimento ter uma medio de custo.

Tendo usado a informao do catlogo do sistema relativa ao estado corrente do banco de dados (existncia de ndices, comparaescardinais das relaes, etc.) e tendo tambm usado a informao da interdependncia referenciada acima, o otimizador escolher, ento, um ou mais procedimentos para a implementao de cada uma das operaes na expresso da consulta. Este processo , por vezes, chamado de seleo de percurso de acesso. 2.1.4. Gerao de planos de consulta e escolha do melhor O estgio final do processo de otimizao envolve a construo de um conjunto de planos de consulta candidatos, seguido da escolha do melhor - i.e., o mais barato. Cada plano de consulta construdo pela combinao de um conjunto de procedimentos de implementao candidatos, um para cada operao de nvel inferior da consulta. Observemos que normalmente haver diversos planos razoveis - provavelmente misturando vrios - para cada consulta. De fato, pode no ser uma boa idia gerar todos os planos possveis, posto que haver combinaes de vrios deles, e a tarefa de escolher o mais barato pode tornar-se bastante cara pra si; certa tcnica heurstica para manter o conjunto gerado dentro de limites razoveis seria altamente desejvel.

A escolha do plano mais barato naturalmente necessita de um mtodo para atribuio de custo ao plano em questo. A maioria dos sistemas de E/S em discos envolvidos, sendo que alguns tambm consideram a utilizao da CPU. O problema que tudo, salvo as consultas mais simples, necessita da gerao de resultados intermedirios durante a execuo. De forma a estimar o nmero de E/S em disco de forma correta, porm, necessrio estimar os tamanhos dos resultados
9

25/05/2004

intermedirios tambm, e , infelizmente, estes dependem muito dos valores de dados reais. A estimativa correta do custo um problema difcil.

3.

Estimativa do custo de acessos usando ndices

conta os defeitos de ndices e de funes de hashing no custo de avaliao de uma expresso. A presena dessas estruturas, entretanto, tem uma importncia significativa na escolha de uma estratgia de processamento de consultas. - ndices e funes de hashing permitem acessos rpidos a registros contendo um valor especfico na chave de ndice.

O custo estimado que consideramos para expresses da lgebra relacional no levam em

- ndices ( mas no a maioria das funes de hashing ) permitem que os registros de um arquivo sejam lidos em uma ordem de classificao. Se um ndice permite que registros de um arquivo sejam lidos em uma ordem correspondente ordem fsica, esse ndice chamado ndice de agrupamento fsico de registros em blocos. A estratgia detalhada para processamento de consultas chamada plano de acesso para consulta. Um plano inclui no apenas as operaes relacionais a serem executadas, mas tambm os ndices a serm usados, a ordem na qual as tuplas sero processadas e a ordem na qual as operaes sero executadas. Obviamente, o uso de ndices impe a sobrecarga do acesso queles blocos contendo o agrupamento clustering index. Os ndices de agrupamento permitem-nos tirar vantagem do

ndice. Precisamos levar esses acessos a blocos em conta quando estimar-mos o custo de uma estratgia que envolva o uso de ndices.

Consideraremos consultas envolvendo apenas uma relao. Usamos o predicado de seleo para guiar-nos na escolha do melhor ndice a ser usado no processamento de consultas. Como um exemplo de estimativa do custo de uma consulta usando ndices, assuma que estamos processando a consulta:
10

25/05/2004

select nmero-conta from depsito where nome-agncia = "Perryridge" and nome-cliente="Williams" and saldo>1000 Assuma tambm que temos as seguintes informaes estatsticas sobre a relao depsito: 20 tuplas de depsito cabem em um bloco. V(nome-agncia, depsito) = 50. V(saldo,depsito) = 5.000. V(nome-cliente, depsito) = 200. A relao depsito tem 10000 tuplas. Vamos assumir que existam os seguintes ndices em depsitos: Um ndice em forma de rvore-B+ para nome-agncia com clustering. Um ndice em forma de rvore-B+ para nome-cliente sem clustering.

Como antes, devemos fazer a hiptese simplificadora de que os valores so distribudos uniformemente.

Uma vez que V(nome-agncia, depsito)=50, esperamos que 10000/50 = 200 tuplas da relao depsito pertenam agncia Perryridge. Se usamos o ndice em nome-agncia, precisaremos ler essas 200 tuplas e verificar se cada uma satisfaz a clusula where. Uma vez que o ndice tem clustering, a leitura de 200/20 = 10 blocos ser necessria para ler as tuplas de depsito. 20 ponteiros por n. Isto significa que a rvore-B+ do ndice precisa ter entre 3 e 5 ns folha. Com precisam ser lidos. Assim, a estratgia acima requer a leitura total de 12 blocos lidos. E mais, diversos blocos de ndice precisam ser lidos. Assuma que a rvore-B+ do ndice armazena este nmero de ns folhas, a rvore interira tem uma profundidade de 2, ento 2 blocos de ndice

11

25/05/2004

Se usamos o ndice para nome-cliente, estimamos o nmero de acessos a blocos como segue. Uma vez que V(nome-cliente, depsito) = 200, esperamos que 10000/200 = 50 tuplas da relao depsito pertenam a Williams. No entanto, uma vez que o ndice para nome-cliente no tem clustering, antecipamos que um bloco lido ser requerido para cada tupla. Assim, 50 blocos lidos so requeridos apenas para ler as tuplas depsito. Vamos assumir que 20 ponteiros cabem em um n da rvore-B+ para o ndice de nome-cliente. Uma vez que existem 200 nomes de clientes, a rvore tem entre 11 e 20 ns folha. Assim, como no caso da rvore-B+ para o outro ndice, o ndice para nome-cliente tem profundidade de 2, e 2 blocos de acesso so requeridos para ler os blocos de ndice necessrios. Assim, essa estratgia requer um total de 52 blocos lidos. Conclumos que prefervel usar o ndice para nome-agncia.

Observe que, se os dois ndices no tivessem clustering, preferiramos usar o ndice para nome-cliente, uma vez que esperamos apenas 50 tuplas com nome-cliente=Williamscontra 200 tuplas com nome-agncia=Perryridge.Sem a propriedade de clustering, nossa primeira estratgia poderia requerer o acesso a at 200 blocos para ler os dados, uma vez que, no pior dos casos, cada tupla est em um bloco diferente. Adicionamos isso aos dois acessos a blocos num total de 202 blocos lidos. Entretanto, por causa da propriedade de clustering do ndice nome-agncia, realmente menos caro neste exemplo usar o ndice para nome-agncia.

exemplo o seguinte. Use o ndice para nome-cliente para obter os ponteiros para registros com

Um outro modo pelo qual os ndices podem ser usados para processar nossa consulta-

nome-cliente=Williams em vez dos prprios registros. Digamos que P1 represente o conjunto desses ponteiros. Da mesma forma, use o ndice para nome-agncia para obter os ponteiros para registros com nome-agncia=Perryridge. Digamos que P2 represente esse conjunto de ponteiros. Ento P1O P2 um conjunto de ponteiros para registros com nome-agncia= Perryridgee nomecliente=Williams. Esses registros precisam ser recuperados e testados para ver se saldo > 1000. Uma vez que essa tcnica requer que os dois ndices sejam usados, um total de quatro blocos

de ndice so lidos. Estimamos o nmero de blocos que precisam ser lidos do arquivo depsito calculando aproximadamente o nmero de ponteiros em P1O P2.

12

25/05/2004

Como V(nome-agncia, depsito) = 50 e V(nome-cliente, depsito) = 200, estimamos que uma tupla em 50 x 200 ou uma em 10.000 tenha nome-agncia = Perryridge e nome-cliente = Williams. Essa estimativa baseada em uma hiptese de distribuio uniforme e em uma hipotese adicional qua a distribuio de nomes de agncia e nomes de clientes so independentes. Com base nessas tentativas, P1 O P2 estimado como tendo apenas um ponteiro. Assim, apenas um bloco de depsito precisa ser lido. O custo total estimado desta estratgia de cinco blocos lidos. para uma estratgia de processamento de consultas por duas razes: - No h nenhum ndice para saldo. - O predicado de seleo em saldo envolve uma comparao maior do que. Em geral, predicados de igualdade so mais seletivos do que predicados maior do que. Uma vez que temos um predicado de igualdade disponvel (na verdade, temos dois), preferimos comear usando tal predicado j que provvel que ele selecione menos tuplas. A estimativa de custo de acesso usando ndices permite estimar o custo completo, em termos No consideramos o uso do atributo saldo e do predicado saldo > 1000 como um ponto de partida

de acessos a blocos, de uma estratgia. Para uma dada expresso da lgebra relacional, pode ser possvel formular diversas estratgias. A fase de seleo do plano de acesso de um otimizador de consultas escolhe a melhor estratgia para uma dada expresso. possvel que uma expresso da lgebra relacional (para a qual um bom plano exista) seja prefervel uma expresso da lgebra aparentemente mais eficiente, mas que possibilite apenas planos inferiores.

4.

Estratgia de Juno

Nesta seo, aplicamos nossas tcnicas para estimar o custo de processamento de uma consulta ao problema de estimar o custo de processamento de uma junho. A ordem fsica das tuplas numa relao.

A presena de ndices e o tipo de ndice (com clustering ou sem clustering).

O custo de computar um ndice temporrio com o nico fim de procesar uma consulta. Vamos iniciar considerando a expresso
13

25/05/2004

depsitoXcliente e assumindo que n depsito = 10.000. n cliente = 200.

Vamos considerar diversos mtodos para processar a juno e vamos analisar seu custo respectivo.

O nmero de acessos a disco requeridos para computar a juno obviamente depende do tamanho do buffer e do algoritimo de substituio de pginas. Computaremos esse nmero para: Cenrio de pior caso. O buffer consiste em 2 blocos, um contendo um bloco da relaao de depsito e um contendo um bloco da relao cliente. Cenrio de melhor caso. O buffer suficientemente grande para acomodar tanto a relao depsito como a relao cliente.

Calcularemos esses nmeros assumindo procedimentos diferentes para computar a juno.

4.1. Iterao Simples

Vamos assumir pelo momento que no temos quaisquer ndeces. Se no pretendemos criar

um ndice, precisamos examinar cada possvel par de tuplas td em depsito e tc em cliente. Portanto examinamos 10.000 * 200 = 2.000.000 pares de tuplas. Suponha que usemos o procedimento da figura abaixo para computar a juno. Lemos cada tupla de depsito uma vez. Isto pode requerer aproximadamente 10.000 acessos a blocos se cada tupla de depsito reside em um bloco diferente. Cada tupla de cliente deve ser referenciada uma vez para cada tupla de depsito. Isto significa que referenciamos cada tupla de cliente 10.000 vezes. No pior caso, cada, cada uma dessas referncias requer um acesso a disco. Uma vez que ncliente = 200, poderamos fazer 2.000.000 de acessos para ler as tuplas de cliente. Ajuntando tudo, no pior caso poderamos fazer at 2.010.000 acessos a bloco para processar a juno. No cenrio de melhor caso, no entanto, podemos ler ambas as relaes somente uma vez e executar o processamento. Isso requer no mximo 10.200 acessos a blocos, uma melhoria significativa em relao ao cenrio de pior caso.

14

25/05/2004

Se as tuplas de depsito so armazenadas juntas fisicamente, menos acessos so requeridos. Se assumirmos que 20 tuplas de depsito cabem em um bloco, ento a leitura de depsito requer 10.000/20=500 acessos a blocos. De maneira semelhante, assumindo que 20 tuplas de cliente cabem em um bloco, ento no mximo 10 acessos so requeridos para ler a relao cliente na sua totalidade. Assim, somente 10 acessos por tupla de depsito em vez de 200 so necessrios. Isto

implica que no cenrio do pior caso, no mximo 100.000 acessos a blocos so requeridos para ler tuplas de cliente. Portanto, o custo desta abordagem simples de 100.500 acessos a blocos. No caso do melhor cenrio, no entanto, podemos ler ambas as relaes somente uma vez, o que requer no mximo 520 acessos a blocos. for each tupla d in depsito do begin for each tupla in cliente do begin teste o par (d,c) para ver se uma tupla deve ser adicionada ao resultado end end

Se o buffer demasiadametne pequeno para conter inteiramente ambas as relaes na memria principal, podemos ainda obter uma grande economia em acessos a blocos se processarmos as relaes numa base por bloco em vez de numa base por tupla. Novamente, assumindo que as tuplas de depsito esto armazenadas fisicamente juntas, podemos usar o procedimento da figura abaixo para computar depsitoXcliente. Esse procedimento executa a juno considerando um bloco inteiro de tuplas de depsito de uma vez. Ainda precisamos ler a relao depsito inteira a um custo de 500 acessos. No entanto, em vez de leremos a relao cliente uma vez para cada tupla de depsito. Assim, no cenrio do pior caso, uma vez que existem 500 blocos de tuplas de depsito e 10 blocos de tuplas de cliente, a leitura de cliente uma vez para cada bloco de tuplas de depsito requer 10 x 500 = 5.000 acessos a blocos. Assim, o custo total em termos de acesso a blocos de 5.500 acessos (5.000 acessos para blocos de cliente mais 500 acessos eram necessrios para nossa estratgia inicial. for each bloco Bd of depsito do begin for each bloco Bc of cliente do
15

para blocos de depsito). Claramente, isto um avano significativo sobre o nmero de acessos que

25/05/2004

begin

for each tupla d in Bd do begin for each tupla c in Bc do begin end teste o par (d,c) para vers se uma tupla deve ser adicionada ao resultado) end

end

end

Nossa escolha de depsito para o lao externo e cliente para o lao interno foi arbitrria. Se usamos cliente como a relao para o lao externo e depsito para o lao interno, o custo de nossa estratgia final seria um pouco mais baixo (5.010 acessos a blocos). Uma vantagem importante do uso da relao menor (cliente) no lao interno que pode ser possvel armazenar a relao inteira na memria principal temporariamente. Isto acelera o processamento de consultas significativamente uma vez que preciso ler a relao de lao interno apenas uma vez. Se cliente realmente pequeno o suficiente para caber inteiro na memria principal, nossa estratgia requer apenas 500 blocos para ler depsito mais 10 blocos para ler cliente para um total de apenas 510 acessos a blocos.

4.2.

Juno por Intercalao

Nos casos em que nenhuma relao cabe na memria principal, ainda possvel processar a

juno eficientemente se ambas as relaes estiverem armazenads na ordem dos atributos da juno. Suponha que as relaes cliente e depsito estejam ordenadas por nome-cliente. Nesse caso

podemos executar a operao de juno por intercalao (merge join). Associamos um ponteiro a medida que o algoritmo executado, os ponteiros se movem atravs da relao. lido um grupo de correspondentes da outra relao so lidas. Umavez que as relaes esto ordenadas, as tuplas com o mesmo valor nos atributos da juno esto em ordem consecutiva. Isto nos permite ler cada tupla apenas uma vez. No caso, em que as tuplas das relaes so armazenadas fisicamente juntas, esse algoritmo nos permitecomputar a juno lendo cada bloco exatamente uma vez.
16

cada relao. Esses ponteiros apontam inicialmente para a primeira tupla da respectiva relao. tuplas de uma relao com memo valor nos atributos da juno. Ento as tuplas (se houver)

25/05/2004

exemplo de depsito x cliente. Nesse caso, existe um total de 510 acessosa blocos. Este mtodo cliente inteira cabe dentro da memria principal. Em vez disso, suficiente manter todas as tuplas ambas as relaes sejam grandes. Uma desvantagem do mtodo de juno por intercalao que ambas as relaes precisam estar classificadas fisicamente. pd := endereo da primeira tupla de depsito; pc := endereo da primeira tupla de cliente; while (pc @ nulo) do begin

A figura abaixo mostra como o esquema de juno por intercalao aplicado a nosso

to bom quanto o mtodo anterior de juno apresentado para o caso especial no qual a relao com o mesmo valor para os atributos da juno na memria principal. Isto vivel mesmo que

tc := tupla para a qual pc aponta; sc := {tc} ajuste pc para apontar para a prxima tupla de cliente; pronto := false; begin; while (not pronto and pc @ nulo) do tc' := tupla para a qual pc aponta; then begin

if tc' [nome-cliente] = tc[nome-cliente] si := sc UNIO {tc}; end

ajuste pc para apontar para a prxima tupla de cliente; else pronto := true;

td := tupla para a qual pd aponta;

ajuste pd para apontar para a prxima tupla de depsito; while (td[nome-cliente] < [nome-cliente] do begin td := tupla para a qual pd aponta;
17

25/05/2004

while (td[nome-cliente] = tc[nome-cliente]) do begin for each t in sc do begin end compute t x td e adicione ao resultado;

end

ajuste pd para apontar para a prxima tupla de depsito;

ajuste pd para apontar para a prxima tupla de depsito; end td := tupla para a qual pd aponta;

4.3.

Uso de um ndice
As trs estratgias consideradas dependem das tcnicas fsicas usadas para armazenamento

end.

das relaes. A juno por intercalao requer uma ordenao. A iterao orientada a blocos requer que as tuplas de cada relao estejam armazenadas juntas fisicamente. Apenas a terceira estratgia, iterao simples, pode ser aplicada se hover tuplas sem sem clustering. O custo da iteracao simples de nosso exemplo depsito x cliente de 2 milhes de acessos a blocos. Quando um ndice computada com significamente menos acessos a blocos. Freqentemente, os atributos da juno formam uma chave de busca para um ndice de uma usado, mas sem qualquer hiptese sendo feita sobre o armazenamento fsico, a ligao pode ser

das relaes da juno. Nesse caso, podemos considerar uma estratgia de juno que usa tal ndice. usando nome-cliente. Dada a tupla d em depsito, no mais necessrio ler a relao cliente inteiro. d[nome-cliente].

A estratgia simples da Figura 5.1 pode ser feita mais eficientemente se existir um ndice de cliente Em vez disso, o ndice usado para buscar as tuplas em cliente para as quais o valor nome-cliente

depsito apenas uma busca de ndice necessria. Se assumirmos (como antes) que nclientes = 200,

Ainda precisamos de 10.000 acessos para ler depsito. Entretanto, para cada tupla de

e que 20 ponteiros cabem em um bloco, ento essa pesquisa requer no mximo o acesso a dois blocos de ndices, mais um bloco de acesso para ler a tupla de cliente propriamente dita. Fazemos o
18

25/05/2004

acesso a tr6es blocos por tupla de depsito em vez de 200. Adicionando isto aos 10.000 acessos para ler depsito, descobrimos que o custo total dessa estratgia de 40.000 acessos.

Embora esse custo de 40.000 acessos possa parecer alto, precisamos lembrar que encontramos estratgias mais eficientes apenas quando assumimos que as tuplas estavam armazenadas fisicamente juntas. Se essa hiptese no valer para as relaes que esto sento juntadas, ento a estratgia que acabamos de apresentar altamente desejvel. Realmente, a ndice com o nico propsito de processar esta nica consulta e elimin-la depois, podemos executar menos acessos do que se usasse a estratgia da iterao simples. economia de 160.000 acessos suficiente para justificar a criao do ndice. Mesmo que crie o

4.4.

Juno com Hashing

Pode ser compensador construir um ndice especificamente para o uso na computao de

uma juno, mesmo que esse ndice no seja retido aps a computao da juno. Em vez de construir um ndice em forma de rvore-B+, freqentemente prefervel usar o hashing para um ndice do tipo "use uma vez" construdo para auxiliar a computao de uma nica juno.

Uma funo de hashing h usada para as tuplas de ambas as relaes sobre os atributos da funo. Os buckets resultantes, que contm ponteiros para tuplas das relaes, so usados para limitar o nmero de pares de tuplas que devem ser comparados. Se d uma tupla de depsito e c uma tupla de cliente, ento d e c devem ser testadas apenas se h(c) = h(d). Se h(c) DIFERENTE h(d), ento c e d devem ter valores diferentes para nome-cliente. Entretanto, se h(c) = h(d) precisamos testar c e d, uma vez que possvel que eles tenham valores para nome-cliente que do o mesmo valor de hashing.

A figura abaixo mostra os detalhes do algoritmo de juno com hashing como aplicado ao nosso exemplo de depsitos x clientes. A funo de hashing h deveria ter as boas propriedades de aleatoriedade e uniformidade. Usaremos essas propriedades para estimar o custo da execuo da juno com hashing. Na Figura 5.4 assumimos que:

19

25/05/2004

h uma funo de hashing mapeando valores de nome-cliente em {0, 1, ..., max}. inicialmente vazio.

Hc0, Hc1... Hcmax representam buckets de ponteiros para tuplas de cliente, cada um Hd0, Hd1... Hdmax representam buckets de ponteiros para tuplas de depsito, cada um iniciando vazio. Usamos em seguida essas propriedades para estimar o custo da execuo de uma juno com hashing. A distribuio de ponteiros para buckets de hashing nos dois laos for do algoritmo requer uma leitura completa de ambas as relaes. O custo desta operao requer 510 acessos a blocos se as tuplas de depsito e as tuplas de cliente estiverem armazenadas juntas fisicamente. Uma vez que os buckets contm apenas ponteiros, assumimos que eles cabem na memria principal, assim nenhum acesso a disco necessrio para fazer acesso aos buckets. h. O lao for final externo computa A parte final do algoritmo varre os valores assumidos por h. Digamos que i sejaum valor de

rd x rc onde rd o conjunto de tuplas de depsito cujo valor de hashing as coloca no bucket i e rc o conjunto de tuplas de cliente cujo valor de hashing leva-as ao bucket i. Esta juno computada usando a iterao simples, uma vez que esperamos que rd e rc sejam suficientemente pequenos para caber na memria principal. Uma vez que o hashing de uma tupla leva-a exatamente em um bucket, cada tupla lida apenas uma vez pelo lao for final externo. Como observamos anteriormente, isto requer 510 acessos a bloco. Assim, o custo total estimado de uma juno com hashing cujo contra domnio seja grande o suficeiente para asseurar que os buckets contenham um nmero suficientemente pequeno de ponteiros para que rc e rd caibam na memria principal. O otimizador no deve escolher uma funo de hashing que tenha um contra domnio to grande que os buckets fiquem vazios. Isto gastaria espao e foraria o algoritmo de juno com hashing a incorrer em desperdcio processando buckets vazios. for each tupla c in cliente do begin i := h(c[nome-cliente]);
20

25/05/2004

for each tupla d in depsito do begin i := h(d[nome-cliente]);

end

Hci := Hci UNIO {ponteiro para c};

for i := 0 to max do begin rc := ;

end

Hci := Hdi UNIO {ponteiro para d};

rd := ;

for each ponteiro pc in Hci do begin c := tupla para a qual pc aponta rc := rc UNIO {c}

for each tupla d in rd do begin for each tupla d in rc do begin teste o par (d,c) para ver se uma tupla poderia ser adicionada ao resultado end end

end

end.

4.5.

Juno Tripla
Vamos agora considerar uma juno envolvendo trs relaes: Assuma que ndepsito = 10.000, ncliente = 200 e nagncia = 50. No apenas temos uma agncia x depsito x client

escolha de estratgia para o processamento de juno, mas temos tambm uma escolha de qual

21

25/05/2004

juno computaremos primeiro. Existem muitas estratgias possveis a considerar. Analisaremos diversas delas a seguir e deixaremos outras como exerccios para o leitor. Estratgia 1. Compute a juno depsitoxcliente usando uma das tcnicas apresentadas dessa juno tem no mximo 10.000 tuplas (o nmero de tuplas em depsito). Se construirmos um ndice em agncia para nome-agncia, podemos computar agncia x (depsito x cliente) considerando cada tupla t de (depsito x cliente) e buscando a tupla em agncia com um valor de nome-agncia igual a t[nome-agncia]. Uma vez que nome-agncia uma chave de agncia, sabemos que precisamos examinar apenas uma tupla de agncia para cada uma das 10.000 tuplas

anteriormente. Uma vez que nome-cliente uma chave de cliente, sabemos que o resultado

em (depsito x cliente). O nmero exato de acessos a blocos requeridos por esta estratgia depende do modo pelo qual computamos (depsito x cliente) e do modo pelo qual agncia armazenada fisicamente. Diversos exerccios examinam os custos de vrias possibilidades. Estratgia 2. Compute uma juno tripla sem construir qualquer ndice. Isto requer a verificao de 50*10.000*200 possibilidades, ou num total de 100.000.000. Estratgia 3. Em vez de executarmos duas junes, executamos um par de junes de cada vez. Essa tcnica primeira envolve a construo de dois ndices: Sobre agncia usando nome-agncia Sobre cliente usando nome-cliente.

correspondentes em cliente e as tuplas correspondentes em agncia. Assim, examinamos cada tupla de depsito exatamente uma vez..

Em seguida consideramos cada tupla t em depsito. Para cada t, buscamos as tuplas

A estratgia 3 representa uma forma que no havamos considerado anteriormente. Esta no corresponde diretamente a uma operao da lgebra relacional. Em vez disso, combina duas juno de trs relaes mais eficientemente do que usando duas junes de duas relaes. Os custos operaes e uma operao especial. Com a estratgia 3, frequentemente possvel executar uma

22

25/05/2004

relativos dependem do modo pelo qual as relaes esto armazenadas, da distribuio de valores dentro das colunas e da presena de ndices. Os exerccios oferecem oportunidade de computar esses custos em diversos exemplos.

5.

Estratgias de Juno para processadores paralelos

As estratgias de juno que consideramos at agora assumem um nico processador est

disponvel para computar a juno. Nesta seo, consideramos o caso em que diversos processadores esto disponveis para a computao paralela de uma juno. Assumimos um ambiente de multiprocessamento no qual os processadores so parte de um sistema de computadores, todos dividindo uma nica memria principal. Numerosas arquiteturas tem sido propostas para processadores paralelos para aplicaes de banco de dados. Muitas dessas mquinas de banco de dados so discutidas em referncias de notas bibliogrficas. Consideraremos uma arquitetura simples com os seguintes recursos:

- Todos os processadores tem acesso a todos os discos.

- Todos os processadores compartilham a memria principal.

As tcnicas apresentadas a seguir para o processamento paralelo de junes podem ser adaptadas as outras arquiteturas nas quais cada processador tem sua prpria memria particular.

5.1.

Juno Paralela
Nas tcnicas que discutimos para processar junes em um nico processador, a eficicncia

obtida pela reduo do nmero de pares de tuplas que precisam ser testados. A meta de um

algoritimo de juno paralela dividir os pares a serem testados entre os diversos processadores. Cada processador ento computa parte da juno. No passo final, os resultados de cada processador so coletados para produzir o resultado final.

23

25/05/2004

processadores. Se tal diviso feita sem qualquer sobrecarga, uma juno paralela usando N processadores tomar 1/N do tempo que a mesma juno tomaria em um nico processador. Na prtica, o aceleramento menos dramtico por diversas razes:

Idealmente, o trabalho geral de computar a juno particionado igualmente entre todos os

- Ocorre sobrecarga ao se particionar o trabalho entre os processadores.

- Ocorre sobrecarga ao se coletar os resultados computados para cada processador para produzir o resultado final. - O esforo feito para dividir o trabalho igualmente apenas uma aproximao, assim alguns processadores podem ter mais trabalho do que outros. O resultado final no pode ser obtido at que o ltimo processador tenha de fato terminado. - Os processadores podem competir por recursos compartilhados do sistema. Isto resulta em demoras medida que os processadores esperam que outros processadores liberem os recursos.

Vamos considerar novamente nossos exemplos de depsitos x cliente, assumindo que temos N processadores P1, P2, ... ,PN. Dividimos depsito em N participaes de igual tamanho: depsito 1, depsito2,...,depsitoN. (Para simplificar, assumimos que o tamanho da relao depsito um computamos a unio dos resultados parciais computados por cada processador. mltiplo de N). Ento cada processador Pi computa depsitoixcliente em paralelo. No passo final,

O custo desta estratgia depende de diversos fatores:

- A escolha do algoritimo de juno usado por cada processador.

- O custo de montagem do resultado final.

- Os atrasos impostos pela contano de recursos. Embora cada processador use sua prpria partio de depsito, todos os processadores fazem acesso a cliente. Se a memria principal no
24

25/05/2004

suficientemente grande para guardar a relao cliente inteira, os processadores precisam sincronizar seus acessos a cliente para reduzirem o nmero de vezes que cada bloco de cliente precisa ser lido do disco.

O potencial de conteno da memria principal ao armazenar tuplas de cliente sugere que tomemos alguns cuidados na diviso do trabalho entre os processadores para reduzir a conteno. Existem muitos modos de fazer isso. Uma tcnica simples usar uma verso paralela do algoritimo de juno com hashing. Escolhemos uma funo de hashing cujos limiters so {1,2,...,N}. Isto permite atribuir cada

um dos N processadores para exatamente um dos buckets do hashing. Uma vez que o lao final

externo for do algoritimo atua sobre os buckets, cada processador a iterao que corresponde ao seu bucket atribudo. Nenhuma tupla atribuda a mais de um bucket, assim no h conteno para as tuplas de cliente. Uma vez que cada processador considera um par de tuplas por vez, o total da requisio de memria particular pelo algoritimo suficientemente baixo e a conteno de espao na memria principal improvvel.

5.2.

Juno Mltipla em duto (PIPELINED)

Nesta seo, exploramos a possibilidade de computar diversas junes em paralelo. Esta

uma questo importante, uma vez que muitas consultas do mundo real, particularmente aquelas expressas em termos de uma viso, envolvem diversas relaes.

Vamos considerar uma juno de quatro relaes. Claramente, podemos computar t1 r1 x r2 em paralelo com t2 r3 x r4. Quando essas duas computaes estiverem completas, computamos. t1xt2 r1 x r2 x r3 x r4

25

25/05/2004

Um paralelismo ainda maior pode ser feito ajustando um duto ("pipeline") que permite que as trs computaes sejam feitas em paralelo. Digamos que o processador em r1 x r2, ele deixa essas tuplas disponveis para o processador P3. Da mesma forma, medida que o processador P2 computa tuplas em r3 x r4, ele torna essas tuplas disponveis para P3. Assim, P3 tem disponveis algumas tuplas de r1 x r2 e r3 x r antes que os processadores P1 e P2 tenham de (r1 x r2) x (r3 x r4) antes mesmo que r1 x r2 e r3 x r4 tenham sido completamente computadas. execute a computao r1 x r2 e digamos que P2 execute r3 x r4. medida que P1 computa tuplas

acabado totalmente seus servios. P3 pode usar essas tuplas disponveis para iniciar a computao

Essa juno em duto, que mostra um "fluxo" de tuplas de P1 para P3 e de P2 para P3. Em nossa mquina paralela assumida, as tuplas so passadas via memria principal partilhada. Esta tcnica aplicvel a outras arquiteturas paralelas. Os processadores P1 e P2 esto livres para usar qualquer um dos algoritimos de juno que

consideramos antes. A nica modificao que quando uma tupla t adicionada ao resultado, t consistindo em ENDP1 e ENDP2, respectivamente, feita aps o trmino da computao. pronto1: = false pronto2: = false de1: = ; de2: = ;

precisa ser tornada disponvel para P3 colocando tna fila. Alm disso, uma entrada especial de fila

resultado: = ; begin

while not pronto 1 or not pronto 2 do if fila esta vazia then espere at que a fila no esteja vazia; t: = entrada mais alta na fila; if t = ENDP1 then pronto 1 := true else if t de P1 then begin

else if t = ENDP2 then pronto 2: = true

de 1: = de1 U{t}; resultado: = resultado U({t}x de 2); end

26

25/05/2004

else /*t de P2*/ begin de 2: = U{t}; resultado: = resultado U (de 1x {t}); end end

O conceito ilustrado pela computao em duto de uma juno qudrupla r1x r2 x r3 x r4 pode ser estendido para manipular junes com n relaes.

6.

Organizao Fsica
As tcnicas que consideramos para a computao de juno paralela aumentam a taxa em

que ocorrem acessos a disco. Para a juno paralela dupla da Seo 6.1, vimos que, escolhendo cuidadosamente o modo pelo qual a relao particionada, poderamos reduzir a conteno de disco. Entretanto, para aquela tcnica, assim como para a tcnica da juno em duto da seo precedente, o disco provavelmente ser o gargalo.

A fim de reduzir a conteno nos acessos a disco, o banco de dados pode ser particionado em diversos discos. Isto permite diversos acessos a disco a serem servidos em paralelo. Entretanto, a fim de explorarmos o potencial de acessos paralelos a disco, precisamos escolher uma boa distribuio de dados entre os discos.

O algoritimo de juno paralela dupla requer diversos processadores para fazer o acesso a relaes em paralelo. A fim de reduzir a conteno, til distribuir as tuplas de relaes individuais entre os diversos discos. Esta tcnica chamada fatiamento de disco (disk striping). Vamos juno com hashing que apresentamos na Seo 6.1. considerar um exemplo de fatiamento de disco particularmente bem adequado verso paralela da

Usamos a funo de hashing do algoritimo de juno com hashing que atribui tuplas ao disco. Todos os grupos de tuplas que partilham um bucket so atribudos para o mesmo disco. A cada grupo designado um disco separado se possvel. De qualquer forma, os grupos so distribudos uniformemente entre os discos disponveis. Essa forma de fatiamente permite que a
27

25/05/2004

juno paralela dupla com hashing explore acessos a disco paralelos. No caso em que cada grupo atribudo a um disco separado, no h conten para acessos a disco! A tcnica de fatiamento de disco menos til para a juno em duto da Seo 6.2. Para essa

juno, desejvel que cada relao seja mantida em um disco e que relaes distintas sejam

atribudas a discos separados at o grau possvel. No esquema para a Figura 9.5, para computao de (r1 x r2) x (r3 x r4), se cada relao est em um disco diferente, a conteno eliminada pelos processadores P1 e P2.

claro que a organizao fsica tima difere para consultas diferentes. O administrador do banco de dados precisa escolher uma organizao fsica que acredite ser boa para a composio esperada de consultas do banco de dados. O otimizador de consultas do sistema de banco de dados precisa escolher entre as vrias tcnicas paralelas e sequenciais que consideramos, estimando o custo de cada tcnica em uma dada organizao fsica.

28

25/05/2004

7.

Estrutura do Otimizador de Consultas

Discutimos apenas algumas das muitas estratgias de processamento de consultas usadas em

vrios sistemas comerciais de banco de dados. Como a maioria dos sistemas implementa apenas umas poucas estratgias, o nmero de estratgias, o nmero de estratgias a ser considerado pelo otimizador de consultas limitado. Outros sistemas consideram um grande nmero de estratgias. Para cada estratgia, computado um custo estimado.

Alguns sistemas reduzem o nmero de estratgias que necessitam ser levadas em considerao fazendo uma estimativa heurstica de uma boa estratgia. Seguindo isto, o otimizador considera cada estratgia possvel, mas finaliza to logo ele determina que o custo maior do que a melhor das estratgias consideradas anteriormente. Se o otimizador inicia com uma estratgia que provavelmente de baixo custo, apenas umas poucas estratgias competitivas requerero uma anlise completa de custo. Isto pode reduzir as despesas gerais do otimizador de consultas. A fim de simplificar a tarefa de seleo de estratgia, uma consulta pode ser dividida em diversas subconsultas. Isto no apenas simplica a seleo de estratgia, mas tambm permite ao otimizador de consultas reconhecer casos em que uma subconsulta particular aparece diversas vezes na mesma consulta. Se tais subconsultas so computadas apenas uma vez, o tempo economizado na fase de otimizao de consulta e na execuo da prpria consulta. O reconhecimento de subconsults iguais anlogo ao reconhecimento de subexpresses iguais em muitos compiladores com otimizao para linguagens de programao. Claramente, o exame de uma consulta em busca de subconsultas iguais e a estimativa de custo de um grande nmero de estratgias impem uma sobrecarga de trabalho substancial no processamento de consultas. Entretanto, o custo adicional da otimizao de consulta normalmente mais do que compensador pela economia no tempo de execuo de uma consulta. A economia ampliada nas aplicaes processadas regularmente e reexecutam as mesmas consultas em cada execuo. Por isso, a maioria dos sistemas comerciais incluem otimizadores relativamente complexos. As notas bibliogrficas do referncias a descries de otimizadores de consultas de sistemas de banco de dados.

29

25/05/2004

Bibliografia : Livros: Sistemas de bancos de dados Herry F. Korth Abraham Silberchatz 2 Ed - SP

30