Sistema de Análise e Dimensionamento de Vigaspostgresql/conteudo/publicationsfiles/SBBD09... · 2...

1

Tuning e Self-Tuning de Bancos de Dados

José Maria Monteiro

Universidade de Fortaleza (UNIFOR)

Secretaria da Fazenda do Estado do Ceará (SEFAZ-CE)

[email protected]

[email protected]

Tuning e Self-Tuning de

Bancos de DadosJosé Maria Monteiro UNIFOR Mini-curso SBBD 2009 2/113

Contexto VLDB

Vários GB de dados terabytes ou terrorbytes

cartões de crédito, correios expressos

Caso Petrobras coorporativo anos atrás 5K tabelas e índices + 2K views

Algumas tabelas com mais de 50M tuplas

20 consultas por minuto

12K usuários (200 simultâneos)

SAP R/3 “básico” 16K tabelas e 19K índices!

2



Tuning de Bancos de Dados

Sintonia ou ajuste fino

“Realizar ajustes em um sistemas de banco de dados de forma a obter um melhor tempo de resposta e/ou aumentar a vazão (throughput) para determinada aplicação”

=> Buscar um bom desempenho em um sistema de banco de dados existente

Hipótese: HW e SW não mudam!



(1)insert into SALES (prodNum, date, qty, value)

values (4, current_timestamp, 20, 348);

(2)select prodNum, date, sum(value) as total

from SALES

where value > 1500000 and

date between ‘20040101’ and ‘20040131’

group by prodNum, date;

Indices para uma aplicação que contém estas(e possivelmente muitas outras…) cláusulas SQL?

Problema típico

3



Problema simples?

update venda

set valor = valor -1

where valor > 2375000;

Índices ajudam ou atrapalham?



Princípios de Tuning (Shasha)

Pensar globalmente, fixar localmente

80 x 20: qual consulta é responsável?

Particionar para resolver gargalos

Espaço, transações

Start-up tem custo alto, execução não

Orientado a conjuntos!

Ao servidor o que é do servidor

triggers

Esteja pronto para trade-offs

Cobertor curto!

4



Problemas de sintonia

Seleção de índices

Alocação de dados

Controle de carga (ajuste de MPL)

Política de substituição de páginas em memória

Ajuste de tamanhos/quantidades de buffers

Refino automático de estatísticas



Tuning

Dificuldades:

Perceber que um recurso está sendo mal

utilizado => monitoramento é parte

fundamental do processo

Localizar e entender a verdadeira fonte do

problema => Mais de 90% do tempo para

resolução de problemas de desempenho é

gasto no diagnóstico.

5



O que é preciso saber?

A atividade de tuning envolve:

Hardware e sistemas operacionais

Gerência de memória e acesso a discos

Controle de concorrência e recuperação

Uso de índices adequados

Otimização e reescrita de consultas

Projeto de banco de dados adequado

Ajuda conhecer SGBDs específicos!



Agenda

o Introdução e Motivação

o Conceitos e Fundamentoso Arquiteturas de SGBD, Arquivos e Índices

o Processamento de Consultas e Operadores Relacionais

o Tuningo Planos e Métodos de Acesso

o Monitoramento e Ações

o Self-tuningo Visão Geral do Estado da Arte

o PostgreSQL @ PUC-Rio

o Adicionais Tuning e Comentários Finais

6



Arquitetura ANSI/SPARC

EE1 EE2 EE3

EC

EI

Três níveis de abstração:

• Esquemas Externos (EE)

• Esquema Conceitual (EC)

• Esquema Interno (EI)

Princípio da Independência de Dados

• Independência física e lógica

• E.g. Modelo Relacional de Dados



Controle de

Concorrência

Processador de Consultas

Gerente de Armazenamento

Arquitetura FuncionalComponentes de um SGBD

Otimizador Executor

Gerência de

Bloqueios

Gerência de

Transação e

Recuperação

Controle de Memória

Controle de Dados

Meta-Dados e

Estatísticas

Dados e

Índices

Log de

Transações

SQL

7



Componentes do SGBD

Gerenciadores (Managers):

RM - Relational Manager

DM - Data Manager

FM - File Manager

BM - Buffer Manager

RM - Recovery Manager

LgM - Log Manager

LkM - Lock Manager



Organização de Arquivos

Tipos básicos de arquivos: Heap (entry sequenced files)

Ordenados (sorted)

Hash

Árvores balanceadas

8



Heap Files

Organização Seqüencial

não há ordenação dos registros

Inclusão de registro

simples e eficiente

Acesso

somente pesquisa seqüencial

Exclusão de registro

exclusão lógica eficiente, mas necessita reorganizações periódicas.



Arquivos Ordenados

(Sorted) –pesquisa interessante para campos chave

Num Nome Idade Sal

1000 Ademar 25 5000

1050 Afonso 27 7000

1075 Angela 22 6000

1100 Antonio 28 2500

1300 Carlos 23 1200

1350 Cesar 25 2000

.

.

.

3100 Sonia 28 3000

3150 Tatiana 20 1000

bloco

1

bloco

2

bloco

n

1

2

3

4

5

6

.

.

.

39

40

}}

}

9



Arquivos Hash

Usa uma função de cálculo de endereço (hashing)

• função gera endereço provável

• Em geral, um único I/O por bloco para obter registro desejado

• endereço:– bloco ou– bloco + registro no bloco

Nome = Cristiano

