Partition Table (Cenários/Benefícios) – Parte#2

Sharing is caring!

Fala galera, uma duvida frequente quando falamos em particionar uma tabela, é: Porque Particionar?!

Pensamos em particionamento de tabelas quando ela possui muitos registros e precisamos melhorar escalabilidade, performance e gerenciamento. Normalmente desenhamos as tabelas para armazenar informações de uma entidade específica, como Funcionarios, Vendas ou Produtos. Não é porque desenhamos e entendemos este modelo e dados, que otimizamos a tabela para receber grande volume… Já encontrei por ai, e não foi só uma vez, tabelas com quantidade de dados significativa e que não tinha nenhum tipo de índice. Acreditem, é triste mas é verdade!

Quando falamos de bancos de dados realmente grandes, nos referimos à VLDB (Very Large Database). Não é regra que um VLDB possua tabelas que precisam ser particionadas. Para particionar uma tabela um dos pontos mais importante a se levar em consideração é o tempo gasto para dar manutenção nesta tabela, e não somente a quantidade de registros. Imaginem o caso de uma tabela de Produtos de um e-Commerce que fica 2h/dia lenta porque está reorganizando/reconstruindo o índice, ou fica travada quando estão rodando algum relatório… Esse tipo de tabela pode ser particionada para melhorar o tempo de resposta das consultas e garantir que o e-Commerce continue fazendo suas vendas online.

Pensando em relatórios, isso pode causar uma lentidão grande no seu RDBMS (Relational Database Management System) quando tem um ROLAP (Relational On Line Analysis Processing) realizando agregações. Se uma tabela com 1 milhão de registros precisa agregar as vendas por mês, o processamento irá trabalhar com todas as linhas da tabela e fará o somatório. Imaginando este mesmo cenário em um ambiente particionado, cada partição faz suas agregações e no final do processamento, você terá uma resposta mais rápida e seu ambiente continuou respondendo com rapidez.

Um outro tipo de particionamento de tabelas pode ser feito para separar dados “quentes” e histórico. Os dados quentes são os dados que você trabalha atualmente, por exemplo, os dados do trimestre atual e os dados de histórico são os dados dos trimestres passados. Se você separar os dados da sua tabela a cada 3 meses, você pode deixar os dados atuais em discos mais nobres do seu storage (SSD) e os dados de histórico em outros discos menos nobres (SAS). Imagine a necessidade de consultar as vendas do ultimo ano, com a tabela particionada, você faria isso sem ter nenhuma concorrencia com as transações que estão acontecendo atualmente na tabela.

Sobre Diego Nogare 306 Artigos
Diego Nogare é CDO - Chief Data Officer - na Lambda3. Também é professor em programas de pós graduação no Mackenzie e na FIAP, em São Paulo. Foi nomeado como Microsoft MVP por 11 anos seguidos, e hoje faz parte do programa Microsoft Regional Director.

Seja o primeiro a comentar

Faça um comentário