quarta-feira, 28 de novembro de 2012

Prioridade zero: O banco de dados!


Vou agora começar a mostrar onde geralmente estão os principais gargalos nos sistemas desenvolvidos para web, e algumas técnicas para evitá-los.

A "prioridade número zero" em qualquer sistema que esteja apresentando lentidão e precise ser otimizado é atacar os gargalos no banco de dados.

Pode-se otimizar de tudo em um sistema: a rede, o número de servidores, o poder de processamento dos mesmos, aumentar a quantidade de memória, mas nada disso surtirá o efeito desejado sem uma prévia otimização do banco de dados.

Isso porque no final das contas, toda a cadeia de processos envolvidos dependem dele. Os pedidos dos usuários, em geral, culminam num acesso ao banco de dados.

Portanto, não compensa ficar enxugando a aplicação (por exemplo) para ganhar 10 ou 20 milissegundos na carga de uma página, se não tiver sido feito antes, um ajuste fino no banco de dados.

E, através de modificações triviais no banco de dados, pode-se diminuir segundos do tempo de resposta (em contrapartida aos milissegundos ganhos sob outra abordagem), o que representa um ganho muito mais expressivo na performance geral do sistema, impedindo o enfileiramento de requisições no servidor de aplicação.
 
Note que é assim que se melhora a performance de um sistema. Medindo-se o tempo gasto em cada pequena parte e a otimizando-a, pois cada pequeno processo desses será chamada o número de vezes que requisições forem feitas pela aplicação ao banco de dados. Então é algo que é exponencial.

Os pontos-chave a se observar no contexto do banco de dados são, portanto:

* Otimizar as queries

Tenha o hábito de medir o tempo que leva cada query do seu sistema, do início ao fim do processamento. No Oracle, por exemplo,  isso é feito com o comando "SET TIMING ON". Toda query executada após este comando terá seu tempo de processamento mostrado na tela, em milissegundos. Quanto menor o tempo gasto pela query, melhor. Diria que qualquer valor acima de 1 segundo é indesejável:

    set timing on;
 
    select dsc_serie from serie
    where ind_status = 'A';


    25 linhas selecionadas.
    real: 141 (milissegundos)



* Evitar usar a cláusula IN ou EXISTS nas queries

A cláusula IN em queries SQL são muito lentas. Dê prioridade aos joins.


* Utilizar materialized views para consultas que gerarão relatórios.

Muitos sistemas geram relatórios a partir das próprias tabelas que estão sofrendo inserções e atualizações de dados  pelos usuários do site. Isso cria uma situação de lentidão tanto para quem está requisitando o relatório quanto para quem está entrando ou atualizando dados. A solução é criar uma materialized view com um job associado, que a atualizará de tempos em tempos. Sugiro a pesquisa no Google pelo termo "ETL".

* Utilizar índices nas tabelas.

Os índices criam uma espécie de "mapa" para o banco de dados acessar as informações de forma muito, muito mais rápida. Mas, relembrando a citação de Lavoisier, em contrapartida, tornam a inserção de dados ligeiramente mais lenta, pois algum tempo é necessário para que a indexação seja realizada. No entanto, a relação custo x benefício é vantajosa.

* Restringir o número de linhas no retorno de uma query.

Quando o usuário estiver fazendo uma pesquisa digitando um nome em uma caixa de texto, por exemplo, que gera uma atualização instantânea do conteúdo da caixa (o famoso autocomplete), pode-se especificar na query o número máximo de linhas retornadas. Isso agiliza bastante a resposta. O usuário não perderá informações, pois quanto mais letras digita, mais precisa é a resposta.

* Trazer tabelas específicas inteiras para a memória real

Com a diminuição do preço da memória RAM, é muito comum termos servidores com grande oferta de memória disponível. Algumas empresas já estão utilizando esta técnica para agilizar as consultas a banco de dados - trazer TODO o conteúdo de certas tabelas para a memória real.


Há outras dezenas de técnicas de otimização possíveis no âmbito do banco de dados. Área em que  não sou especialista. Mas certamente, uma equipe de banco de dados saberá responder prontamente a qualquer pedido nesse sentido, fornecendo as melhores estratégias para diminuir o tempo de processamento das queries, que é a necessidade objetiva que tentei passar com este post.


Entretanto... Há uma técnica em especial que é uma daquelas coisas que costumamos dizer que "funciona como mágica", como diz a famosa música do Queen - "It´s a kind of magic!":
 
 
 O Cache de queries.
 
 
Será o tema do nosso próximo post. Imperdível!!!

Nenhum comentário:

Postar um comentário