Otimização e Execução de Consultas Caso Centralizado Parse Query

Transcrição

1 Bancos de Dados III Processamento de Consultas em Bancos de Dados Distribuídos Rogério Costa 1 Otimização e Execução de Consultas Caso Centralizado Parse Query Check de Semântica Query Rewrite Otimização do Plano de Acesso Geração de Código 2 1

2 Processamento de Consultas Caso Centralizado Análise Sintática e Tradução Tradução da consulta para uma representação interna de uma consulta ao sistema SQL -> Álgebra relacional estendida Conferência da sintaxe da consulta definida pelo usuário dos nomes das relações Etc 3 Processamento de Consultas Caso Centralizado Otimização Dada uma consulta, há diversos métodos possíveis de calcular a resposta uma consulta em SQL pode ser escrita de diversas formas uma consulta em SQL pode ser traduzida em álgebra relacional de vários modos há diversos algoritmos diferentes para executar uma operação algébrica relacional 4 2

3 Processamento de Consultas Caso Centralizado Exemplo AGÊNCIA(nome_agência, cidade_agência, fundos) CONTA(número_conta, saldo, nome_agência) DEPOSITANTE(nome_cliente, número_conta) Consulta: Quais os nomes dos clientes que possuem conta em agências na cidade Brooklin com saldo abaixo de 1.000? SELECT FROM WHERE nome_cliente agencia A, conta C, depositante D C.numero_conta = D.numero_conta and A.nome_agencia = C.nome_agencia and A.cidade_agencia = Brooklin and C.saldo < Processamento de Consultas Caso Centralizado Exemplo SELECT FROM WHERE Π nome_cliente nome_cliente agencia A, conta C, depositante D C.numero_conta = D.numero_conta and A.nome_agencia = C.nome_agencia and A.cidade_agencia = Brooklin and C.saldo < Π nome_cliente σ cidade_agencia= Brooklin saldo < depositante agencia σ cidade_agencia= Brooklin σ saldo < conta depositante agencia conta 6 3

4 Processamento de Consultas Caso Centralizado Π nome_cliente classificar para remover duplicatas hash-junção merge-junção depositante σ cidade_agencia= Brooklin σ saldo < use o índice 1 use a varredura linear agencia conta 7 Processamento de Consultas Caso Centralizado Otimização Plano de Execução Seqüência de operações primitivas que podem ser usadas para executar uma consulta Os diferentes planos de execução podem ter diferentes desempenhos. É de responsabilidade do sistema (e não do usuário) escolher um plano de execução que minimize o tempo de execução ou que maximize o throughput 8 4

5 Processamento de Consultas Caso Centralizado Consulta em alto nível definida pelo usuário Transformação que garanta: Corretude: consulta gerada tem que ser equivalente semanticamente, ou seja produzir o mesmo resultado. Eficiência: Minimizar uma função de custos e/ou maximizar o desempenho e/ou maximizar o throughput (parâmetros mais relevantes: I/O de disco, CPU) Consulta em baixo nível para o sistema 9 Processamento de Consultas Caso Centralizado Otimizadores Baseados em regras Baseados em estatísticas 10 5

6 Processamento de Consultas Caso Centralizado Otimização baseada em regras - Algumas estratégias... 1 single row by rowid 2 single row by cluster join 3 single row by hash cluster key with unique or primary key 4 single row by unique or primary key 5 cluster join 6 hash cluster key 7 indexed cluster key 8 composite key 9 single-row indexes 10bounded range search on indexed columns 11unbounded range search on indexed columns 12sort-merge join 13max or min of indexed columns 14order by on indexed columns 15full table scan 11 Processamento de Consultas Caso Centralizado Otimização baseada em custos - escolha entre diferentes planos de execução através de estimativa do custo de cada plano Os otimizadores de consulta utilizam informações estatísticas armazenadas no catálogo do SGBD, que inclui, por exemplo: nr = número de tuplas da relação r br = número de blocos que contém tuplas da relação r sr = tamanho em bytes de uma tupla da relação r V(A,r) = número de valores distintos que aparecem na relação r para o atributo A. SC(A,r) = cardinalidade de seleção do atributo A da relação r. Ou seja, número médio de registros que satisfaz a condição de igualdade no atributo A.Se A for chave primária, a cardinalidade é 1. Mas se não, estima-se que os valores distintos de V(A,r) são distribuídos uniformemente entre as tuplas. 12 6

