Experiências com banco de dados.

Meu amigo foi incumbido pelo professor de sua cadeira de Banco de Dados (ou algo que o valha) a entrevistar alguém que usasse MySQL profissionalmente, ou um DBA que usasse este banco. Ele me procurou, e acabei enviando um longo e-mail a ele, falando sobre o meu histórico com banco de dados e acerca da escolha pelo MySQL (e não outro produto concorrente).

Gostei do resultado, e por isso resolvi colocá-lo aqui no Blogue. Escrevi a altas horas da noite, o cérebro e os dedos já estavam no piloto automático, e não revisei o texto, enviei-o a meu amigo “as was” (acabo de inventar isso). E é assim mesmo que eu o publico aqui, apenas removendo as referências aos nomes de clientes por uma questão de sigilo profissional.

Fábio, falar sobre dia-a-dia é complicado, porque sou mais programador
que DBA, mas tu podes adaptar o texto como achares melhor.

Meu “background” com banco de dados começa no dBase II+ (versão do dBase II para CMP/80 que continha alguns melhoramentos com relação a cálculos de datas, e alguma outra coisinha que não lembro agora); depois fui para o dBase III, e em seguida conheci o Clipper. Já comecei a trabalhar com o Clipper 5, que incluía uma orientação a objetos meio rudimentar, mas com engenhosidade a gente fazia vetores e blocos de código (um tipo de dado muito interessante, que permitia armazenar numa variável um trecho de código compilado) virarem propriedades e métodos. Naquela época muito pouco se ouvia falar de bancos relacionais, tudo era arquivo DBF, que funcionava na base do SET FILTER e do INDEX ON para filtrar e classificar dados.

Quando a Internet começou a se popularizar no Brasil eu tinha muita cultura acumulada do MS-DOS e do Windows (acho que era o 3.11). Logo, meus primeiros CGIs foram escritos em Clipper, e serviam para exibir um relatório de alguma coisa para os clientes da empresa em que eu trabalhava.

Nessa época havia basicamente duas frentes de desenvolvedores: os renitentes que achavam que nunca deixaria de haver espaço para o Clipper, e os renovadores que reescreviam em VB ou Delphi os seus programas Clipper de antes. Aos poucos o Access começou a ganhar espaço, até porque era raro um PC que não tivesse uma cópia do MS-Office. A tendência natural, então, foi eu começar a usar mais Access para meus projetos, principalmente os menores, pois as hospedagens ofereciam suporte gratuito a ele (o MSDAC, o JET, e outras siglas da Microsoft sempre foram instaladas por padrão no IIS).

Então, nos projetos menores eu usava Access, e para os maiores precisava de um banco de dados que fosse robusto, tivesse bom desempenho, e funcionasse sob Windows. Já tinha ouvido falar muito de “um tal de” Interbase, que vinha junto com o Delphi, e resolvi experimentar. Era perfeito para as soluções da empresa, e por ODBC era fácil de utilizá-lo em páginas ASP. Porém, os hosts comerciais não instalavam Interbase (que depois virou nome comercial, sendo substituído pela iniciativa da comunidade do Open Source chamada Firebird), e era frustrante desenvolver numa plataforma e na hora de publicar ter de fazer adaptações para outra, com bem menos performance e confiabilidade.

Nessa altura dos fatos, não sei precisar bem o ano, MySQL e PostgreSQL já eram bancos de dados famosos, o primeiro por sua leveza e modesta necessidade de recursos de processamento, o segundo por seus recursos avançados comparáveis aos encontrados em produtos caríssimos como Sybase e Oracle. Claro, ambos Open Source, era só compilar e usar.

