ambiente de recomendação de índices para bancos de dados mysql

Ambiente de recomendação de índices para bancos de

dados MySQL

Eduardo WeilandOrientador Prof. Msc. Eduardo Kroth

Universidade de Santa Cruz do SulCurso de Ciência da Computação

Roteiro

> Motivação

> Objetivos

> Metodologia

> Referencial teórico

> Trabalhos relacionados

> Solução desenvolvida

> Resultados

> Conclusão

> Trabalhos futuros

> Referências

2Universidade de Santa Cruz do Sul12 julho 2016

Motivação


Muitas aplicações utilizam bancos de dados relacionais como principal meio de armazenamento de dados.

O desempenho do Sistema de Gerenciamento do Banco de Dados (SGBD) afeta diretamente essas aplicações.

Fonte: O autor

Motivação


Um banco de dados relacional utiliza índices para acessar os dados de maneira mais eficiente

Fonte: Lightstone (2007)

Servidor Índice Arquivos de dados

Motivação

12 julho 2016 Universidade de Santa Cruz do Sul 5

O SGBD tenta escolher o melhor índice possívelpara executar cada consulta

Motivação



Mas só considera os índices que JÁ EXISTEMno banco de dados

Motivação



Mas só considera os índices que JÁ EXISTEMno banco de dados

Como encontrar o melhor índice se ele não existe?

Objetivo geral

Desenvolver uma ferramenta de código aberto

capaz de identificar possíveis melhorias na

estrutura física de um banco de dados MySQL e

sugerir as modificações necessárias para melhorar

a performance de execução das consultas.


Objetivos específicos

> Verificar quais as principais características que influenciam a performance dos bancos de dados relacionais em geral

> Elaborar a ferramenta possibilitando integração com diferentes SGBDs

> Validar a solução desenvolvida em um ambiente de uso real


Metodologia

> Exploratória e bibliográfica- Pesquisa em trabalhos relacionados

> Quantitativa- Redução do custo para execução de consultas

> Descritiva- Execução de testes e análise de resultados

- Ambiente controlado e ambiente real


Por que MySQL?

> Após uma pesquisa inicial, foram encontradas ferramentas semelhantes para outros SGBDs do mercado- SQL Server, DB2, Oracle, PostgreSQL

> Para MySQL não foi encontrada nenhuma publicação com uma proposta semelhante

> "Os SGBDs de código aberto não oferecem nenhuma ferramenta de ajustes (tuning) automatizada"(Alagiannis et al., 2010)


Referencial teórico



Bancos de dados

> Modelo cliente-servidor

> Modelo lógico X modelo físico

> Instruções SQL (workload)

Fonte: Bell (2012)

Processamento de consultas


Fonte: Bell (2012)

Estratégias de otimização

> Existem três principais abordagens utilizadas para otimização de índices:- Offline

- Online

- Adaptativa

> Essas estratégias representam a evolução da otimização de índices


Otimização o f f l i n e

> Foi a primeira estratégia a ser desenvolvida e utilizada:- SQL Server: Chaudhuri e Narasayya (1997), Agrawal et al. (2004)

- Oracle: Dageville et al. (2004)

- DB2: Zilio et al. (2004)

- PostgreSQL: Alagiannis et al. (2010)

> Realiza a análise das consultas e do banco de dados de forma isolada, apenas sugerindo melhorias- Banco de dados otimizado para a carga de trabalho analisada

> Necessita interação de um DBA durante o processo


Otimização o n l i n e

> Evolução da estratégia offline- PostgreSQL: Schnaitter et al. (2006)

- SQL Server: Bruno e Chaudhuri (2007)

> Avalia o custo das consultas durante a execução normal do banco de dados

> Periodicamente o SGBD cria ou exclui os índices automaticamente- Banco de dados otimizado para as últimas consultas

> Não necessita interação do DBA após configuração inicial


Otimização adaptativa

> Evolução da estratégia online

> Utilizada principalmente em bancos de dados em memória- Idreos, Kersten e Manegold (2007)

- Graefe e Kuno (2010) - proposta de implementação para bancos de dados relacionais

> A cada consulta o SGBD avalia possíveis ajustes nos índices- Realiza modificações parciais e incrementais nos índices

- Banco de dados otimizado para a carga de trabalho atual

> Não necessita interação do DBA após configuração inicial


Simulação de índices

