Hoje, vi uma dúvida na lista do PostgreSQL-Br sobre como fazer um DELETE ficar mais rápido. Traduzi um artigo do Sr. Josh Berkus que trás algumas dicas de performance que podem ajudar muito. Além disso, você deve, é claro, dar uma olhada no plano de consulta do seu comando. Ver se os índices estão sendo utilizados corretamente, etc. No entanto, e se eu estiver com uma tabela realmente grande e precisar excluir uma porcentagem significativa de registros de uma tabela realmente grande (com pelo menos alguns milhões de de registros)? Um índice não resolverá o problema. Ocorre que a operação de DELETE é lenta quando utilizada para muitos registros por vários motivos:

• Precisa atualizar todos os índices da tabela;
• Precisa checar todos as chaves estrangeiras (FKs) e gatilhos apontadas para esta tabela;
• Precisa atualizar todo o mapeamento de espaço livre no disco, para permitir a alocação deste espaço novamente;
• Precisa atualizar as estatísticas da tabela.

Os mecanismos de alocação física em disco variam muito de SGDB para SGDB. O PostgreSQL utiliza o vacuum para reclamar os espaço vazio entre os dados, o Oracle utiliza uma complexa estrutura de extensões e cabeçalhos de arquivos para manter as informações sobre a alocação destas extensões. Seja como for, gerenciar os índices e o espaço em disco é um trabalho que custa caro para ser realizado.

Se você quer simplesmente zerar todos os registros de uma tabela, a solução é simples, basta um TRUNCATE. Você também pode utilizar tabelas temporárias para armazenar valores intermediários de cálculos longos e complexos. As tabelas temporárias podem durar uma sessão ou apenas uma transação. Isto elimina a necessidade de ter que excluir registros ou dar um TRUNCATE. Mas estes são casos bastante específicos.

O Fato é que as pessoas não costumam criar tabelas que se esvaziam completamente. Em rotinas de arquivamento isso é comum. Mas nem sempre podemos excluir TODOS os registros da tabela. Se estamos falando de bases com tabelas grandes (milhões de registros), a primeira solução que deve estar sempre em mente é particionar a tabela. O particionamento pode lhe permitir excluir apenas uma partição da tabela, deixando as demais intactas. Assim, o nosso amigo TRUNCATE pode ser utilizado para excluir uma parte dos registros rapidamente, mantendo os demais registros intactos.

É claro que particionar tabelas exige um campo que se possa ser utilizado para dividir a tabela em várias partições. Nem sempre o critério de particionamento vai corresponder ao critério de exclusão de registros. Você pode precisar excluir uma grande quantidade de registros que compõe uma fração de uma ou mais partições da tabela. Assim, temos que recorrer a outro expediente para contornar o problema da lentidão no DELETE. Uma opção utilizada em ambientes de grande porte é trocar o DELETE pelo INSERT. Ocorre que inserir registros é muito mais rápido que apaga-los. De maneira geral temos que:

TRUNCATE < INSERT < DELETE

Vejamos uma forma de resolver problema de excluir muitos registros utilizando o INSERT:

