Các DB nhiều người thuê có nhiều cơ sở dữ liệu hoặc các bảng dùng chung không?


24

Là cơ sở dữ liệu nhiều người thuê:

  • Một máy chủ DB có cơ sở dữ liệu / lược đồ (giống hệt nhau) cho mỗi khách hàng / người thuê nhà?; hoặc là
  • Máy chủ DB có cơ sở dữ liệu / lược đồ nơi khách hàng / người thuê nhà chia sẻ các bản ghi bên trong cùng một bảng?

Ví dụ, trong Tùy chọn # 1 ở trên, tôi có thể có một máy chủ MySQL tại mydb01.example.com, và, nó có thể có một customer1cơ sở dữ liệu bên trong nó. customer1Cơ sở dữ liệu này có thể có 10 bảng cung cấp năng lượng cho ứng dụng của tôi cho khách hàng cụ thể đó (Khách hàng số 1). Nó cũng có thể có một customer2cơ sở dữ liệu với chính xác 10 bảng trong đó, nhưng chỉ chứa dữ liệu cho Khách hàng số 2. Nó có thể có một customer3cơ sở dữ liệu, customer4cơ sở dữ liệu, v.v.

Trong Tùy chọn # 2 ở trên, sẽ chỉ có một cơ sở dữ liệu / lược đồ duy nhất myapp_db, một lần nữa, với 10 bảng trong đó (cùng các bảng như trên). Nhưng ở đây, dữ liệu cho tất cả các khách hàng tồn tại trong 10 bảng đó và do đó họ "chia sẻ" các bảng. Và ở lớp ứng dụng, logic và kiểm soát bảo mật mà khách hàng có quyền truy cập vào bản ghi nào trong 10 bảng đó và phải hết sức cẩn thận để đảm bảo rằng Khách hàng số 1 không bao giờ đăng nhập vào ứng dụng và xem dữ liệu của Khách hàng # 3, v.v.

Những mô hình nào trong số này tạo thành một DB "nhiều người thuê" truyền thống? Và nếu không, thì ai đó có thể cung cấp cho tôi một ví dụ (sử dụng các kịch bản được mô tả ở trên) về DB nhiều người thuê là gì không?


"Nhiều người thuê nhà" ngụ ý bảo mật mạnh mẽ - được triển khai ở đâu đó - để một người thuê không thể xem dữ liệu của người khác, không thể sửa đổi dữ liệu, không thể từ chối quyền truy cập vào nó, v.v ... Bảo mật đó phải được thực hiện bằng cách nào đó. Các tùy chọn # 1 và # 2 của OP đều hoạt động nhưng phân tích bảo mật và công việc cần thiết để thực hiện bảo mật là khác nhau. Để biết giá trị của nó, tôi đã làm việc tại một công ty khởi nghiệp triển khai nhiều hợp đồng thuê nhà thông qua tùy chọn # 2 trong đó các bảng - với các hàng thuộc nhiều người thuê - đã bị ẩn (thông qua quyền) từ tất cả người dùng cuối và bảo mật được thực hiện hoàn toàn trong các thủ tục được lưu trữ.
davidbak


1
Nếu điều này kết thúc được đóng lại như một bản sao, tôi nghĩ chúng ta nên gắn cờ để hợp nhất nó với mục tiêu bị lừa bởi vì cả hai câu hỏi đều có một số câu trả lời thực sự tốt.

Câu trả lời:


29

Mô hình nào trong số này tạo thành một DB "nhiều người thuê" truyền thống

Cả hai khái niệm này được gọi là đa thuê nhà, vì nó chỉ là một khái niệm logic "trong đó một phiên bản phần mềm duy nhất chạy trên máy chủ và phục vụ nhiều người thuê" (từ Wikipedia ). Nhưng làm thế nào bạn thực hiện khái niệm này "về thể chất" là tùy thuộc vào bạn.

Tất nhiên, ứng dụng cần một khái niệm cơ sở dữ liệu cho phép tách dữ liệu của những người thuê khác nhau và ý tưởng của nhiều bên thuê là chia sẻ một số tài nguyên máy chủ (ít nhất là phần cứng) để sử dụng tài nguyên tốt hơn và quản trị dễ dàng hơn. Vì vậy, "DB nhiều người thuê" là một hỗ trợ trực tiếp , trong đó các phần của mô hình db hoặc các bảng được chia sẻ.

Nói chính xác, có thể xây dựng một ứng dụng nhiều người thuê với một DB không phải là nhiều người thuê, cung cấp một cá thể DB riêng cho mỗi khách hàng. Tuy nhiên, điều này ngăn cấm chia sẻ bất kỳ tài nguyên DB nào trực tiếp giữa những người thuê và lớp ứng dụng phải đảm bảo kết nối đúng đối tượng thuê với cơ sở dữ liệu phù hợp.


Cảm ơn @Doc Brown (+1) nhưng sau đó, làm thế nào bạn có thể có bất kỳ cơ sở dữ liệu nào không phải là nhiều người thuê?!?
smeeb

