Fonte: IGTIBlog
À medida que um banco de dados cresce, um assunto inevitável é a melhora da performance de uma consulta SQL. Em muitos casos aquela consulta que funcionava muito bem para 1.000 registros, não possui mais o mesmo comportamento para 10.000 registros, pior ainda se a expectativa é que o banco possa ter 100.000 registros. Em alguns momentos ouvimos a frase: “Se estiver funcionando, está bom!”. Uma velha máxima de alguns profissionais de tecnologia, que não funciona mais.
Em várias circunstâncias do dia a dia, nenhum de nós fica satisfeito em ter que esperar, isso desde uma simples fila do banco, até um complexo engarrafamento de trânsito. Então imagine ter que esperar pelo retorno de uma consulta SQL? Em determinados contextos, poucos segundos fazem a diferença. Em contexto parecido, podemos citar as compras online, um dos fatos que influencia na decisão de compra do cliente, pode ser o tempo de resposta para ações realizadas no site, ou seja, se uma funcionalidade, como a pesquisa de produtos, for lenta, a empresa pode perder um cliente.
Uma ressalva: quando o assunto está relacionado com a performance ou otimização, há muitos processos envolvidos, como por exemplo, arquitetura do sistema operacional, hardware, SGBD e principalmente como o banco foi modelado. Contudo, é essencial que as consultas SQL fiquem bem estruturadas. As estratégias mencionadas nesse texto estão suscetíveis a todas essas variáveis, ou seja, determinada estratégia pode funcionar em um ambiente “A”, mas pode não funcionar perfeitamente em um ambiente “B”.
Vamos partir do princípio que você tomou todos os cuidados básicos para estruturar sua consulta, por exemplo, não utilizou “*” em seu SELECT, especificando apenas os campos necessários de retorno, verificou o código fonte em busca de possíveis erros de sintaxe e evitou cálculos em JOINS e WHERES. Lembre-se, estamos falando de segundos ou até menos, que somados à quantidade de execuções e ao tamanho dos dados, fazem toda a diferença! Por isso, não tenha preguiça! Você fará o código uma única vez para que ele seja executado quantas vezes? Então seja detalhista e tente melhorar sempre.
Na disciplina de Aplicações com Linguagem SQL, presentes nos cursos de MBA em Banco de Dados e MBA em Engenharia de Dados, são discutidos com vários profissionais de banco de dados, o que em suas experiências, já foi feito e o que de fato melhorou e otimizou uma consulta SQL. É válido destacar que no geral, a ideia é que o profissional realize uma primeira análise das consultas utilizadas, o que por mais simples que pareça, nem sempre acontece e por isso, muitas vezes as ações são corretivas e não preventivas.
É importante ter um bom monitoramento em ambiente de produção e saber quais consultas estão performando pior, para evitar que o problema chegue até o usuário final. Por fim, o cenário ideal seria garantir que a arquitetura de todos os ambientes seja a mesma, embora saibamos que nem sempre isso é possível em função de fatores internos e externos de uma empresa, para não dizer que faltou um planejamento adequado.
Dito isto, vamos falar sobre a criação de índices, principalmente se a quantidade de dados for grande, pois a criação de índices para bancos de dados pequenos influencia pouco na velocidade das consultas. Uma boa estratégia para criação de índices é analisar o plano de execução, disponível em vários bancos de dados. É importante fazer a análise do plano de execução em todos os ambientes: desenvolvimento, teste e produção, inclusive com o uso dos mesmos parâmetros problemáticos que obviamente apresentam um retorno ruim. Ao analisar o plano de execução, será possível determinar outras necessidades além da criação de índices e planejar estratégias específicas (procedures, funções ou view materializadas) para melhorar a performance.
Em discussão que tive com alguns profissionais de banco de dados, alguns defendem a Desnormalização de dados. Para entender melhor, vamos relembrar o que é a normalização de dados. Na prática é uma etapa importante do projeto de um banco de dados, sendo a realização de uma série de passos, que permitem um armazenamento consistente de dados e como consequência, reduzem a redundância e as chances dos dados se tornarem inconsistentes.
O lado que defende a desnormalização afirma que, se os problemas de performance são exclusividade de alguma extração de dados, como relatórios e exportações, por exemplo, para bases analíticas, a desnormalização juntamente com a replicação de dados é uma solução aceitável. Por outro lado, a desnormalização gera inconsistências e dados duplicados, e neste caso, fico ao lado dos profissionais que discordam da desnormalização. Em todos os casos, é interessante analisar o plano de execução e entender se no momento é vantajoso ou não, desnormalizar. Caso seja necessário, tenha total ciência que você administrará muito bem a desnormalização realizada.
Agora, se você gostou das dicas e deseja aprofundar seus conhecimentos, outro assunto importante no que diz respeito ao desempenho de uma consulta é o de Performance Tuning. O Tuning visa diretamente a otimização de consultas, existem várias dicas e ferramentas específicas de Tuning em cada banco de dados, você pode inclusive fazer cursos específicos sobre o assunto! Basicamente o Tuning é dividido em três partes:
- Entendimento do problema
- Elaboração de Diagnóstico
- Aplicar dicas e técnicas de otimização
Concorda com as dicas do texto? Tem alguma outra sugestão que utilizou em algum caso real e obteve sucesso? Compartilhe conosco!
0 comentários:
Postar um comentário