Cách tiếp cận được khuyến nghị đối với cơ sở dữ liệu nhiều người thuê trong MongoDB là gì?

Tôi đang nghĩ đến việc tạo một ứng dụng nhiều người thuê bằng MongoDB. Tôi không có bất kỳ dự đoán nào về số lượng người thuê mà tôi có, nhưng tôi muốn có thể mở rộng thành hàng nghìn người.

Tôi có thể nghĩ ra ba chiến lược:

1. Tất cả người thuê trong cùng một bộ sưu tập, sử dụng các trường dành riêng cho người thuê để bảo mật
2. 1 Bộ sưu tập cho mỗi người thuê trong một DB được chia sẻ duy nhất
3. 1 Cơ sở dữ liệu cho mỗi người thuê

Giọng nói trong đầu tôi đang gợi ý rằng tôi nên chọn phương án 2.

Suy nghĩ và hàm ý, bất cứ ai?

Tôi có cùng một vấn đề cần giải quyết và cũng đang xem xét các biến thể. Vì tôi đã có nhiều năm kinh nghiệm tạo các ứng dụng dành cho nhiều người thuê SaaS nên tôi cũng sẽ chọn tùy chọn thứ hai dựa trên kinh nghiệm trước đây của tôi với cơ sở dữ liệu quan hệ.

Trong khi thực hiện nghiên cứu của mình, tôi đã tìm thấy bài viết này trên trang web hỗ trợ mongodb (đã thêm từ khi nó không còn nữa): https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-case/multi -tenant.html

Các chàng trai đã tuyên bố tránh các tùy chọn thứ 2 bằng bất kỳ giá nào, theo tôi hiểu không phải là đặc biệt cụ thể cho mongodb. Ấn tượng của tôi là điều này có thể áp dụng cho hầu hết các dbs NoSQL mà tôi đã nghiên cứu (CoachDB, Cassandra, CouchBase Server, v.v.) do các chi tiết cụ thể của thiết kế cơ sở dữ liệu.

Các bộ sưu tập (hoặc nhóm hoặc tuy nhiên chúng gọi nó trong các DB khác nhau) không giống như các lược đồ bảo mật trong RDBMS mặc dù chúng hoạt động như một vùng chứa cho các tài liệu mà chúng vô dụng để áp dụng tách biệt đối tượng thuê. Tôi không thể tìm thấy cơ sở dữ liệu NoSQL có thể áp dụng các hạn chế bảo mật dựa trên bộ sưu tập.

