1 auto-sintonia de Índices completa: create, drop e reindex automáticos no postgresql prof....

1

Auto-sintonia de Índices Completa: create, drop e

reindex automáticos no PostgreSQL

Prof. Sérgio LifschitzDepto Informática PUC-Rio

[email protected]

ERBD 2008Florianópolis (SC)

2

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!

3

Sintonia de Bancos de Dados

• Tuning - 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!

4

Afinal, sintonia fina de quê?

• 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

5

Atividade de Sintonia

• 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.

6

(1)insert into SALES (prodNum, date, qty, value)values (4, current_timestamp, 20, 348);

(2)select prodNum, date, sum(value) as totalfrom SALESwhere 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

7

Problema simples?

update venda

set valor = valor - 1

where valor > 2375000;

Índices ajudam ou atrapalham?

8

Agendao Introdução e Motivaçãoo Fundamentos

o SGBD, Índices e Processamento de Consultas

o Estado da Arteo Auto-sintonia local e global

o Índices Hipotéticoso What-if

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

PostgreSQL

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

o Comentários Finais

9

O que é preciso saber?

A atividade de sintonia fina 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 bastante conhecer SGBDs específicos!

10

Controle de Concorrência

Processador de Consultas

Gerente de Armazenamento

Arquitetura FuncionalComponentes de um SGBD

Otimizador Executor

Gerência deBloqueios

Gerência deTransação e Recuperação

Controle de Memória

Controle de Dados

Meta-Dados eEstatísticas

Dados e Índices

Log de Transações

SQL

11

Processamento de Consultas

Parse Query

Check de Semântica

Query Rewrite

Otimização doPlano de Acesso

Geração de Código

12

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

13

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

14

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

15

QEP: Query Execution Plan

• Exemplo:

SELECT endereço, data-nascimento

FROM empregado

WHERE nome = ‘Guga Kuerten’

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)

16

Acesso por Í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!

17

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

18

Caso Árvores B+

23 37

58 75

43 95

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

19

• Manutenção:– N chaves, m ponteiros por página (ordem) – número máximo de níveis d (pior caso):

Características de Á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

☹

20

Índices Clusterizados

21

Índices Não-clusterizados

22






PostgreSQL



23

Autonomic Computing

• Um grande desafio para a comunidade acadêmica e indústria– tornar os sistemas computacionais mais

autônomos

• Visões de futuro– Asilomar Report on Database Research

(1998)– IBM’s Autonomic Computing Manifesto

(2001)

24

Auto-Sintonia (Self-Tuning)

• Capacidade de auto-ajuste dos SGBDs ao ambiente existente para obtenção de melhor desempenho

• Alguns SGBDs comerciais já oferecem versões com algumas características automáticas

• Trabalhos científicos: – muitos artigos sendo publicados nos últimos 10

anos!

25

25/22

Trabalhos Correlatos

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

Índices Hipotéticos

Survey

Auto-Sintonia Global

Heurística de Benefícios

DB2: db2advisDB2: db2advis

SQL Server 2005: Database Tuning Advisor

SQL Server 2005: Database Tuning Advisor

Oracle 10g: Automatic Database Diagnostic Monitor

Oracle 10g: Automatic Database Diagnostic Monitor

Pg_autovacuumPg_autovacuum

26

Caso SQL Server

27

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


por construção


por adaptação

Possível Classificação

28

Self-Tuning de índices

• Sintonia fina de índices:– Índices podem auxiliar em consultas– Índices podem ser prejudiciais a atualizações– Quais índices criar?

• Dificuldades adicionais:• Quando criar ou destruir?• Risco de criar-recriar inúmeras vezes

29






PostgreSQL



30

• Uso de SGBD completo de código aberto• Simulação? Não!• PostgreSQL (por ora, v. 7.4 beta 3)• Linux

• Abordagem intrusiva• Código core modificado• Comando create hypothetical index

Ambiente de Implementação

31

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

Actual indexes are created for all of the tables’ primary keys. Scripts to create the university database can be found here.

Uso de Índices Hipotéticos

32

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 Frequentes

33

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

34

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:

create hypothetical index hi_employee_salary

on employee(salary);