4
@smeeb: multi-tenancy là một thuộc tính của ứng dụng được sử dụng bởi những người thuê khác nhau, không phải của cơ sở dữ liệu "đằng sau" ứng dụng. Tất nhiên, khái niệm db cần hỗ trợ nhiều hợp đồng thuê để thực hiện điều này.
Doc Brown

4
@smeeb: giả sử bạn có một bảng Người dùng với một ràng buộc rằng tên người dùng là duy nhất, bây giờ một số nhân viên của người thuê không thể sử dụng tên người dùng nữa chỉ vì một người khác làm việc tại một người thuê khác đã sử dụng nó.
RemcoGerlich

5
@smeeb: nếu cách duy nhất để phục vụ hai người thuê là cài đặt và chạy một ứng dụng hai lần, trên hai máy chủ khác nhau, với hai cơ sở dữ liệu riêng biệt, tôi nghĩ người ta sẽ không gọi đây là nhiều người thuê.
Doc Brown

1
Tôi đã đi đến một bài thuyết trình trên Azure một thời gian trước đó nói rằng MYOB chạy giải pháp đám mây của họ trên Azure và mỗi người thuê đều có DB của riêng họ (và có lẽ cả máy chủ web nữa); họ chỉ có một số công cụ tự động hóa tuyệt vời để quản lý hàng trăm trường hợp DB cần phải có. Mặt khác, tổ chức mà tôi hiện đang làm việc để điều hành hàng trăm khách hàng ra khỏi một cơ sở dữ liệu duy nhất, có khá nhiều công việc được thực hiện trong phần mềm để thực thi việc cách ly dữ liệu của khách hàng. Chúng tôi cũng đã xem xét một sự kết hợp, trong đó những khách hàng lớn nhất của chúng tôi sẽ nhận được DB của riêng họ, trong khi những người khác chia sẻ bản gốc.
David Keaveny

36

Theo Microsoft, thuật ngữ này có 3 ý nghĩa tiềm năng (một cơ sở dữ liệu cho tất cả người thuê hoặc một cơ sở dữ liệu cho mỗi người thuê).

Để sử dụng ví dụ của bạn, mỗi khách hàng sẽ là người thuê nhà riêng.

  1. Cơ sở dữ liệu cho mỗi người thuê (khách hàng)

    • Mỗi người thuê nhà được cách ly với những người khác (không có quyền truy cập ngẫu nhiên vào dữ liệu của người thuê khác)
    • Sự cô lập cũng giúp quản lý khôi phục dữ liệu cũng như đáp ứng nhu cầu lưu trữ phù hợp với nhu cầu của người thuê dễ dàng hơn.
  2. Một cơ sở dữ liệu dùng chung, lược đồ riêng.

    • Mỗi người thuê nhà có lược đồ riêng của mình và dữ liệu của họ nằm trong các bảng riêng.
    • Việc khôi phục có thể tốn nhiều thời gian hơn, vì mọi người đều ở trong cùng một cơ sở dữ liệu, bạn không thể khôi phục cơ sở dữ liệu về bản sao lưu trước đó (nó sẽ khôi phục dữ liệu của mọi người thuê nhà). Tùy chọn là khôi phục vào cơ sở dữ liệu mới và sau đó hợp nhất / sao chép dữ liệu của 1 người thuê.
  3. Một cơ sở dữ liệu dùng chung, lược đồ dùng chung.

    • Dữ liệu của mọi người thuê nhà nằm trong cùng một bảng. Nếu bạn theo dõi các đơn hàng chẳng hạn, đơn hàng của mọi người thuê sẽ được đặt trong "dbo.Order".
    • Dữ liệu của người thuê được phân tách bằng một cột trong mỗi bảng (có thể là TenantId), cho thấy chủ sở hữu của hàng.

Có những ưu và nhược điểm đối với từng loại, được giải thích rõ trong bài viết này: https://msdn.microsoft.com/en-us/l Library / aa479086.aspx

Tiền thưởng: bạn có thể coi đó là khu nhà ở (đơn giản hóa rất nhiều).

  1. Mỗi người thuê nhà có nhà riêng của mình. Họ có thể làm bất cứ điều gì họ muốn, và nếu nó bị cháy, điều đó thực sự không ảnh hưởng đến bất kỳ ai khác.

  2. Mọi người thuê nhà ở trong cùng một tòa nhà, nhưng có căn hộ riêng.

  3. Mọi người sống trong cùng một căn hộ, và tất cả những thứ được đánh dấu bằng một ghi chú dán để cho biết ai sở hữu nó.


2
Cảm ơn bạn vì câu trả lời. Bạn có thể vui lòng giải thích câu trả lời của bạn một chút. Điều đó sẽ tạo ra một câu trả lời tốt hơn.
Thomas Junk

1
ví dụ về phần thưởng của bạn thật tuyệt vời @ ims90
Aravin

3
Microsoft đã bỏ trang bạn đã liên kết từ MSDN. Máy wayback vẫn có một bản sao.
Mike Sherrill 'Nhớ lại mèo'

1
Bài viết tương tự từ MS (có thể giống như đã di chuyển): docs.microsoft.com/en-us/azure/sql-database/ Kẻ
Pierre Henry
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.