Uma Abordagem Não-Intrusiva para Sintonia Automática de Consultas SQL

Transcrição

1 Uma Abordagem Não-Intrusiva para Sintonia Automática de Consultas SQL Arlino H. Magalhães de Araújo 1, José Maria Monteiro 1, José Antônio F. de Macêdo 1 1 Departamento de Computação Universidade Federal do Ceará (UFC) Campus do Pici - Bloco Fortaleza CE Brasil {arlino,monteiro,jose.macedo}@lia.ufc.br Nível: Mestrado Ingresso: março de 2010 Conclusão esperada: março de 2012 Etapa concluída: disciplinas Abstract. The cost models used in current DBMS query optimizers depend on several factors, such as: statistics, estimates and properties. This fact makes these optimizers, in many cases, inaccurate to pick plans, generating suboptimal plans. In such situations, it is necessary to tune SQL statements to guide the optimizer in choosing a better execution plan than that which would normally be selected. However, this process requires a high level of expertise and skill of the DBA. Thus, this paper presents an approach for automatic and non-intrusive SQL tuning. Resumo. Os modelos de custo utilizados pelos otimizadores de consulta dos SGBDs atuais dependem de diversos fatores que podem torná-los imprecisos, tais como: estatísticas, estimativas e propriedades. Este fato faz com que esses otimizadores sejam, em muitos casos, imprecisos na escolha de planos de execução, gerando planos sub-ótimos. Em tais situações, é necessário realizar a sintonia da consulta SQL a fim de orientar o otimizador na escolha de um plano de execução melhor do que aquele que normalmente seria selecionado. Entretanto, esse processo exige um alto nível de especialização e habilidade do DBA. Neste sentido, este trabalho apresenta uma abordagem para a sintonia automática e não-intrusiva de consultas SQL. 1. Introdução Sistemas Gerenciadores de Bancos de Dados (SGBDs) permitem especificar consultas usando linguagens declarativas de alto nível, como, por exemplo, SQL (Structured Query Language). O otimizador de consultas é responsável por escolher um plano de execução eficiente para cada consulta a ser executada pelo SGBD. Para este propósito, os otimizadores baseados em custos procuram, em um grande espaço de busca, o plano de execução que proporcione o menor tempo de resposta. Para realizar esta tarefa os otimizadores utilizam um modelo de custo, o qual possibilita estimar os recursos necessários e o custo da execução de cada um dos planos analisados, possibilitando assim comparar o custo de execução das várias alternativas de plano e selecionar o plano de execução ótimo, ou seja, que apresente o menor custo de execução. 7