Analisando os recursos dos dois produtos, a impressão que se tinha era que o PostgreSQL era muito mais banco do que o MySQL: implementava recursos que só agora na versão 5 o MySQL oferece, como integridade referencial, atualizações em cascata, transações, triggers, etc. Porém, sofria de uma deficiência crônica (para o mercado em que eu estava inserido na época): só funcionava no Linux, não tinha port para Windows. Quer dizer, até tinha, para quem se aventurasse a fazer umas gambiarras usando Cygwin, e tivesse hardware de sobra. Isso fez com que aquelas mesmas empresas que ofereciam o Access como banco de dados em seus pacotes de hospedagem passassem a oferecer também MySQL, que por ODBC permitia que as páginas ASP contassem com muito mais performance e flexibilidade. Esse foi, aliás, o fator decisivo para que eu adotasse o MySQL como meu banco de dados favorito, em detrimento do PostgreSQL.

Outro fator que leva os usuários de MySQL a preferirem-no, a despeito de testes de benchmark, que considero piada (o que importa é a satisfação das necessidades “abaixo de pau”), é a facilidade de encontrar, principalmente para quem trabalha com web. Em qualquer lugar veem-se ofertas de hosts, principalmente em Linux, oferecendo MySQL pré-configurado (a famosa plataforma LAMP). Ainda mais em tempos de MySQL 5, que implementa tudo aquilo que antes só o PostgreSQL e outros bancos caros tinham.

Cabe falar sobre o que é ter performance “abaixo de pau”.

Um dos usos de bancos de dados que fiz recentemente foi no (nome suprimido). A necessidade era de permitir acesso facilitado a determinadas informações das operações realizadas no (nome do produto suprimido), via e-pack (um produto de comunicação de dados da Embratel). Diariamente o e-pack envia um arquivo com cerca dois milhões de linhas (exceto em finais de semana e vésperas de datas assinaladas, esse valor pode ser cinco vezes maior), contendo numa o início de uma operação, e na outra o seu final. Um pequeno script faz a análise destes dados, e combina as duas linhas num único registro, e insere-o no banco de dados.

Qualquer um com um pouco de experiência saberia que o Access não teria como segurar essa barra (talvez o MSDE, mas segundo sei ele tem limitações quanto ao número de registros que pode suportar). As alternativas seriam o Oracle, que tem um custo de operação caríssimo para uma operação que não é “nobre”, ou MySQL, ou PostgreSQL. Como a batalha para a instalação do PostgreSQL fora muito dura da outra vez, e não dispúnhamos de muito hardware (um PIII com 512MB de RAM, HD de 80GB 7200RPM), acabamos instalando o MySQL.

Na primeira tentativa a performance foi meio lenta, porque os índices não estavam corretamente definidos. Limpamos as tabelas, redefinimos os índices com mais cuidado, e agora temos um banco que cresce à razão de um milhão de linhas por dia, plenamente gerenciável no MySQL em hardware modesto. Só tive, na condição de DBA mesmo, que dar um jeitinho numa consulta que totalizava os valores diários, que demorava um tempo inaceitável (do ponto de vista do usuário) para rodar. Então criei uma tabela auxiliar para fazer cache destes resultados (já que os dados só entram, mas não são alterados), e o banco só parou de funcionar uma vez, para instalação de uma nova unidade de disco.

Hoje meu principal foco é otimizar um aplicativo que já teve muitos “padrastos”, lotado de tabelas redundantes. Parece que os analistas anteriores não entenderam o significado de “relacional”. O ciclo básico é: levantar necessidade do usuário; descrever o modelo; criar tabelas; implementar o protótipo e popular o banco; analisar resultados, com vistas a tornar o banco eficiente quanto à otimização de índices e refinamento de queries. Algumas medidas simples, como utilização de INNER JOIN sempre que possível, utilização de campos ENUM quando o conjunto de valores é previamente conhecido, e o extermínio total de SELECT * fazem muita diferença, mas na maior parte dos casos a otimização implica mexer em aspectos não tão óbvios assim.

Bom, brother, não sei mais o que escrever. Desculpa não ter te mandado antes, mas meu dia foi um pé no saco, e também demorei horas pra encerrar esse texto.

Me manda a versão final que quero publicar no blog, acho que vai dar um artigo interessante. 🙂 Mas vou esperar a versão final, para caso o professor veja meu texto não compare as diferenças.

Abração!

Como meu amigo disse que ia entregar o texto sem alterações para o professor, ei-lo publicado aqui na íntegra.