Solutions d'archivage de bases de données

Suite à une question que j'ai posée sur Est-ce une bonne idée de déplacer des tables à volume élevé et à accès élevé vers une base de données distincte? , je suis à la recherche de différentes techniques / solutions disponibles pour l'archivage de bases de données dans PostgreSQL.

Peu de solutions auxquelles je peux penser sont:

1. Partitionnement de table
2. Espace de table et / ou schéma séparés
3. Déplacement des enregistrements / tables archivés vers un autre disque dur

Toutes autres suggestions / pointeurs / solutions sont vraiment les bienvenues et appréciées.

REMARQUE: nous exécutons PostgreSQL v9.1.3 sur CentOS5.2

Ma suggestion sur l'archivage:

1. Créer archive_tablespace(si vous le souhaitez, vous pouvez séparer le matériel sur l'archive)

2. Créez des tableaux. Par exemple, nous voulons archiver les articles du tableau.

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

   Après cela, nous aurons 2 nouvelles tables: public.posts_all (avec les mêmes colonnes que dans les articles) pour interroger tous les articles (archives et production) et public.posts_archive pour interroger tous les articles d'archives. Public.posts héritera de posts_all.
   Les insertions doivent se faire à l'ancienne (dans le tableau public.posts) à moins que vous n'écriviez des déclencheurs sur posts_all pour rediriger les insertions vers la table des publications. Si vous avez un partitionnement, ce sera plus compliqué. Avec l'application fonctionnelle et avant l'ancienne migration des données, vous n'avez rien à changer dans le code de l'application pour travailler avec cette approche.

3. Créez une archive de schéma pour la séparation logique. Ma suggestion sera de séparer les données d'archives par une certaine période de temps (année ou mois) si possible (archive_2005).

4. Créer des tables d'archives dans le schéma 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;

   Après cela, vous aurez de nouveaux messages de table dans le schéma archive_2005 et le planificateur postgresql saura que les données ne s'y trouvent que dans la période de temps prévue. Si vous interrogez sur une autre période, postgresql ne cherchera pas dans ce tableau.

5. Créez des fonctions / procédures / déclencheurs pour déplacer des données vers des tables d'archives.

6. Faites l'archivage une fois pour une période de temps (année ici) et passez l'aspirateur sur l'ancienne table ou faites-le automatiquement par des déclencheurs (plus lourd sur le vide automatique). Les deux techniques présentent de nombreux avantages et inconvénients.

Si mis en œuvre:

1. Peut interroger les données d'archive (sélectionnez * dans posts_archive), toutes les données (sélectionnez * dans posts_all) et de production (sélectionnez * dans public.posts) séparément
2. Peut faire un vidage des schémas d'archivage séparément et déposer une cascade sur eux de manière simple. pg_dump -s archive_2005 datase_name drop schema archive_2005 cascade; - soyez prudent car il supprime toutes les tables associées
3. Anciennes données séparées physiquement par l'espace de table et logiquement par le schéma.
4. Structure assez compliquée pour gérer le processus d'archivage
5. Peut créer différents index sur les tables de production et d'archivage pour optimiser les requêtes à la fois (index plus petits et spécialisés = requêtes plus rapides et moins d'espace requis)
6. Si vous avez des tables partitionnées (par année ou mois), le processus d'archivage consistera simplement à déplacer la table entière archive_tablespaceou à la modifier pour hériter de posts_archive (je n'ai pas testé cela)
7. Si vous ne souhaitez pas accéder aux anciennes données (archivées), vous n'avez rien à changer dans l'application.

Il s'agit d'une technique générale et vous devez l'adapter à vos besoins. Des suggestions pour améliorer cela?

Lectures complémentaires: héritage PostgreSQL , partitionnement