 | Nível: Introdutório Scott Hayes, President and CEO, DBI Software
30/Jun/2009 Uma olhada na otimização de banco de dados e no que todo o gerente deve saber para torná-la bem-sucedida
Seu banco de dados é, provavelmente, o último
lugar para o qual você olharia em busca de
economia nos custos de TI. Afinal de contas, o
que é mais importante para um banco de dados é
que ele sempre forneça as informações apropriadas
e na hora certa. No entanto, a beleza da otimização
do banco de dados é que, ao mesmo tempo, ela corta
custos e melhora o desempenho. A otimização dos
bancos de dados da sua organização reduz o consumo
desnecessário e o desperdício da CPU, gerando um
efeito em cadeia de benefícios: menor consumo da
CPU, menor custo da energia de alimentação de
hardware e refrigeração, maior consolidação e
virtualização do servidor, menores custos de
hardware, menores custos de licenciamento de
software e maior produtividade organizacional por
meio de tempos de repostas melhores, mais confiáveis e mais previsíveis.
No entanto, para tirar o máximo dos seus esforços
de otimização do banco de dados, há duas coisas
que você precisa saber. A primeira é: O design
físico do banco de dados é de importância crítica,
principalmente os índices. Os índices são importantes
para os bancos de dados, praticamente, pelos mesmos
motivos que os são para as pessoas: eles tornam
possível localizar coisas mais rapidamente, com menos esforços.
Imagine se você tem uma tigela de amoras no seu
refrigerador e deseja utilizá-las em uma receita.
Você pega o seu livro de culinária favorito para
localizar receitas que usam amoras, mas ele é muito
grande: 592 páginas. É possível consultar cada página
do livro e examinar as listas de ingredientes
procurando por amoras, mas essas consultas não são de
graça. Elas envolvem tempo, consomem energia e podem,
até mesmo, deixar os seus olhos doendo. É mais provável
que o seu livro de culinária tenha um bom índice no
final e que seja possível procurar por "amoras", localizar
as receitas e ir diretamente às páginas a fim de selecionar
a que se deseja.
Os bancos de dados funcionam do mesmo modo. Seu livro
de culinária de 592 páginas não resultaria em uma tabela
de banco de dados muito grande - ela seria, quase
certamente, pequena o suficiente para caber em um
pendrive USB de 32 MB. Mas, se você solicitasse a um
aplicativo culinário para procurar receitas com amoras
na lista de ingredientes, ele enviaria uma consulta ao
banco de dados e este, por sua vez, varreria as entradas
das receitas. A varredura teria de consultar 592
instruções da CPU ou mais, caso o livro culinário
ainda não estivesse na memória do banco de dados,
e isso levaria cinco segundos para ser executado.
Agora, e se houvesse um índice útil sobre INGREDIENTES?
A mesmo pesquisa poderia ser concluída usando apenas
seis instruções da CPU, o que envolveria uma fração
de segundo.
Os aplicativos do sistema da sua empresa,
provavelmente, não pesquisam amoras com muita
frequência, mas o mesmo princípio se aplica.
Praticamente, todo armazém de dados e banco
de dados corporativo possuem um grande número
de pequenas tabelas acessadas com frequência
que caberiam em unidades de jump USB. Pergunte
aos DBAs, quantas tabelas existem nos seus
bancos de dados menores que 64 MB - a resposta
poderá ser surpreendente. As tabelas de banco
de dados menores são importantes devido à
segunda coisa que você precisa saber: A máxima
otimização do desempenho é possível apenas quando
você leva em consideração todo o sistema.
Os DBAs usam um utilitário fornecido pelos
fornecedores de banco de dados, denominado
EXPLAIN, para examinar a estratégia de acesso
do banco de dados ao satisfazer as consultas.
O utilitário EXPLAIN informa o custo antecipado
do recurso de processamento de execução da
consulta. Os DBAs, normalmente, examinam os
custos antecipados antes de colocar as consultas
em produção. Se esse custo for alto, eles
ajustarão a instrução e o design físico do banco
de dados a fim de reduzir seu custo antecipado, muitas vezes, adicionando um índice.
Se o custo antecipado de uma consulta for
relativamente baixo - digamos, uma consulta
de cinco segundos sobre amoras - o DBA
dificilmente prestará atenção nela. O problema
é que o EXPLAIN fornece estimativa apenas para
uma única execução de determinada consulta. Se
o seu aplicativo acessar frequentemente tabelas
menores sem os índices apropriados, o banco de
dados as carregará na memória toda vez e fará
a varredura.
O desperdício de processamento como esse
prolifera em, pelo menos, 9 de cada 10 bancos
de dados de produção. Em um grande banco de
dados em que trabalhei recentemente, um
aplicativo financeiro OLTP, com vários
Terabytes, gastou 34% de todo o tempo da CPU
executando consultas em uma tabela com apenas
32 linhas. Em um grande varejista, a inclusão
de um índice ausente em uma tabela pequena,
de 2.000 linhas, em um armazém de dados de
8 TB reduziu o tempo de decorrido de uma
consulta de suporte de decisão crítica de
três horas para dois minutos. Em outro
varejista on-line, 97% do custo da CPU em
um sistema com oito CPUs foram atribuídos
a uma única consulta acessando uma tabela
relativamente pequena. Agora, vamos direto
ao âmago da questão - instruções esbanjadoras e de custo elevado como essas existem, praticamente, em todos os bancos de dados, mas elas ficam fora da visão comum porque acessam tabelas menores.
Banco de dados com recursos de autoajuste de
memória detectarão consultas dispendiosas e
tentarão preservar as tabelas menores na memória,
diminuindo os custos de E/S e reduzindo, um pouco,
o tempo de resposta. Mas essas consultas que
ainda estão executando em uma CPU custam 99 por
cento a mais do que deveriam custar. O autoajuste
da memória simplesmente reage às características
de desempenho observadas e faz o melhor que pode
para compensar as deficiências no design físico.
No atual clima econômico, a necessidade
imediata e o valor do ajuste e da otimização
dos custos de desempenho do banco de dados não
podem ser exagerados. A menos que a sua
organização esteja soltando dinheiro pelo ladrão
e não tenha nenhuma restrição quanto à energia
e meio-ambiente, já passou do tempo de aplicar
em seus bancos de dados o ajuste apropriado.
Ignorar essa convocação para ação não faz mais
sentido do que dirigir seu carro com pneus
murchos e um porta-malas cheio de pedras.
Pense: Se fosse possível cortar o número de
servidores de banco de dados pela metade, seus
custos com licença pela metade, seus custos com
energia pela metade e, simultaneamente, dobrar ou
triplicar o desempenho e aumentar a confiabilidade,
você faria? E em que você gostaria de investir para
obter essas economias e aprimoramentos?
Sobre o autor | | | Scott Hayes é presidente e CEO da DBI Software. Integrante dos programas IBM Data Champion e Gold Consultant, ele é orador frequente nas conferências IDUG, IBM, ISACA e ISSA; autor de livro publicado; e autor constante de um blog sobre o desempenho do DB2 para Linux, UNIX e Windows. |
Avalie esta página
| |
