Solusi arsip basis data


18

Sebagai kelanjutan dari pertanyaan yang saya posting di Apakah ide yang bagus untuk memindahkan tabel bervolume tinggi dan sangat diakses ke database terpisah? , saya mencari berbagai teknik / solusi yang tersedia untuk pengarsipan basis data di PostgreSQL.

Beberapa solusi yang dapat saya pikirkan adalah:

  1. Partisi tabel
  2. Memisahkan tablespace dan / atau skema
  3. Memindahkan arsip / tabel yang diarsipkan ke harddisk yang berbeda

Saran / petunjuk / solusi lain sangat diterima dan dihargai.

CATATAN: Kami menjalankan PostgreSQL v9.1.3 di CentOS5.2

Jawaban:


13

Saran saya tentang pengarsipan:

  1. Buat archive_tablespace(jika mau, Anda dapat memisahkan perangkat keras pada arsip)
  2. Buat tabel. Misalnya kita ingin mengarsipkan posting tabel.

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

    Setelah itu kita akan memiliki 2 tabel baru: public.posts_all (dengan kolom yang sama seperti di posting) untuk meminta semua posting (arsip dan produksi) dan public.posts_archive untuk meminta semua posting arsip. Public.posts akan diwarisi dari posts_all.
    Sisipan harus masuk dengan cara lama (ke tabel public.posts) kecuali jika Anda akan menulis pemicu pada posts_all untuk mengarahkan ulang sisipan ke tabel posting. Jika Anda mempartisi, ini akan lebih rumit. Dengan aplikasi yang berfungsi dan sebelum migrasi data lama, Anda tidak perlu mengubah apa pun dalam kode aplikasi untuk bekerja dengan pendekatan ini.

  3. Buat arsip skema untuk pemisahan logis. Saran saya adalah untuk memisahkan data arsip dengan periode waktu tertentu (tahun atau bulan) jika memungkinkan (archive_2005).

  4. Buat tabel arsip dalam skema 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;

    Setelah itu Anda akan memiliki posting tabel baru di schema archive_2005 dan postgresql planer akan tahu bahwa data hanya ada dalam periode waktu yang dirancang. Jika Anda melakukan query dengan periode waktu lain postgresql tidak akan mencari di tabel ini.

  5. Buat fungsi / prosedur / pemicu untuk memindahkan data ke tabel arsip.

  6. Lakukan pengarsipan sekali untuk periode waktu (tahun di sini) dan kosongkan meja lama atau lakukan secara otomatis dengan pemicu (lebih berat saat autovacuum). Ada banyak kelebihan dan kekurangan dalam kedua teknik.

Jika diterapkan:

  1. Dapat meminta arsip (pilih * dari posts_archive), semua (pilih * dari posts_all) dan produksi (pilih * dari public.posts) data secara terpisah
  2. Dapat melakukan dump skema arsip secara terpisah dan menjatuhkan kaskade dengan mudah. pg_dump -s archive_2005 datase_name drop schema archive_2005 cascade; - berhati-hatilah karena menghapus semua tabel terkait
  3. Data lama dipisahkan secara fisik oleh tablespace dan secara logis berdasarkan skema.
  4. Struktur yang cukup rumit untuk mengelola proses pengarsipan
  5. Dapat membuat indeks berbeda pada tabel produksi dan arsip untuk mengoptimalkan kueri ke keduanya (indeks lebih kecil dan khusus = kueri lebih cepat dan lebih sedikit ruang yang dibutuhkan)
  6. Jika Anda memiliki tabel yang dipartisi (berdasarkan tahun atau bulan) proses pengarsipan akan hanya untuk memindahkan seluruh tabel archive_tablespaceatau hanya mengubahnya untuk mewarisi dari posts_archive (saya tidak menguji ini)
  7. Jika Anda tidak ingin mengakses data lama (diarsipkan), Anda tidak perlu mengubah apa pun dalam aplikasi.

Ini adalah teknik umum dan Anda harus menyesuaikannya dengan kebutuhan Anda. Ada saran untuk meningkatkan ini?

Bacaan lebih lanjut: pewarisan PostgreSQL , partisi


Saya tidak bisa memahami langkah ke-2 dengan jelas Create tables (table posts example):. Bisakah Anda menjelaskan langkah spesifik berapa banyak tabel yang ada secara total dan bagaimana pewarisan antar tabel saling terkait?
Gnanam

Jawaban yang diedit. Saya harap itu cukup untuk memahami dan mengimplementasikan pengarsipan.
sufleR

Dalam aplikasi real-time, akan ada lebih dari satu tabel dependen / anak terhubung / terkait dengan tabel induk / master. Jadi langkah-langkah yang diuraikan di sini secara otomatis berlaku untuk semua tabel dependen / turunannya juga? Apakah pemahaman saya benar?
Gnanam

Iya. Ini hanya satu contoh tabel. Saya telah menerapkan ini dalam database 100GB tetapi hanya untuk beberapa tabel terbesar.
sufleR

Jadi dalam hal ini, tabel mana yang biasanya kosong ( posts, posts-allatau posts-archive), yang ada hanya untuk mewakili seluruh kumpulan data?
Gnanam
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.