MYSQL Conference 2010 – Problemas de Mundo Real

O MySQL Users Conference é palco ideal para juntar criadores e desenvolvedores do MySQL, DBA’s, desenvolvedores, curiosos, fuções e fuçetas… Enfim, toda “geek-aiada” unida numa grande explosão de conhecimento acerca do ecossistema MySQL. Aliás, como venho pregando há algum tempo, o slogan “MySQL é um ecossistema e não um produto” vai pegar… Aliás já pegou. Estou todos entoando este coro.

Pois bem, a conferência está sempre aberta para que empresas (usuários, parceiros ou desenvolvedores) apresentem estudos de caso, ou, problemas de mundo real. E isto é uma parte bem interessante. Pois, mostra aos demais, como outros usuários estão enfrentando e superando obstáculos. Além de compartilhar conhecimento, traz à comunidade outros pontos de vistas, e criatividade na solução de problemas. Afinal, é muito chato viver em um ambiente onde, somente, o fabricante tem o dom da palavra e dono da razão mais absoluta. Horizontalizar e compartilhar conhecimento é uma das características da comunidade do MySQL.

Ning (ning.com)

O Ning é uma rede social onde é possível concatenar pessoas com mesmos interesses. Através de ferramentas simples e práticas, pode-se criar um portal com blog, forum, controle de membros, fotos, vídeos e muito mais. Veja por exemplo, a rede de nossa amiga Sarah Sproehnle em EveryThingMySQL.ning.com, é um bom exemplo de como funciona o Ning e de quanta informação ele precisa gerenciar.

A palestra entitulada “Faster than Alter – Less Downtime” (“Mais rápido que ALTER – Menor Indisponibilidade”) sugere que é muito mais rápido, e aconselhável (de acordo com a experiência do Ning) fazer a exportação dos dados, e, após importá-los, novamente, através de LOAD DATA INFILE.

Chris Scheneide (Ning) continua, dizendo que precisa manipular tabelas MyISAM com tamanho superiores a 70GB. E que, neste cenário, o ALTER TABLE torna-se inviável. Solução adotada: exporta-se os dados, faz-se as alterações de schema necessárias, e, então LOAD DATA INFILE.

Comentário: É preciso lembrar que o MySQL/MariaDB processa a alteração gerando uma cópia temporária da tabela. Quer dizer, de uma forma ou de outra, um segundo arquivo irá existir. Mas o fato é que o MySQL/MariaDB faz isso de forma lenta e complicada. Criação de novos índices, alterações de colunas, é preferível, realmente, fazer através do método apresentado pelo Ning. É lógico que é uma medida extrema, que só é justificado para tabelas, digamos, maior que 2GB a 5GB. E não deixa de já funcionar como uma manutenção preventiva que dependendo do storage engine (innoDB, MyISAM, Maria, PBXT) irá eliminar desfragmentação de dados/páginas, organizar índices, eliminar linhas apagadas, etc. São dois coelhos numa única comandada, oops, digo, paulada.

Agende uma reunião aqui