Thiết kế cấu trúc dữ liệu để hỗ trợ nhân rộng cơ sở dữ liệu

Chà, điều đầu tiên tôi sẽ làm là bỏ phân tích cú pháp chuỗi icky ở khắp mọi nơi và thay thế nó bằng các kiểu gốc PostgreSQL. Để lưu trữ trạng thái sao chép trên mỗi bản ghi tương tự như giải pháp hiện tại của bạn:

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[];

Điều này khiến bạn tốn thêm một chút không gian lưu trữ - giá trị enum là 4 byte thay vì 1 và các mảng có một số chi phí. Tuy nhiên, bằng cách dạy cho cơ sở dữ liệu các khái niệm của bạn thay vì ẩn chúng, bạn có thể viết những thứ như:

-- 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[];

Bạn có thể đặt chỉ mục GIN ngay trên rep_status_array nếu điều đó giúp ích cho trường hợp sử dụng của bạn, nhưng tốt hơn là xem xét các truy vấn của bạn và tạo các chỉ mục cụ thể cho những gì bạn sử dụng:

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[];

Điều đó nói rằng, với 200 bảng, tôi muốn chia nó thành một bảng trạng thái sao chép duy nhất - một hàng với một mảng trạng thái hoặc một hàng trên mỗi máy chủ, tùy thuộc vào cách hoạt động của phần còn lại của logic sao chép. Tôi vẫn sử dụng cách liệt kê đó:

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 chỉ định nội bộ cho mỗi bảng một OID (thử SELECT *, tableoid FROM t LIMIT 1 ), là một định danh số ổn định thuận tiện trong một hệ thống cơ sở dữ liệu duy nhất. Nói một cách khác, nó sẽ thay đổi nếu bảng bị xóa và được tạo lại (điều này có thể xảy ra nếu bạn kết xuất và khôi phục cơ sở dữ liệu), và vì lý do tương tự, nó rất có thể khác nhau giữa phát triển và sản xuất. Nếu bạn muốn những tình huống này hoạt động để đổi lấy việc phá vỡ khi bạn thêm hoặc đổi tên bảng, hãy sử dụng kiểu liệt kê thay vì OID.

Sử dụng một bảng duy nhất cho tất cả các bản sao sẽ cho phép bạn dễ dàng sử dụng lại các trình kích hoạt và truy vấn và như vậy, tách hầu hết logic sao chép khỏi dữ liệu mà nó đang sao chép. Nó cũng cho phép bạn truy vấn dựa trên trạng thái của một máy chủ nhất định trên tất cả các bảng gốc của bạn bằng cách tham chiếu đến một chỉ mục duy nhất, điều này có thể quan trọng.

Đối với kích thước bảng, PostgreSQL chắc chắn có thể xử lý 10 triệu hàng trong cùng một bảng. Nếu bạn sử dụng bảng liên quan đến sao chép chuyên dụng, bạn luôn có thể phân vùng mỗi máy chủ. (Phân vùng theo bảng không có ý nghĩa gì đối với tôi; nó có vẻ tệ hơn việc lưu trữ trạng thái sao chép trên mỗi hàng ngược dòng.) Cách nào để phân vùng hoặc có phù hợp hay không hoàn toàn phụ thuộc vào loại câu hỏi bạn định hỏi cơ sở dữ liệu của mình và loại hoạt động nào xảy ra trên các bảng cơ sở. (Phân vùng có nghĩa là duy trì nhiều đốm màu nhỏ hơn thay vì một vài đốm màu lớn và có khả năng truy cập nhiều đốm màu nhỏ hơn để thực hiện một thao tác duy nhất.) Thực sự là vấn đề lựa chọn khi bạn muốn đĩa của mình tìm kiếm.