Auto-sintonia de Índices Completa: create, drop e reindex automáticos no PostgreSQL Prof. Sérgio Lifschitz Depto Informática PUC-Rio sergio@inf.puc-rio.br.

Apresentação em tema: "Auto-sintonia de Índices Completa: create, drop e reindex automáticos no PostgreSQL Prof. Sérgio Lifschitz Depto Informática PUC-Rio sergio@inf.puc-rio.br."— Transcrição da apresentação:

1 Auto-sintonia de Índices Completa: create, drop e reindex automáticos no PostgreSQL Prof. Sérgio Lifschitz Depto Informática PUC-Rio ERBD 2008 Florianó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 Problema típico insert into SALES (prodNum, date, qty, value) values (4, current_timestamp, 20, 348); select prodNum, date, sum(value) as total from SALES where value > and date between ‘ ’ and ‘ ’ group by prodNum, date; Indices para uma aplicação que contém estas (e possivelmente muitas outras…) cláusulas SQL?

7 Índices ajudam ou atrapalham?
Oracle Otimização Problema simples? update venda set valor = valor - 1 where valor > ; Índices ajudam ou atrapalham? DI/PUC-Rio

8 Agenda Introdução e Motivação Fundamentos Estado da Arte
SGBD, Índices e Processamento de Consultas Estado da Arte Auto-sintonia local e global Índices Hipotéticos What-if Criação autônoma de índices TPC-C, sintonia local, heurística de benefícios, PostgreSQL Destruição e reindex automáticos TPC-H, sintonia global, fragmentação física 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 Arquitetura Funcional Componentes de um SGBD
Controle de Concorrência Processador de Consultas Gerência de Bloqueios Otimizador SQL Executor Gerência de Transação e Recuperação Gerente de Armazenamento Controle de Memória Controle de Dados Meta-Dados e Estatísticas Dados e Índices Log de Transações

11 Processamento de Consultas
Parse Query Check de Semântica Query Rewrite Otimização do Plano 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 SELECT STATEMENT Optimizer=CHOOSE TABLE ACCESS (BY INDEX ROWID) OF 'EMPREGADO' INDEX (UNIQUE SCAN) OF 'PK_EMP' (UNIQUE) Execution Plan SELECT STATEMENT Optimizer=CHOOSE TABLE ACCESS (BY INDEX ROWID) OF 'EMPREGADO' 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: Alguns SGBDs permitem:
Á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+    Uma árvore B+ é uma estrutura híbrida formada pelo uso combinado de Sequence Set e B-Tree. Ela é usada quando um mesmo arquivo puder ser pesquisado sequencialmente e por índice. Para pesquisar sequencialmente usa-se o sequence set e usa-se a árvore B que conterá nas suas chaves os índices do arquivo. A organização de arquivos VSAM – Virtual Storage Access Method – foi uma das primeiras implementações das árvores B+. 03-22 23-35 37-42 43-54 58-74 75 -

19 Características de Árvores B
Manutenção: N chaves, m ponteiros por página (ordem) número máximo de níveis d (pior caso): ☹ N = N = m = m = 512 d   3 níveis d   3 níveis Em uma árvore B todas as páginas folhas aparecem no mesmo nível e os registros aparecem em ordem crescente da esquerda para a direita. Podemos dizer que a árvore B é extensão natural da árvore binária de pesquisa. O processo de divisão (split) de páginas garante a manutenção das propriedades da B-tree durante a inserção. Essas propriedades precisam ser mantidas, também, durante a eliminação de chaves. Supondo que podemos colocar 512 chaves por página (valor razoável para páginas de 8K, por exemplo) , uma árvore B possuirá 3 níveis tanto para uma tabela de de linhas, quanto para uma tabela de de linhas.