1. Crie uma tabela auxiliar com a mesma estrutura da tabela em que os dados serão excluídos. Não crie índices, chaves primarias (PKs), estrangeiras (FKs) ou qualquer outro tipo de rescrição neste momento. Apenas os campos e seus tipos de dados. Utilize um tablespace que comporte o volume de dados que serão inseridos no próximo passo. O espaço em disco extra necessário é uma desvantagem deste tipo de procedimento, mas quem disse que performance não tem preço?
2. Insira os registros que você NÃO quer apagar na tabela auxiliar. É aqui que o INSERT aparece na história. Você poderia utilizar um CREATE TABLE … AS SELECT … WHERE … para inserir apenas os registros que você não deseja excluir e ainda criar a tabela auxiliar numa tacada só. Em grande escala isto nem sempre é interessante. Apesar da tabela criada ser apropriada para a operação, realizar um INSERT em uma única tacada pode ser inadequado. Veja algumas observações no final do texto.
3. Agora que você já tem os dados que você pretende preservar em outro lugar, você não precisa mais de nenhuma informação na tabela original. Você pode se livrar de todos os dados da tabela original. Você poderia dar um TRUNCATE na tabela original e depois carregar os dados de volta para ela. Mas neste caso você precisaria dar um novo INSERT, o que poderia lhe custar muito caro. Além disso, precisaríamos excluir ou desabilitar todos os índices e restrições (FKs, PKs, CHECKs, gatilhos, etc) para que o INSERT ocorra de forma mais rápida. Na verdade qualquer operação de carga, seja INSERT ou UPDATE, deve desabilitar todos os índices e restrições antes da carga. Depois da carga feita, você pode reconstruí-los ou habilita-los, assim como é feito na carga de um backup lógico. Desta forma, o que vamos fazer aqui é excluir todas as dependências externas a tabela original, como gatilhos e FKs. Você pode fazer uma varredura no dicionário de dados para lhe auxiliar nesta tarefa de forma mais cuidadosa e dinâmica. Há um exemplo aqui que mostra como fazer isso no Oracle. Com um pouco de reengenharia você pode adaptar o exemplo para a sua situação.
4. Uma vez que todas as dependências para a tabela originas foram removidas, você pode enfim exclui-la com um simples DROP TABLE.
5. Agora é hora de você renomear a tabela auxiliar com um ALTER TABLE para o nome da tabela original, uma vez que ela vai substituí-la.
6. Com o nome correto, você pode recriar os índices, PKs, FKs, gatilhos, etc.

Deu trabalho? Quem disse que trabalhar com grandes bancos de dados seria fácil? Mesmo com todos estes passos, o processo será muito mais rápido do que realizar um simples DELETE. É claro que com um número pequeno de registros o custo de todas as operações de DDL podem superar o custo do DELETE. O limite de onde é vantajoso trocar um DELETE por todo este procedimento com INSERT deve variar para cada ambiente, mas quando você começa a trabalhar com alguns milhões de registros isto faz muito sentido. Um erro comum entre os desenvolvedores é não imaginar o sistema em produção depois de alguns anos… durante a implantação inicial o sistema se comporta com ótima velocidade. Depois que as tabelas alcançam um certo volume, os problemas de desempenho surgem e procedimentos como este mostram sua eficiência. Pense grande!

Um detalhe importante é que o INSERT também tem suas limitações. Você não deve realizar o INSERT de milhões de linhas numa única transação. Também não deve realizar um COMMIT por linha obrigando a gravação constante no log de transações. Agrupe o INSERT em transações alguns milhares registros. Um pouco de PL deve resolver seu problema. Outra questão, que fica para outro artigo, é que alguns SGDBs possuem outras formas de otimizar o INSERT como:

• Múltiplos registros por INSERT em INSERT … VALUES (…, …, …) , (…, …, …) , …
• Uso de procedimentos preparados como PREPARE … EXECUTE
• Uso do COPY ou outros comandos que substituem o INSERT em carga de dados.

Nesta sexta-feira chegaram meus livros de Oracle que encomendei no início de novembro. Achei que comprar pela Amazon foi um bom negócio. Comprei 3 livros sobre Oracle. O mais caro deles custa na Livraria Cultura R$249 e na Amazon custa U$ 63. Paguei ainda U$ 30 pelo frete dos 3 livros, mas existe uma opção de frete pela metade do preço que demora o dobro ou uma opção que custa o dobro e chega na metade do tempo. Pelas minhas contas, gastei a metade do que gastaria se encomendasse numa livraria, consegui um título que não encontro no Brasil e ainda recebi os livros em apenas 2 semanas. Na Livraria Cultura e na Tempo Real, a previsão é de 6 semanas.

