データベースアーカイブソリューション

私が投稿した質問に続いて、大量のアクセス頻度の高いテーブルを別のデータベースに移動することをお勧めしますか？、PostgreSQLでのデータベースアーカイブに利用できるさまざまなテクニック/ソリューションを探しています。

私が考えることができるいくつかのソリューションは次のとおりです。

1. テーブルのパーティション分割
2. 別のテーブルスペースおよび/またはスキーマ
3. アーカイブされたレコード/テーブルを別のハードディスクに移動する

他の提案/ポインター/ソリューションは本当に歓迎され、高く評価されています。

注： CentOS5.2でPostgreSQL v9.1.3を実行しています

アーカイブに関する私の提案：

1. 作成archive_tablespace（必要に応じて、アーカイブでハードウェアを分離できます）

2. テーブルを作成します。たとえば、テーブルの投稿をアーカイブします。

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

   その後、2つの新しいテーブルがあります。すべての投稿（アーカイブと本番）を照会するpublic.posts_all（投稿と同じ列）、およびすべてのアーカイブ投稿を照会するpublic.posts_archiveです。Public.postsはposts_allを継承します。
   挿入は、posts_allでトリガーを作成して挿入を投稿テーブルにリダイレクトしない限り、古い方法で（テーブルpublic.postsに）送信する必要があります。パーティショニングがある場合、より複雑になります。動作中のアプリケーションを使用し、古いデータを移行する前に、このアプローチで動作するようにアプリケーションコードを変更する必要はありません。

3. 論理的な分離のためにスキーマアーカイブを作成します。可能であれば、アーカイブデータをある期間（年または月）で分離することをお勧めします（archive_2005）。

4. 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;
   

   その後、スキーマarchive_2005に新しいテーブルポストがあり、postgresqlのプレーナーはデータが設計された期間にのみ存在することを認識します。別の期間でクエリを実行すると、postgresqlはこのテーブルを検索しません。

5. 関数/プロシージャ/トリガーを作成して、データをアーカイブテーブルに移動します。

6. 一定期間（ここでは年）アーカイブを1回行い、古いテーブルをバキュームするか、トリガーによって自動的にアーカイブします（autovacuumでより重い）。両方の手法には多くの利点と欠点があります。

実装されている場合：

1. アーカイブ（posts_archiveから*を選択）、すべて（posts_allから*を選択）、およびプロダクション（public.postsから*を選択）データを個別にクエリできます
2. アーカイブスキーマを個別にダンプし、それらにカスケードを簡単にドロップできます。pg_dump -s archive_2005 datase_name drop schema archive_2005 cascade; -すべての関連テーブルが削除されるため注意してください
3. テーブルスペースによって物理的に分離され、スキーマによって論理的に分離された古いデータ。
4. アーカイブプロセスを管理するための非常に複雑な構造
5. プロダクションテーブルとアーカイブテーブルに異なるインデックスを作成して、両方に対するクエリを最適化できます（より小さく特殊なインデックス=より高速なクエリと必要なスペースの削減）
6. パーティション化されたテーブルがある場合（年または月archive_tablespaceごと）、アーカイブプロセスは単にテーブル全体を移動するか、posts_archiveから継承するように変更するだけです（これはテストしませんでした）
7. 古い（アーカイブされた）データにアクセスしたくない場合は、アプリケーションで何も変更する必要はありません。

これは一般的な手法であり、ニーズに合わせて調整する必要があります。これを改善するための提案はありますか？

さらに読む：PostgreSQLの継承、パーティション分割