Como todo profissional de T.I. sabe, quanto mais dados para manipular mais lento fica a manipulação desses dados. É uma regra básica e até meio óbvia, mesmo para pessoas que não são profissionais da área, não é mesmo?

Uma das ferramentas que mais nos ajudam na manipulação de um grande volume de dados é o sistema gerenciador de bancos de dados, ou simplesmente “banco de dados”. Mas mesmo os bancos de dados mais poderosos sentem quando o volume de dados é muito grande. Não tem como não sentir a carga quando se manipula tabelas com centenas de milhões ou bilhões de linhas.

Eu precisei particionar as tabelas quando elas chegaram ao patamar de cerca de 30 milhões de linhas. A partir deste ponto a velocidade de acesso aos dados começou a mostrar que não era mais a mesma, a degradação da velocidade era sensível e algo precisava ser feito.

Primeiramente pensei em aumentar a máquina servidora de banco de dados. Como nosso ambiente estava na Nuvem, seria algo muito fácil de se fazer. Como a cada incremento de máquina, em geral, o servidor tem sua capacidade dobrada tanto em memória como em quantidade de processadores, bastaria um simples incremento de máquina e provavelmente estaríamos atendidos por mais algum tempo. Mas havia um outro fator a ser considerado, o custo. Dobrar a máquina significaria também dobrar o custo do servidor, o que na época não era algo fácil de defender junto à diretoria. Os diretores já estavam achando alto os custos dos servidores na Nuvem e queriam reduzir os gastos, imaginem eu dizer que ainda teria de aumentar mais.

De qualquer maneira fiz uns testes aumentando a máquina para ver como ficaria, mas os ganhos não foram tão grandes quanto o esperado. Havíamos dobrado quantidade de processadores e de memória RAM, mas a quantidade de linhas em cada tabela continuava a mesma e com isso o tempo de acesso ao disco continuava praticamente o mesmo. Ganhávamos apenas em cache (tínhamos mais memória) e em capacidade de atendimentos simultâneos (mais processadores), mas este último não era problema.

Então, o que fazer? Podíamos dividir as tabelas, criando várias outras, uma por mês por exemplo, mas aí teríamos de mudar todos os processos para gravar e ler os dados da tabela certa todas as vezes, além do que ficaria bem mais complicado quando alguém quisesse novos relatórios englobando vários meses. Eu poderia criar também tabelas separadas apenas para as consultas, mas não resolveria o problema da gravação e, em todo caso, seriam necessários processamentos adicionais para manter essas novas tabelas atualizadas. Até aí, alguns dirão, era só trabalho de escrever código. Sim, verdade, mas isso demoraria um tempo considerável e a velocidade de acesso estava piorando a cada dia. Lembro que incluíamos milhões de linhas por semana nas tabelas.

Assim, decidimos que seria melhor particionar as tabelas. Uma solução muito mais elegante, rápida, fácil e barata. Vamos ver como ficaram os particionamentos e quanto ganhamos com esta mudança? Então vejam o vídeo no Canal Overloaded do YouTube.