Xử lý số lượng người thuê ngày càng tăng trong Kiến trúc cơ sở dữ liệu nhiều người thuê

Xử lý một số lượng khách hàng (người thuê nhà) khiêm tốn trong một máy chủ chung có cơ sở dữ liệu riêng cho từng đối tượng của ứng dụng là tương đối đơn giản và thường là cách chính xác để thực hiện việc này. Hiện tại tôi đang xem xét kiến ​​trúc cho một ứng dụng trong đó mỗi người thuê có thể hiện cơ sở dữ liệu riêng của họ.

Tuy nhiên, vấn đề là ứng dụng này sẽ có số lượng lớn người thuê (5.000-10.000) với số lượng người dùng đáng kể, có thể là 2.000 cho một người thuê. Chúng tôi sẽ cần hỗ trợ phát triển hệ thống bởi nhiều người thuê mỗi tuần.

Ngoài ra, tất cả người thuê và người dùng của họ sẽ được cung cấp một quy trình đăng nhập chung (tức là mỗi người thuê không thể có URL riêng). Để làm điều này, tôi cần một quy trình đăng nhập tập trung và một phương tiện để tự động thêm cơ sở dữ liệu vào hệ thống và đăng ký người dùng.

• Làm thế nào quá trình đăng ký và tạo cơ sở dữ liệu có thể được tự động hóa mạnh mẽ?

• Là quá trình tạo và đăng ký cơ sở dữ liệu của người thuê trên hệ thống có thể gây ra các vấn đề về hiệu suất hoặc khóa. Nếu bạn nghĩ rằng đây có thể là một vấn đề, bất cứ ai cũng có thể đề xuất các cách để giảm thiểu nó?

• Làm cách nào tôi có thể quản lý xác thực trung tâm theo cách thông tin đăng nhập của người dùng sẽ được liên kết với cơ sở dữ liệu của một người thuê cụ thể nhưng người dùng có thể đăng nhập thông qua một trang chung (tức là tất cả thông qua cùng một URL đăng nhập, nhưng ứng dụng gia đình của họ sẽ nằm trên cơ sở dữ liệu của một số người thuê cụ thể ). Người thuê sẽ phải có khả năng duy trì thông tin đăng nhập và quyền của riêng họ, nhưng một hệ thống đăng nhập trung tâm phải nhận thức được những điều này. Bất cứ ai có thể đề nghị một cách để làm điều này?

• Nếu tôi cần 'mở rộng quy mô' bằng cách thêm nhiều máy chủ cơ sở dữ liệu, bất kỳ ai cũng có thể đề xuất những vấn đề tôi có thể phải giải quyết trong việc quản lý danh tính người dùng trên các máy chủ (mạo danh, v.v.) và một số cách để giảm thiểu những vấn đề đó?

Ở cấp thấp hơn (500 người thuê / 10000 người dùng) đây là cách tôi đã làm. Đầu tiên, bạn có cơ sở dữ liệu "kiểm soát" toàn cầu, trung tâm và chứa tất cả thông tin về người thuê và người dùng (Tôi thực sự không nghĩ rằng bạn muốn quản lý chúng dưới dạng thông tin đăng nhập SQL). Vì vậy, hãy tưởng tượng một cơ sở dữ liệu gọi là "Điều khiển" với các bảng sau:

CREATE TABLE dbo.Instances
(
  InstanceID INT PRIMARY KEY,
  Connection VARCHAR(255)
  --, ...
);

INSERT dbo.Instances SELECT 1, 'PROD1\Instance1';
INSERT dbo.Instances SELECT 1, 'PROD2\Instance1';
-- ...

CREATE TABLE dbo.Tenants
(
  TenantID INT PRIMARY KEY,
  Name NVARCHAR(255) NOT NULL UNIQUE,
  InstanceID INT -- Foreign key tells which instance this tenant's DB is on
  --, ...
);

INSERT dbo.Tenants SELECT 1, 'MyTenant', 1;
-- ...

CREATE TABLE dbo.Users
(
  UserID INT PRIMARY KEY,
  Username VARCHAR(320) NOT NULL UNIQUE,
  PasswordHash VARBINARY(64), -- because you never store plain text, right?
  TenantID INT -- foreign key
  --, ...
);

INSERT dbo.Users SELECT 1, 'foo@bar.com', 0x43..., 1;

