Hiệu suất không nhất thiết phải tệ hơn. Như bài viết giải thích, có những điều kiện cụ thể làm cho cách tiếp cận lược đồ tốt hơn hoặc tệ hơn tùy thuộc vào thiết kế ứng dụng và khối lượng công việc của bạn. Hãy để tôi giải thích sự cân bằng của phương pháp tiếp cận "lược đồ đối tượng" và "bảng chia sẻ":
lược đồ người thuê là tốt nhất khi bạn có một số lượng tương đối nhỏ người thuê nhà khá lớn. Ví dụ về điều này sẽ là một ứng dụng kế toán, chỉ với những người dùng đăng ký trả phí. Những điều khiến nó trở thành tùy chọn hoạt động tốt hơn cho bạn bao gồm:
- một số lượng nhỏ người thuê với nhiều dữ liệu mỗi người
- một giản đồ tương đối đơn giản không có nhiều bảng cho mỗi người thuê
- nhu cầu tùy chỉnh các lược đồ của một số người thuê
- khả năng sử dụng các vai trò cơ sở dữ liệu cho mỗi người thuê
- yêu cầu di chuyển dữ liệu của người thuê từ máy chủ này sang máy chủ khác
- khả năng tạo ra một máy chủ ứng dụng chuyên dụng trên đám mây của bạn cho từng người thuê
Những điều khiến nó trở thành một tùy chọn hoạt động kém bao gồm:
- nhiều người thuê với rất ít dữ liệu mỗi người
- cách tiếp cận không trạng thái đối với các kết nối trong đó mỗi yêu cầu có thể là bất kỳ người thuê nào
- thư viện máy khách hoặc orm lưu siêu dữ liệu vào bộ nhớ cache cho tất cả các bảng (như ActiveRecord)
- một yêu cầu để tổng hợp kết nối hiệu quả, hiệu suất cao và / hoặc bộ nhớ đệm
- sự cố với VACUUM và các hoạt động quản trị PostgreSQL khác có quy mô kém trên 1000 bảng.
Liệu lược đồ đối tượng có gây hại cho việc di chuyển / thay đổi giản đồ hay không thực sự phụ thuộc vào cách bạn thực hiện chúng. Việc triển khai thay đổi giản đồ chung một cách nhanh chóng là không tốt, nhưng tốt cho việc triển khai các thay đổi giản đồ dưới dạng triển khai dần dần cho các đối tượng thuê.
bảng chia sẻ hoạt động tốt hơn cho các tình huống khi bạn có nhiều người thuê và nhiều người thuê của bạn có rất ít dữ liệu. Một ví dụ về điều này sẽ là một ứng dụng di động xã hội trung gian cho phép các tài khoản miễn phí và do đó có hàng nghìn tài khoản bị bỏ rơi. Những điều khác làm cho mô hình bảng chia sẻ có lợi là:
- tốt hơn cho việc tổng hợp kết nối, vì tất cả các kết nối có thể sử dụng cùng một nhóm
- tốt hơn cho quản trị PostgreSQL, vì tổng số bảng ít hơn
- tốt hơn cho việc di chuyển và thay đổi giản đồ, vì chỉ có một "tập hợp" bảng
Hạn chế chính của shared-table là cần phải thêm điều kiện bộ lọc đối tượng thuê vào mỗi truy vấn trong lớp ứng dụng. Nó cũng có vấn đề vì:
- các truy vấn kết hợp nhiều bảng có thể hoạt động kém vì bộ lọc đối tượng thuê loại bỏ việc lập kế hoạch truy vấn
- bảng phát triển đến 100 triệu hàng có thể gây ra các vấn đề về hiệu suất và bảo trì cụ thể
- không có cách nào để thực hiện các thay đổi ứng dụng cụ thể đối với người thuê hoặc nâng cấp giản đồ
- đắt hơn để di chuyển người thuê giữa các máy chủ
Vì vậy, mô hình nào "hoạt động tốt hơn" thực sự phụ thuộc vào sự đánh đổi nào khiến bạn bị tổn thương nặng nhất.
Ngoài ra còn có một mô hình kết hợp, "tenant-view", nơi dữ liệu thực tế được lưu trữ trong các bảng được chia sẻ, nhưng mỗi kết nối ứng dụng sử dụng chế độ xem hàng rào bảo mật để xem dữ liệu. Điều này có một số sự cân bằng của mỗi mô hình. Về cơ bản, nó có những lợi ích bảo mật của mô hình lược đồ-đối tượng thuê với một số hạn chế về hiệu suất của cả hai mô hình.