Vale a pena agrupar mais de um ítem numa única compra. Comprando um único livro o custo do frete era de U$ 20 e com três livros o custo do frete foi para U$ 30 e não U$ 60. O único inconveniente é precisar de um cartão de crédito internacional para fazer a compra. Mas com o dólar em R$1,7 o custo fica realmente tentador. Note que o valor em Reais será calculado com o preço do dólar oficial na data da compra no site. Você não paga nenhum imposto ao importar um livro (para outro tipo de encomenda eu não sei). O livro chega direto na sua casa e o valor pago é aquele que está na sua fatura de cartão de crédito

Bom… agora tenho bastante material para me divertir até Janeiro!

Já está sendo divulgado aos quatro cantos do país. Grupos de usuários de Minas Gerais, Rio Grande do Sul, Paraná, Santa Catarina, Brasília, Rio de Janeiro… o número de inscritos bateu a casa dos 150 com 3 semanas para o evento. Quem quiser garantir sua vaga e de quebra garantir um preço mais em conta, sugiro que faça a sua inscrição aqui, até o dia 23/11. Depois o preço fica um pouco mais salgado. A novidade agora é que o site do evento também traz a tão esperada grade de palestras. Muitos colegas como o Fernando Ike, Euler Taveira, Diogo Biazus, Leonardo Cezar, Leandro Dutra, Ivo Nascimento e Kenia Milene estarão lá. O nosso amigo de São Francisco - CA, também estará para dar sua palestra e provavelmente tomar umas caipirinhas depois do evento. Algumas pessoas são novas para mim e será um prazer conhecê-las. Um detalhe bacana é que a grade não é composta 100% de homens, pois teremos a Monica Tissian como palestrane Eu também estarei com uma palestra lá… já estou preparando o material, que é estará disponível neste blog após o evento. Estarei falando sobre melhores práticas no uso do PostgreSQL, que já é um tema recorrente aqui neste blog.

Alguns palestrantes infelizmente ficaram fora. Tem muita gente aí com conhecimento muito maior que o meu que não poderá vir ou que não ficou sabendo da chamada de trabalhos na época. No entanto isto não me preocupa. Inicialmente sempre dá uma angústia para colocar o maior número de palestras possíveis no evento. Mas não precisamos nos desesperar, este será o primeiro de muitos eventos do PostgreSQL e teremos espaço para todos.

Estaremos também com um stand no saguão do evento que será um ponto de encontro para a turma da comunidade. Estaremos distribuindo material sobre o PostgreSQL e vendendo camisetas também. Acho que demos uma patinada na organização do evento no inicio do segundo semestre, mas acredito que já estejamos com tudo nos trilhos e o evento será um sucesso.

Bom, encontro vocês no PgCon Brasil, até mais!

Conisli 2007

Nesta sexta-feira, fui ao CONISLI 2007 substituir o Fernando Ike que enviou 4 palestras para o evento e teve 3 aprovadas. Assim ele me convidou para dar a palestra “PostgreSQL, O Elefante Mais Rápido que Leopardo“. Dei uma mexida nos slides dele fui para o CONISLI. O evento está em sua 5 edição e começou em 2003 em parceria com a SUSCESO-SP. Em 2005 rompeu com a SUSCESO-SP em cima da hora e teve muitos problemas com isso, tendo dificuldade em locar um espaço que comportasse um evento do porte do CONISLI com um orçamento mais apertado, o evento ocorreu no SESC Itaquera. Em 2006 a organização deu a volta por cima e conseguiu realizar o evento novamente no Anhembi. Em 2007 a equipe que organiza o CONISLI diminuiu, e a organização ficou um pouco comprometida. A região da UNICID onde o evento foi sediado, até que era bacana, mas o espaço interno do evento ficou desagregado. Expositores num espaço, salas com palestras 2 andares acima, laboratórios em outro prédio.