20 Índices Clusterizados
Um índice clusterizado é um índice em que as linhas que têm um dado valor da chave de pesquisa aparecem em blocos que são amplamente dedicados a armazenar tuplas com esse valor da chave de pesquisa. Com um índice clusterizado, existe uma tendência a recuperarmos uma ou poucas páginas de dados para cada página folha do índice. Desta forma, uma varredura de todas as folhas de um índice clusterizado realiza um número de acessos a páginas de dados aproximadamente igual ao número de páginas folha do índice. Em geral, os índices de chave primária são clusterizados.

21 Índices Não-clusterizados
Em um índice não-clusterizado, duas chaves consecutivas, armazenadas em uma mesma página folha do índice, podem apontar para páginas de dados totalmente distintas. Com isto, uma varredura por todas as páginas folha do índice tende a realizar um número de acessos a páginas de dados igual ao número de chaves de pesquisa contidas nas páginas folha do índice.

22 Agenda Introdução e Motivação Fundamentos Estado da Arte
SGBD, Índices e Processamento de Consultas Estado da Arte Auto-sintonia local e global Índices Hipotéticos What-if Criação autônoma de índices TPC-C, sintonia local, heurística de benefícios, PostgreSQL Destruição e reindex automáticos TPC-H, sintonia global, fragmentação física Comentários Finais

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 Oracle Otimização 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. DB2: db2advis SQL Server 2005: Database Tuning Advisor Oracle 10g: Automatic Database Diagnostic Monitor Índices Hipotéticos Survey Auto-Sintonia Global Heurística de Benefícios Pg_autovacuum DI/PUC-Rio

26 Caso SQL Server

27 Possível Classificaçã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 por adaptaçã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 Agenda Introdução e Motivação Fundamentos Estado da Arte
SGBD, Índices e Processamento de Consultas Estado da Arte Auto-sintonia local e global Índices Hipotéticos What-if Criação autônoma de índices TPC-C, sintonia local, heurística de benefícios, PostgreSQL Destruição e reindex automáticos TPC-H, sintonia global, fragmentação física Comentários Finais

30 Ambiente de Implementação
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

31 Uso de Índices Hipotéticos
Tutorial: estudo de caso para what-if Department Employee Product Sale id – int name – varchar(50) managerid – int 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) id – int year – int month – int day – int prodid – int sellerid – int Price – numeric(4,2) Number of tuples: 200 Number of tupes: 100 Number of tuples: 250 Number of tuples: 250 Actual indexes are created for all of the tables’ primary keys. Scripts to create the university database can be found here.

32 Consultas Frequentes The following query is very frequently issued by the university application: select d.name, e.name, e.salary from employee e, department d where e.depid = d.id and e.salary between 1000 and 2500; Lets take a look at its query execution plan using the explain statement: explain select d.name, e.name, e.salary from employee e, department d where e.depid = d.id and e.salary between 1000 and 2500;

33 Plano de Consulta Query Execution Plan QUERY PLAN Hash Join (cost= rows=2499 width=50) Hash Cond: ("outer".depid = "inner".id) -> Seq Scan on employee e (cost= rows=2498 width=42) Filter: ((salary >= 1000::numeric) AND (salary <= 2500::numeric)) -> Hash (cost= rows=26 width=16) -> Seq Scan on department d (cost= 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.

34 Criando Índices Hipotéticos
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);

35 Planos de Consultas com
Índices Hipotéticos 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: explain hypothetical select d.name, e.name, e.salary from employee e, department d where e.depid = d.id and e.salary between 1000 and 2500;

