Soluciones de archivo de base de datos

En continuación a una pregunta publicada por mí en ¿Es una buena idea mover tablas de gran volumen y de alto acceso a una base de datos separada? , estoy buscando diferentes técnicas / soluciones disponibles para el archivo de bases de datos en PostgreSQL.

Pocas soluciones en las que puedo pensar son:

1. Particionamiento de tabla
2. Separar espacio de tabla y / o esquema
3. Mover registros / tablas archivadas a un disco duro diferente

Cualquier otra sugerencia / puntero / solución es realmente bienvenida y apreciada.

NOTA: Estamos ejecutando PostgreSQL v9.1.3 en CentOS5.2

Mi sugerencia sobre el archivo:

1. Crear archive_tablespace(si lo desea, puede separar el hardware en el archivo)

2. Crea tablas. Por ejemplo, queremos archivar las publicaciones de la tabla.

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

   Después de eso tendremos 2 nuevas tablas: public.posts_all (con las mismas columnas que en las publicaciones) para consultar todas las publicaciones (archivo y producción) y public.posts_archive para consultar todas las publicaciones de archivo. Public.posts heredará de posts_all.
   Las inserciones deben ir de una manera antigua (a la tabla public.posts) a menos que escriba disparadores en posts_all para redirigir las inserciones a la tabla de publicaciones. Si tiene particiones, será más complicado. Con la aplicación en funcionamiento y antes de la migración de datos anterior, no tiene que cambiar nada en el código de la aplicación para trabajar con este enfoque.

3. Cree un archivo de esquema para la separación lógica. Mi sugerencia será separar los datos de archivo por algún período de tiempo (año o mes) si es posible (archive_2005).

4. Crear tablas de archivo en el 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;

   Después de eso, tendrá nuevas publicaciones en la tabla en el esquema archive_2005 y postgresql planer sabrá que los datos solo están en el período de tiempo diseñado. Si realiza una consulta por otro período de tiempo, postgresql no buscará en esta tabla.

5. Cree funciones / procedimientos / disparadores para mover datos a tablas de archivo.

6. Archive una vez por un período de tiempo (año aquí) y aspire la tabla antigua o hágalo automáticamente por disparadores (más pesado en autovacuum). Hay muchas ventajas y desventajas en ambas técnicas.

Si se implementa:

1. Puede consultar el archivo (seleccione * de posts_archive), todos (seleccione * de posts_all) y los datos de producción (seleccione * de public.posts) por separado
2. Puede volcar esquemas de archivo por separado y soltarlos en cascada de manera fácil. pg_dump -s archive_2005 datase_name drop schema archive_2005 cascade; - tenga cuidado porque elimina todas las tablas relacionadas
3. Datos antiguos separados físicamente por tablespace y lógicamente por esquema.
4. Estructura bastante complicada para gestionar el proceso de archivo
5. Puede crear diferentes índices en las tablas de producción y archivo para optimizar las consultas a ambos (índices más pequeños y especializados = consultas más rápidas y menos espacio requerido)
6. Si tiene tablas particionadas (por año o mes), el proceso de archivo será solo para mover la tabla completa archive_tablespaceo simplemente alterarla para heredar de posts_archive (no probé esto)
7. Si no desea acceder a datos antiguos (archivados), no tiene que cambiar nada en la aplicación.

Esta es una técnica general y debe adaptarla a sus necesidades. ¿Alguna sugerencia para mejorar esto?

Lectura adicional: herencia de PostgreSQL , particionamiento