2 Os modelos de custo utilizados pelos otimizadores de consulta atuais são bastante complexos e dependem de fatores que podem torná-los imprecisos, tais como: (a) estimativas de cardinalidade, que são inferidas através de suposições sobre correlação e uniformidade; (b) constantes de calibração, usadas na estimativa de determinados custos, os quais não podem ser calculados de forma exata ou que dependem de aspectos específicos do hardware utilizado, como, por exemplo, o custo de I\O em um disco rígido específico; (c) fórmulas de cálculo de determinados custos podem não capturar todos os detalhes dos algoritmos utilizados nos planos de execução; (d) parâmetros de configuração do banco de dados influenciam os custos de execução das consultas, como, por exemplo, tamanho do buffer de memória; e (e) mesmo que fosse possível determinar com exatidão o custo de uma determinada consulta de maneira isolada, na prática, as consultas executam de forma concorrente e a execução de uma consulta pode influenciar o tempo de execução das demais devido a fatores como o compartilhamento das estruturas de índice e bloqueios excessivos [Bruno and Chaudhuri and Ramamurthy 2009]. 2. Definição do Problema Mesmo usando métodos de acesso e estratégias de avaliação suportadas pelo SGBD, às vezes, os otimizadores não conseguem produzir planos ótimos. Nestes casos, deve ser realizado o ajuste (ou sintonia) da consulta SQL. Para isso, em geral, duas estratégias são frequentemente utilizadas: (a) reescrever a consulta SQL de tal forma que esta retorne o mesmo resultado da cláusula SQL anterior e influencie o otimizador a escolher um plano de execução que ofereça um desempenho melhor que o plano de execução gerado anteriormente; e (b) aplicar Query Hinting para forçar a seleção de um determinado plano de consulta que seja mais eficiente que o plano de execução gerado inicialmente [Shasha and Bonnet 2003]. A técnica de reescrita consiste em escrever uma nova cláusula SQL semanticamente equivalente à cláusula SQL inicialmente utilizada (ou seja, que retorne o mesmo resultado) e que apresente ganhos de desempenho [Hamakrishnan and Gehrke 2008]. Um mecanismo comum usado nos bancos de dados comerciais é a Query Hinting. Essencialmente, um hint (dica) instrui o otimizador a restringir seu espaço de busca para certo subconjunto de planos de execução (por exemplo, impor a escolha de planos que usem um determinado tipo índice ou determinar a ordem e/ou método de junção). O uso de um hint é feito apenas alterando-se a sintaxe do comando SQL. Contudo, deve ser observado se o plano escolhido para esta nova consulta (após a inserção do hint) proporciona um desempenho melhor [Bruno and Chaudhuri and Ramamurthy 2009]. O Administrador de Bancos de Dados (DBA) utiliza-se da reescrita de SQL e da inserção de hints para ajustar (sintonizar) as consultas SQL. Entretanto, esse processo é complexo e requer bastante conhecimento em áreas, como: (i) otimização de consultas, execução de operadores de planos de consultas, configuração de parâmetros e outros aspectos internos dos bancos de dados; (ii) identificação de índices necessários e outras estruturas de acesso; (iii) manutenção de estatísticas sobre os dados; e (iv) características dos sistemas de armazenamento de dados [Herodotou and Babu 2009]. 8

3 Além disso, em geral, o DBA trabalha de uma forma reativa, ou seja, só é acionado quando é percebido que uma consulta está lenta (em geral, isso é detectado por um usuário). Depois de monitorar e identificar o problema, ele ajusta a consulta, testa e a envia para o programador realizar esta alteração no código da aplicação que está usando a consulta SQL. Todo esse processo consome bastante tempo, tanto do DBA como do programador. 3. Solução Proposta Para lidar com os fatores que influenciam o otimizador de consultas a escolher um plano sub-ótimo, esse trabalho propõe uma abordagem e uma arquitetura, a qual está organizada em dois módulos, cuja finalidade é realizar a sintonia automática de consultas SQL em bancos de dados relacionais. O primeiro módulo consiste em um advisor capaz de automaticamente: (i) capturar as consultas anteriormente executadas, (ii) analisar essas consultas e (ii) sugerir (por meio de alertas, wizards ou relatórios) oportunidades de sintonia de consultas SQL. Assim, o advisor identifica cláusulas SQL que se fossem ajustadas, reescritas ou utilizassem hints, poderiam fazer com que o otimizador de consultas escolhesse planos de execução melhores, reduzindo o tempo de execução das consultas SQL e trazendo ganhos de desempenho. O segundo módulo consiste em um middleware que atua entre a aplicação e o SGBD. Este middleware é responsável por: (i) receber as consultas SQL enviadas pelas aplicações; (ii) realizar a sintonia automática das consultas SQL recebidas; (iii) enviar as consultas obtidas pelo processo de sintonia (reescritas) para o SGBD e (iv) receber do SGBD o resultado da execução da consulta e enviá-lo à aplicação. A abordagem proposta utilizará um conjunto de heurísticas para realizar a sintonia das consultas SQL. As heurísticas são constituídas de regras para identificar potenciais problemas de sintonia nos comandos SQL, bem como de formas de reescrever as consultas para solucionar os problemas identificados. A solução proposta apresenta ainda as seguintes características: - Não-intrusiva: completamente desacoplada do código do SGBD. Isso permite que a solução concebida possa ser utilizada com qualquer SGBD. - Independente de localização: pode executar em uma máquina distinta daquela utilizada para hospedar o SGBD. Adicionalmente, o middleware que compõe o segundo módulo da arquitetura proposta apresenta ainda as seguintes características: - Automático: completamente independente de interações com seres humanos. - On-the-fly: ser executado de forma contínua durante o funcionamento normal do SGBD. 3.1 Contribuições As principais contribuições desta dissertação são: (1) Uma abordagem não-intrusiva para sintonia automática de consultas SQL. (2) Um conjunto de heurísticas voltadas para identificar oportunidades de sintonia em consultas SQL e ajustar (reescrever) essas consultas de forma a induzir o otimizador a escolher um plano de execução melhor, ou seja, que proporcione um tempo de execução menor. 9