Trong trường hợp của chúng tôi khi chúng tôi thêm một người thuê mới, chúng tôi sẽ xây dựng cơ sở dữ liệu một cách linh hoạt, nhưng không phải khi người dùng quản trị viên nhấp vào OK trong giao diện người dùng ... chúng tôi đã có một công việc nền tảng kéo cơ sở dữ liệu mới ra khỏi hàng đợi cứ sau 5 phút, đặt mô hình thành một người dùng và sau đó tạo từng cơ sở dữ liệu mới. Chúng tôi đã làm điều này để (a) ngăn người dùng quản trị viên chờ tạo cơ sở dữ liệu và (b) để tránh hai người dùng quản trị viên cố gắng tạo cơ sở dữ liệu cùng một lúc hoặc bị từ chối khả năng khóa mô hình (bắt buộc khi tạo cơ sở dữ liệu mới ).

Cơ sở dữ liệu được tạo ra với sơ đồ tên Tenant000000xxnơi xxđại diện Tenants.TenantID. Điều này làm công việc bảo trì khá dễ dàng, thay vì phải tất cả các loại cơ sở dữ liệu tên BurgerKing, McDonalds, KFCvv Không phải là chúng ta đang ở trong thức ăn nhanh, chỉ cần sử dụng đó như một ví dụ.

Lý do chúng tôi không phân bổ trước hàng ngàn cơ sở dữ liệu như nhận xét đề xuất là vì người dùng quản trị viên của chúng tôi thường có ý tưởng về việc người thuê sẽ trở nên lớn như thế nào, liệu họ có ưu tiên cao hay không, v.v. sẽ ra lệnh cho các cài đặt kích thước và tự động ban đầu của chúng, mà hệ thống con tệp dữ liệu / nhật ký của chúng sẽ đi đến, cài đặt khôi phục, lịch sao lưu để tránh bản lề và thậm chí thông báo về trường hợp nào sẽ triển khai cơ sở dữ liệu để cân bằng tốt nhất việc sử dụng ( mặc dù quản trị viên của chúng tôi có thể ghi đè lên điều này). Khi cơ sở dữ liệu được tạo, bảng đối tượng thuê được cập nhật với phiên bản đã chọn, người dùng quản trị viên đã được tạo cho người thuê và quản trị viên của chúng tôi đã gửi email thông tin đăng nhập cho người thuê mới.

Nếu bạn đang sử dụng một điểm nhập cảnh duy nhất, việc cho phép nhiều người thuê có người dùng có cùng tên người dùng là không khả thi. Chúng tôi đã chọn sử dụng địa chỉ email, trong đó - nếu tất cả người dùng làm việc cho công ty và sử dụng địa chỉ email công ty của họ - sẽ ổn. Mặc dù giải pháp của chúng tôi cuối cùng đã trở nên phức tạp hơn vì hai lý do:

1. Chúng tôi đã có các chuyên gia tư vấn làm việc cho nhiều khách hàng của chúng tôi và cần quyền truy cập vào nhiều
2. Chúng tôi có những người thuê nhà mà bản thân họ thực sự bao gồm nhiều người thuê

Vì vậy, chúng tôi đã kết thúc với một TenantUsersbảng cho phép một người dùng được liên kết với nhiều người thuê.

Ban đầu khi người dùng đăng nhập, ứng dụng sẽ chỉ biết chuỗi kết nối cho cơ sở dữ liệu điều khiển. Khi đăng nhập thành công, sau đó nó có thể xây dựng chuỗi kết nối dựa trên thông tin tìm thấy. Ví dụ

SELECT i.Connection
  FROM dbo.Instances AS i
  INNER JOIN dbo.Tenants AS t
  ON i.InstanceID = t.InstanceID
  INNER JOIN dbo.TenantUsers AS u
  ON i.TenantID = u.TenantID
  WHERE u.UserID = @UserID;

Bây giờ ứng dụng có thể kết nối với cơ sở dữ liệu của người dùng (mỗi người dùng có một người thuê mặc định ) hoặc người dùng có thể chọn từ bất kỳ người thuê nào họ có thể truy cập. Sau đó, ứng dụng sẽ chỉ cần truy xuất chuỗi kết nối mới và chuyển hướng đến trang chủ cho người thuê đó.

Nếu bạn vào khu vực người dùng 10MM này mà bạn đề xuất, bạn chắc chắn sẽ cần điều này để được cân bằng tốt hơn. Bạn có thể muốn liên kết ứng dụng để chúng có các điểm nhập khác nhau kết nối với các cơ sở dữ liệu điều khiển khác nhau. Nếu bạn cung cấp cho mỗi người thuê một tên miền phụ (ví dụ TenantName.YourApplicationDomain.com) thì bạn có thể thực hiện việc này đằng sau hậu trường bằng DNS / định tuyến mà không làm gián đoạn họ khi bạn cần mở rộng thêm.