endereço = f (nome)

Número Nome Idade Salário. . . . . . . . . . . .

1100 Antônio 28 2500

. . . . . . . . . . . .

1140 Cristiano 20 1000

. . . . . . . . . . . .



Árvores B

Árvores B: Bayer e McCreight (1972)

características:

construção: bottom up

paged tree

splits

chaves ordenadas em cada página

k chaves por página

k + 1 ponteiros por página

../../Configura��es%20locais/Temp/ATBD%20I%20-%203/T10%20Organiza��o%20de%20Arquivos/Arvore%20B%20exemplo.ppt




10



Outras características:

N chaves, m ponteiros por página (ordem)

número máximo de níveis d (pior caso):

Árvores B

2/1log1 2/ Nd m

– N = 1.000.000 N = 10.000.000

– m = 512 m = 512

– d 3.37 3 níveis d 3.78 3 níveis

☹



Árvores B+

23 37 58 75

43 95

03-22 23-35 37-42 43-54 58-74 75 -

11



Ainda Árvores B+

Sequence Set:

conjunto ordenado de blocos

chaves ordenadas em cada bloco

lista simples ou duplamente encadeada

03 – 11 – 15 23 – 35 – 36 37 – 40 – 42 43 – 50 – 54 58 – 73 - 74



Índices

Estruturas auxiliares para permitir acesso mais rápido dados

Sem índices, para obter uma informação de uma tabela, todas as linhas devem ser lidas do arquivo

Com índice, pode ser feito acesso direto

Índices em livros permitem que

passemos diretamente para o

capítulo desejado!

12



Estruturas auxiliares: Índices

0 1 2

3 4

n

20

80 70 60

110 30 90

40 100 10

180 160 50

5

6 7 8

09 10 11

12 13 14

10 11

30 07

20 02

40 09

50 14

60 05

chave pág.



Tipos de Índices

Podem ser de diversos tipos:

Árvore B+

Cluster ou não-cluster

Bitmap

...

Alguns SGBDs permitem:

índices com valores em ordem reversa

índices em resultados de funções

13



Índices

Normalmente são variações das árvores B e B+

03–22 23-42 43-55 56-64 65-78 79-99

cage 55 eva folk 99

du 99

7864

55

22 42



Clusterização

Índices podem ser utilizados para: garantir unicidade das chaves na tabela

ordem física de armazenamento das linhas na tabela: cluster indexes no DB2 e SQL Server Index Organized tables no Oracle

índice cluster linhas armazenadas na seqüência da chave

índice não cluster chave do índice não influencia no posicionamento

14



Índices Clusterizados



Índices Não-clusterizados

15



Processamento de Consultas

Parse Query

Check de Semântica

Query Rewrite

Otimização doPlano de Acesso

Geração de Código



Otimização e Execução de Consultas

Envolve

Reescrita da consulta

Determinação do melhor plano de acesso

Após otimização, ocorre a execução da consulta de acordo com o plano

16



Otimização de Consultas

Problema NP-difícil:

muitas alternativas de planos

O otimizador de consultas determina o plano de acesso através de:

Heurísticas (otimização por regras, RBO)

Busca de plano de melhor custo (otimização por custo, CBO)



Metabase e Estatísticas

A otimização por custo demanda estatísticas:

de tabelas: número de tuplas, blocos, tamanho de registro médio

de colunas: número de valores distintos, nulos, histogramas

de índices: número de folhas, níveis, clustering

de sistema: utilização típica de I/O e de CPU

Estatísticas devem sempre estar atualizadas!

17



Agenda











Planos de Execução

É o resultado da otimização

É especificado no plano de execução: Ordem de acesso às tabelas

Ordem de operações seleção, projeção e junção

Índices utilizados

Tipos de junção

Ordenações

Tabelas intermediárias

18



QEP: Query Execution Plan

Exemplo:

SELECT endereço, data-nascimento

FROM empregado

WHERE nome = ‘Chico Cesar’

Execution Plan

---------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMPREGADO'

2 1 INDEX (UNIQUE SCAN) OF 'PK_EMP' (UNIQUE)



Métodos de Acesso

Tipos básicos de operação:

Varreduras seqüenciais (full scan)

Indexadas (index scan)

Implementação de operadores Junções,

Uniões

Ordenações e eliminação de duplicatas

19



Junções

Principais algoritmos:

Laços Aninhados (Nested Loops Join)

Ordenação/Intercalação (Merge Join)

Hashing (Hash Join)



Nested Loops

60

50

40

30

20

10

T1

Outer Table

70

60

50

20

20

05

70

T2

Inner Table

20



Merge Join

60

50

40

30

20

10

Outer Table

70

60

50

20

20

05

70

Inner Table

Ord

enad

a

Ord

enad

a



Hash Join

60

50

40

30

20

10

Outer Table 70

60

50

20

20

05

70

Inner Table

Build Phase

f(chave)10

20 50

30

40

60

Probe Phase

21



Ordenação

Operação básica para diversas outras operações físicas

Resolve (usualmente) várias cláusulas: Order By, Group By, Distinct, Union, Minus, …

Operação cara

Se o conjunto a ser ordenado não cabe em memória, pode ser ainda mais cara!



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

22



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



Fator de Filtro

Estatísticas:

Tabela de Empregados com 10.000 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

Select nome

from empregados

where sexo = „F‟

Estima retorno

de 5000 linhas

Não usa