A sala onde dei a palestra estava meio vazia e o tema era relativamente avançado. Não sei se me saí muito bem. Tive a impressão que ou fui muito superficial ou quem ninguém estava entendendo nada. No mais encontrei alguns bons amigos como o pessoal da organização (Ariane Paola, Leonardo César, Rodolfo Avelino , Rafael, etc) e outras figurinhas como o Leonardo Melo, Rencka, Slot, Marcos Sinhoreli, etc. Muitas pessoas deixaram para ir só no final-de-semana. Acabei não encontrando-os pois só fui na sexta-feira, devido a outros compromissos.

Organizando eventos

É sempre bom reencontrar as pessoas. Mas eu fiquei um pouco preocupado com o rumo dos eventos este ano. O PSL-ABCD perdeu o fôlego este ano. Eu confesso que deixei o pessoal um pouco na mão. Parece que a nova geração não teve fôlego. O pessoal do Centro Público (leia-se Ernani) até tentou dar uma injeção de ânimo e marcou uma reunião para organizar um evento este ano. Mas parece que foram poucas pessoas e logo o assunto esfriou.

Estou ajudando na organização do PgConBrasil este ano, mas também confesso que não estou disponibilizando o mesmo tempo que outrora. O reflexo disso é que ainda estamos correndo atrás de alguns detalhes apesar de estar fazendo o evento junto a Tempo Real Eventos.

Uma coisa que notei semelhante no PSL-ABCD e no PostgreSQL é que sempre aparece gente dizendo: “se precisar de alguma coisa, estou aqui”, “precisam de ajuda?” ou “Como posso ajudar” e coisas do tipo. E mesmo assim, sempre são alguns poucos que acabam carregando o piano. Notem que o Piano do CONISLI é enorme… o que me faz pensar que os organizadores do CONISLI são verdadeiros heróis. Me parece que as pessoas estão muito acostumadas a trabalhar obedecendo a algum tipo de chefe ou se submeter a hierarquia. Poucos realmente tomam a iniciativa e fazem acontecer. Os eventos de comunidade dependem de pessoas dispostas a liderar , oraganizar e trabalhar. Um bom exemplo é o Faw, na comunidade Debian. Apesar dele não tomar cerveja (um desvio de caráter imperdoável!) ) sempre vejo ele organizando a participação do Debian nos eventos por aí. Ele não é um líder eleito ou aclamado, aliás, se tornou a DD a pouco tempo. Mas é de fato alguém que põe a mão na massa e faz as coisas acontecerem.

Tipos de Eventos de Software Livre

Ok, não é novidade para ninguém que são poucas pessoas que se dispõem a abrir mão das suas horas de lazer para se dedicar a algum tipo de comunidade ou organização de malucos (sempre me vem a imagem das pessoas me perguntando o que eu ganho com isso…). Mas eu fico imaginando se o perfil dos eventos não está mudando. Acho que há duas categorizações interessantes para nós observarmos:

• Evento comunitário X Evento corporativo

A questão dos eventos corporativos se devem ao sucesso de mercado do Software Livre. A Linux World e o Linux Park tem um perfil diferenciado. Ocorrem em locais mais caros, tem expositores maiores e um custo que praticamente exclui os estudantes, em favor dos gestores de TI. Acho que os eventos corporativos tendem a aparecer com maior frequência, mas não substituirão os eventos comunitários. Talvez algumas coisas como install fests tenham uma tendência de diminuir, pois além de ser uma fórmula desgastada, ficou cada dia mais fácil instalar uma distribuição Linux em um desktop.