7 Processamento de Consultas Caso Centralizado A otimização por custo demanda estatísticas Para gerar estatísticas em uma tabela cada SGBD disponibiliza um comando: Oracle: analyze; DB2: runstats; SQLServer: create/update statistics; 13 Planos de Execução Existem dois tipos básicos de operação: Métodos de Acesso (varreduras seqüenciais e indexadas) Outras operações (junções, uniões, eliminação de duplicatas) 14 7

8 Varredura Seqüencial Leitura seqüencial de todas as páginas de uma tabela Comumente chamada de full table scan SGBDs costumam implementar sequential prefetch (read ahead) Eficiente para consultar todas ou quase todas as linhas de uma tabela 15 Varredura Indexada Leitura dos dados através de um ou mais índices Comumente chamada de indexed table scan Vários índices possíveis: árvores B+, bitmaps, árvores R Eficiente para recuperar subconjunto restrito dos dados Índices podem ser "clusterizados" ou "não-clusterizados" 16 8

9 Ordenação Operação básica para diversas outras operações físicas Resolve a cláusula ORDER BY Se o conjunto a ser ordenado não cabe em memória, esta operação pode ser muito cara Comumente chamada de sort 17 Eliminição de Duplicatas e Agregação Estas operações são implementadas em geral através de uma ordenação (sort) Após a ordenação pelo critério de agregação, o resultado é varrido e a operação é computada Também é possível resolver este tipo de operação através de técnicas de hash 18 9

10 União Podemos usar UNION ou UNION ALL em consultas UNION ALL: realiza uma operação de concatenação entre os conjuntos (concatenate) UNION: realiza a concatenação (concatenate) seguida de eliminação de duplicatas (sort ou hash) 19 Intersecção e Diferença Operações de conjunto semelhantes a eliminação de duplicatas Em geral, são resolvidas com ordenações (sort) seguidas da operação propriamente dita Também é possível utilizar métodos de hash 20 10

11 Junções Os algoritmos clássicos utilizados em junções são: Loops Aninhados (Nested Loops Join) Ordenação/Intercalação (Merge Join) Hashing (Hash Join) Existem outros algoritmos: Hybrid hash join Star join Nested Loops T Outer Table T2 Inner Table 22 11

12 Nested Loops Eficiente quando: Outer table pequena ou filtrada Índice clusterizado para acessar inner table Poucas páginas da inner table acessadas 23 Merge Join Ordenada Ordenada Inner Table Outer Table 24 12

13 Merge Join Eficiente quando: São acessadas muitas linhas das duas tabelas Não existem índices adequados Atributos de junção com muitos valores repetidos 25 Hash Join Build Phase 10 f(chave) Outer Table Probe Phase Inner Table 26 13

14 Hash Join Eficiente quando: Hash table é pequena, cabendo em memória Atributo de junção da menor tabela é único Não existem índices para a junção 27 Fator de Filtro Fator de filtro de um predicado: percentual de linhas da tabela que satisfazem determinado predicado. Utilizado pelo Otimizador para: estimar tamanho da tabela resultado decidir sobre uso de índices e outras estratégias de acesso Calculado com base nas estatísticas existentes 28 14

15 Fator de Filtro Fator de filtro de um predicado: número entre 0 e 1: 0 FF 1 FF 0 poucas linhas FF 1 todas as linhas da tabela 29 Fator de Filtro Estatísticas: Tabela de Empregados com linhas Coluna Sexo: 2 valores distintos. Estimativas: FF(M) = 0.5, FF(F) = 0.5 Select nome from empregados where sexo = M Estima retorno de 5000 linhas Não usa índice Select nome from empregados where sexo = F Estima retorno de 5000 linhas 30 15

