A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


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

1 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 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 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 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 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 6 (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 > and date between and group by prodNum, date; Indices para uma aplicação que contém estas (e possivelmente muitas outras…) cláusulas SQL? Problema típico

7 7 Problema simples? update venda set valor = valor - 1 where valor > ; Índices ajudam ou atrapalham?

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

9 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 10 Controle de Concorrência Processador de Consultas Gerente de Armazenamento Arquitetura Funcional Componentes 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

11 11 Processamento de Consultas Parse Query Check de Semântica Query Rewrite Otimização do Plano de Acesso Geração de Código

12 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 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 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 15 QEP: Query Execution Plan Exemplo: SELECT endereço, data-nascimento FROM empregado WHEREnome = Guga Kuerten Execution Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMPREGADO' 2 1 INDEX (UNIQUE SCAN) OF 'PK_EMP' (UNIQUE)

16 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 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 18 Caso Árvores B

19 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 –N = N = –m = 512m = 512 –d níveisd níveis

20 20 Índices Clusterizados

21 21 Índices Não-clusterizados

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

23 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) – IBMs Autonomic Computing Manifesto (2001)

24 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 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: db2advis SQL Server 2005: Database Tuning Advisor Oracle 10g: Automatic Database Diagnostic Monitor Pg_autovacuum

26 26 Caso SQL Server

27 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 Auto-sintonia global por construção Auto-sintonia global por adaptação Possível Classificação

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

30 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 31 DepartmentEmployeeProduct id – int name – varchar(50) managerid – int Number of tuples: 200 Number of tupes: 100Number 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. here Uso de Índices Hipotéticos

32 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 select d.name, e.name, e.salary from employee e, department d where e.depid = d.id and e.salary between 1000 and 2500; Consultas Frequentes

33 33 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. Plano de Consulta

34 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 35 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; 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 36 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. Análise de Custos na presença de Índices Hipotéticos

37 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 38 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; Lets check the query execution plan for the query with the actual index created: Plano de consulta com novo índice criado

39 39 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. Análise dos custos

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

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

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

43 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 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 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 46 Avaliação de Vazão (Throughput) Escala do BD: # de armazéns Teste de 90 min: período de aprendizado ok

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

49 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 50 Componentes = Agentes

51 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 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 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 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 55 Fragmentação no Nível Folha

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

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

60 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 61 Acknowledgments Rogério Costa Marcos Antonio Vaz Salles Maíra Noronha Anolan Milanes Eduardo Morelli José Maria Monteiro …

62 62 OBRIGADO!


Carregar ppt "1 Auto-sintonia de Índices Completa: create, drop e reindex automáticos no PostgreSQL Prof. Sérgio Lifschitz Depto Informática PUC-Rio"

Apresentações semelhantes


Anúncios Google