Nhiều khách hàng; một ứng dụng được lưu trữ. Bạn đang mô tả cơ sở dữ liệu nhiều người thuê.
Khi bạn xây dựng cơ sở dữ liệu nhiều người thuê, bạn cần xem xét
- truy vấn
- chi phí
- cách ly và bảo vệ dữ liệu
- bảo trì và
- khắc phục thảm họa.
Các giải pháp cho nhiều người thuê bao gồm từ một cơ sở dữ liệu cho mỗi người thuê (không chia sẻ gì) đến một hàng cho mỗi người thuê (chia sẻ mọi thứ).
"Không có gì được chia sẻ", "cơ sở dữ liệu riêng biệt" hoặc một cơ sở dữ liệu cho mỗi người thuê
- Đắt nhất cho mỗi khách hàng. (Số lượng lớn khách hàng ngụ ý số lượng lớn máy chủ.)
- Mức độ cô lập dữ liệu cao nhất.
- Việc khắc phục sau thảm họa cho một người thuê rất đơn giản và dễ hiểu.
- Bảo trì là về mặt lý thuyết khó hơn, bởi vì các thay đổi cần được thực hiện trong mọi cơ sở dữ liệu. Nhưng dbms của bạn có thể dễ dàng hỗ trợ chạy các thủ tục được lưu trữ trong mỗi cơ sở dữ liệu. (Ví dụ:SQL Server có quy trình lưu trữ hệ thống không có tài liệu, sp_msforeachdb. Bạn có thể tự viết.) "Không có gì được chia sẻ" cũng là cách dễ tùy chỉnh nhất, nhưng điều đó cũng làm nảy sinh nhiều vấn đề về bảo trì hơn.
- Số hàng trên mỗi bảng thấp nhất. Tốc độ truy vấn gần tối ưu.
"Mọi thứ được chia sẻ" hoặc "lược đồ được chia sẻ" hoặc "một cơ sở dữ liệu trên mỗi hành tinh"
- Ít tốn kém cho mỗi người thuê.
- Mức độ cô lập dữ liệu thấp nhất. Mỗi bảng có một cột xác định đối tượng thuê mà một hàng thuộc về. Vì các hàng của đối tượng thuê được trộn lẫn trong mọi bảng nên việc vô tình làm lộ dữ liệu của đối tượng thuê khác là điều tương đối đơn giản.
- Việc khắc phục sau thảm họa cho một người thuê là tương đối phức tạp; bạn phải khôi phục các hàng riêng lẻ trong nhiều bảng.
- Bảo trì cấu trúc đơn giản hơn, vì tất cả người thuê đều chia sẻ các bảng. Tuy nhiên, nó làm tăng tải thông tin liên lạc vì bạn phải giao tiếp và điều phối từng thay đổi với mọi người thuê. Nó không dễ dàng tùy chỉnh.
- Số hàng cao nhất trên mỗi bảng. Truy vấn nhanh khó hơn, nhưng nó phụ thuộc vào số lượng người thuê và bao nhiêu hàng. Bạn có thể dễ dàng chuyển sang lãnh thổ VLDB.
Giữa "không chia sẻ gì" và "mọi thứ được chia sẻ" là "lược đồ được chia sẻ".
"Lược đồ được chia sẻ"
- Người thuê chia sẻ một cơ sở dữ liệu, nhưng mỗi người thuê có một lược đồ được đặt tên riêng. Chi phí nằm giữa "không chia sẻ gì" và "mọi thứ được chia sẻ"; các hệ thống lớn thường cần ít máy chủ hơn là "không chia sẻ gì", nhiều máy chủ hơn "mọi thứ được chia sẻ".
- Cách ly tốt hơn nhiều so với "chia sẻ mọi thứ". Không hoàn toàn cô lập như "không chia sẻ gì". (Bạn có thể CẤP và THU HỒI quyền trên các lược đồ.)
- Khôi phục sau thảm họa cho một đối tượng thuê yêu cầu khôi phục một trong nhiều lược đồ. Điều này tương đối dễ hoặc khá khó, tùy thuộc vào dbms của bạn.
- Bảo trì dễ dàng hơn so với "không có gì được chia sẻ"; không dễ dàng như "chia sẻ mọi thứ". Nó tương đối đơn giản để viết một thủ tục được lưu trữ sẽ thực thi trong mỗi lược đồ trong cơ sở dữ liệu. Việc chia sẻ các bàn chung giữa những người thuê sẽ dễ dàng hơn so với "không có gì được chia sẻ".
- Thông thường, nhiều người thuê hoạt động trên mỗi máy chủ hơn là "không có gì được chia sẻ", có nghĩa là họ chia sẻ (làm suy giảm) nhiều tài nguyên hơn. Nhưng không tệ như "đã chia sẻ mọi thứ".
Microsoft có một bài viết hay về kiến trúc nhiều người thuê với nhiều chi tiết hơn. (Liên kết chỉ đến một trang của tài liệu nhiều trang.)
