Quando construimos uma aplicação que acessa ou manipula bancos de dados temos como responsabilidade verificar se as nossas escolhas foram adequadas.
Algumas vezes durante a codificação não sabemos exatamente como os dados serão usados, quais os filtros mais utilizados nas pesquisas, quantos usuários acessarão a base de dados simultaneamente. Além de termos as diferenças entre o ambiente de desenvolvimento e o ambiente de produção.
O que devemos fazer para termos a certeza de que as nossas queries e nosso modelo tem e continuarão a ter o desempenho adequado no ambiente produtivo?
Os testes são fundamentais!
Mauro Pichiliane escreveu um artigo fantástico no portal iMasters onde ele fala do “Mito do Melhor Desempenho em Banco de Dados”, atenção para o que ele escreve:
“Para saber justificar quantitativamente as melhorias de desempenho em um banco de dados é preciso realizar testes. E testes que sejam de acordo com o ambiente, pois é preciso levar em consideração uma série de fatores. Infelizmente, seguir receitas prontas e recomendações gerais não quantificadas ou baseadas em pouca teoria pode até indicar um caminho certo, mas tal prática torna imprevisível a medição de resultados sem testes. O que quero dizer aqui é que sem testes de desempenho, sejam eles genéricos ou específicos, é muito difícil quantificar efetivamente qual seria a melhoria da implementação de tal funcionalidade X ou Y ou Z. E isso tem um impacto muito grande em certos profissionais a ponto de informações jogadas serem propagadas sem nenhum questionamento. Vejam bem, é inadequado para um profissional dizer que tomou tal atitude ou desenvolveu de certa maneira por que disseram-lhe, sem comprovação com dados ou fundamentação teórica, que era melhor assim. E isso é uma realidade muito próxima quando se fala em melhoria de desempenho de banco de dados – especialmente entre programadores.”
Mas o que deve ser testado?
Testes para melhorar desempenho em bancos de dados são chamados de tuning. Este extenso e que tange principalmente aos DBAs. Neste artigo a intenção não é exatamente fazer um tuning, mas mostra-lhe como você pode fazer correções que ajudam a melhorar do desempenho da sua aplicação. Eu me arrisco a chamar de “mini tuning”!
Lembrando mais uma vez que não existe receita de bolo, nem fórmula mágica. Tudo deve ser testado, avaliado e só depois decidido.
Os itens que eu gostaria que você se atentasse são:
- Índices
- Conversões implícitas
- Uso Transações
- Tabelas em memória
- Views Materializadas
Índices
Pense no índice de um livro… Ele te ajuda a localizar uma determinada informação de forma mais rápida. Em uma tabela, ou coleção, ou família de colunas, ou grafo; o índice tem a mesma função, ele faz com que a busca pelos dados seja mais rápida. *
Os índices são muito recomendados para acelerar as consultas, desde que as tabelas não tenham atualizações constantes, porque neste caso os índices podem impactar negativamente o desempenho da aplicação. Sendo assim, durante os testes da aplicação verifique se existem índices em excesso, se existem índices em tabelas que sofrem muitas alterações, exclusões e inclusões de dados e se existem consultas que precisam de índices.
* Atenção ao fato de que índices existem em bancos de dados relacionais e NoSQL.
Conversões implícitas
As conversões implícitas são aquelas onde o banco de dados automaticamente converte os dados de um tipo de dados em outro. Por exemplo, quando um smallint é comparado com um int, neste caso o smallint é convertido implicitamente em int antes da comparação.
Conversões implícitas degradam o desempenho da aplicação e podem indicar erros de modelagem… Por isso fique atento!
Uso de Transações
Você leu o post sobre transações?
As transações são importantes para garantir as propriedades ACID em bancos de dados relacionais. Mas elas também podem ser muito custosas, porque consomem recursos e podem diminuir ao desempenho da sua aplicação. Não use transações para tudo! Análise a necessidade.
Atenção, por exemplo, ao nível de isolamento necessário, porque esta propriedade pode impedir que a tabela seja acessada enquanto ocorrem atualizações, que pode gerar erros ou causar lentidão na aplicação.
Tabelas em Memória
Existem dados que são frequentemente acessados pela aplicação. Ás vezes são configurações, tabelas de domínio, dados temporários. Enfim… São poucos dados, acessados frequentemente pela aplicação. Neste caso ou use bancos de dados key-value ou acesse o banco de dados uma única vez e mantenha os dados em memória, evite acessos desnecessários ao BD.
Views Materializadas
São objetos de bancos de dados que armazenam os resultados de uma consulta. Diferentes de uma view que é uma tabela lógica, as views materializadas “existem no banco de dados”. É como se o banco de dados criasse uma trigger interna, com o objetivo de manter a view materializada atualizada, sempre que ocorrem atualizações nos dados de colunas que fazem parte dela.
O uso da view materializada aumenta o desempenho nas consultas aos dados, mas piora o desempenho nas atualizações.
Se você utiliza este recurso faça uma avaliação criteriosa quando finalizar a codificação.
Conclusão
Finalizar a codificação é muito diferente de finalizar o aplicativo. Teste, avalie, verifique se usou os recursos certos.
Termine as suas aplicações como o profissional de sucesso que eu seu que você é!
Veja também
Veja os outros artigos desta série:
- 3 erros que os desenvolvedores iniciantes cometem e que impedem a criação de ótimas aplicações
- Aviso: Você já escolheu o tipo de banco de dados?
- Por que você vai criar o modelo de dados?
Próximos passos
Finalizamos a série de artigos sobre os erros que impedem os aplicativos de desenvolvedores iniciantes de ter sucesso.
Nenhum dos 3 assuntos estão finalizados, temos muito que aprender juntos!!!
Nas próximas semanas conheceremos um pouco mais do MongoDB. Um banco de dados orientado a documentos, muito usado ao redor do mundo.
Mas não se preocupe, que surgindo novidades, não terei problemas em criar uma “branch”.
Caso tenha algum assunto que você queira conversar aqui no blog, entre em contato comigo, envie a sua sugestão! Afinal de contas, o blog é nosso!!!
Para que você não precise procurar meus contatos são:
- @DaniMonteiroDBA (Twitter)
- DB4Beginners (Facebook)
- Danielle Monteiro
Referências
https://pt.stackoverflow.com/questions/138033/qual-a-diferença-entre-view-e-materialized-view
https://www.ibm.com/developerworks/br/java/library/j-ts6/index.html
https://gustavomaiaaguiar.wordpress.com/tag/fk/
Se você gostou, compartilhe este post! Se você tiver dúvidas, fale comigo.