Optimizações

Ao fazer a análise a uma Base de Dados para resolver problemas de performance ou optimizar as queries que são realizadas, começamos, normalmente, por verificar quais as queries mais lentas, que levam mais tempo a executar, de modo a actuar nessas queries.

Ora, além do tempo de execução das queries, temos também que analizar a "big picture", isto é, a actividade geral do sistema e o número de vezes que cada uma dessas queries é executada num determindao período de tempo.

Vamos a um exemplo concreto:
- Um sistema que analisei tinha problemas de performance (tempo de resposta) na Base de Dados. Após obter uma lista das queries que estavam a demorar mais de 10 segundos a executar, verifiquei que havia algumas que demoravam mesmo mais de 60 segundos em tempo de execução.
- Ao verificar o número de vezes que cada query corria no período em análise,foi fácil verificar que era mais preocupante uma query que estava a demorar entre 10 e 20 segundos que as que demoravam mais tempo, e isto porque essa query era executada cerca de 30 vezes mais que a que demorava 60 segundos !!
- Após algumas mudanças no sistema, que dispensaram 99% das execuções dessa dita query, o número de queries que ultrapassaram os 10 segundos de execução caiu para menos de um quinto, no mesmo período da análise anterior !!

Conclusões:
- Muitas vezes ganha-se mais em actuar numa query relativamente "normal" que é executada muitas vezes que procurar optimizar logo uma queriy muito longa;
- Ao optimizar um sistema, neste caso uma Base de Dados, a solução pode estar "fora" da Base de Dados, ou seja, podemos actuar noutro ponto do sistema e obter ganhos de performance na Base de Dados;


Até breve !

Mais dicas sobre o tamanho

Boa noite,

O comentário de um "corajoso internauta" a um post anterior, leva-me a fazer mais um post relacionado com tamanhos :)

Tem isto a ver com o que se pode ganhar em termos de tamanho de uma BD ao aplicar algumas técnicas de optimização de dados.

Hoje estive a ver uma BD, real, que tem uma tabela com cerca de um milhão e meio de registos. Um dos campos é do tipo "bigint", ou seja ocupa 8 bytes de armazenamento e permite que sejam guardados números inteiros entre -2^63 a 2^63-1. Se não forem necessários valores tão grandes podemos transformar este campo para um tipo "int" (valores entre -2^31 e 2^31) ou até um "smallint" (valores entre -65000 e 65000 aprox.)

Nestas transformações ganham-se respectivamente 4 ou 6 bytes de cada registo. Como a tabela tem um milhão e meio de registos, diz-nos a matemática que se podem ganhar entre 6 a 9 MiB de espaço nesta coluna :)

Parece pouco, mas podemos ainda fazer a análise de outro modo: podemos medir a "largura" de uma tabela, ou seja, o tamanho de cada registo. Nesta tabela em particular vamos começar com uma largura de 356 bytes. Se cada página de armazenamento da BD tiver 8KiB, temos cerca de 8000 bytes para armazenar os dados (devido a headers e informação administrativa da BD). Desta quantidade, pode estar definida uma percentagem máxima de ocupação (vamos supor 80%), que nos dá uma capacidade efectiva de 6400 bytes. Dividindo 6400 por 356 podemos armazenar 17 registos completos numa página (os registos não podem estar divididos por duas páginas), ou seja, para 1500000 de registos, necessitamos de 88236 páginas, ou cerca de 689 MiB. Se reduzirmos 6 bytes a cada registo e fizermos novamente as contas passamos a ocupar 83334 páginas, ou cerca de 651 MiB, poupamos 38 MiB de espaço efectivo de armazenagem... e isto numa tabela de dimensão média... :)

Propagando estas alterações para outras colunas e outras tabelas dentro desta BD, podemos poupar dezenas ou centenas de MiB, conforme o grau que quisermos levar esta análise. Claro que estas mudanças têm o seu preço e poderão envolver também alterações na programação subjacente ao Sistema que faz uso destes dados.

E para já é tudo !

Até breve.