Desain struktur data untuk dukungan replikasi database

Yah, hal pertama yang akan saya lakukan adalah membuang parsing string yang menjijikkan di mana-mana dan menggantinya dengan tipe asli PostgreSQL. Untuk menyimpan status replikasi pada setiap record yang mirip dengan solusi Anda saat ini:

CREATE TYPE replication_status AS ENUM (
  'no_action',
  'replicate_record',
  'record_replicated',
  'error_1',
  'error_2',
  'error_3'
  );
ALTER TABLE t ADD COLUMN rep_status_array replication_status[];

Ini menghabiskan sedikit lebih banyak ruang penyimpanan - nilai enum adalah 4 byte, bukan 1 dan array memiliki beberapa overhead. Namun, dengan mengajarkan database konsep Anda alih-alih menyembunyikannya, Anda dapat menulis hal-hal seperti:

-- find all records that need to be replicated to host 4
SELECT * FROM t WHERE rep_status_array[4] = 'replicate_record';

-- find all records that contain any error status
SELECT * FROM t WHERE rep_status_array &&
  ARRAY['error_1', 'error_2', 'error_3']::replication_status[];

Anda dapat menempatkan indeks GIN tepat di rep_status_array jika itu membantu kasus penggunaan Anda, tetapi lebih baik untuk melihat kueri Anda dan membuat indeks khusus untuk apa yang Anda gunakan:

CREATE INDEX t_replication_host_4_key ON t ((rep_status_array[4]));
CREATE INDEX t_replication_error_key ON t (id)
  WHERE rep_status_array && ARRAY['error_1', 'error_2', 'error_3']::replication_status[];

Yang mengatakan, mengingat 200 tabel, saya akan tergoda untuk membagi ini menjadi tabel status replikasi tunggal -- baik satu baris dengan larik status atau satu baris per host, tergantung pada cara kerja logika replikasi lainnya. Saya masih menggunakan enumerasi itu:

CREATE TABLE adhoc_replication (
  record_id bigint not null,
  table_oid oid not null,
  host_id integer not null,
  replication_status status not null default 'no_action',
  primary key (record_id,table_oid,host_id)
  );

PostgreSQL secara internal menetapkan setiap tabel sebuah OID (coba SELECT *, tableoid FROM t LIMIT 1 ), yang merupakan pengidentifikasi numerik stabil yang nyaman dalam satu sistem basis data. Dengan kata lain, itu berubah jika tabel dijatuhkan dan dibuat ulang (yang dapat terjadi jika Anda misalnya membuang dan memulihkan database), dan untuk alasan yang sama ini sangat mungkin berbeda antara pengembangan dan produksi. Jika Anda lebih suka situasi ini berfungsi sebagai ganti pemutusan saat Anda menambahkan atau mengganti nama tabel, gunakan enumerasi alih-alih OID.

Menggunakan satu tabel untuk semua replikasi akan memungkinkan Anda untuk dengan mudah menggunakan kembali pemicu dan kueri dan semacamnya, memisahkan sebagian besar logika replikasi dari data yang direplikasi. Ini juga memungkinkan Anda untuk membuat kueri berdasarkan status untuk host tertentu di semua tabel Asal Anda dengan mereferensikan satu indeks, yang mungkin penting.

Adapun ukuran tabel, PostgreSQL pasti dapat menangani 10 juta baris dalam tabel yang sama. Jika Anda menggunakan tabel khusus terkait replikasi, Anda selalu dapat partisi per tuan rumah. (Mempartisi menurut tabel tidak masuk akal bagi saya; tampaknya lebih buruk daripada menyimpan status replikasi pada setiap baris hulu.) Cara mana untuk mempartisi atau apakah itu sesuai atau tidak sama sekali tergantung pada jenis pertanyaan apa yang ingin Anda tanyakan ke database Anda, dan jenis aktivitas apa yang terjadi pada tabel dasar. (Mempartisi berarti mempertahankan banyak gumpalan kecil, bukan beberapa gumpalan besar, dan berpotensi mengakses banyak gumpalan kecil untuk melakukan satu operasi.) Ini benar-benar masalah memilih kapan Anda ingin disk Anda terjadi.