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

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

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ível
para executar cada consulta

Motivação
Mas só considera os índices que JÁ EXISTEM
no banco de dados

Motivação
Mas só considera os índices que JÁ EXISTEM
no 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 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

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

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

- 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 índices
candidatos
> 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
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:
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 da
soluçã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

Recomendados

Recomendados

Más contenido relacionado

Similar a Ambiente de recomendação de índices para bancos de dados MySQL

Similar a Ambiente de recomendação de índices para bancos de dados MySQL (20)

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