índice

23



Fator de Filtro

Estatísticas com a presença de Histograma: otimizador pode

perceber distribuição não-uniforme: tabela de Empregados com 10.000 linhas:

coluna Sexo: distribuição não uniforme.

estatísticas de distribuição não uniforme:

M: 9.000 empregados

F: 1.000 empregados

FF(F) = 0.1

Para consulta “sexo = `F`”, otimizador pode decidir utilizar o índice da coluna sexo



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.

24



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 = 0.018

Estimativa para a tabela resultado: 180 linhas



Fator de Filtro

O Otimizador pode ser enganado em alguns casos em predicados correlacionados:select * from empregados where cidade = ‘ rio de

janeiro’

FF = 1 / 1.000 R = 100.000 / 1.000 = 100 linhas

select * from empregados where cidade = ‘ rio de janeiro’ and estado = ‘ rj’ and pais = ‘ brasil’

FF = (1 / 28) * (1 / 1.000) * (1/10) R = 100.000 / 28.000 = 3,5 linhas

25



Tuning

Problema está em uma consulta apenas...

Tentar primeiro métodos com impactos locais

reescrita da consulta

Criação de índices, desnormalização do esquema e reordenação de transações:

podem afetar todo o sistema!



Reescrita

Evitar having se pudermos utilizar where. Where elimina linhas antes da operação de agrupamento e facilita a utilização de índices na comparação

Select max(salario)

From empregado

Group by depnum

Having depnum = 100

Select max(salario)

From empregado

Where depnum = 100

26



Reescrita

Exemplo Oracle:

------------------------------------------------------------------------

| Operation | Name | Rows | Bytes| Cost

------------------------------------------------------------------------

| SELECT STATEMENT | | 1 | 16 | 360

| FILTER | | | |

| SORT GROUP BY | | 1 | 16 | 360

| TABLE ACCESS FULL |EMPREGADO | 100K| 1M| 102

Select max(salario) From empregado

Group by depnum Having depnum = 100



Reescrita

Exemplo Oracle

-------------------------------------------------------------------------


-------------------------------------------------------------------------

| SELECT STATEMENT | | 1 | 16 | 2

| SORT AGGREGATE | | 1 | 16 |

| TABLE ACCESS BY INDEX RO|EMPREGADO | 100 | 1K| 2

| INDEX RANGE SCAN |IDX_EMP_DEPNUM | 100 | | 1

Select max(salario)

From empregado

Where depnum = 100

Custo cai de 360 para 2!

Queda para apenas 0,5% do

original!!!

27



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



-------------------------------------------------------------------------


-------------------------------------------------------------------------

| SELECT STATEMENT | | 100K| 2M| 937

| SORT UNIQUE | | 100K| 2M| 937

| TABLE ACCESS FULL |EMPREGADO | 100K| 2M| 102

Reescrita

Exemplo Oracle:

select distinct ident, nome from empregado;

select ident, nome from empregado; Custo = 102

28



Junções e Sub-Consultas

select E.Ident, E.nome from empregado Ewhere 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)

Sem estatísticas




Sem estatísticas

select E.Ident, E.nome from Empregado E, Dependente D where D.Idemp = E.Ident

Execution Plan

----------------------------------------------------------


NESTED LOOPS

TABLE ACCESS (FULL) OF 'DEPENDENTE'

TABLE ACCESS (BY INDEX ROWID) OF ‘EMPREGADO'

INDEX (UNIQUE SCAN) OF 'IDX_EMPREGADO_ID' (UNIQUE)

29




Sem estatísticas

select E.Ident, E.nome from Empregado Ewhere E.Ident in ( select IdEmp

from Dependente D)

Execution Plan

----------------------------------------------------------


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)




Com estatísticas

select E.Ident, E.nome from Empregado Ewhere exists ( select * from Dependente D

where D.Idemp = E.Ident )

Execution Plan

----------------------------------------------------------

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)

select E.Ident, E.nome from Empregado Ewhere E.Ident in ( select IdEmp from Dependente D)

30




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)



Outras Atividades de Tuning

Uso de hints

Cuidadoso!

Operações vs instruções SQL:

E.g. distinct --> internal sort

Ausência de PKs e/ou FKs

Full scan only

31



Ainda Atividades e Causos

Projeto físico:

Clusterização + indices invertidos

Mudança na estrutura de persistência

Independência física!

Ferramentas de apoio ao DBA

E.g. Veritas, Quest

Monitoramento, alertas, consoles gráficos...



Agenda









32



Motivação para Self-tuning

Sistemas de bancos de dados se tornam cada vez mais utilizados na nossa sociedade

Sistemas de bancos de dados exigem profissionais especializados para a sua administração



Idéia: Autonomic Computing

Um grande desafio para a comunidade acadêmica: tornar os sistemas computacionais mais autônomos

Ansilomar Report on Database Research (1998)

IBM’s Autonomic Computing Manifesto (2001)

33



Autonomic Computing

Ciclo Clássico



Autonomic Computing

34



Auto-Sintonia (Self-Tuning)

Capacidade de auto-ajuste dos SGBDs ao ambiente para obter de melhor

desempenho



Atividades de Self-Tuning

Coleta de informações (CI) – monitoramento do sub-sistema onde está sendo realizado a auto-sintonia;

Avaliação da situação (AS) – avaliação da necessidade de alterações no sistema considerando as medidas da etapa anterior e métricas relacionadas ao sistema;