4 (3) Uma arquitetura baseada na colaboração entre agentes de software que possibilite implementar a abordagem proposta. (4) Uma implementação da arquitetura e da abordagem proposta. 4. Arquitetura Proposta A arquitetura concebida (ilustrada na Figura 1) baseia-se na colaboração entre agentes de software e é dividida em dois módulos: o módulo 1, um advisor cuja finalidade é analisar as consultas previamente executadas e sugerir oportunidades de sintonia de consultas SQL; e o módulo 2, um middleware que atua entre as aplicações e o SGBD realizando a sintonia automática e on-the-fly das consultas SQL enviadas pelas aplicações. Figura 1: Arquitetura não-intrusiva para sintonia automática de consultas SQL. Os principais componentes desta arquitetura são: - Agent for Workload Obtainment (AWO): consulta a metabase do SGBD e recupera as cláusulas SQL que foram ou estão sendo executadas, juntamente com seus respectivos planos de execução e estimativas de custo. E, em seguida, as armazena na metabase local (Local MetaData - LM). - Local MetaData (LM): armazena a carga de trabalho capturada pelo AWO. - Driver for Workload Access (DWA): driver que permite recuperar a carga de trabalho submetida a um SGBD específico. - Driver for Data Access (DDA): driver que permite que o motor do middleware proposto (Middleware for Query Rewrite) envie as consultas ajustadas automaticamente para o SGBD e receba o resultado da execução dessas consultas. - Agent for Statistics Obtainment (ASO): acessa o SGBD e recupera informações estatísticas, como, por exemplo, o número de linhas de uma determinada tabela, etc. 10

5 - Driver for Statistics Access (DSA): driver que permite recuperar as estatísticas de um SGBD específico. - Heuristic Set (HS): conjunto de heurísticas utilizadas pelos agentes para identificar consultas SQL com oportunidades de melhoria e para reescrever essas cláusulas. Algumas das heurísticas identificadas são genéricas e se aplicam a qualquer SGBD, já outras, no entanto, são específicas. - Agent for Query Rewrite (AQR): analisa uma determinada consulta SQL, utilizando o conjunto de heurísticas (HR), a fim de identificar oportunidades de melhoria e reescrever a consulta, caso seja necessário. - Middleware for Query Rewrite (MQR): é motor do middleware proposto e responsável por receber consultas SQL das aplicações, ajustar automaticamente essas consultas, enviar as consultas ajustadas para o SGBD, receber o resultado da execução dessas consultas e enviá-los para as aplicações. 5. Trabalhos Relacionados Em [Krishnaprasad et al 2004] é descrita uma técnica para transformar uma consulta XML em uma cláusula equivalente no modelo relacional ou objeto-relacional por meio de reescrita em tempo de compilação. No trabalho proposto em [Bruno and Chaudhuri and Ramamurthy 2009] é discutido um framework denominado Power Hints, o qual possibilita a criação e utilização de hints. O framework possibilita a criação de hints por meio de expressões regulares, tornando mais fácil e flexível criar restrições para planos de execução de consulta, permitindo uma sintonia mais precisa. Em [Herodotou and Babu 2009] é apresentada uma ferramenta denominada ztuned cuja finalidade é facilitar experimentos relacionados à sintonia de consultas SQL. A ferramenta produz conjuntos de planos que possuem operadores com a mesma cardinalidade (chamados de planos da vizinhança) e escolhe o plano ótimo entre os melhores planos de cada vizinhança, utilizando-se do mecanismo de estimativa de custos do próprio SGBD. A ferramenta trabalha desacoplada do otimizador de consultas e pode ser potencialmente utilizada com qualquer SGBD que possua um otimizador baseado em custos. No Oracle 10g é introduzido um componente denominado Automatic SQL Tuning Advisor que fornece recomendações de criação de índices baseado nos predicados presentes nas cláusulas SQL e recomendações de oportunidades de reescrita de consultas utilizando equivalências semânticas [Dageville and Dias 2006]. Existem algumas ferramentas tais como o IBM Optim Development Studio [Studio 2010], o Embarcadero DB Optimizer XE [Optimizer 2010] e o Quest SQL Optimizer for Oracle [Oracle 2010] que já realizam sintonia de consultas através de recomendações de reescrita, de uso de hints e/ou de criação de índices. Entretanto, elas adotam uma abordagem offline (não contínua) na solução do problema e transferem para o DBA, dentre outras tarefas, a decisão de executar ou não as recomendações sugeridas. 11