> Alguns SGBDs permitem simular a existência de índices para realizar testes- SQL Server, Oracle, DB2, PostgreSQL

> O componente de simulação de índices é denominado "What-if"

> Nessa simulação, os índices não são materializados- Os dados não são indexados

- Apenas são calculadas as estatísticas do índice (seletividade, cardinalidade, etc.)


Trabalhos relacionados


Alagiannis et al. (2010) - PostgreSQL

> Otimização offline

> Recomendação de índices e particionamento

> Desenvolvimento de um componente "What-if" para simular os índices

> Possibilita também uma utilização alternativa, parcialmente online e parcialmente offline- Consultas são avaliadas em tempo real (online)

- Nenhuma modificação é realizada no banco de dados (offline)


Agrawal et al. (2004) - SQL Server


> Recomendação de índices, partições e views materializadas

> Utiliza componente "What-if" desenvolvido por Chaudhuri e Narasayya (1997)

> Acesso ao otimizador de consultas do SGBD para calcular estimativa de custo

> Como resultado, obteve recomendações superiores às obtidas manualmente (com base no custo total)


Zilio et al. (2004) - DB2


> Recomendação de índices, partições, views materializadas e agrupamento multidimensional

> Utilizado componente "What-if" já existente no DB2

> Recomendação iterativa ou integrada- Iterativa: recomenda cada funcionalidade separadamente

- Integrada: avalia dependências entre funcionalidades

> Obteve redução entre 77% e 93% do tempo de execução


Solução desenvolvida

MIST:

MySQL Index Suggestion Tool


Proposta inicial

> Todos os trabalhos relacionados utilizam simulação de índices para testar as recomendações

> Proposta de desenvolvimento de uma solução semelhante para MySQL, para ser utilizada neste trabalho

> Extensa análise do código-fonte do MySQL- Modificações demandariam muito tempo para serem

implementadas

> Solução alternativa utilizada neste trabalho foi a criação dos índices materializados



> Otimização offline- Processa um conjunto de consultas SQL e indica quais são os

melhores índices

- Utiliza um banco de dados isolado para realizar os testes

- Não modifica diretamente nenhuma estrutura do banco de dados

- O resultado deve ser avaliado e aplicado manualmente por um DBA




Fonte: O autor


> Entrada da ferramenta:- Arquivos XML: mais fácil de interpretar do que SQL

- Arquivo XML com estrutura das tabelas existentes- MSDF: MIST Schema Definition File

- Colunas, chaves primárias e estrangeiras, estatísticas sobre dados

- Arquivo XML com histórico de consultas executadas- MQLF: MIST Query Log File

- Tabelas consultadas, condições de WHERE e JOIN

> Saída da ferramenta:- Conjunto de índices otimizado para as consultas analisadas


Arquivo MSDF

MIST

Schema

Definition

File


Arquivo MQLF

MIST

Query

Log

File


Fluxo principal


> Visão geral do processo

executado pela ferramenta

desenvolvida

Fonte: O autor

Fluxo principal


> Detalhamento da etapa c

Fonte: O autor


Fonte: O autor

Geração de índicescandidatos

> Visão detalhada

da etapa c do

fluxo principal

Geração de índices candidatos

> Ordem de inclusão das colunas no índice:1. colunas utilizadas em comparação de igualdade com valores

constantes (parâmetros de comparação informados no SQL)

2. colunas utilizadas em comparação de igualdade com outras colunas no WHERE ou no JOIN

3. colunas utilizadas em condições por intervalo de valores

4. colunas utilizadas em comparação com uma lista de valores constantes (por exemplo, utilizando a construção IN do SQL)

5. colunas utilizadas com o operador LIKE



> Colunas desconsideradas:- Em consultas com GROUP BY e ORDER BY, as colunas da

ordenação não são consideradas para sugerir índices

- Índices candidatos que correspondem a um prefixo da chave primária da tabela são desconsiderados. Ex.:

- Chave primária: (col_a, col_b)

- Índices (col_a, col_b) e (col_a) são desconsiderados

- Colunas dos tipos BLOB e TEXT são ignoradas, pois essas colunas não podem ser inteiramente indexadas (deve ser informado um prefixo para ser indexado)



SELECT categoria.descricao AS categoria,

SUM(parcela.valor) AS total

FROM parcela

LEFT JOIN categoria

ON parcela.empresa_id = categoria.empresa_id

