Soluções de arquivamento de banco de dados

Em continuação a uma pergunta publicada por mim em É uma boa idéia mover tabelas de alto volume e alto acesso para um banco de dados separado? , estou procurando diferentes técnicas / soluções disponíveis para arquivamento de banco de dados no PostgreSQL.

Poucas soluções que consigo pensar são:

1. Particionamento de tabela
2. Espaço de tabela e / ou esquema separados
3. Movendo registros / tabelas arquivados para um disco rígido diferente

Quaisquer outras sugestões / sugestões / soluções são realmente bem-vindas e apreciadas.

NOTA: Estamos executando o PostgreSQL v9.1.3 no CentOS5.2

Minha sugestão sobre arquivamento:

1. Criar archive_tablespace(se você quiser, pode separar o hardware no arquivo morto)

2. Crie tabelas. Por exemplo, queremos arquivar postagens de tabela.

   create table  posts_all ( LIKE public.posts)  ;
   create table  posts_archive () inherits  ( public.posts_all)  ;
   alter table  public.posts  inherits ( public.posts_all ) ;
   

   Depois disso, teremos 2 novas tabelas: public.posts_all (com as mesmas colunas como nas postagens) para consultar todas as postagens (archive e produção) e public.posts_archive para consultar todas as postagens do arquivo morto. Public.posts herda de posts_all.
   As inserções devem ser antigas (para a tabela public.posts), a menos que você escreva gatilhos em posts_all para redirecionar as inserções para a tabela de postagens. Se você tiver particionamento, será mais complicado. Com o aplicativo em funcionamento e antes da migração de dados antigos, você não precisa alterar nada no código do aplicativo para trabalhar com essa abordagem.

3. Crie archive de esquema para separação lógica. Minha sugestão será separar os dados do arquivo por algum período (ano ou mês), se possível (arquivo_2005).

4. Criar tabelas de archive no esquema archive_year

   create table archive_2005.posts (
     check(record_date >= '2005-01-01 00:00:00'::timestamp 
       and record_date <  '2006-01-01 00:00:00'::timestamp)
   ) inherits (posts_archive) tablespace archive_tablesapce;
   

   Depois disso, você terá novas postagens de tabela no esquema archive_2005 e o postgresql planer saberá que os dados existem apenas no período de tempo projetado. Se você consultar por outro período, o postgresql não pesquisará nesta tabela.

5. Crie funções / procedimentos / gatilhos para mover dados para arquivar tabelas.

6. Arquive uma vez por um período de tempo (ano aqui) e aspire a tabela antiga ou faça-o automaticamente por gatilhos (mais pesado no vácuo automático). Existem muitas vantagens e desvantagens em ambas as técnicas.

Se implementado:

1. Pode consultar dados de arquivamento (selecione * de posts_archive), todos (selecione * de posts_all) e dados de produção (selecione * de public.posts) separadamente
2. Pode despejar esquemas de arquivamento separadamente e soltar cascata neles de maneira fácil. pg_dump -s archive_2005 cascata do esquema de descarte datase_name archive_2005; - tenha cuidado porque remove todas as tabelas relacionadas
3. Dados antigos separados fisicamente por espaço de tabela e logicamente por esquema.
4. Estrutura bastante complicada para gerenciar o processo de arquivamento
5. Pode criar índices diferentes nas tabelas de produção e arquivamento para otimizar as consultas para ambos (índices menores e especializados = consultas mais rápidas e menos espaço necessário)
6. Se você tiver tabelas particionadas (por ano ou mês), o processo de arquivamento será apenas para mover a tabela inteira archive_tablespaceou alterá-la para herdar de posts_archive (eu não testei isso)
7. Se você não deseja acessar dados antigos (arquivados), não precisa alterar nada no aplicativo.

Essa é uma técnica geral e você deve adaptá-la às suas necessidades. Alguma sugestão para melhorar isso?

Leitura adicional: herança do PostgreSQL , particionamento