Enumeração de possíveis alterações (EPA) –detectada ineficiência de um sub-sistema, são enumeradas possíveis alterações a serem realizadas;

Realização de alterações (RA) – a partir das alternativas enumeradas, alterações nos mais diversos componentes do SGBD podem ser realizadas;

35




Alguns SGBDs comerciais possuem implementação de algumas características

Trabalhos científicos:

Muitos artigos sendo publicados nos últimos 10 anos!

Self-Tuning Database Systems: A Decade of Progress (Chaudhuri et al., Microsoft Research, VLDB 2007)



Projeto SMART (Self Managing and Resource Tuning) do Centro de

Pesquisas IBM Almaden em parceria com os Laboratórios de Toronto e do

Vale do Silício;

Projeto AutoAdmin da Microsoft Research;

Oracle;

PostgreSQL;

Grupo de auto-sintonia em SGBDs

do Departamento de Informática PUC-Rio.

Índices Hipotéticos

Survey

Auto-Sintonia Global

Heurística de Benefícios

DB2: db2advis

SQL Server

2005: Database

Tuning AdvisorOracle 10g: Automatic

Database Diagnostic Monitor

Pg_autovacuum


36



Possível Classificação

Auto-Sintonia por Projeto

Auto-Sintonia por Adaptação



Auto-sintonia de

bancos de dados

Auto-sintonia global Auto-sintonia local

Projeto

Físico

Alocação

de dados

Controle

de carga

Substituição

de páginas

Ajuste de

buffers

Refino de

estatísticas

Auto-sintonia global

por construção

Auto-sintonia global

por adaptação


37






Sistemas Auto-sintonizáveis por Projeto

RISC-style Database System

Autores: Chaudhuri (Microsoft, AutoAdmin) e Weikum (Universidade de Saarland)

Idéia de criar sistemas de bancos de dados com componentes menores, especializados

Exemplo: gerente de dados com capacidade SPJ (select-project-join)

Apenas position paper

38



Sistemas Auto-sintonizáveis por Projeto

Projeto COMFORT

ETH em cooperação com UBS

Observar-predizer-reagir

Modelagem formal para determinar métricas

Auto Tune

IBM T. J. Watson Research Centre

Agente para controle inteligente

Independente da tecnologia monitorada



Seleção de Índices

Várias gerações de soluções: Escolha através de regras especializadas

(Rozen & Shasha, outros)

Criação de configurações de índices virtuais e uso do otimizador para custeamento (Microsoft Index Wizard, muitos outros)

Enumeração de índices virtuais e uso do otimizador para escolha (DB2 Index Advisor)

39



Alocação de Dados

Mudanças nos padrões de acesso aos dados pode sobrecarregar discos ou nós de processamento

A idéia é mover arquivos ou fragmentos de arquivos dinamicamente entre os nós de processamento Vistas propostas para sistemas shared nothing (p.

ex., clusters de PCs, aB+-Tree) e sistemas shared memory (p. ex., arrays de discos; projeto COMFORT, disk cooling)



Controle de Carga

Num sistema que usa locks, muitas transações concorrentes podem causar conflitos que levam a uma redução da vazão do sistema

A idéia é ajustar dinamicamente o MPL do sistema

Observação de métrica de conflitos (projeto COMFORT, conflict ratio)

40



Substituição de páginas

Será LRU a melhor política de substituição de páginas para todas as variações de carga de trabalho?

A idéia é entender quais páginas ficam mais populares à medida que a carga de trabalho no sistema varia LRU-K: P. O’Neil, E. O’Neil, G. Weikum (projeto

COMFORT)

2Q: melhoria de desempenho de LRU-K, proposta por Johnson e Shasha



Ajuste de Buffers

Alguns sistemas permitem que criemos vários buffer pools, com diferentes objetos (tabelas, índices) associados a cada um

Como dividir os objetos em buffer pools de forma a melhorar o desempenho? É possível fazer isto dinamicamente? Configuração e seleção de tamanho de buffer

pools para o DB2

41



Refino de estatísticas

Estatísticas são um fator determinante da qualidade dos planos escolhidos por otimizadores de custo

A idéia é atualizar as estatísticas do sistema com base no resultado de consultas que estão sendo executadas Microsoft Self-tuning Histograms

DB2 LEO – LEarning Optimizer



Self-Tuning de índices

Tuning de índices: Índices podem auxiliar em consultas

Índices podem ser prejudiciais a atualizações

Quais índices criar?

No self-tuning, dificuldade adicional: quando criar ou destruir?

Risco de criar-recriar inúmeras vezes

42



Self-Tuning de índices – SQL Server -



Self-Tuning de índices – QUIET -

Quiet (Query-Driven Index Tuning)

Sugestão automática de criação de índices

Baseada em comandos proprietários DB2

Necessidade de reescrever aplicações existentes (cláusulas SQL)

Impossibilidade de gerência de carga de trabalho submetida diretamente ao SGBD

43



Self-Tuning de índices – QUIET -



Self-Tuning de índices – COLT -

COLT (Continuos On-Line Tuning)

Monitora as consultas submetidas ao SGBD

Ajuste automático da configuração de índices (criação e remoção)

Implementado junto ao PostgreSQL

Cada consulta é otimizada uma vez para cada índice candidato → Sobrecarga

44



Self-Tuning de índices – COLT -



Self-Tuning de índices – [Luhring et al 2007] -