AND parcela.categoria_id = categoria.categoria_id

WHERE parcela.empresa_id = '10'

AND parcela.lancamento_id IS NULL

AND parcela.data_pagamento BETWEEN '2015-01-01' AND '2016-04-18'

AND parcela.removido = 0

AND parcela.recorrencia = 0

GROUP BY categoria.categoria_id

ORDER BY categoria.descricao;





FROM parcela

LEFT JOIN categoria











Etapa (a): índices para ORDER BY

> categoria.descricao é do tipo

TEXT, não cria índice




FROM parcela

LEFT JOIN categoria











Etapa (b): índices para GROUP BY

> gera prefixo de índice para

categoria.categoria_id




FROM parcela

LEFT JOIN categoria











Etapa (c): índices para WHERE

> gerar índices para a tabela parcela

com as condições encontradas




FROM parcela

LEFT JOIN categoria











Gerando índices para tabela parcela

1. campos com condição de pesquisa constante




FROM parcela

LEFT JOIN categoria











Gerando índices para tabela parcela

2. campos com condição de pesquisa por intervalo


> Resultado da etapa (c):

> Índice para ORDER BY- nenhum

> Índice para GROUP BY- categoria(categoria_id)

> Índices para WHERE- parcela(empresa_id, lancamento_id, removido, recorrencia,

data_pagamento)



> Resultado da etapa (c):

> Índice para ORDER BY- nenhum

> Índice para GROUP BY- categoria(categoria_id)

> Índices para WHERE- parcela(empresa_id, lancamento_id, removido, recorrencia,

data_pagamento)


Etapa (d): combinação dos índices

> tabelas categoria e parcela são diferentes,

não gera combinações

> em outros casos, adiciona prefixo dos

índices de ORDER BY e GROUP BY no início

dos índices WHERE para a mesma tabela


> Exemplo da combinação de índices:- Índice para ORDER BY: tabela(campo_a, campo_b)

- Índice para WHERE: tabela(campo_c, campo_d)

> Índices gerados:- tabela(campo_a, campo_b, campo_c, campo_d)

- tabela(campo_a, campo_c, campo_d)

- tabela(campo_c, campo_d)



> Redução dos índices- Índices menores e menos seletivos

> Índice original:- parcela(empresa_id, lancamento_id, removido, recorrencia,

data_pagamento)

> Índices reduzidos:- parcela(empresa_id, lancamento_id, removido, recorrencia)

- parcela(empresa_id, lancamento_id, removido)

- parcela(empresa_id, lancamento_id)

- parcela(empresa_id)


Fluxo principal


> Detalhamento das etapas d e e

Fonte: O autor

Avaliação de custo dos índices


Explain JSON


> Saída do EXPLAIN no formato JSON

> Disponível a partir do MySQL 5.6

> Ainda não possui um formato padronizado

EXPLAIN FORMAT=JSON SELECT ...

Fluxo principal


> Detalhamento da etapa f

Fonte: O autor


Fonte: O autor

Escolha dasolução final

> Visão detalhada

da etapa f do

fluxo principal

Escolha da solução final

> Exemplo:



> Consulta #1 + tabela1


Demonstração da ferramenta




Fonte: O autor

Resultados

> Testes executados com banco de dados de sistema real

> Índices recomendados apresentaram uma redução de 95,8% do custo total em relação à execução sem nenhum índice- Custo total = soma do custo de todas as consultas

- De 1.040.877,3 para 44.166,68


Resultados

> Testes executados com banco de dados de sistema real

> Índices recomendados apresentaram uma redução de 95,8% do custo total em relação à execução sem nenhum índice- Custo total = soma do custo de todas as consultas

- De 1.040.877,3 para 44.166,68

> Essa comparação não representa uma otimização real- Um BD sem nenhum índice raramente é utilizado em aplicações

reais no mercado


Resultados

> Comparação deve ser feita com um conjunto de índices previamente selecionado- Índices que já existem no banco de dados analisado

- Índices escolhidos manualmente por um DBA

> Essa comparação não é feita automaticamente pelo MIST- Foi realizada manualmente para validar a solução


Resultados

> Comparação deve ser feita com um conjunto de índices previamente selecionado- Índices que já existem no banco de dados analisado

- Índices escolhidos manualmente por um DBA

> Essa comparação não é feita automaticamente pelo MIST- Foi realizada manualmente para validar a solução