16 Fator de Filtro Estatísticas com a presença de Histograma: otimizador pode perceber distribuição não-uniforme: tabela de Empregados com linhas: coluna Sexo: distribuição não uniforme. estatísticas de distribuição não uniforme: M: empregados F: empregados FF(F) = 0.1 Para consulta sexo = `F`, otimizador pode decidir utilizar o índice da coluna sexo 31 Fator de Filtro x Índices O fator de filtro influencia diretamente na utilização de índices => quando consulta retorna poucas linhas e existem índices adequados, otimizador pode utilizar índices; Poucas linhas depende de SGBD para SGBD e de versão para versão

17 Fator de Filtro Predicado composto: AND select * from empregados where dept = 600 and sexo = m and cargo = pgmr FF(sexo) = 0.9 FF(dept) = 0.2 FF(cargo) = 0.1 FF = 0.9 * 0.2 * 0.1 = Estimativa para a tabela resultado: 180 linhas 33 Plano de Execução Exemplo: SELECT endereço, data-nascimento FROM empregado WHERE nome = Chico Cesar Execution Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMPREGADO' 2 1 INDEX (UNIQUE SCAN) OF 'PK_EMP' (UNIQUE) 34 17

18 Reescrita Exemplo Oracle: Select max(salario) From empregado Group by depnum Having depnum = Operation Name Rows Bytes Cost SELECT STATEMENT FILTER SORT GROUP BY TABLE ACCESS FULL EMPREGADO 100K 1M Reescrita Exemplo Oracle Select max(salario) From empregado Where depnum = 100 Custo cai de 360 para 2! Queda para apenas 0,5% do original!!! Operation Name Rows Bytes Cost SELECT STATEMENT SORT AGGREGATE 1 16 TABLE ACCESS BY INDEX RO EMPREGADO 100 1K 2 INDEX RANGE SCAN IDX_EMP_DEPNUM

19 Reescrita Eliminar DISTINCT Verificar a lógica da aplicação Para consultas em uma única tabela, verificar se o resultado da consulta contém alguma coluna definida como chave única Para consultas com junções verificar o tipo de junção, as colunas da junção e as colunas resultado 37 Reescrita Exemplo Oracle: select distinct ident, nome from empregado; Operation Name Rows Bytes Cost SELECT STATEMENT 100K 2M 937 SORT UNIQUE 100K 2M 937 TABLE ACCESS FULL EMPREGADO 100K 2M 102 select ident, nome from empregado; Custo =

20 Junções e Sub-Consultas Sem estatísticas select E.Ident, E.nome from empregado E where exists ( select * from dependente D where D.Idemp = E.Ident ) Execution Plan SELECT STATEMENT Optimizer=CHOOSE FILTER TABLE ACCESS (FULL) OF EMPREGADO' INDEX (RANGE SCAN) OF 'IDX_DEPENDENTE_IDEMP' (NO N-UNIQUE) 39 Junções e Sub-Consultas Sem estatísticas select E.Ident, E.nome from Empregado E, Dependente D where D.Idemp = E.Ident Execution Plan SELECT STATEMENT Optimizer=CHOOSE NESTED LOOPS TABLE ACCESS (FULL) OF 'DEPENDENTE' TABLE ACCESS (BY INDEX ROWID) OF EMPREGADO' INDEX (UNIQUE SCAN) OF 'IDX_EMPREGADO_ID' (UNIQUE) 40 20

21 Junções e Sub-Consultas Sem estatísticas select E.Ident, E.nome from Empregado E where E.Ident in ( select IdEmp from Dependente D) Execution Plan SELECT STATEMENT Optimizer=CHOOSE NESTED LOOPS VIEW OF 'VW_NSO_1' SORT (UNIQUE) TABLE ACCESS (FULL) OF 'DEPENDENTE' TABLE ACCESS (BY INDEX ROWID) OF EMPREGADO' INDEX (UNIQUE SCAN) OF 'IDX_EMPREGADO_ID' (UNIQUE) 41 Com estatísticas Execution Plan Junções e Sub-Consultas select E.Ident, E.nome from Empregado E where exists ( select * from Dependente D where D.Idemp = E.Ident ) select E.Ident, E.nome from Empregado E where E.Ident in ( select IdEmp from Dependente D) SELECT STATEMENT Optimizer=CHOOSE (Cost=10 Card=1640 Bytes=173840) HASH JOIN (SEMI) (Cost=10 Card=1640 Bytes=173840) TABLE ACCESS (FULL) OF 'EMPREGADO' (Cost=5 Card=2200 Bytes=226600) INDEX (FAST FULL SCAN) OF 'IDX_DEPENDENTE_IDEMP' (NON-UNIQUE) (Cost=2 Card=3000 Bytes=9000) 42 21

