ou “Zen e a arte do tuning em banco de dados”
Nada mais fácil do que reclamar do desempenho do banco de dados. Algumas aplicações que se comportavam bem por anos começam a se tornar lentas sem aviso prévio. Aplicações que tinham um excelente desempenho num banco de dados ficam exorbitantemente lento ao adotar outro fornecedor. É comum alguns desacreditarem completamente um fornecedor por não conseguir o desempenho esperado. Vejo pessoas pedindo ajuda, ficando perdidos no meio do caminho, desistindo e colocando a culpa no banco de dados. O fato é que muita gente acha que sabe como fazer ajustes de desempenho (também conhecido como tuning) em bancos de dados, mas poucos realmente o fazem. Eu aqui como aprendiz de feiticeiro resolvi deixar algumas dicas para quem pretende se enveredar nesta mistura de arte, ciência e bruxaria.
1 – Entre no espírito do tuning
A primeira lição para os os jovens padawans do tuning é ter paciência, humildade e persistência. Você não desvendará tudo de uma hora para outra. Os seus segredos serão revelados aos poucos. Mesmo que você disponha da melhor bibliografia sobre o assunto, você só aprenderá de fato com o tempo. Seja humilde, ouça os desenvolvedores, os administradores de sistemas e redes, escute DBAs mais experientes e menos experientes também. Nunca cometa o erro de achar que você já domina bem o assunto. Sempre há mais para se aprender e o conhecimento pode vir das fontes menos esperadas. Seja persistente, não desista facilmente. Achar o ajuste ideal pode levar meses até mesmo para um DBA experiente. Você deve realmente se concentrar no assunto e se dispor a gastar muito tempo nele. Nunca espere ou prometa resultados rápidos. Alguns ajustes podem levar alguns minutos e terem resultados fantásticos enquanto outros podem levar meses para atingir uma melhoria de 10%. Lembre-se que em alguns casos, 10% pode significar a economia de milhões de dólares.
2 – Seja um aprendiz que realmente aprende
Se você tem a intenção de aprender, esteja disposto a estudar e experimentar. Estudar não significa ler alguns tutoriais e sair realizando baterias de testes. Estudar não significa pegar o Date, Tanenbaun ou qualquer outro clássico e achar que irá absorver tudo e depois estará craque no assunto. Tuning é um daqueles assuntos que exigem conhecimento genuíno que só pode ser obtido através da fusão entre teoria e prática. Portanto, estamos falando um processo de vários ciclos de ação, reflexão e revolução. Outra forma de encarar a mesma coisa seria dizer que não importa se você fez doutorado em banco de dados ou se você trabalha a 20 anos como DBA. Importam as oportunidades que você teve de dissecar casos reais e descobrir causas concretas dos problemas de performance.
3 – Concentre-se na Lei do 80/20 dos bancos de dados
Por mais que os desenvolvedores reclamem do servidor de banco de dados, em 80% dos casos o problema está na aplicação e em 20% no SGDB. Não que a aplicação seja ruim em si, mas ela pode não usar o SGDB de forma eficiente. Existem várias formas de se obter os mesmos dados de forma ineficiente. Pior, uma consulta que funcionava bem num SGDB pode ter uma performance catastrófica em outro SGDB. Infelizmente isto pode ocorrer também com migrações para outra versão do mesmo SGDB. Mesmo assim, a culpa ainda não é do SGDB. A aplicação que tem (infelizmente) de adaptar às especificidades de cada fornecedor e cada versão.
Na verdade, se formos levar a questão de forma mais ponderada, a lei não seria 80/20, seria 99,9/0,01 . Isto ocorre por um motivo simples, ajustes de SQL e modelagem podem resultar em ganhos de performance da ordem de 10, 100 ou até 1000 vezes. Enquanto isso, ajustes no SO e SGDB tem ganhos da ordem de até 10 vezes. Portanto, antes de mais nada aprenda a modelar bem e conheça as minúcias do SQL do seu SGDB. Depois aprenda a analisar com profundidade os planos de execução e reescreva consultas complexas a partir deste tipo de análise.
4 – Concentre-se na Lei do 80/20 da informática
20% dos parâmetros de configuração do seu SGDB são utilizados em 80% do tempo. Aprenda a manejar bem estes parâmetros antes de mais nada. A maioria dos outros parâmetros são utilizados em ocasiões específicas e não tem um impacto tão forte no desempenho. Normalmente o tuning do SGDB começa por estes parâmentros mais importantes, os demais só são utilizados se você conhece especificidades da sua aplicação que sugerem o seu uso, caso contrário são deixados em seus valores padrão.
5 – Conheça o perfil das suas aplicações
A forma como a sua aplicação utiliza o seu SGDB é de suma importante para o DBA. Existem alguns padrões que lhe indicam caminhos já trilhados por outros. Sendo assim identificar o tipo de carga que a aplicação projeta sobre o banco de dados é muito importante. Aqui alguns tipos clássicos:
- OLTP ou On Line Trasactional Processing consiste na maior parte da carga das aplicações corporativas atuais. É caracterizado por um grande volume de pequenas transações conconrretes e alto volume de gravações. As cargas OLTP são as que tem o desempenho de disco mais crítico.
- BI ou Business Inteligence consistem num universo paralelo com diversas tecnologias como Data Mining, OLAP, Data Warehouse, Data Mart, Balanced Scored Card, etc. A questão é que quando falamos em BI, o banco de dados sempre acaba de um jeito ou de outro, tendo que suportar consultas enormes, com grande quantidade de dados e cálculos complexos. As cargas de BI exigem muita velocidade em leitura de disco, memória para ordenações e uso intenso do processador.
- Sites Web Dinâmicos: os sites dinâmicos são aqueles que armazenam o seu conteúdo num banco de dados. Desta forma um único acesso numa página web pode representar uma dúzia de pequenas leituras no banco de dados. As cargas de sites web são caracterizadas por um enorme número de conexões simultâneas realizando pequenas leituras.
- Operações em lote ou bath são cargas de trabalho intensas no banco de dados que podem durar várias horas para se completar e tem um grande impacto na performance. São comuns tanto em aplicações OLTP (cálculo de uma folha de pagamento, fechamento de ano fiscal, etc), como em BI (carga de grandes tabelas vindas de fontes externas). As cargas em lote sempre são alvos de estudos cuidadosos tem o potencial de crescer rapidamente em tempo de execução até inviabilizar os negócios da empresa.
É claro que uma única aplicação pode ter todas estas características ao mesmo tempo. É óbvio também que tem-se o hábito de abrigar várias aplicações no mesmo banco de dados, tornando tudo muito mais divertido…
6 – Monitore hoje, monitore sempre
Estar sempre atento a fatos notáveis no seu banco de dados são atitudes de valor inestimável para quem se preocupa com desempenho. Quem participa da equipe de desenvolvimento tem sempre a oportunidade de ser mais proativo e detectar possíveis problemas antes deles ocorrerem. Mas quem cuida de um banco de dados já em produção acaba sendo mais reativo. É claro que se você conhece bem o seu banco de dados, você sabe em que momentos o desempenho se torna crítico e quando não. Ter isso bem documentado é fundamental. Você pode saber que uma determinada rotina demora normalmente 2 horas para ser executada. Um dia esta rotina começa a demorar 3 ou 4 horas e você quer saber o porquê. Se você tiver documentado o perfil da carga quando tudo funcionava bem, você poderá comparar isso com a nova situação e detectar rapidamente o que realmente mudou. Se você não tiver isto documentado, será muito mais difícil de saber porque o tempo de execução aumentou.
7 – Crie suas próprias métricas e guarde-as com cuidado
É muito fácil coletar zilhões de estatísticas através do SO, SGDB ou até mesmo através dea aplicação. No entanto elas não tem muito valor se você não souber o que elas realmente significam e se não puder inferir uma estatística a um dado evento. De nada adianta saber o volume de leituras do seu disco num dado momento. No entanto saber quantas leituras em disco uma determinada transação provoca, é muito mais útil. Conheça as estatísticas disponíveis. Saiba como extraí-las através das ferramentas disponíveis, saiba como extrair estas informações do forma a torna-las relevantes e saiba o que elas realmente significam. Para isto é preciso criar pequenos programas que gerem cargas padronizadas no seu banco de dados.
Quanto mais próxima a carga gerada se assemelhar da sua aplicação, maior será o valor da sua métrica. Há programas sofisticados que são capazes de gerar cargas idênticas a de um ambiente de produção. Estes sistemas simulam cargas concorrentes e até mesmo criam robôs que utilizam as suas aplicações como se fossem usuários normais. Como é possível imaginar, testes que simulam uma carga de stress muito próxima da realidade tem um custo exorbitante. Há ferramentas intermediárias que geram cargas como o TPC-H ou TPC-C que podem ser muito interessantes para medir a capacidade do servidor para gargas genéricas.
8 – Saia do geral e vá para o específico
A maioria dos SGDBs permite que você realize uma configuração geral do banco de dados para o uso cotidiano e uma configuração específica para situações especiais. É comum você ter uma carga específica que possui um perfil diferenciado das demais. Este tipo de operação pode receber uma configuração específica. Você pode fazer com que todo o banco de dados assuma uma determinada configuração em um determinado momento, pode isolar isso para um usuário específico, para uma sessão específica ou até para uma transação específica. Apesar de ser trabalhoso, operações em lote, grandes relatórios e outras cargas mais pesadas se beneficiam muito deste tipo de atenção do DBA. Outra questão a se analisar sempre é a de evitar ao máximo a concorrência junto a este tipo de operação agendando sempre que possível para um horário de menor demanda.
9 – Tenha rigor científico
Apesar de todo o ar de mistério e magia em torno do tuning, a melhor forma de você saber o que está fazendo é utilizar do rigor científico. Uma das premissas da ciência é a de que você só tem um experimento válido se puder reproduzi-lo. Isto significa que não adianta rodar uma determinada carga num banco de dados em produção para ver como ele se comporta. No ambiente em produção, há outras pessoas agindo sobre ele de forma que você nunca conseguirá reproduzir exatamente as mesmas condições de teste. O tamanho das tabelas, índices, estatísticas tem de ser todos idênticos. Não preciso dizer que o servidor tem que ter o mesmo hardware, o mesmo software e exatamente a mesma configuração, para que o teste seja válido.
Outra coisa importante e que dá trabalho é a entediante tarefa de lidar com apenas uma variável por vez. É comum alguém querer alterar diversas coisas de uma vez só para depois testar o seu impacto sobre a performance. Você nunca vai saber qual das suas alterações ajudou e qual atrapalhou na performance final se fizer assim. Há vezes em que se chega numa configuração muito boa assim. No entanto você nunca tem o conhecimento claro sobre a influência de cada variável. Assim, o êxito pode se transformar em fracasso miserável quando aplicado em outra situação.
10 – Saiba gerar e analisar métricas manualmente
Os bancos de dados proprietários como o Oracle e o DB2 levam uma enorme vantagem (talvez a mais importante delas) sobre os livres no que diz respeito a ferramentas de monitoramento, gerenciamento e autotuning. São recursos poderosos que coletam métricas pré-determinadas, fazem análises e recomendações. Estas ferramentas são excelentes para resolver problemas comuns do dia-a-dia. Em empresas de pequeno e médio porte, estas ferramentas podem diminuir bastante a dependência do DBA para as tarefas mais cotidianas. Mas existem 2 problemas intrínsecos a este tipo de ajuda:
- Você aprende menos, uma vez que se acomoda com os resultados já enlatados pela sua ferramenta. O uso constante dos conselheiros (ou ‘advisors’), assistentes (ou ‘wizards’) e outras tecnologias no estilo nnf (next, next, finish) embrutecem muito o profissional de informática que deixa de entender completamente o que se passa de fato nos bastidores do SGDB. Veja, não é porque existe calculadora que as pessoas deixaram de aprender a fazer as contas na mão.
- A ferramenta pode errar. Nem sempre as recomendações da sua ferramenta serão as melhores. É impossível para quem desenvolve uma ferramenta deste tipo prever todas as situações possíveis. Além disso, a ferramenta nunca tem todas as informações relevantes ao negócio para poder fazer uma avaliação realmente segura. O ser humano ainda não pode ser substituído na sua capacidade de julgamento. Existem muitas ações que podem ser conveniente automatizadas, outras não. É por isso que a figura do “conselheiro” apenas aconselha, não decide. Um DBA experiente saberá quando o conselho é útil e quando não. Mas para isso você não pode ter se acomodado com o uso apenas da sua ferramenta automatizada.
11 – Torne-se um ninja em discos
10 entre 10 DBAs se preocupam com discos mais do que qualquer outro componente do hardware. Não se trata apenas de ter espaço de armazenamento para seus dados. Trata-se de desempenho. Os custos de uma boa solução de storage podem ser estratosféricos, com um custo de mais de R$ 30 mil num único disco. E não se surpreenda se ouvir falar em bancos de dados com milhares de discos. Então este é um universo que o DBA precisa dominar. SATA, SCSI, SAS, Fibre Channel, iSCSI, RAID e outras tecnologias devem ser bem conhecidas. Não basta saber quais tipos de RAID existem, é preciso testa-los, saber quais as diferenças quando implementados via software, por uma controladora local ou em um storage externo. Os sistemas de arquivo também são motivos de intermináveis discussões. Conhecer as suas diferenças, seus parâmetros e seu desempenho e estabilidade são obrigações do DBA. Um detalhe capcioso aqui é que ferramentas de benchmarks para discos e sistemas de arquivo costumam ser de pouca utilidade para o DBA. A carga que estas ferramentas criam nos discos dificilmente equivale a carga que um banco de dados cria na prática. Assim, a melhor forma de testa-los, continua sendo através de programas que gerem carga diretamente no banco de dados. Baseie as suas métricas de disco neste tipo de teste.
12 – Não troque segurança por desempenho
É muito fácil conseguir aumentar o desempenho de um banco de dados abrindo mão da segurança. Lembre-se que as pessoas utilizam bancos de dados mais pela sua confiabilidade e versatilidade do que pelo seu desempenho. Rotinas de backup, tolerância a falhas, garantia de ACID e outras questões não podem ser jogadas pela janela de uma hora para outra, a não ser que você se permita ser jogado pela janela quando as coisas derem errado. Existem parâmetros no SO, no SGDB e configurações de hardware que fazem o seu SGDB decolar, mas o tornam muito vulnerável ao menor problema que acontecer.
É fundamental conhecer bem os mecanismos de logs de transação e rollback. Ajustes nestes mecanismos tem grande impacto nas operações de gravação. Ao mesmo tempo, qualquer falha nesta área compromete definitivamente a integridade do banco de dados.