> Todos os índices recomendados pelo MIST já são utilizados no banco de dados analisado


Conclusão

> Não é possível afirmar que a solução encontrada pelo MIST é a ideal (menor custo possível)- Pode existir um conjunto de índices melhor ou não

> É possível afirmar que a solução encontrada é válida- Foram recomendados os mesmos índices que um DBA

selecionou previamente após uma extensa análise manual

> MIST pode ser utilizado como ferramenta auxiliar no trabalho do DBA- Reduz o trabalho manual de verificação dos índices


Trabalhos futuros

> Entrada de dados automática- Muito trabalho para gerar arquivos de entrada

- Ferramenta para geração dos arquivos XML (MSDF e MQLF)

- Consulta do modelo diretamente no banco de dados analisado

- Análise das consultas SQL diretamente

> Suporte a consultas mais complexas- Ex.: subconsultas, UNION

- Integração com parser do MySQL


Trabalhos futuros

> Suporte a instruções INSERT, UPDATE e DELETE- Deve considerar custos de atualização dos índices

> Parametrizar seleção de índices- Ex.: limites de armazenamento, número de atributos indexados

> Otimizar geração de índices candidatos- Heurísticas para gerar as combinações mais prováveis

- Menos combinações para testar = execução mais rápida

> Implementação de componente "What-if" para MySQL


Referências

> AGRAWAL, S. et al. Database tuning advisor for Microsoft SQL Server 2005. In: VLDB. Very Large Data Bases Endowment Inc., 2004.

> ALAGIANNIS, I. et al. An automated, yet interactive and portable DB designer. In: Proceedings of the 2010 ACM SIGMOD International Conference on Management of Data. New York, NY, USA: ACM, 2010. (SIGMOD ’10), p. 1183–1186.

> BELL, C. Expert MySQL. 2nd. ed. Berkely, CA, USA: Apress, 2012.

> BRUNO, N.; CHAUDHURI, S. An online approach to physical design tuning. In: 2007 IEEE 23rd International Conference on Data Engineering. IEEE, 2007. p. 826–835. ISSN 1063-6382.

> CHAUDHURI, S.; NARASAYYA, V. R. An efficient cost-driven index selection tool for Microsoft SQL Server. In: Proceedings of the 23rd International Conference on Very Large Data Bases. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 1997. (VLDB ’97), p. 146–155. ISBN 1-55860-470-7.


Referências

> DAGEVILLE, B. et al. Automatic SQL tuning in Oracle 10G. In: Proceedings of the Thirtieth International Conference on Very Large Data Bases - Volume 30. VLDB Endowment, 2004. (VLDB ’04), p. 1098–1109. ISBN 0-12-088469-0.

> GRAEFE, G.; KUNO, H. Self-selecting, self-tuning, incrementally optimized indexes. In: Proceedings of the 13th International Conference on Extending Database Technology. New York, NY, USA: ACM, 2010. (EDBT ’10), p. 371–381. ISBN 978-1-60558-945-9.

> IDREOS, S.; KERSTEN, M. L.; MANEGOLD, S. Database cracking. In: Proceedings of the 3rd International Conference on Innovative Data Systems Research (CIDR). Asilomar, California: CIDR, 2007. p. 68–78.

> LIGHTSTONE, S. S.; TEOREY, T. J.; NADEAU, T. Physical Database Design: The Database Professional’s Guide to Exploiting Indexes, Views, Storage, and More. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2007. ISBN 978-0-12-369389-1.


Referências

> PETRAKI, E.; IDREOS, S.; MANEGOLD, S. Holistic indexing in main-memory column-stores. In: Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data. New York, NY, USA: ACM, 2015. (SIGMOD ’15), p. 1153–1166.

> SCHNAITTER, K. et al. COLT: Continuous on-line tuning. In: Proceedings of the 2006 ACM SIGMOD International Conference on Management of Data. New York, NY, USA: ACM, 2006. (SIGMOD ’06), p. 793–795. ISBN 1-59593-434-0.

> ZILIO, D. C. et al. DB2 design advisor: Integrated automatic physical database design. In: Proceedings of the Thirtieth International Conference on Very Large Data Bases - Volume 30. VLDB Endowment, 2004. (VLDB ’04), p. 1087–1097. ISBN 0-12-088469-0.


Obrigado!

github.com/eduardoweiland/mist


ambiente de recomendação de índices para bancos de dados mysql

Software