- [Luhring et al 2007]

Monitoramento contínuo + Periodicamente soluciona o ISP (criação/remoção)

Segue o ciclo Observação/Predição/Reação

Cada consulta é otimizada duas vezes

45



AutoAdmin Online

Extensão do SQL Server 2005

Executa continuamente e reage a variações na carga de trabalho ou nos dados

Modifica automaticamente o projeto físico do BD (criação e remoção)

Cada consulta é executa uma única vez

Self-Tuning de índices – AutoAdmin Online -

-



Self-Tuning de índices – AutoAdmin Online -

-

46



Índices Hipotéticos

Uso de SGBD completo de código aberto Simulação? Não!

PostgreSQL (8.3.5)

Linux

Abordagem intrusiva Código core modificado

Comando create hypothetical index/drop hypothetical index e explain hypothetical index

Self-Tuning de índices – PUC-Rio -



Department Employee Product

id – int

name – varchar(50)

managerid – int

Number of tuples: 200

Number of tupes: 100 Number of tuples: 250

id – int

name – varchar(50)

address – varchar(200)

salary – numeric(10,2)

depid – integer

id – int

type – varchar(30)

description – varchar(150)

measure – varchar(30)

price – numeric(5,2)

Sale

id – int

year – int

month – int

day – int

prodid – int

sellerid – int

Price – numeric(4,2)

Number of tuples: 250

Tutorial: estudo de caso para what-if

Uso de Índices Hipotéticos

47



select d.name, e.name, e.salary

from employee e, department d

where e.depid = d.id and

e.salary between 1000 and 2500;

The following query is very frequently issued by the university application:

Lets take a look at its query execution plan using the explain statement:

explain





Consultas Freqüentes



Query Execution Plan

QUERY PLAN

---------------------------------------------------------------------------

Hash Join (cost=1.32..314.96 rows=2499 width=50)

Hash Cond: ("outer".depid = "inner".id)

-> Seq Scan on employee e (cost=0.00..269.91 rows=2498 width=42)

Filter: ((salary >= 1000::numeric) AND (salary <= 2500::numeric))

-> Hash (cost=1.26..1.26 rows=26 width=16)

-> Seq Scan on department d (cost=0.00..1.26 rows=26 width=16)

(6 rows)

A sequential scan was chosen by the planner to access the employee table.

Perhaps we could improve this by creating an index on the salary column.

Plano de Consulta Gerado

48



create hypothetical index hi_employee_salary

on employee(salary);

Criando um Índice Hipotetico

Although we could benefit from the existence of an index on the salary column, we should be

careful to create it. Firstly, we do not know if the DBMS will actually choose to use an index in the

salary column if it exists. Secondly, if we try to create an actual index in this column, the DBMS will

prevent writers from accessing the table. So it is hard to experiment with new indexes and

evaluate how good they are.

Instead of incurring the burden of creating an actual index on the column, we could simulate if this

index would be useful to the database. To do that, we create it as a hypothetical index:



Plano de Consulta com Índices Hipotéticos

explain hypothetical





The hypothetical index is not actually materialized in the database. Therefore, we will not

incur in heavy creation costs or obtain locks on the underlying table to create it. The

DBMS, however, cannot use the hypothetical index to answer a user query. If we query

the database again or use the explain statement, the system will still use a sequential

scan to access the employee table.

We can see how the DBMS would behave if the hypothetical index were materialized

using the explain hypothetical statement:

49



Análise de Custos com Índices Hipotéticos


QUERY PLAN

------------------------------------------------------------------------



-> Index Scan using hi_employee_salary on employee e

(cost=0.00..124.37 rows=2498 width=42)

Index Cond: ((salary >= 1000::numeric) AND (salary <= 2500::numeric))


-> Seq Scan on department d (cost=0.00..1.26 rows=26 width=16)

(6 rows)00

If the index hi_employee_salary was materialized, the DBMS would use it

to process the query. The estimated cost to process the query would drop

from 314.96 using the sequential scan to 169.42 using the index scan.



Índices Hipotéticos eventualmente se tornam reais

drop hypothetical index hi_employee_salary;

create index i_employee_salary on

employee(salary);

Now that we know that the index is beneficial to performance, we can drop the

hypothetical index and create a corresponding actual one:

50



Plano de consulta com novo índice criado

explain select

d.name, e.name, e.salary




Lets check the query execution plan for the query with the actual index created:



Análise dos custos


QUERY PLAN

------------------------------------------------------------------------



-> Index Scan using i_employee_salary on employee e

(cost=0.00..94.24 rows=2490 width=42)

Index Cond: ((salary >= 1000::numeric) AND

(salary <= 2500::numeric))


-> Seq Scan on department d (cost=0.00..1.26 rows=26

width=16)

(6 rows)

The cost estimated by the planner for the query using the hypothetical index was 169.42. With the actual

index, the planner gave us an estimate of 139.15. Cost estimates for hypothetical indexes tend to be

conservative, but always close to the cost of using the actual index.

51



Modelo localSGBD

Componente N

Componente N + 1

Componente M + 1

Área sendo

ajustada

Avaliação de

métricas e

alterações na

execução

(AS e EPA)

Envio de informações

sobre alteração na

execução de tarefa (RA)

Coleta de informações

preliminares (CI)


sobre alterações (CI)


sobre execução final (CI)

Componente de

Auto-Sintonia

Componente M




