Artigos Banco de Dados Particionamento de tabelas no PostgreSQL

De que trata o artigo:

Este artigo trata da implementação do recurso de particionamento de tabelas em um banco de dados PostgreSQL, recurso este não provido originalmente neste SGBD, mas que pode ser implementado com o uso de heranças e triggers.


Para que serve:

O artigo apresenta através de exemplos práticos como implementar o particionamento de tabelas em um banco de dados PostgreSQL, de forma que DBAs possam usar este conhecimento para melhor gerenciar um banco de dados através da divisão de tabelas com grande volume de dados em partes menores, e mais fáceis de serem gerenciadas.


Em que situação o tema é útil:

A ideia de particionar tabela de dados é útil para dividirmos uma grande tabela em partições (ou tabelas) menores, de forma a tornar as consultas de geração de relatório e estatísticas menos onerosas para o banco de dados.

Particionar uma tabela de dados consiste em dividir um grande volume de dados que seria armazenado em uma única tabela em partições (ou tabelas) menores, onde cada uma delas atende a um conjunto específico de dados definido a partir de critérios/regras bem definidas para divisão. Assim, ao invés de consultarmos um único “tabelão” com milhões de registros, nossa consulta pode acessar apenas a partição que contém os dados que desejamos, gerando um custo muito menor para o banco de dados e consequentemente, uma consulta mais rápida e eficiente.

Particionar tabelas no PostgreSQL é um pouco mais complexo e trabalhoso que em SGBDs como SQL Server e Oracle, pois não se trata de um recurso nativo do banco de dados e sim uma adaptação de recursos disponíveis para esse fim, mas se bem aplicado torna-se muito útil para aplicações que possuam grandes volumes de dados e que podem ser divididos seguindo alguma regra específica.

A equipe de desenvolvimento do PostgreSQL já se manifestou a esse respeito e prometeu recursos mais eficientes e nativos para esse caso em versões futuras. Já sabemos que esse recurso não virá na próxima versão 8.5, mas quem sabe em um futuro não muito distante?

Neste artigo conheceremos uma forma de aplicarmos os conceitos de particionamento de dados usando o PostgreSQL como banco de dados. Para isso, iremos adaptar o uso de herança (ver Nota DevMan 1) e triggers (ver Nota DevMan 2) para atingirmos esse objetivo. Seguiremos um estudo de caso simples, mas que nos permitirá entender como aplicar este recurso em diferentes situações do dia-a-dia do administrador de banco de dados (DBA).

Nota DevMan 1. Herança de tabelas de dados

A herança de tabelas é muito útil quando precisamos criar diversas tabelas com exatamente a mesma estrutura física. Uma tabela que herda de outra tabela traz automaticamente todas as colunas da tabela pai. Assim, se precisarmos alterar ou inserir uma coluna em todas as tabelas (principal e herdeiras), basta executarmos a alteração na tabela principal que as demais tabelas serão afetadas com a mesma modificação/inclusão.

Esse recurso serve tanto para padronizar as tabelas, para facilitar a criação e manutenção de tabelas iguais, quanto para a implementação de particionamento.

Mais detalhes sobre herança de tabelas no PostgreSQL podem ser vistos em http://www.postgresql.org/docs/current/static/ddl-inherit.html.

Nota DevMan 2. Trigger em banco de dados

Uma triggerconsiste em um código procedural que representa um gatilho executado automaticamente em resposta a certos eventos em uma tabela ou view particular em um banco de dados. Trigger é comumente usada para manter a integridade das informações em um banco de dados.

Dessa forma, Triggers são comumente usadas para:

· Prevenir mudanças de ocorrerem em um banco de dados;

· Registrar as mudanças em um arquivo de log (ex: manter uma cópia dos dados antigos);

· Auditar mudanças (ex: manter um log dos usuários e papéis envolvidos em mudanças);

· Garantir regras de negócio (ex: requerer que toda compra possua ao menos 1 item);

· Executar regras de negócio (ex: notificar um gerente sempre que o número da conta corrente de um cliente do banco for alterado);

· Replicar dados (ex: armazenar um registro de todas as mudanças para que ele seja persistido em outro banco de dados posteriormente);

· Garantir desempenho (ex: atualizar o saldo de uma conta corrente após uma transação, para consultas rápidas ao saldo).

Uma trigger é definida para ser ativada quando uma instrução de INSERT,DELETE, ouUPDATEseja executa na tabela associada. Uma trigger pode ser configurada para ser ativada antes ou após a instrução. Por exemplo, podemos ter uma trigger que será ativada antes que cada linha de uma tabela seja inserida ou após a atualização de uma linha da tabela.

Por exemplo, podemos definir que um determinado gatilho será disparado antes de um insert em uma tabela CLIENTE para verificar se a coluna NOME está composta por pelo menos 5 caracteres ou que atendem a outras regras específicas. Podemos definir também que uma trigger será disparada após um update em uma tabela para gravar as informações alteradas em outra tabela para manter um histórico de alterações.

Hoje em dia, triggers ...

Quer ler esse conteúdo completo? Tenha acesso completo