Os eventos comunitários continuarão a existir onde a comunidade for organizada o suficiente para isso, e enquanto houverem pessoas querendo se reunir para tomar cerveja. O perfil do evento pode variar de acordo com a intenção da comunidade. Pode ser um GNU Beer combinado rapidamente em uma lista de discussões, pode ser um fórum com alto nível técnico para desenvolvedores, ou mesmo um evento para angariar novos usuários e divulgar mais a comunidade. Cada comunidade vive um momento específico e tem demandas e vontades específicas. Participar ativamente de uma lista de discussões (onde a maioria das comunidades se consubstanciam) de uma comunidade é como escolher seu estilo musical na adolescência (bom, na minha adolescência, isto fazia sentido, agora eu já não tenho certeza). Alguns grupos são muito ativos e estão sempre criando novas formas de se encontrarem ou de promover a comunidade. Outros, parecem grupos de amigos que gostam de falar sobre tecnologia. Há os grupos em que o número de usuários gera um alto tráfego destinado a suporte técnico. O perfil destes grupos dizem qual tipo de evento é possível de se realizar em uma determinada região.

• Evento genérico X Evento focado

Quando eu era pequeno, ocorriam todos os anos as “feiras de informática” no Anhembi. Era tudo coisa do outro mundo para mim que utilizava fitas cassetes para gravar os meus primeiros programas em basic. Depois veio a Fenasoft que passou a ocupara o Pavilhão da Bienal e depois o Anhembi. A Fenasoft rapidamente se popularizou e trazia uma tonelada de gente. Logo veio a Condex que tinha um foco mais corporativo, também no Anhembi. Stantds enormes com mais de um andar, superproduções com shows de luzes e som. Vocês lembram? Pois é… sumiram todos. Não apenas no Brasil como no mundo todo. Os mega eventos sumiram, diminuíram de tamanho ou passaram a ocorrer com menor freqüência. Parece que depois que a bolha .com estourou, deixou um rastro de destruição no caminho.

Por outro lado, os pequenos eventos continuam pipocando por aí. Eles tem algumas vantagens interessantes sobre os eventos genéricos pois são menores, mais fáceis de se organizar e podem aprofundar temas que teríam pouco público num evento genérico. Depois de assistir a alguns eventos grandes, você começa a se interessar por uma palestra ou outra. O restante da grade costuma se concentrar em palestras de pouco interesse técnico. É claro que ficar nos stands de comunidades conversando com o pessoal é uma das coisas mais divertidas nestes eventos,

No Brasil temos alguns eventos de Software Livre grandes como FISL, CONISLI e Latinoware e uma infinidade de eventos de pequeno e médio porte espalhados por aí. Acho que a comunidade que tem apresentado mais garra na organização de eventos tem sido o pessoal do FISL até agora. Eles tem uma equipe grande e realizam eventos grandiosos. Realmente é o maior evento de Software Livre do Brasil. No entanto, talvez não tenhamos espaço para muitos eventos de grande porte. Acho que a médio prazo os eventos com foco em um assunto mais específico vão acabar dominando o cenário.

4 Fun

No entanto, os eventos precisam sempre de gente com tempo e disposição para organizar. Os eventos realizados por comunidades precisam de gente com estas qualidades para sobreviver. Os estudantes costumam ser bons candidatos. Me parece que a renovação deste quadro de “militantes” do Software Livre precisa acontecer. Mesmo porquê, não é só de evento que o Software Livre vive. É preciso ter gente contribuindo de outras formas, com documentação, tradução e principalmente com código. Acredito que temos espaço para todo o tipo de contribuição. Acredito também que um projeto que deseja agregar a contribuição de novas pessoas deve se estruturar para isso. Esta estrutura pode dar mais trabalho do que muitas pessoas imaginam.

Existem muitas pessoas dispostas a colaborar, mas poucas tem o espírito desbravador de assumir a organização de um evento. Da mesma forma ainda temos poucas pessoas contribuindo com código nos projetos. Se temos um número de usuários cada vez maior de Softwares Livres, podemos estar nos equivocando em algum lugar, pois o número de desenvolvedores ativos parece não acompanhar este crescimento. De qualquer forma, contribuir deve ser algo prazeroso. Pode dar trabalho, mas deve haver uma bom grau de satisfação dos que participam, deve haver um crescimento pessoal e sobre tudo, deve haver diversão!