SGBDs baseados em Agentes

Três arquiteturas

Arquitetura Embutida

SGBD

Arquitetura IntegradaArquitetura em Camadas

SGBD

Sistema de Agentes SGBD

Sistema de Agentes

Componentes

do SGBD Sistema

de

Agentes

Lifschitz e Macedo, CLEI 2001

52



Agente em Camadas

Agentes de software

Autonomia: capacidade de agir para atingir um objetivo sem intervenção humana

Reatividade: capacidade de responder a mudanças para atingir objetivos;

Pró-atividade: agir para atingir seus objetivos, antecipando-se a mudanças no ambiente;

Sociabilidade: capacidade de interagir com outros participantes do ambiente;

Sensor

Ação

Raciocínio

Mobilidade

Colaboração

Tradução

Crença



Agentes e Self-Tuning

Agente em camada e etapas do Self-tuning (Costa e Lifschitz, CLEI 2002)

Sensor

Ação

Raciocínio

Mobilidade

Colaboração

Tradução

Crença

Agente Etapas da

Auto-Sintonia

Outras funcionalidades

Coleta de Informações

Avaliação da Situação

e

Enumeração de Possíveis

Alterações

Realização de Alterações

Decisões sobre colaboração

com outros agentes,

preparação e envio de

mensagens.

Recebimento e análise

prévia de mensagens de

outros agentes

Armazenamento de

estatísticas, decisões

tomadas e crenças

53



SGBDs baseados em Agentes e Self-Tuning

Modelo global com agentesSGBD

Troca de

informações

Componente N

Componente N + 1

Componente M +1

Agente de

Self-tuning

Local

Componente M

“Lembrança de

operações passadas”

(dados persistentes)

Gravação de dados

Leitura de

dados

Área sendo

ajustada

Envio de informações a

outros agentes

de Self-tuning

Informações provenientes

de outros agentes de

Self-tuning



Modelo Global

54



Questionamentos

Dada uma solicitação para criação ou destruição de um índice, agente de self-tuning de índices pode indicar que: Nenhum índice é benéfico/ prejudicial para a

consulta ou operação de atualização;

A criação/destruição de um índice já foi determinada e será realizada no momento adequado;

Índices já foram criados/destruídos antes da solicitação ser recebida;



Questões de implementação

Ciclo de uma operação

SGBD

Otimização do

Plano de Acesso

Geração de

código

Agente de

Self-tuning

Mobilidade

SGBD Query Rewrite

Otimização do

Plano de Acesso

Geração de

códigoAgente de

Self-tuning

Sensor

SGBD

Agente de

Self-tuing

Crença Estatísticas

SGBD

Agente de

Self-tuning

Raciocínio

Tomada de decisão

com possível

enumeração de

índices propostos

ou decisões sobre

imediata/posterior

criação/destruição

de índices

SGBD

Geração do Plano

de Acesso

Agente de

Self-tuning

Mobilidade

Solicitação de

montagem de plano

segundo uma dada

configuração

Consulta

55




Criação autônoma de índices TPC-C, sintonia local, heurística de

benefícios, PostgreSQL




56



Arquitetura do Componente de Auto-sintonia




Seja B(ej,qk) o beneficio proporcionado pela estrutura ej para oprocessamento de uma tarefa qk. Este beneficio pode ser formalmentedefinido como:

onde, cost(qk) representa o custo de execução da tarefa qk sem autilização da estrutura ej e cost(qk, ej) representa o custo de execuçãoda tarefa qk utilizando-se a estrutura de acesso ej ;

Observe que se cost(qk) − cost(qk, ej) > 0, a utilização da estrutura ej

contribui para aumentar o desempenho da tarefa qk, logo: Bej ,qk > 0;

Caso contrario, a utilização da estrutura ej não proporciona nenhumamelhoria no desempenho da tarefa qk, podendo inclusive, se fosseutilizada, reduzir este desempenho (cost(qk) − cost(qk, ej) < 0).Contudo, neste caso, a estrutura ej não seria utilizada pelo otimizadordo SGBD, e, por conseguinte, Bej ,qk = 0

57



O beneficio acumulado de uma determinada estrutura de acesso ej, representado por (BAej ), corresponde a soma dos seus benefícios para cada uma das tarefas anteriormente executadas. Logo:

onde, NQWt é o numero total de tarefas da carga de

trabalho.





1. Para cada comando qk capturado faça:

2. Otimize qk dada a configuração real de índices → costR(qk) + IR

3. Otimize qk dada a configuração de índices hipotéticos e reais→ costH(qk) + IH

4. Otimize dada uma configuração sem índices → costS(qk)

5. Para cada índice hipotético i em IH faça:

6. Bi,qk = max{0, costR(qk) - costH(qk)}

7. BAi = BAi + Bi,qk

8. Se BAi > ECCi

9. Criar o índice i + bonusi = BAi / Qtd

58



1. P ara cada comando qk capturado faça:

10. Para cada índice real r em IR faça:

11. Br,qk = max{0, costS(qk) - costR(qk)}

12. BAr = BAr + Br,qk / BAr = BAr + bonusr

13. Se é qk é uma atualização

14. Para cada índice i afetado por qk faça:

15. BAi = BAi – ECAi

16. Se (i é real) e (BAi < 0) e (|BAi|>ECCi)

17. BAi = - ECCi

18. Remover o índice i




Resultados Experimentais

Testes com DBT-2 toolkit

