Datenbank-Archivierungslösungen

In Fortsetzung einer von mir gestellten Frage zu Ist es eine gute Idee, Tabellen mit hohem Datenvolumen und hohem Zugriff in eine separate Datenbank zu verschieben? Ich suche nach verschiedenen Techniken / Lösungen für die Datenbankarchivierung in PostgreSQL.

Einige Lösungen, die mir einfallen, sind:

1. Tabellenpartitionierung
2. Separater Tablespace und / oder separates Schema
3. Verschieben von archivierten Datensätzen / Tabellen auf eine andere Festplatte

Alle anderen Vorschläge / Hinweise / Lösungen sind sehr willkommen und geschätzt.

HINWEIS: Wir führen PostgreSQL v9.1.3 unter CentOS5.2 aus

Mein Vorschlag zur Archivierung:

1. Erstellen archive_tablespace(wenn Sie möchten, können Sie Hardware im Archiv trennen)

2. Tabellen erstellen. Zum Beispiel wollen wir Tabellenbeiträge archivieren.

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

   Danach haben wir 2 neue Tabellen: public.posts_all (mit den gleichen Spalten wie in posts) zum Abfragen aller Posts (Archiv und Produktion) und public.posts_archive zum Abfragen aller Archivposts. Public.posts erbt von posts_all.
   Einfügungen sollten auf eine alte Weise erfolgen (um public.posts zu tabellieren), es sei denn, Sie schreiben Trigger auf posts_all, um Einfügungen zur Tabelle posts umzuleiten. Wenn Sie eine Partitionierung haben, wird dies komplizierter. Mit einer funktionierenden Anwendung und vor der alten Datenmigration müssen Sie nichts am Anwendungscode ändern, um mit diesem Ansatz zu arbeiten.

3. Erstellen Sie ein Schemaarchiv für die logische Trennung. Mein Vorschlag ist, die Archivdaten nach Möglichkeit nach einem bestimmten Zeitraum (Jahr oder Monat) zu trennen (archive_2005).

4. Erstellen Sie Archivtabellen im 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;
   

   Danach haben Sie neue Tabellenbeiträge im Schema archive_2005 und postgresql planer weiß, dass die Daten nur im festgelegten Zeitraum vorliegen. Wenn Sie nach einem anderen Zeitraum abfragen, sucht postgresql nicht in dieser Tabelle.

5. Erstellen Sie Funktionen / Prozeduren / Trigger, um Daten in Archivtabellen zu verschieben.

6. Archivieren Sie einmal für einen bestimmten Zeitraum (Jahr hier) und vakuumieren Sie den alten Tisch oder tun Sie dies automatisch durch Auslöser (schwerer bei automatischem Vakuum). Beide Techniken haben viele Vor- und Nachteile.

Wenn implementiert:

1. Kann Archivdaten (* aus posts_archive auswählen), alle Daten (* aus posts_all auswählen) und Produktionsdaten (* aus public.posts auswählen) separat abfragen
2. Sie können Archivschemata separat sichern und auf einfache Weise kaskadieren. pg_dump -s archive_2005 datase_name drop schema archive_2005 cascade; - Seien Sie vorsichtig, da alle zugehörigen Tabellen entfernt werden
3. Alte Daten, die physisch nach Tablespace und logisch nach Schema getrennt sind.
4. Sehr komplizierte Struktur zur Verwaltung des Archivierungsprozesses
5. Kann verschiedene Indizes für Produktions- und Archivtabellen erstellen, um Abfragen für beide zu optimieren (kleinere und spezialisierte Indizes = schnellere Abfragen und weniger Speicherplatz erforderlich)
6. Wenn Sie partitionierte Tabellen (nach Jahr oder Monat) haben, wird der Archivierungsprozess nur darin bestehen, die gesamte Tabelle zu verschieben archive_tablespaceoder sie so zu ändern, dass sie von posts_archive erbt (ich habe dies nicht getestet).
7. Wenn Sie nicht auf alte (archivierte) Daten zugreifen möchten, müssen Sie in der Anwendung nichts ändern.

Dies ist eine allgemeine Technik, die Sie an Ihre Bedürfnisse anpassen sollten. Irgendwelche Vorschläge, um dies zu verbessern?

Weiterführende Literatur: PostgreSQL-Vererbung , Partitionierung