22 Junções e Sub-Consultas Com estatísticas select E.Ident, E.nome from Empregado E, Dependente D where D.Idemp = E.Ident Execution Plan SELECT STATEMENT Optimizer=CHOOSE (Cost=8 Card=3000 Bytes=318000) HASH JOIN (Cost=8 Card=3000 Bytes=318000) INDEX (FAST FULL SCAN) OF 'IDX_DEPENDENTE_IDEMP' (NON-UNIQUE) (Cost=2 Card=3000 Bytes=9000) TABLE ACCESS (FULL) OF 'EMPREGADO' (Cost=5 Card=2200 Bytes=226600) 43 Processamento de Consultas Caso Distribuído Consulta em alto nível definida pelo usuário Transformação que garanta: Corretude: consulta gerada tem que ser equivalente semanticamente, ou seja produzir o mesmo resultado. Eficiência: Minimizar uma função de custos e/ou maximizar o desempenho e/ou maximizar o throughput (parâmetros mais relevantes: I/O de disco, CPU, custo de comunicação) Consulta em baixo nível para o sistema 44 22

23 Processamento de Consultas Caso Distribuído Minimizar a função de custo: custo de I/O + custo de CPU + custo de comunicação Estes fatores podem ter diferentes pesos em diferentes ambientes Wide area networks - WANs Custo de comunicação será dominante Pequena largura de banda Menor velocidade Grande overhead de comunicação Alguns algoritmos irão ignorar todos os outros custos Local area networks - LANs Custos de comunicação não são dominantes Considerar outros fatores (I/O, CPU,.) 45 Exemplo Processamento de Consultas Caso Distribuído EMP(eno, ename,etitle): dados pessoais do empregado PROJ(pno,pname,budget): dados do projeto ASG(eno, pno, resp, dur): qual projeto um empregado trabalha e sua responsabilidade e tempo gasto no projeto. Consulta: Quais os nomes dos empregados que estão gerenciando um projeto? SELECT ename FROM EMP, ASG WHERE emp.eno = asg.eno and asg.resp = Manager 46 23

24 Processamento de Consultas Caso Distribuído Exemplo - Quais os nomes dos empregados que estão gerenciando um projeto? SELECT ename FROM EMP, ASG WHERE emp.eno = asg.eno and asg.resp = Manager Opção 1: Opção 2: Π ename (σ asg.resp= Manager emp.eno = asg.eno (EMP x ASG)) Π ename (EMP eno (σ asg.resp= Manager (ASG))) 47 Processamento de Consultas Caso Distribuído - Exemplo Site 3 Site 4 EMP1= σ eno <= E3 (EMP) EMP2 = σ eno > E3 (EMP) Site 5 Resposta da consulta Site 1 Site 2 ASG1 = σ eno <= E3 (ASG) ASG2 = σ eno > E3 (ASG) 48 24

25 Processamento de Consultas PROPOSTA 1 Caso Distribuído Resultado = (EMP1 EMP2) eno (σ asg.resp= Manager (ASG1 ASG2))) Site 5 EMP1 EMP2 Site 3 Site 4 EMP1= σ eno <= E3 (EMP) ASG1 ASG2 EMP2 = σ eno > E3 (EMP) Site 1 Site 2 ASG1 = σ eno <= E3 (ASG) ASG2 = σ eno > E3 (ASG) 49 Processamento de Consultas PROPOSTA 2 Caso Distribuído Site 5 result = EMP1 EMP2 EMP1 EMP2 Site 3 EMP1 = EMP1 eno ASG1 Site 4 EMP2 = EMP2 eno ASG2 EMP1= σ eno <= E3 (EMP) ASG1 EMP2 = σ eno > E3 (EMP) ASG2 Site 1 ASG1 = σ asg.resp= Manager (ASG1) Site 2 ASG2 = σ asg.resp= Manager (ASG2) ASG1 = σ eno <= E3 (ASG) ASG2 = σ eno > E3 (ASG) 50 25