6 Adicionalmente, vale destacar que não foi encontrado nenhum trabalho relacionado à sintonia de consultas SQL que possua as três características a seguir: onthe-fly (executar de forma contínua), automática (independente de intervenções humanas) e não-intrusiva (desacoplada do código do SGBD). 6. Estado Atual do Trabalho 7. Conclusões (1) Identificação das heurísticas para reescrita de consultas (etapa concluída). (2) Identificação das heurísticas para a utilização de query hinting (em desenvolvimento). (3) Implementação e avaliação do protótipo (em desenvolvimento). (4) Elaboração do texto (não iniciado). Neste trabalho apresentamos uma arquitetura e uma abordagem não-intrusiva para sintonia automática de consultas SQL. A solução proposta aplica-se a situações onde o otimizador de consultas não consegue produzir planos ótimos, mesmo usando métodos de acesso e estratégias de avaliação suportadas pelo SGBD. A ferramenta proposta utiliza um conjunto de heurísticas e a colaboração entre agentes de software para realizar de forma autônoma a sintonia das consultas SQL. Para avaliar e validar a abordagem proposta pretende-se utilizar uma carga de trabalho sintética, mais precisamente o benchmark TPC-H, e uma carga de trabalho real. Referências Bruno, N., Chaudhuri, S. and Ramamurthy, R. (2009) Power Hints for Query Optimization, In: Proceedings of the 2009 IEEE International Conference on Data Engineering, ACM, Washington, DC, USA. Dageville, B. and Dias, K. (2006) Oracle s Self-Tuning Architecture and Solutions, In: IEEE Computer Society Technical Committee on Data Engineering, Oracle, USA. Hamakrishnan, R. and Gehrke, J. (2008) Sistemas de Bancos de Dados, São Paulo: McGraaw- Hill. Herodotou, H. and Babu, S. (2009) Automated SQL Tuning through Trial and (Sometimes) Error, In: DBTest 09, ACM, Rhode Island, USA. Krishnaprasad, M., Liu, Z. H., Manikutty, A., Warner, J. W., Arora, V. and Kotsovolos, S. (2004) Query Rewrite for XML in Oracle XML DB, In: Proceedings of the Vldb Conference, Toronto, Canada. Optimizer, D. X. (2010) Embarcadero DB Optimizer XE, Available: June. Oracle, S. O. (2010) Quest SQL Optimizer for Oracle, Available: Optimizer-for-Oracle, June. Shasha, D. and Bonnet, P. (2003) Database Tuning: Principles, Experiments and Troubleshooting Techniques, Morgan Kaufmann. Studio, O. D. (2010) IBM Optim Development Studio, Available: 01.ibm.com/software/data/optim/development-studio, June. 12