Còn nhiều điều nữa - như @Darin tôi chỉ đang gãi trên bề mặt ở đây. Hãy cho tôi biết nếu bạn cần tư vấn không miễn phí. :-)

Bạn có cho mình một dự án khá thú vị. Tôi chưa bao giờ thấy trực tiếp bất cứ ai cố gắng thực hiện một cái gì đó lớn như vậy, ít nhất là trên SQL Server. Càng đọc bài viết của bạn, tôi càng có nhiều câu hỏi ...

Trường hợp xấu nhất là cơ sở hạ tầng khôn ngoan (thực sự là kịch bản trường hợp tốt nhất, khôn ngoan về kinh doanh), bạn cần 10 nghìn cơ sở dữ liệu gấp 2 lần người dùng. Đó là 20.000.000 người dùng. Bạn sẽ không thành công khi cố gắng quản lý thông tin đăng nhập SQL M 20 M. IMO. Chỉ là số lượng lớn trong số họ, xử lý việc chuyển chúng từ máy chủ này sang máy chủ khác, xem ra các xung đột ID và ID không khớp, cộng với tôi không chắc chắn SQL Server sẽ hành xử như thế nào với 20 M hàng trong sys.server_principals. Ngoài ra, ứng dụng web của bạn có thể sẽ muốn kết nối dưới dạng một hoặc rất ít người dùng. IIS không thể gộp các kết nối trừ khi các chuỗi DSN của chúng giống hệt nhau. Một trong những thuộc tính của chuỗi DSN là tên người dùng. Người dùng khác nhau có nghĩa là không gộp.

Bạn sẽ cần phải cuộn sơ đồ thông tin người dùng của riêng bạn. Nó sẽ phải có khả năng tìm ra người thuê thuộc về ai và sau đó mã web của bạn sẽ cần phải chọn cơ sở dữ liệu phù hợp. Siêu dữ liệu người dùng đó rất quan trọng, nó sẽ cần được lưu trữ ở đâu đó, nó sẽ cần được phân cụm hoặc nhân đôi, nó sẽ cần phải nhanh và nó sẽ cần được bảo vệ tốt (từ góc độ bảo mật. IOW, mã hóa nó.). Giả sử rằng SQL thậm chí là một ý tưởng tốt ở đây, tôi sẽ để cơ sở dữ liệu này tránh xa các trường hợp mà người thuê máy chủ. Điều này giúp từ quan điểm bảo mật và từ quan điểm tải, mặc dù tôi đoán rằng một khi người dùng được xác thực và ứng dụng web được dẫn đến cơ sở dữ liệu chính xác trong một trường hợp khác, sẽ không có thêm truy vấn nào về siêu dữ liệu người dùng này liên quan đến điều đó người sử dụng.

Câu hỏi nhanh: hai người dùng khác nhau, thuộc hai người thuê khác nhau, có được phép có cùng tên người dùng không?

Một câu hỏi nhanh khác: Nếu tôi nói với bạn rằng tôi làm việc cho FuBar, Inc., làm sao bạn biết điều đó? FuBar sẽ cung cấp cho bạn một danh sách người dùng và bạn cung cấp cho họ một danh sách tên người dùng, hoặc họ sẽ tự cung cấp?

Bạn sẽ cần phải đi nhiều trường hợp. Nếu thậm chí một phần trong số những người dùng đó quyết định truy cập ứng dụng cùng một lúc, một trường hợp duy nhất sẽ tan chảy. Nó sẽ không có đủ luồng công nhân để chạy tất cả các yêu cầu đó cùng một lúc. Nếu chỉ có 1000 người dùng truy cập vào cá thể của bạn cùng một lúc, nó có thể sẽ hết các luồng công nhân và yêu cầu sẽ bắt đầu xếp chồng lên nhau và chờ đợi. Tôi đã thấy điều này xảy ra; triệu chứng gần đúng là các kết nối mới sẽ không thể đăng nhập vào thể hiện vì không có các luồng công nhân có sẵn để phục vụ chúng. Nếu đây là hành vi rất ngắn, ứng dụng của bạn có thể tồn tại. Nếu không, hoặc ứng dụng của bạn cầu kỳ, người dùng sẽ gặp lỗi.