Carga TPC-C

Estudos de caso: Sem índice: BD sem índices e agente desligado

Índice Automático: BD sem índices e agente ligado

Indexação estática: DB com índices propostos pelosprojetistas do toolkit e agente desligado

Resultados surpreendentes! Um índice dos projetistas não criado

Um índice não projetado criado... Porém útil!

59



Avaliação de Vazão (Throughput)

Escala do BD: # de armazéns

Teste de 90 min: período de aprendizado ok

0

10

20

30

40

50

60

1 2 3 4

Number of Warehouses

Th

rou

gh

pu

t (t

r/m

in)

No

indexing

Automatic

Indexing

Static

indexing



Análise dos Resultados

O componentes conseguiu obter boa vazão média para a aplicação em questão

O componente-agente passa por fase de aprendizado até atingir estabilidade

Quanto mais tempo o componente estiver ativo com carga estável, melhor é a vazão observada do sistema

60




Destruição e reindex automáticos TPC-H, sintonia global, fragmentação física



Estudos com carga OLAP

TPC-H 6 consultas representativas (das 22)

Consultas muito demoradas

Novo comando

Evaluate

select linenumber, quantity

from lineitem

where orderkey = 200 and linenumber = 2;

61



Resultados Experimentais

Testes com DBT-2 toolkit agora com carga TPC-H

Três estudos de caso como anteriormente

Mesma carga submetida para SGBDs comerciais SQL 2005 e Oracle 10g

Novo índice criado.... E útil !!!

Heurística de benefícios alterada Critério histórico

Bônus = Benefício Acumulado / Utilizações

O ideal seria calcular a contribuição exata de cada índice por comando submetido

E.g. Chaudhuri et al – 2004

Malus?



Resultados Experimentais (2)

Testes com DBT-2 toolkit novamente com TPC-C

Três estudos de caso como anteriormente

Mais consultas, ajustes na carga submetida

Captura de poucas consultas agora não é bom...

Índices eliminados foram recriados!!!

62



Recriação de Índices

Fragmentação prejudica desempenho para varreduras: confirmado!

Fragmentação aumenta espaço ocupado por um índice: confirmado!

Fragmentação x Custo: confirmado?!

Malefícios Causados pela Fragmentação de Índices



Fragmentação no Nível Folha

63



Fragmentação de Índices

Idéia básica: Índices fragmentados merecem nova chance!

Novos critérios antes de um drop Grau de fragmentação

G = 100 – [(Ra/Ri) * 100]

Tamanho do índice

Taxa de varreduras

Novo comando: getsize



Agenda









64



Técnicas de Tuning

Métodos com maior abrangência:

Criação/destruição de índices

Utilização de índices cluster

Visões materializadas

Escolha do tamanho adequado de bloco

Posicionamento dos arquivos em disco

Particionamento de objetos

Ajuste das áreas de memória

Ajuste dos parâmetros do SGBD

...



Utilização da Memória

SGBDs utilizam a memória para armazenar:

Dados mais recentemente acessados. Operações de atualização realizadas por usuários podem fazer com que existam em memória várias versões da mesma informação;

Informações sobre árvores de execução de comandos SQL;

Informações sobre a instância utilizada e a base de dados acessada;

Processos do servidor e seus parâmetros de controle;

65



Utilização da Memória

Para melhorar desempenho:

Aumentar memória principal: nem sempre é a solução => realocar memória

Aumentar memória para o SGBD: concorrência com outros programas no servidor

Manter na memória as informações que são realmente necessárias



Estruturas de Memória

Database Buffer Cache

Contém cópias de blocos de dados lidos de arquivos

Único para os processos de todos os usuários conectados

Buffers organizados em listas - geralmente LRU

66



Estruturas de Memória

Quando uma informação é acessada, SGBD procura essa informação no database buffer cache. Se encontra (cache hit) os dados são

utilizados diretamente da memória.

Se não (cache miss), o bloco de dados é copiado do arquivo de dados para o database buffer cache e, então, utilizado.

Um alto número de cache misses pode ser um indicador de problemas de desempenho



Buffer Cache

Finalidade: manter páginas mais usadas em memória

reduzir operações de I/O

Leitura lógica página desejada pode estar ou não no BP

Leitura física necessário realizar operação de I/O

67



Buffer Cache

Eficiência do Buffer Pool: hit ratio

%100l

l

readsogical

readsphysicalreadsogicalratiohit

• Desejável:

hit ratio > 95%

depende das características do sistema



Equilibrando I/O

Mapeamento entre tabelas / índices e os data files

Tabela

Índice

Índice

Tablespace

Tablespace

68



Estrutura de Armazenamento

Tabelas e índices alocam um espaço no banco de dados quando são criados => tamanho inicial.

A medida que crescem, podem surgir extensões, que podem não ser contíguas;

Fragmentação pode gerar problema de desempenho;



Comentários Finais

Regras básicas x experiência

Algumas regras indicam o caminho a tomar.

O otimizador pode gerar situações ilógicas... Experiência e criatividade ajudam muito!

Sempre testar as soluções adotadas em ambiente de simulação!

• Sintonia automática: será a solução?

69



Agradecimentos

Sérgio [email protected]

Ana Carolina, Morelli, Maíra, Marcos, Anolan, Rogério, Tonho, Pedro…

www.inf.puc-rio.br/~postgresql



Perguntas?

OBRIGADO!

