MultiTenant so với nhiều DBs

Question

Tôi đang phát triển một giải pháp CRM tùy chỉnh sẽ được bán thông qua mô hình Web/SaaS. Tôi dự đoán hàng chục hoặc hàng trăm khách hàng sử dụng giải pháp này. Tôi sẽ sử dụng MS SQL làm công cụ db.

Tùy chọn 1 là có một DB duy nhất và bao gồm cột TenantId trên bảng, chỉ mục phù hợp và sử dụng 'where tenantId = {...}' trên mỗi truy cập db.

Tùy chọn 2 là có một DB riêng cho từng khách hàng, tránh sự cần thiết đối với TenantId và điều khoản.

Tôi dự đoán rằng mỗi khách hàng sẽ có hàng trăm nghìn bản ghi, chứ không phải hàng triệu bản ghi.

Như tôi thấy, sẽ có tổng số trang dữ liệu tùy theo tôi chọn. Quyết định này dường như tập trung vào việc liệu SQL có tốt hơn trong việc quản lý nhiều DB, hay một DB duy nhất với TenantId và chỉ mục. Ban đầu, giải pháp sẽ chạy trên một máy chủ DB, nhưng cuối cùng sẽ chuyển sang SAN.

Có ai có bất kỳ chế độ xem nào về điều này không?

Answer 1

Có một bài viết MSDN thú vị, có tiêu đề Multi-Tenant Data Architecture, bạn có thể muốn kiểm tra. Các tác giả thực hiện một phân tích ngắn gọn về nơi một cách tiếp cận nhất định có thể thích hợp hơn nữa:

Số, thiên nhiên, và nhu cầu của các thuê bạn mong đợi để phục vụ tất cả ảnh hưởng đến bạn quyết định kiến ​​trúc dữ liệu trong cách khác nhau . Một số câu hỏi sau đây có thể thiên vị bạn theo hướng tiếp cận riêng biệt hơn , trong khi những người khác có thể bạn thiên về hướng tiếp cận được chia sẻ hơn .

• Có bao nhiêu người thuê nhà tiềm năng Bạn mong đợi để nhắm mục tiêu? Bạn có thể không ở đâu gần như có thể ước tính sử dụng tiềm năng với thẩm quyền, nhưng nghĩ về thứ tự độ lớn: bạn có đang xây dựng đơn đăng ký cho hàng trăm người thuê nhà không? Hàng ngàn? Hàng chục trong số hàng nghìn? Hơn? Bạn càng lớn, số sẽ trông chờ cơ sở người thuê nhà của bạn trở thành, nhiều khả năng bạn sẽ muốn xem xét cách tiếp cận được chia sẻ nhiều hơn.

• Bao nhiêu dung lượng lưu trữ bạn có mong đợi dữ liệu của người thuê nhà trung bình để chiếm không? Nếu bạn mong đợi một số hoặc tất cả người thuê để lưu trữ lượng dữ liệu rất lớn, thì phương pháp tiếp cận cơ sở dữ liệu riêng biệt có thể là . (Thật vậy, yêu cầu lưu trữ dữ liệu có thể buộc bạn phải áp dụng một mô hình cơ sở dữ liệu riêng lẻ . Nếu vậy, sẽ dễ dàng hơn nhiều để thiết kế ứng dụng theo cách đó từ bắt đầu để chuyển sang phương thức cơ sở dữ liệu riêng lẻ sau này.)

• Có bao nhiêu người dùng cuối đồng thời bạn có mong đợi người thuê nhà trung bình hỗ trợ? Số càng lớn, càng có nhiều thích hợp cách tiếp cận riêng biệt hơn sẽ đáp ứng các yêu cầu của người dùng cuối.

• Bạn có mong đợi để cung cấp bất kỳ mỗi người thuê nhà giá trị gia tăng dịch vụ, chẳng hạn như sao lưu mỗi người thuê nhà và khôi phục khả năng? Các dịch vụ như vậy dễ dàng hơn để cung cấp thông qua cách tiếp cận bị cô lập hơn.

Lưu ý rằng "cách tiếp cận chia sẻ" là tùy chọn 1, và "cách tiếp cận riêng biệt" là phương án 2, trong trường hợp của bạn. Bạn không thiên vị ở hai bên khi nói đến hai điểm đầu tiên, vì vậy tôi nghĩ rằng tôi sẽ căn cứ quyết định của tôi về hai điểm cuối cùng.

Answer 2

Nếu bạn không phải liên kết dữ liệu giữa những người thuê nhà, bạn nên sử dụng nhiều cơ sở dữ liệu. Bảo trì dễ dàng hơn, thiết lập dễ dàng hơn và hiệu suất sẽ tốt hơn nhiều. Khi có dữ liệu từ nhiều người thuê trong một bảng, các khóa bảng và truy vấn tìm kiếm trên các bảng lớn có thể và rất có thể sẽ làm chậm giải pháp của bạn.

Lý do duy nhất để chia sẻ một db tôi sẽ thấy nếu bạn có rất nhiều khách hàng và số lượng rất thấp các hàng cho mỗi khách hàng.