Phát triển một ứng dụng đa khách hàng, chúng tôi dự định sử dụng một cơ sở dữ liệu khác nhau cho mỗi khách hàng. Nhưng nó có thể là hơn 1000 khách hàng (ứng dụng).
PostgreSQL sẽ xử lý nó mà không có vấn đề gì?
Có ai đã thử một cái gì đó tương tự?
Lưu ý: 35 bảng cho mỗi bảng, với trung bình tối đa 3000 bản ghi cho mỗi cơ sở dữ liệu.
Câu trả lời:
Tôi đã không thử bản thân mình, nhưng có những người khác xung quanh có. Ở đây bạn có thể thấy rằng thậm chí 10.000 cơ sở dữ liệu chạy mà không gặp vấn đề gì trong một trường hợp duy nhất. Bạn thậm chí có thể tìm thấy một số khía cạnh thực tế trên ServerFault .
Vì cơ sở dữ liệu của bạn khá nhỏ, bạn sẽ không gặp phải bất kỳ giới hạn số lượng tệp nào của HĐH máy chủ. Vấn đề duy nhất tôi có thể nghĩ đến là khi tất cả các cơ sở dữ liệu này sẽ được truy cập đồng thời, việc xử lý tất cả các kết nối đó sẽ rất khó khăn.
Và, như một lưu ý cuối cùng: bạn rất hoan nghênh trên trang web này. Chúng tôi hy vọng bạn sẽ ở lại với chúng tôi trong một thời gian dài.
Âm thanh như một điều lộn xộn để làm từ quan điểm quản lý. Làm thế nào để bạn có kế hoạch sao lưu nhiều cơ sở dữ liệu? với một kịch bản mà vòng lặp mặc dù mỗi một?
Trừ khi bạn có một lý do thực sự tốt, tại sao không chỉ có một cơ sở dữ liệu trong đó cấu trúc được thiết kế sao cho tất cả dữ liệu sẽ liên kết để quay lại ID khách hàng. Thêm chỉ mục / Khóa ngoại / Khóa chính dựa trên trường này sẽ đảm bảo tính toàn vẹn dữ liệu.
Sau đó, bạn chỉ cần có một mệnh đề where trong tất cả các truy vấn của mình để chỉ truy cập một ID khách hàng. Điều này sẽ đơn giản hơn nhiều để duy trì và cũng dễ phát triển (vì trong cả hai trường hợp bạn cần cho phép nhận dạng khách hàng)
search_pathnó phù hợp với bạn.
Có những người làm điều này, đặc biệt cho lưu trữ máy chủ chia sẻ.
Suy nghĩ thông qua các vấn đề ở đây không có bữa ăn trưa miễn phí. Bạn có thể có thể làm điều đó với các lược đồ theo cách minh bạch ứng dụng. Tuy nhiên, sau đó bạn có được hàng ngàn lược đồ và hàng chục nghìn bảng, điều này sẽ đặt ra các vấn đề khác.
Tôi nghĩ về tổng thể, cách tiếp cận nhiều db là rõ ràng nhất cho ý kiến của bạn.
Quản lý (như sao lưu) sẽ trở nên thú vị. Ngoài ra tôi sẽ nghĩ rằng tại một số điểm kết nối với db sẽ bắt đầu mất nhiều thời gian hơn. Nếu bạn đang sử dụng pg_hba.conf để hạn chế quyền truy cập (điều mà bạn sẽ làm) sẽ trở nên đau đầu và có lẽ bạn sẽ muốn xây dựng một giải pháp để tạo tệp đó cho bạn .....
Tôi hy vọng liên kết này tốt hơn để đọc: 10.000 cơ sở dữ liệu trên cụm PostgreSQL của Jon Jensen, 2008.
Một đoạn trích:
Câu trả lời ngắn gọn: Postgres 8.1 xử lý 10.000 cơ sở dữ liệu tốt.
\ltrong psql tạo ra một danh sách dài các cơ sở dữ liệu, tất nhiên, nhưng trả về đủ nhanh. Kiểm tra đồng thời ad-hoc là tốt. Chạy các truy vấn, chèn, v.v. trên một nhóm được lựa chọn cẩn thận của các cơ sở dữ liệu chơi khác nhau hoạt động tốt, bao gồm cả khi các cơ sở dữ liệu mới đang được tạo.[...]
Giới hạn thực tế trên nền tảng [ Linux ext3 ] này có lẽ là 31995 cơ sở dữ liệu, vì mỗi cơ sở dữ liệu chiếm một thư mục con trong dữ liệu / cơ sở / và hệ thống tệp ext3 có giới hạn 31998 thư mục con trên một thư mục, xuất phát từ giới hạn 32000 liên kết trên mỗi thư mục inode.