Để phân vùng hay không phân vùng?

Đã đọc một số câu hỏi về SO, bài viết trên blog và hướng dẫn sử dụng bên ngoài

• SO : Ràng buộc khóa ngoài đối với bảng được phân vùng trong PG
• dba.SE : Các cách xử lý FK khác nhau đối với bảng được phân vùng trong PG
• Hướng dẫn sử dụng : Kế thừa
• Hướng dẫn : Phân vùng
• Hướng dẫn sử dụng : Hạn chế kích hoạt
• Blog : Postgres mô hình với sự kế thừa

Tôi vẫn thấy mình băn khoăn không biết có nên đi phân vùng xem xét trường hợp của mình hay không.

Vụ án - đơn giản hóa

Lưu trữ dữ liệu khách hàng. Tất cả tên của các bảng được đề cập dưới đây được tạo nên cho rõ ràng.

1. Có các đối tượng được khách hàng nhận dạng và không phải là vật thể, cũng là các đối tượng vật lý mà chúng thực sự được lưu trữ trong trường hợp cần gửi một số đối tượng cho khách hàng theo yêu cầu hoặc xử lý theo một số cách khác. Chúng được ánh xạ trong một mối quan hệ nhiều-nhiều. objects_nonphysical, objects_physical, objects_mapping_table.

2. Mối quan hệ nhiều-nhiều thứ hai là giữa các đối tượng phi vật lý và số liệu của chúng. Có những đối tượng bị ràng buộc với một số số liệu. metrics,metrics_objects_nonphysical

3. Cả hai đối tượng phi vật lý và vật lý đều có các bảng phân cấp là quan hệ cha-con. objects_nonphysical_hierarchy,objects_physical_hierarchy

Tùy thuộc vào nhu cầu và yêu cầu của từng khách hàng, dữ liệu về các đối tượng vật lý có thể được cung cấp hoặc có thể cần được tạo từ đầu. Về cơ bản, những gì tôi cần làm là:

• Duy trì hệ thống nội bộ cho nhanh INSERTvà SELECTbáo cáo, bởi vì đây là nơi sẽ diễn ra ánh xạ.

• Duy trì hệ thống để khách hàng bên ngoài xem và vận hành trên các đối tượng phi vật lý của họ - truy xuất dữ liệu nhanh chóng. Nhu cầu hiệu quả cao cho các SELECTbáo cáo - dữ liệu này có sẵn cho nhiều khách hàng tìm kiếm bất cứ khi nào họ muốn.

Tôi cân nhắc

Có thể có một khách hàng, những người có thể truy cập dữ liệu, xem và vận hành trên đó, nhưng đó không cần phải là nhà thầu mà chúng tôi đã nhận được dữ liệu từ / đang xử lý dữ liệu.

