Aqui estão os índices candidatos gerados para a consulta SQL apresentada:
1. Índice na coluna parcela.empresa_id
2. Índice na coluna parcela.data_pagamento
3. Índice composto nas colunas parcela.empresa_id e parcela.data_pagamento
4. Índice na coluna parcela.categoria_id
5. Índice composto nas colunas parcela.empresa_id, parcela.categoria_id e parcela.data_pagamento
O algoritmo gerou esses índices focando nas colunas usadas
Ambiente de recomendação de índices para bancos de dados MySQL
1. Ambiente de recomendação
de índices para bancos de
dados MySQL
Eduardo Weiland
Orientador Prof. Msc. Eduardo Kroth
Universidade de Santa Cruz do Sul
Curso de Ciência da Computação
2. 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
3. Motivação
3Universidade de Santa Cruz do Sul12 julho 2016
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
4. Motivação
4Universidade de Santa Cruz do Sul12 julho 2016
Um banco de dados relacional utiliza índices para acessar os
dados de maneira mais eficiente
Fonte: Lightstone (2007)
Servidor Índice Arquivos de dados
5. Motivação
12 julho 2016 Universidade de Santa Cruz do Sul 5
O SGBD tenta escolher o melhor índice possível
para executar cada consulta
6. Motivação
12 julho 2016 Universidade de Santa Cruz do Sul 6
O SGBD tenta escolher o melhor índice possível
para executar cada consulta
Mas só considera os índices que JÁ EXISTEM
no banco de dados
7. Motivação
12 julho 2016 Universidade de Santa Cruz do Sul 7
O SGBD tenta escolher o melhor índice possível
para executar cada consulta
Mas só considera os índices que JÁ EXISTEM
no banco de dados
Como encontrar o melhor índice se ele não existe?
8. 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.
8Universidade de Santa Cruz do Sul12 julho 2016
9. 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
12 julho 2016 Universidade de Santa Cruz do Sul 9
10. 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
12 julho 2016 Universidade de Santa Cruz do Sul 10
11. 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)
12 julho 2016 Universidade de Santa Cruz do Sul 11
13. 12 julho 2016 Universidade de Santa Cruz do Sul 13
Bancos de dados
> Modelo cliente-
servidor
> Modelo lógico X
modelo físico
> Instruções SQL
(workload)
Fonte: Bell (2012)
15. 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
12 julho 2016 Universidade de Santa Cruz do Sul 15
16. Otimização offline
> 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
12 julho 2016 Universidade de Santa Cruz do Sul 16
17. Otimização online
> 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
12 julho 2016 Universidade de Santa Cruz do Sul 17
18. 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
12 julho 2016 Universidade de Santa Cruz do Sul 18
19. 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.)
12 julho 2016 Universidade de Santa Cruz do Sul 19
21. 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)
12 julho 2016 Universidade de Santa Cruz do Sul 21
22. Agrawal et al. (2004) - SQL Server
> Otimização offline
> 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)
12 julho 2016 Universidade de Santa Cruz do Sul 22
23. Zilio et al. (2004) - DB2
> Otimização offline
> 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
12 julho 2016 Universidade de Santa Cruz do Sul 23
25. 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
12 julho 2016 Universidade de Santa Cruz do Sul 25
26. Solução desenvolvida
> 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
12 julho 2016 Universidade de Santa Cruz do Sul 26
28. Solução desenvolvida
> 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
12 julho 2016 Universidade de Santa Cruz do Sul 28
31. Fluxo principal
12 julho 2016 Universidade de Santa Cruz do Sul 31
> Visão geral do processo
executado pela ferramenta
desenvolvida
Fonte: O autor
32. Fluxo principal
12 julho 2016 Universidade de Santa Cruz do Sul 32
> Detalhamento da etapa c
Fonte: O autor
33. 12 julho 2016 Universidade de Santa Cruz do Sul 33
Fonte: O autor
Geração de índices
candidatos
> Visão detalhada
da etapa c do
fluxo principal
34. 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
12 julho 2016 Universidade de Santa Cruz do Sul 34
35. Geração de índices candidatos
> 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)
12 julho 2016 Universidade de Santa Cruz do Sul 35
36. Geração de índices candidatos
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;
12 julho 2016 Universidade de Santa Cruz do Sul 36
37. Geração de índices candidatos
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;
12 julho 2016 Universidade de Santa Cruz do Sul 37
Etapa (a): índices para ORDER BY
> categoria.descricao é do tipo
TEXT, não cria índice
38. Geração de índices candidatos
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;
12 julho 2016 Universidade de Santa Cruz do Sul 38
Etapa (b): índices para GROUP BY
> gera prefixo de índice para
categoria.categoria_id
39. Geração de índices candidatos
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;
12 julho 2016 Universidade de Santa Cruz do Sul 39
Etapa (c): índices para WHERE
> gerar índices para a tabela parcela
com as condições encontradas
40. Geração de índices candidatos
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;
12 julho 2016 Universidade de Santa Cruz do Sul 40
Gerando índices para tabela parcela
1. campos com condição de
pesquisa constante
41. Geração de índices candidatos
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;
12 julho 2016 Universidade de Santa Cruz do Sul 41
Gerando índices para tabela parcela
2. campos com condição de
pesquisa por intervalo
42. Geração de índices candidatos
> 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)
12 julho 2016 Universidade de Santa Cruz do Sul 42
43. Geração de índices candidatos
> 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)
12 julho 2016 Universidade de Santa Cruz do Sul 43
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
44. Geração de índices candidatos
> 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)
12 julho 2016 Universidade de Santa Cruz do Sul 44
45. Geração de índices candidatos
> 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)
12 julho 2016 Universidade de Santa Cruz do Sul 45
46. Fluxo principal
12 julho 2016 Universidade de Santa Cruz do Sul 46
> Detalhamento das etapas d e e
Fonte: O autor
47. Avaliação de custo dos índices
12 julho 2016 Universidade de Santa Cruz do Sul 47
48. Explain JSON
12 julho 2016 Universidade de Santa Cruz do Sul 48
> 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 ...
49. Fluxo principal
12 julho 2016 Universidade de Santa Cruz do Sul 49
> Detalhamento da etapa f
Fonte: O autor
50. 12 julho 2016 Universidade de Santa Cruz do Sul 50
Fonte: O autor
Escolha da
solução final
> Visão detalhada
da etapa f do
fluxo principal
51. Escolha da solução final
> Exemplo:
12 julho 2016 Universidade de Santa Cruz do Sul 51
52. Escolha da solução final
> Consulta #1 + tabela1
12 julho 2016 Universidade de Santa Cruz do Sul 52
53. Escolha da solução final
> Consulta #1 + tabela2
12 julho 2016 Universidade de Santa Cruz do Sul 53
54. Escolha da solução final
> Consulta #2 + tabela1
12 julho 2016 Universidade de Santa Cruz do Sul 54
55. Escolha da solução final
> Consulta #2 + tabela2
12 julho 2016 Universidade de Santa Cruz do Sul 55
64. 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
12 julho 2016 Universidade de Santa Cruz do Sul 64
65. 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
12 julho 2016 Universidade de Santa Cruz do Sul 65
66. 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
12 julho 2016 Universidade de Santa Cruz do Sul 66
67. 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
12 julho 2016 Universidade de Santa Cruz do Sul 67
68. 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
12 julho 2016 Universidade de Santa Cruz do Sul 68
69. 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
12 julho 2016 Universidade de Santa Cruz do Sul 69
70. 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
12 julho 2016 Universidade de Santa Cruz do Sul 70
71. 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.
71Universidade de Santa Cruz do Sul12 julho 2016
72. 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.
72Universidade de Santa Cruz do Sul12 julho 2016
73. 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.
73Universidade de Santa Cruz do Sul12 julho 2016