web-dev-qa-db-ja.com

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

大量のアクセス頻度の高いテーブルを別のデータベースに移動するのは良い考えですか？、私が投稿した質問に続き、 PostgreSQLでのデータベースのアーカイブに使用できるさまざまな手法/ソリューションを探します。

私が考えることができるいくつかの解決策は次のとおりです。

  1. テーブル分割
  2. 個別のテーブルスペースまたはスキーマ、あるいはその両方
  3. アーカイブされたレコード/テーブルを別のハードディスクに移動する

他の提案/ポインタ/解決策は本当に歓迎され、高く評価されています。

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

postgresqlpartitioningpostgresql-9.1archive
18
Gnanam

アーカイブについての私の提案：

  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にトリガーを記述して挿入をpostsテーブルにリダイレクトしない限り、挿入は古い方法で（テーブル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 planerはデータが設計された期間にのみ存在することを認識します。別の期間でクエリを実行すると、postgresqlはこのテーブルを検索しません。

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

  6. 一定期間（ここでは1年）アーカイブを1回実行し、古いテーブルをバキュームするか、トリガーによって自動で実行します（自動バキュームではより重い）。どちらの手法にも多くの長所と短所があります。

実装されている場合：

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

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

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

13
sufleR