Tất nhiên bạn có thể sử dụng bảo mật dựa trên vai trò mongodb để hạn chế quyền truy cập ở cấp cơ sở dữ liệu / máy chủ. ( http://docs.mongodb.org/manual/core/authorization/ )

Tôi muốn giới thiệu lựa chọn đầu tiên khi:

• Bạn có đủ thời gian và nguồn lực để giải quyết sự phức tạp của việc thiết kế, triển khai và thử nghiệm kịch bản này.
• Nếu bạn sẽ không có nhiều khác biệt về cấu trúc và chức năng trong cơ sở dữ liệu cho những người thuê khác nhau.
• Thiết kế ứng dụng của bạn sẽ cho phép người thuê chỉ thực hiện các tùy chỉnh tối thiểu trong thời gian chạy.
• Nếu bạn muốn tối ưu hóa không gian và giảm thiểu việc sử dụng tài nguyên phần cứng.
• Nếu bạn sắp có hàng nghìn người thuê.
• Nếu bạn muốn mở rộng quy mô nhanh và chi phí tốt.
• Nếu bạn KHÔNG sao lưu dữ liệu dựa trên người thuê (giữ các bản sao lưu riêng biệt cho từng người thuê). Có thể làm được điều đó ngay cả trong trường hợp này nhưng nỗ lực sẽ rất lớn.

Tôi sẽ chuyển sang biến thể 3 nếu:

• Bạn sẽ có một danh sách nhỏ những người thuê (vài trăm).
• Các chi tiết cụ thể của doanh nghiệp đòi hỏi bạn phải có khả năng hỗ trợ những khác biệt lớn trong cấu trúc cơ sở dữ liệu cho các đối tượng thuê khác nhau (ví dụ: tích hợp với hệ thống của bên thứ 3, nhập - xuất dữ liệu).
• Thiết kế ứng dụng của bạn sẽ cho phép khách hàng (người thuê) thực hiện những thay đổi đáng kể trong thời gian chạy ứng dụng (thêm mô-đun, tùy chỉnh các trường, v.v.).
• Nếu bạn có đủ tài nguyên để mở rộng quy mô với các nút phần cứng mới một cách nhanh chóng.
• Nếu bạn được yêu cầu giữ các phiên bản / bản sao lưu dữ liệu cho mỗi người thuê. Ngoài ra việc khôi phục sẽ dễ dàng.
• Có những hạn chế pháp lý / quy định buộc bạn phải giữ những người thuê khác nhau trong các cơ sở dữ liệu khác nhau (thậm chí cả trung tâm dữ liệu).
• Nếu bạn muốn sử dụng đầy đủ các tính năng bảo mật của mongodb chẳng hạn như role.
• Có sự khác biệt lớn về quy mô giữa những người thuê (bạn có nhiều người thuê nhỏ và ít người thuê rất lớn).

Nếu bạn đăng thêm thông tin chi tiết về ứng dụng của mình, có lẽ tôi có thể cho bạn lời khuyên chi tiết hơn.

Tôi đã tìm thấy một câu trả lời hay trong các bình luận trong liên kết này:

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

Về cơ bản tùy chọn số 2 có vẻ là cách tốt nhất để đi.

Trích lời bình luận của David Mytton:

Chúng tôi quyết định không có cơ sở dữ liệu cho mỗi khách hàng vì cách MongoDB phân bổ các tệp dữ liệu của nó. Mỗi cơ sở dữ liệu sử dụng bộ tệp riêng của nó:

Tệp đầu tiên cho cơ sở dữ liệu là dbname.0, sau đó là dbname.1, v.v. dbname.0 sẽ là 64MB, dbname.1 128MB, v.v., tối đa 2GB. Khi các tệp đạt đến kích thước 2GB, mỗi tệp kế tiếp cũng là 2GB.

Do đó, nếu tệp dữ liệu cuối cùng có mặt là 1GB, tệp đó có thể trống 90% nếu nó được tiếp cận gần đây.

từ sách hướng dẫn.

Khi người dùng đăng ký bản dùng thử và thực hiện, chúng tôi sẽ nhận được ngày càng nhiều cơ sở dữ liệu có kích thước ít nhất là 2GB, ngay cả khi toàn bộ tệp dữ liệu không được sử dụng. Chúng tôi nhận thấy điều này đã sử dụng một lượng lớn dung lượng ổ đĩa so với việc có một số cơ sở dữ liệu cho tất cả khách hàng nơi dung lượng đĩa có thể được sử dụng với hiệu quả tối đa.

Sharding sẽ dựa trên cơ sở mỗi bộ sưu tập làm tiêu chuẩn, điều này gây ra một vấn đề trong đó bộ sưu tập không bao giờ đạt đến kích thước tối thiểu để bắt đầu sharding, như trường hợp của khá nhiều bộ sưu tập của chúng tôi (ví dụ: bộ sưu tập chỉ lưu trữ chi tiết đăng nhập của người dùng). Tuy nhiên, chúng tôi đã yêu cầu rằng điều này cũng sẽ có thể được thực hiện trên mỗi cấp cơ sở dữ liệu. Xem http://jira.mongodb.org/browse/SHARDING-41

Không có sự đánh đổi hiệu suất khi sử dụng nhiều bộ sưu tập. Xem http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

Có một bài viết hợp lý trên MSDN về kiến ​​trúc dữ liệu nhiều bên thuê mà bạn có thể muốn tham khảo. Một số chủ đề chính được đề cập trong bài viết này:

• Cân nhắc kinh tế
• Bảo vệ
• Cân nhắc của người thuê nhà
• Quy định (pháp lý)
• Kỹ năng thiết lập mối quan tâm

Cũng đề cập đến một số mẫu cho cấu hình Phần mềm dưới dạng Dịch vụ (SaaS).

Ngoài ra, đáng để thưởng thức là một bài viết thú vị từ SQL Anywhere nhé các bạn .

Cá nhân của tôi - trừ khi bạn chắc chắn về bảo mật / sự tin tưởng được thực thi, tôi sẽ chọn tùy chọn 3 hoặc nếu các mối quan tâm về khả năng mở rộng cấm dự phòng tối thiểu cho tùy chọn 2. Điều đó nói rằng ... Tôi không chuyên nghiệp với MongoDB. Tôi khá lo lắng khi sử dụng "lược đồ" được chia sẻ - nhưng tôi sẽ vui vẻ chuyển sang các học viên có kinh nghiệm hơn.

Tôi sẽ chọn phương án 2.

Tuy nhiên, bạn có thể đặt tùy chọn dòng lệnh mongod.exe --smallfiles. Điều này có nghĩa là kích thước tệp lớn nhất của một phạm vi sẽ là 0,5 gigabyte chứ không phải 2 gigabyte. Tôi đã thử nghiệm điều này với mongo 1.42. Vì vậy phương án 3 không phải là không thể.

Theo nghiên cứu của tôi trên MongoDB. Trucos y consejos. Aplicaciones đa sắc tố. tùy chọn đó không được khuyến khích nếu bạn không biết mình có thể có bao nhiêu người thuê, nó có thể là hàng nghìn người và sẽ rất phức tạp khi nói đến sharding, hãy tưởng tượng có hàng nghìn bộ sưu tập trong một cơ sở dữ liệu duy nhất ... Vì vậy, trong trường hợp của bạn, nó được khuyến khích sử dụng tùy chọn một. Bây giờ nếu bạn sẽ có một số lượng người dùng hạn chế, nó đã khác và có, bạn có thể sử dụng tùy chọn hai như bạn nghĩ.

Trong khi cuộc thảo luận ở đây là về NoSQL và chủ yếu là MongoDB, chúng tôi tại Citus đang sử dụng PostgreSQL và xây dựng cơ sở dữ liệu đa đối tượng phân tán / phân đoạn.

Hướng dẫn trường hợp sử dụng của chúng tôi sẽ giới thiệu qua một ứng dụng mẫu, bao gồm lược đồ và các tính năng cụ thể dành cho nhiều người thuê khác nhau.

Để có thêm dữ liệu phi cấu trúc, chúng tôi sử dụng cột JSONB của PostgreSQL để lưu trữ dữ liệu đó và dữ liệu dành riêng cho đối tượng thuê.