Ngay cả khi bạn sẽ không có nhiều người thuê để bắt đầu, bạn nên bắt đầu nghĩ về tương lai và tự động hóa bởi vì khi bạn thấy rằng máy chủ của bạn bị sa lầy và có 10 người thuê mới để đưa trực tuyến, thì đã quá muộn và dịch vụ của bạn (và khách hàng của bạn và khách hàng sắp trở thành khách hàng cũ của bạn) sẽ phải chịu đựng cho đến khi bạn viết ra khỏi vấn đề.

Bạn sẽ cần một cách để di chuyển cơ sở dữ liệu xung quanh, từ các máy chủ quá tải đến các máy chủ được tải nhẹ (hoặc mới). Việc bạn có thể có được một cửa sổ thời gian chết hay không sẽ phụ thuộc vào SLA của bạn.

Bạn đang cung cấp một ứng dụng cụ thể, như SalesForce, hay những cơ sở dữ liệu này chỉ là nơi chứa bất cứ thứ gì mà người thuê của bạn muốn đưa vào?

Cơ sở dữ liệu lớn như thế nào? Nếu chúng không lớn, bạn có thể khôi phục từ tệp sao lưu cung cấp mẫu. (Điều này không khác nhiều so với những gì cơ sở dữ liệu mô hình làm, nhưng tôi chưa thấy ai thực sự sử dụng mô hình theo cách tốt kể từ thời của tôi với SQL 6.5.) Một khi mẫu đã được khôi phục thành tên cơ sở dữ liệu mới, bạn có thể sau đó tùy chỉnh cơ sở dữ liệu mới khi cần thiết cho một người thuê cụ thể. Bạn không thể thực hiện các tùy chỉnh trước khi bạn có người thuê, rõ ràng. Nếu cơ sở dữ liệu lớn, bạn có thể thực hiện theo quy trình cơ bản tương tự ngoại trừ bạn thực hiện khôi phục trước thời hạn, trước khi bất kỳ người thuê mới nào cần không gian. Bạn có thể giữ một vài trong số các cơ sở dữ liệu này, có thể là một ví dụ. Nếu bạn giữ quá nhiều, điều này sẽ buộc bạn có thể mua nhiều phần cứng và / hoặc lưu trữ hơn mức bạn cần,

Nếu đây là ứng dụng của riêng bạn, bạn sẽ xử lý các bản cập nhật cho các lược đồ như thế nào? Làm thế nào bạn sẽ giữ các phiên bản của cơ sở dữ liệu thẳng với các phiên bản của mã, nếu bạn đang sử dụng một URL duy nhất vào ứng dụng web của bạn?

Làm thế nào để bạn phát hiện và phá hủy cơ sở dữ liệu không còn sử dụng nữa? Bạn có đợi cho đến khi nhóm A / R của bạn nói rằng ai đó đã không thanh toán hóa đơn của họ trong ba tháng không?

Nếu người thuê đang quản lý quyền, điều đó có nghĩa là họ có một số hiểu biết về hoạt động bên trong của ứng dụng hoặc ứng dụng của bạn có cấu trúc vai trò rất đơn giản. Sử dụng một cái gì đó như Blogger làm ví dụ sơ bộ, người dùng có thể (đọc bài đăng), (đọc bài đăng và đưa ra nhận xét), (... và tạo bài đăng), (... và chỉnh sửa bài đăng của người khác), (... và có thể đặt lại mật khẩu người dùng khác), hoặc (... và bất cứ điều gì). Có một vai trò cho mỗi nhóm quyền khác nhau và gán người dùng cho vai trò này hoặc vai trò khác không quá khó, nhưng bạn không muốn ứng dụng của mình chạy các câu lệnh 'GRANT'. Coi chừng các vai trò có thứ bậc và phụ thuộc vào sự kế thừa, nó có thể gây nhầm lẫn. Nếu bạn đang quảng cáo hoặc hạ cấp người dùng, tôi muốn nói rằng hãy kéo họ ra khỏi tất cả các vai trò liên quan và sau đó thêm họ trở lại với một vai trò mà họ cần. Oh,

Tôi nghĩ rằng tôi chỉ bị trầy xước bề mặt ở đây, và bài đăng này đã quá dài. Những gì bạn thực sự cần là một cuốn sách, hoặc ít nhất là một whitepaper từ một người đã làm điều này. Hầu hết những kẻ đó sẽ không nói chuyện, nếu họ coi đó là một lợi thế cạnh tranh.