Ưu và nhược điểm của việc sử dụng nhiều lược đồ trong PostgreSQL trái ngược với chỉ một?

Đối với một ứng dụng SAAS lớn (được hỗ trợ bởi PostgreSql 9.4), với hơn 300.000 tài khoản (và đang phát triển), những ưu và nhược điểm của việc sử dụng lược đồ cho mỗi tài khoản để phân vùng dữ liệu so với việc đưa tất cả dữ liệu vào một lược đồ và sử dụng khóa ngoại phân vùng nó trong các truy vấn?

Tôi biết trong quá khứ pg_dump rất chậm khi làm việc với nhiều lược đồ nhưng không chắc đó có phải là trường hợp ngày hôm nay không. Tôi cũng nhận thấy bất kỳ thay đổi nào trong cấu trúc cơ sở dữ liệu sẽ phải được thực hiện trên tất cả các lược đồ. Và tôi biết rằng về mặt tích cực, việc di chuyển một lược đồ từ máy chủ vật lý này sang máy chủ vật lý khác rất dễ dàng, cũng như khôi phục một lược đồ từ bản sao lưu, chưa kể nó có ý nghĩa đối với dữ liệu phân vùng theo cách đó.

Vậy những ưu và nhược điểm tôi đang thiếu là gì?

— Harel
nguồn

Không có vẻ tốt. Một bảng khổng lồ duy nhất ("tăng trưởng theo chiều dọc") khó quản lý và một số lượng lớn các lược đồ ("tăng trưởng theo chiều ngang") cũng khó quản lý.

— Daniel Vérité

Tôi đang xây dựng lại một hệ thống cũ có số lượng tài khoản trên đó (và thậm chí số lượng người dùng lớn hơn). Nó đang sử dụng một cách tiếp cận chia sẻ (sử dụng mySql) và hoạt động tốt theo hiệu suất. Mối quan tâm của tôi là duy trì mức hiệu suất đó nhưng thêm khả năng bảo trì cho nó.

— Harel

@Harel Tôi tò mò, bạn đã thử nó với 400k lược đồ hoặc chuyển sang kiến trúc / công nghệ khác chưa?

— sthzg

Tôi đã từ bỏ ý tưởng sau khi nhìn sâu hơn vào nó. Số lượng lược đồ tôi sẽ tạo sẽ đánh bại mọi sử dụng thực tế này. Tôi đã đi với trường id tài khoản cũ tốt trong mỗi bản ghi. Mặc dù vậy, điều tôi đã làm là bỏ các id tăng tự động số có lợi cho UUID, điều đó có nghĩa là tôi có thể lấy toàn bộ tài khoản từ db này sang db khác mà không phải lo lắng về việc phá vỡ tính toàn vẹn.

— Harel

Rõ ràng, bạn đang xử lý các bảng giống nhau trong mỗi lược đồ người dùng. Bạn đã xem xét thừa kế cho điều này? Nó có thể cung cấp cho bạn tốt nhất của cả hai thế giới cho một số trường hợp sử dụng. Cũng có một số hạn chế . Bạn có thể có một lược đồ riêng cho từng người dùng và vẫn tìm kiếm tất cả các bảng người dùng cùng một lúc rất thuận tiện.

Liên quan:

Ngoài ra, ít nhất phải cấp / thu hồi các đặc quyền, đơn giản hơn nhiều với các lược đồ riêng biệt.

— Thương hiệu Erwin
nguồn

Tôi sẽ xem xét thừa kế. Tuy nhiên, mối quan tâm của tôi là với quy mô ở đây. Ở mọi nơi tôi đọc mọi người đang nói về chiến lược lược đồ nhiều người thuê nhưng đề cập đến hàng chục, hàng trăm hoặc hàng ngàn lược đồ. Một nơi đề cập đến lược đồ 20K. Câu hỏi là - các lược đồ 400K có quá nhiều không? Nó sẽ gây ra một mô tả tập tin điên rồ và giết chết máy chủ? Tôi đang đẩy nó à?

— Harel

Ngoài ra, tôi dự định giữ dữ liệu người thuê (tài khoản và người dùng) trong lược đồ công khai, trong khi vẫn duy trì các lược đồ như dữ liệu người dùng thực tế. Dữ liệu đó không phải và sẽ không bao giờ được chia sẻ trên các lược đồ.

— Harel

Kế thừa sẽ không giúp tôi ở đây tôi không nghĩ. Cách tiếp cận được chia sẻ sử dụng một lược đồ duy nhất với các khóa ngoại bắt buộc cho người dùng hoặc người thuê nên không có gì thu được từ việc kế thừa Tôi sợ.

— Harel

Từ bài viết này trực quan.io / từ Tôi nghĩ rằng chế độ đa lược đồ không phải là một cách tốt cho người thuê số lượng lớn. Cột tenant_id (cách cổ xưa) đến tốt hơn.

— Xiaohui Zhang