26 Processamento de Consultas Caso Distribuído Modelo de custo simples tupacc = 1 acesso a tupla tuptrans = 10 No exemplo Transferência de uma tupla EMP 400 tuplas ASG 1000 tuplas Existem 20 managers. Existe um acesso direto às tuplas de ASG (respetivamente, EMP) baseado no valor do atributo RESP (respectivamente, ENO). 51 Processamento de Consultas PROPOSTA 1 Caso Distribuído Total = Resultado = (EMP1 EMP2) eno (σ asg.resp= Manager (ASG1 ASG2))) (400 * 20) * tupacc = Site * tupacc = ASG * tuptrans = * tuptrans = EMP2 Site 1 Site 4 ASG1 = σ eno <= E3 (ASG) ASG2 EMP2 = σ eno > E3 (EMP) EMP1 Site 2 Site 3 ASG2 = σ eno > E3 (ASG) EMP1= σ eno <= E3 (EMP) 52 26

27 Processamento de Consultas PROPOSTA 2 Caso Distribuído result = EMP1 EMP2 Site 5 Total = 460 ( ) * tuptrans = 200 EMP1 EMP2 EMP1 = EMP1 eno ASG1 EMP2 = EMP2 eno ASG2 Site 3 ( ) * tupacc * 2 = 40 Site 4 ASG1 ASG2 ( ) * tuptrans = 200 ASG1 = σ asg.resp= Manager (ASG1) Site 1 ( ) * tupacc = 20 Site 2 ASG2 = σ asg.resp= Manager (ASG2) 53 Camadas do Processamento de Consulta Consulta sobre relações distribuídas Decomposição de consulta Consulta em álgebra sobre relações distribuídas ESQUEMA GLOBAL SITE DE CONTROLE Localização de Dados Consulta fragmentada Otimização Global ESQUEMA FRAGMENTADO ESTATÍSTICAS DOS FRAGMENTOS Consulta fragmentada otimizada induzindo operações de comunicação SITES LOCAIS Otimização Local ESQUEMAS LOCAIS Consultas locais otimizadas 54 27

28 Camadas do Processamento de Consulta Decomposição de consulta A consulta inicial não sabe sobre a distribuição dos dados Decompõe a consulta em uma consulta em álgebra sobre as relações globais A técnica é a mesma que em SGBD relacional Análise sintática e semântica Tradução e simplificação da consulta Tradução para uma consulta em álgebra relacional -> definir uma consulta em álgebra que seja correta e eficiente (por exemplo através da retirada de predicados redundantes). Consulta ainda não é ótima 55 Camadas do Processamento de Consulta Localização dos Dados Objetivo: Localizar os dados da consulta de acordo com a distribuição existente. As relações estão fragmentadas e armazenadas em conjuntos disjuntos, chamados de fragmentos, cada um armazenando em um site diferente. Esta camada descobre quais fragmentos estão envolvidos na consulta e transforma a consulta distribuída em uma consulta algébrica sobre fragmentos

29 Camadas do Processamento de Consulta Otimização Global Objetivo: Encontrar uma estratégia de execução da consulta próxima do ótimo, incluindo melhor ordem das operações em uma consulta sobre base distribuída e considerando as operações de comunicação. Uma estratégia de execução de uma consulta distribuída pode ser descrita como operações em álgebra relacional e primitivas de comunicação (operações de send / receive) para transferência de dados entre os sites. Considera: I/O de disco, CPU, espaço de buffer, custo de comunicação... Nas camadas anteriores foi feita uma otimização independente das características dos fragmentos, por exemplo através da retirada de predicados redundantes. Esta camada trata da otimização se baseando nos fragmentos. 57 Camadas do Processamento de Consulta Otimização Local Objetivo: Criar consultas locais otimizadas através da escolha de algoritmos para execução das operações, de acordo com o esquema local do site. Esta camada utiliza algoritmos dos sistemas centralizados