mailto:[email protected]



70



Alguns conceitos...

Plano de acesso: caminhos e formas de acesso que serão utilizados pelo SGBD para atender a uma requisição SQL

Otimizador: componente do SGBD responsável por montar o plano de acesso aos dados => independência da consulta com relação ao formato de armazenamento dos dados



Distribuição de Arquivos

I/O paralelo => diminui a disputa por disco.

Dividir arquivos de maior acesso em diferentes discos.

Manter em discos separados:

Tablespaces do sistema;

Arquivos de dados com tabelas muito acessadas;

Arquivos de índices para tabelas muito acessadas;

71



Row Migration

page n

F/V 1 F/V 2 F/V 3 F/V 4L1 L2 L3 L4headerupdate t1 set c1 =

....

page p

F/V 1 F/V 2 F/V 3 F/V 4L1 L2 L3 L4header

page n

header

ANTES

DEPOIS



Row Chaining

page k page p page t

F/V 1 F/V 2L1 L2 F/V 3 F/V 4L3 L4header

Representaçãológicapage k

page p

page t

Armazenamento físicoF/V 3L3 F/V 4L4header

F/V 1header L1

F/V 2header L2

72



Eliminando Fragmentação

Aloque o espaço adequado na criação do objeto

Recrie o objeto, possivelmente movendo para novo tablespace => crie o objeto com o espaço adequado;

Exporte e reimporte a tabela



Particionamento

Decomposição de grandes objetos em objetos menores =>partições.

Cada partição física possui seus próprios atributos físicos => podem ser armazenadas até mesmo em tablespaces diferentes!

Pode ser realizado com dados e com índices.

73



Particionamento

Exemplo:CREATE TABLE vendas (idVenda NUMBER(5),

data DATE,ValorTotal NUMBER(15,3))

PARTITION BY RANGE (data)(PARTITION data1 VALUES LESS THAN TO_DATE('01/04/2004','DD/MM/YYYY')TABLESPACE ts1,PARTITION data2 VALUES LESS THAN TO_DATE('01/07/2004','DD/MM/YYYY')

TABLESPACE ts2. . .PARTITION data4 VALUES LESS THAN TO_DATE('01/01/2005','DD/MM/YYYY')

TABLESPACE ts4)



Particionamento

Pode ocorrer por intervalos de valores (de uma ou mais colunas), hash e lista.

Sub-particionamento => partições para cada partição. Exemplo: partição por estados e, para cada

estado, sub-partição por intervalo de datas

74



Particionamento

Otimizador pode acessar somente uma partição na realização de consultas.

Em tabelas com mesmas chave de particionamento e pontos de quebra, as junções podem ser realizadas por partições



Métodos de Acesso – SQL Server

Principais métodos de acesso:

Table Scan: percorre toda a tabela

Index Scan/Clustered Index Scan: percorre todo o nível folha do índice

Bookmark Lookup: procura uma linha na tabela ou índice baseado em seu rowid

Index Seek/Clustered Index Seek: percorre parte do índice recuperando informações de algumas chaves

75



Métodos de Acesso – Oracle

Principais métodos de acesso: Full Table Scan: leitura seqüencial de todas as

páginas de uma tabela

Index Unique Scan: acessa uma única linha, garantido por constraint

Index Range Scan: acessa subconjunto dos dados de forma ordenada

Index Skip Scan: acesso indexado quando as colunas que prefixam o índice composto não são especificadas

Fast Full Index Scan: usado quando o índice cobre a consulta



Self-tuning de índices baseado em diferenças

Modelo Geral Otimizador de consultas gera plano de

execução

Agente de self-tuning de índices verifica se existe a possibilidade de criação de índices que auxiliem na consulta – índices hipotéticos

Em caso afirmativo, novo plano é gerado considerando os índices hipotéticos

Os ganhos da execução da consulta com índices hipotéticos são comparados com custos de criação dos índices em questão

76




Avaliação de consultas

C = CR – CH;

Se C > CI então:

Criar índice;

Executar consulta;

Senão,

Executar consulta;

Avaliar operações anteriores;

Fim-se;

CR= Custo com índices

existentes

CH= Custo com índices

hipotéticos

CI= Custo de criação

de índices

C= Ganho na execução

da consulta com

índices hipotéticos




Avaliação de operações anteriores

Se CA + C > CI , então

Criar índice;

Apagar CA ;

Senão,

Fazer CA = CA + C ;

Fim-se;

CA= Custo armazenado

de possíveis ganhos

CI= Custo de criação

de índices

C= Ganho na execução

da consulta com

índices hipotéticos

77




Avaliação de operações atualização e exclusões

C = CR – CH ;

Se C > 0

Se C > CI então:

Criar índice;

Executar operação;

Senão,


Avaliar operações anteriores;

Fim-se;

Senão,

CA = CA - C;

Se |CA| = CI então,

Se índice existe, destruir índice;


Apagar CA;

Fim-se;

Fim-se;

CR= Custo com índices existentes

CH= Custo com índices hipotéticos

CI= Custo de criação de índices

CA= Custo armazenado de

possíveis ganhos

CI= Custo de criação de índices

Sistema de Análise e Dimensionamento de Vigaspostgresql/conteudo/publicationsfiles/SBBD09... · 2...

Documents

Transcript of Sistema de Análise e Dimensionamento de Vigaspostgresql/conteudo/publicationsfiles/SBBD09... · 2...