Criando Índices Hipotéticos

35

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:

Planos de Consultas com Índices Hipotéticos

36


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.

Análise de Custos na presença

de Índices Hipotéticos

37

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:

Índices Hipotéticos eventually se tornam reais

38

explain select

d.name, e.name, e.salary




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

Plano de consulta com novo índice criado

39


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.

Análise dos custos

40






PostgreSQL



41

Arquitetura do Componente de Auto-sintonia

Queries, updates,

procedur

e calls

Parser

Optimizer

Executor

Index

Self-tuning

Component

Statements,

Plans

Indexing

Alternatives

Index Creation

Routines

Index Creation

Requests

DBMS

42

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 Sensor

Ação Ação

Raciocínio Raciocínio

Mobilidade Mobilidade

Colaboração Colaboração

Tradução Tradução

Crença Crença

43

Integrando agentes ao SGBD

Statement

Processor

Index

Self-tuning

Agent

Index Creation

Routines

PostgreSQL

Postgres Process

Shared Queue

Postgres Process

Statement

Processor

Postgres Process

Statement

Processor

…

Storage Structures

44

Heurística de Benefícios• Query Evaluation Strategy

Benefit of Hypothetical Index = Cost of Query with Actual Indexes – Cost of Query with Hypothetical Indexes;Update Accumulated Benefit of Hypothetical Index;If (Accumulated Benefit of Hypothetical Index >

Cost to Create Hypothetical Index)Then

Reset Accumulated Benefit of Hypothetical Index;

Materialize Hypothetical Index;End if;

• Updates follow similar rules, but consider index destruction

45

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 pelos

projetistas do toolkit e agente desligado

• Resultados surpreendentes!– Um índice dos projetistas não criado– Um índice não projetado criado... Porém útil!

46

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)

Noindexing

AutomaticIndexing

Staticindexing

47

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

48






PostgreSQL



49

Estudos com carga OLAP

• TPC-H• Menos estável• 6 consultas representativas (das

22)• Novo comando

Evaluate

select linenumber, quantity

from lineitem

where orderkey = 200 and linenumber = 2;

50

Componentes = Agentes

51

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?

52

Ciclo create-drop

• Há risco de destruir índices que serão recriados posteriormente

• Custos envolvidos não desprezíveis• Análise fina da situação: • Por quê índice não está sendo útil?

• Reindex é usado por DBAs

53

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!!!

54

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

55

Fragmentação no Nível Folha

56

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

57






PostgreSQL



58

Algumas conclusões

• DBA automatizado? – SIM! Vale a pena ... – Paper SQLmag: “Será o fim do DBA?”

• Resultados preliminares animadores– Ferramentas de mercado– Academia: e.g. postgreSQL

• Vários problemas em aberto– Sintonia de projeto físico– Grau de autonomia!

59

Planos HipotéticosPlanos Hipotéticos

Workload ObtainmentWorkload Obtainment

Candidate Index SelectionCandidate Index Selection

Final Index SelectionFinal Index Selection

Database ExecuterDatabase Executer

MonitoringSQL

MonitoringSQL

DDL Clauses

DDL Clauses

SELECT *FROM memberWHERE last_name = ‘Randall’

SELECT *FROM memberWHERE last_name = ‘Randall’

CostsCosts

+ Candidate Indexes+ Candidate Indexes

Final Indexes Recommendations

Final Indexes Recommendations

BD

WorkloadWorkload

Modified Plan

Indexes Benefits

Statistics

60

Atuais e Próximos Passos

• Planos hipotéticos na prática• Wizards para PostgreSQL e versão 8• Parceria com UFC e aplicação real• Gráfico de planos reais e hipotéticos• Interação com DBA para tomada de

decisão• Aviso de iminência de criação do índice• Consulta da metabase com índices

hipotéticos• .... E muitas outras idéias ainda surgindo!

61

Acknowledgments

• Rogério Costa• Marcos Antonio Vaz Salles• Maíra Noronha• Anolan Milanes• Eduardo Morelli• José Maria Monteiro …

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

62

OBRIGADO!

1 auto-sintonia de Índices completa: create, drop e reindex automáticos no postgresql prof....

Documents