Điều này đã khiến tôi giới thiệu phân vùng bảng vào hệ thống của mình, xem xét rằng tôi luôn biết dữ liệu phân vùng nào sẽ rơi vào ( phân vùng cho nhà thầu ), sau đó đến hệ thống chính cho khách hàng bên ngoài nơi tôi cần phân vùng cho khách hàng (điều này sẽ được thực hiện với một số trì hoãn sử dụng các công cụ tự động hóa và bộ quy tắc để viết lại dữ liệu theo cách của khách hàng, do đó, đối với mỗi khách hàng, chúng tôi chỉ quét một phân vùng cho mỗi bảng.

Khối lượng dữ liệu

Dữ liệu của tôi sẽ tăng liên tục, đặc biệt là khi nhập đối tượng và số liệu của khách hàng mới. Tốc độ của dữ liệu mới vào hệ thống là không thể dự đoán được vào lúc này trong thời gian dài. Thực sự không có cách nào để đo lường nó mà không biết ai sẽ là khách hàng tiếp theo. Ngay bây giờ chỉ có 2 khách hàng với ít nhất 1M hàng cho mỗi khách hàng trong mỗi bảng. Nhưng trong tương lai, tôi dự đoán khách hàng mới sẽ có một khối lượng 10 triệu hàng.

Câu hỏi

Những câu hỏi này đều liên quan đến nhau.

1. Phân vùng thực sự nên được xem xét ở đây, hoặc đó là một quá mức cần thiết? Tôi coi nó sẽ được sử dụng vì tôi luôn quét chính xác một phân vùng.
2. Nếu phân vùng là cách để đi, làm thế nào để tôi thực thi FKràng buộc xem xét nhu cầu của mình một cách hiệu quả nhất? Tôi nên đi constraint triggers, hoặc chỉ giữ nó trong lớp ứng dụng cho hệ thống nội bộ, hoặc có thể một số phương pháp khác?
3. Nếu phân vùng không phải là cách để đi, tôi nên đi sâu vào vấn đề gì?

Nếu không có đủ dữ liệu được cung cấp, xin vui lòng cho tôi biết trong các ý kiến ​​dưới đây.

Có nhiều kết thúc mở trong câu hỏi của bạn, nhưng phân vùng theo khách hàng có thể là cách để đi - đặc biệt là:

• bạn mong đợi nhiều khách hàng,
• mỗi trong số chúng có thể có hàng tấn dữ liệu ("tấn" có nghĩa là nhiều hơn kích thước bộ nhớ cache của RAM),
• hầu hết các bộ dữ liệu của họ sẽ loại trừ lẫn nhau (mỗi khách hàng nhìn thấy tập hợp con dữ liệu khác nhau).

Quy tắc hoặc kích hoạt là một chi phí hiệu suất, và có thể tránh được.

Hãy xem xét một cái gì đó dọc theo những dòng này:

BEGIN;

CREATE USER tenant1;
CREATE USER tenant2;

CREATE SCHEMA app;
CREATE SCHEMA tenant1;
CREATE SCHEMA tenant2;

CREATE TABLE app.objects_nonphysical(id int);
CREATE TABLE app.objects_physical(id int);
CREATE TABLE app.objects_mapping(id int);    
CREATE TABLE tenant1.objects_nonphysical() INHERITS(app.objects_nonphysical);
CREATE TABLE tenant1.objects_physical() INHERITS(app.objects_physical);
CREATE TABLE tenant1.objects_mapping() INHERITS(app.objects_mapping);
CREATE TABLE tenant2.objects_nonphysical() INHERITS(app.objects_nonphysical);
CREATE TABLE tenant2.objects_physical() INHERITS(app.objects_physical);
CREATE TABLE tenant2.objects_mapping() INHERITS(app.objects_mapping);

GRANT USAGE ON SCHEMA tenant1 TO tenant1;
GRANT USAGE ON SCHEMA tenant2 TO tenant2;
GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN SCHEMA tenant1 TO tenant1;
GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN SCHEMA tenant2 TO tenant2;

/* TEST: simulate login as customer */
SET SESSION AUTHORIZATION tenant2;
/* No schema needed - default search_path works */
SELECT count(*) FROM objects_nonphysical; 

ROLLBACK;

Bạn không cần bất kỳ kích hoạt / quy tắc để duy trì nó.

Có những kết thúc mở ở đây - đó chỉ là một bản nháp ... Một số vấn đề:

• PK, FK và các chỉ mục không được "kế thừa".
• ngay cả khi bạn tạo chúng, PK không được thực thi trên bảng chính
• bạn có thể khắc phục điều này bằng cách sử dụng cùng một trình tự cho tất cả người thuê
• rõ ràng, ứng dụng phải được điều chỉnh cho mô hình này

Sẽ không hại gì nếu bạn triển khai phân vùng ngay bây giờ, nhưng sử dụng một phân vùng duy nhất cho đến khi hệ thống của bạn thực sự yêu cầu phân vùng mới. Hiệu suất-khôn ngoan, sẽ chỉ có một chi phí nhỏ, để đối phó với các khóa chính và như vậy.

Tôi khuyên bạn nên sử dụng quy tắc để chuyển hướng chèn và một bảng bên ngoài cho các khóa chính (ví dụ: CREATE TABLE objects_physical_ids (id bigserial NOT NULL PRIMARY KEY)cùng với một trình kích hoạt chức năng chèn một hàng trong bảng ids và sao chép nó vào NEW.id (ví dụ INSERT INTO objects_physical_ids DEFAULT VALUES RETURNING id INTO NEW.id;) và các trình kích hoạt khác xử lý xóa và các bản cập nhật và một trình kích hoạt thực thi các trình kích hoạt chức năng đó cho mỗi bảng được kế thừa (đừng quên làm điều này khi bạn tạo một bảng kế thừa mới!). Sau đó, tất cả các bảng có liên quan đều có thể có FOREIGN KEYbảng id liên quan (bao gồm mọi hành động khóa ngoại như ON UPDATEhoặc ON DELETE).