Soluzioni di archiviazione del database

In seguito a una domanda da me pubblicata su È una buona idea spostare le tabelle di volume elevato e di accesso elevato in un database separato? , sto cercando diverse tecniche / soluzioni disponibili per l'archiviazione del database in PostgreSQL.

Poche soluzioni che mi vengono in mente sono:

1. Partizionamento della tabella
2. Separato tablespace e / o schema
3. Spostamento di record / tabelle archiviati su un altro disco rigido

Eventuali altri suggerimenti / suggerimenti / soluzioni sono davvero benvenuti e apprezzati.

NOTA: Stiamo eseguendo PostgreSQL v9.1.3 su CentOS5.2

Il mio consiglio sull'archiviazione:

1. Crea archive_tablespace(se lo desideri puoi separare l'hardware nell'archivio)

2. Crea tabelle. Ad esempio, vogliamo archiviare i post delle tabelle.

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

   Dopodiché avremo 2 nuove tabelle: public.posts_all (con le stesse colonne come nei post) per interrogare tutti i post (archivio e produzione) e public.posts_archive per interrogare tutti i post in archivio. Public.posts erediterà da posts_all.
   Gli inserti dovrebbero andare in un vecchio modo (nella tabella public.posts) a meno che tu non scriva i trigger su posts_all per reindirizzare gli inserti alla tabella dei post. Se hai il partizionamento sarà più complicato. Con l'applicazione funzionante e prima della vecchia migrazione dei dati non è necessario modificare nulla nel codice dell'applicazione per funzionare con questo approccio.

3. Creare un archivio di schemi per la separazione logica. Il mio suggerimento sarà di separare i dati di archivio per un certo periodo di tempo (anno o mese), se possibile (archive_2005).

4. Creare tabelle di archivio nello schema 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;

   Dopodiché avrai nuovi posti tabella nello schema archive_2005 e la pialla postgresql saprà che i dati ci sono solo nel periodo di tempo progettato. Se esegui una query per un altro periodo di tempo, postgresql non cercherà in questa tabella.

5. Creare funzioni / procedure / trigger per spostare i dati nelle tabelle di archivio.

6. Archivia una volta per un periodo di tempo (anno qui) e passa l'aspirapolvere alla vecchia tabella o esegui automaticamente i trigger (più pesanti in caso di vuoto automatico). Ci sono molti vantaggi e svantaggi in entrambe le tecniche.

Se implementato:

1. Può interrogare i dati di archivio (selezionare * da posts_archive), tutti (selezionare * da posts_all) e di produzione (selezionare * da public.posts) separatamente
2. Può eseguire il dump degli schemi di archivio separatamente e rilasciarli a cascata in modo semplice. pg_dump -s archive_2005 nome_data drop schema archive_2005 cascata; - fai attenzione perché rimuove tutte le tabelle correlate
3. Vecchi dati separati fisicamente per tablespace e logicamente per schema.
4. Struttura abbastanza complicata per gestire il processo di archiviazione
5. Può creare indici diversi su tabelle di produzione e di archiviazione per ottimizzare le query su entrambi (indici più piccoli e specializzati = query più veloci e meno spazio richiesto)
6. Se hai tabelle partizionate (per anno o mese) il processo di archiviazione sarà solo per spostare l'intera tabella archive_tablespaceo semplicemente modificarla per ereditare da posts_archive (non l'ho testato)
7. Se non si desidera accedere a dati vecchi (archiviati) non è necessario modificare nulla nell'applicazione.

Questa è una tecnica generale e dovresti adattarla alle tue esigenze. Qualche suggerimento per migliorare questo?

Ulteriori letture: eredità PostgreSQL , partizionamento