36 Análise de Custos na presença de Índices Hipotéticos
Query Execution Plan QUERY PLAN Hash Join (cost= rows=2499 width=50) Hash Cond: ("outer".depid = "inner".id) -> Index Scan using hi_employee_salary on employee e (cost= rows=2498 width=42) Index Cond: ((salary >= 1000::numeric) AND (salary <= 2500::numeric)) -> Hash (cost= rows=26 width=16) -> Seq Scan on department d (cost= 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 using the sequential scan to using the index scan.

37 Índices Hipotéticos eventually
se tornam reais Now that we know that the index is beneficial to performance, we can drop the hypothetical index and create a corresponding actual one: drop hypothetical index hi_employee_salary; create index i_employee_salary on employee(salary);

38 Plano de consulta com novo índice criado explain select
Lets check the query execution plan for the query with the actual index created: explain select d.name, e.name, e.salary from employee e, department d where e.depid = d.id and e.salary between 1000 and 2500;

39 Análise dos custos Query Execution Plan QUERY PLAN Hash Join (cost= rows=2491 width=50) Hash Cond: ("outer".depid = "inner".id) -> Index Scan using i_employee_salary on employee e (cost= rows=2490 width=42) Index Cond: ((salary >= 1000::numeric) AND (salary <= 2500::numeric)) -> Hash (cost= rows=26 width=16) -> Seq Scan on department d (cost= rows=26 width=16) (6 rows) The cost estimated by the planner for the query using the hypothetical index was With the actual index, the planner gave us an estimate of Cost estimates for hypothetical indexes tend to be conservative, but always close to the cost of using the actual index.

40 Agenda Introdução e Motivação Fundamentos Estado da Arte
SGBD, Índices e Processamento de Consultas Estado da Arte Auto-sintonia local e global Índices Hipotéticos What-if Criação autônoma de índices TPC-C, sintonia local, heurística de benefícios, PostgreSQL Destruição e reindex automáticos TPC-H, sintonia global, fragmentação física Comentários Finais

41 Arquitetura do Componente de Auto-sintonia
Queries, updates, procedure calls DBMS Indexing Alternatives Parser Index Self-tuning Component Optimizer Index Creation Requests Statements, Plans Executor Index Creation Routines

42 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; Agente em Camadas Sensor Ação Raciocínio Mobilidade Colaboração Tradução Crença

43 Integrando agentes ao SGBD
PostgreSQL Postgres Process Postgres Process Statement Processor Shared Queue Index Self-tuning Agent … Statement Processor Postgres Process Statement Processor Index Creation Routines 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

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 Agenda Introdução e Motivação Fundamentos Estado da Arte
SGBD, Índices e Processamento de Consultas Estado da Arte Auto-sintonia local e global Índices Hipotéticos What-if Criação autônoma de índices TPC-C, sintonia local, heurística de benefícios, PostgreSQL Destruição e reindex automáticos TPC-H, sintonia global, fragmentação física Comentários Finais

49 Estudos com carga OLAP TPC-H Menos estável
Oracle Otimização 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; DI/PUC-Rio

50 Oracle Otimização Componentes = Agentes DI/PUC-Rio

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 Oracle Otimização 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 DI/PUC-Rio

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 Malefícios Causados pela Fragmentação de Índices
Oracle Otimização Recriação de Índices Malefícios Causados pela Fragmentaçã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?! DI/PUC-Rio

55 Fragmentação no Nível Folha
Oracle Otimização Fragmentação no Nível Folha DI/PUC-Rio

56 Fragmentação de Índices
Oracle Otimização 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 DI/PUC-Rio

57 Agenda Introdução e Motivação Fundamentos Estado da Arte
SGBD, Índices e Processamento de Consultas Estado da Arte Auto-sintonia local e global Índices Hipotéticos What-if Criação autônoma de índices TPC-C, sintonia local, heurística de benefícios, PostgreSQL Destruição e reindex automáticos TPC-H, sintonia global, fragmentação física Comentários Finais

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 Candidate Index Selection
Planos Hipotéticos Monitoring SQL SELECT * FROM member WHERE last_name = ‘Randall’ Workload Obtainment Candidate Index Selection Costs + Candidate Indexes Modified Plan Indexes Benefits Statistics Final Index Selection Final Indexes Recommendations BD DDL Clauses Database Executer Workload

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 …

62 OBRIGADO!