Làm thế nào để tạo một cơ sở dữ liệu nhiều người thuê với các cấu trúc bảng được chia sẻ?

Phần mềm của chúng tôi hiện đang chạy trên MySQL. Dữ liệu của tất cả người thuê được lưu trữ trong cùng một lược đồ. Vì chúng tôi đang sử dụng Ruby on Rails, chúng tôi có thể dễ dàng xác định dữ liệu nào thuộc về người thuê. Tuy nhiên, có một số công ty tất nhiên sợ rằng dữ liệu của họ có thể bị xâm phạm, vì vậy chúng tôi đang đánh giá các giải pháp khác.

Cho đến nay tôi đã thấy ba lựa chọn:

• Đa cơ sở dữ liệu (mỗi người thuê đều có riêng - gần 1 máy chủ cho mỗi khách hàng)
• Multi-Schema (không có sẵn trong MySQL, mỗi người thuê có lược đồ riêng trong cơ sở dữ liệu dùng chung)
• Lược đồ được chia sẻ (cách tiếp cận hiện tại của chúng tôi, có thể với hồ sơ nhận dạng bổ sung trên mỗi cột)

Multi-Schema là yêu thích của tôi (xem xét chi phí). Tuy nhiên, việc tạo một tài khoản mới và thực hiện di chuyển có vẻ khá khó khăn, vì tôi sẽ phải lặp lại tất cả các lược đồ và thay đổi bảng / cột / định nghĩa của chúng.

Q: Multi-Schema dường như được thiết kế để có các bảng hơi khác nhau cho mỗi người thuê - tôi không muốn điều này. Có RDBMS nào cho phép tôi sử dụng giải pháp nhiều đối tượng thuê nhiều lược đồ, trong đó cấu trúc bảng được chia sẻ giữa tất cả các đối tượng thuê không?

PS By multi Tôi có nghĩa là một cái gì đó như siêu đa (10.000 khách thuê).

Tuy nhiên, có một số công ty tất nhiên sợ rằng dữ liệu của họ có thể bị xâm phạm, vì vậy chúng tôi đang đánh giá các giải pháp khác.

Điều này thật đáng tiếc, vì đôi khi khách hàng phải chịu một quan niệm sai lầm rằng chỉ có sự cô lập vật lý mới có thể cung cấp đủ bảo mật.

Có một bài viết MSDN thú vị, có tiêu đề Kiến trúc dữ liệu nhiều người thuê , mà bạn có thể muốn kiểm tra. Đây là cách các tác giả giải quyết quan niệm sai lầm về phương pháp chia sẻ:

Một quan niệm sai lầm phổ biến cho rằng chỉ có sự cô lập vật lý mới có thể cung cấp một mức độ bảo mật thích hợp. Trên thực tế, dữ liệu được lưu trữ bằng cách sử dụng phương pháp chia sẻ cũng có thể cung cấp sự an toàn dữ liệu mạnh mẽ, nhưng yêu cầu sử dụng các mẫu thiết kế tinh vi hơn.

Đối với các cân nhắc về kỹ thuật và kinh doanh, bài viết đưa ra một phân tích ngắn gọn về nơi mà một cách tiếp cận nhất định có thể phù hợp hơn so với phương pháp khác:

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

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

• Bạn mong đợi bao nhiêu dung lượng lưu trữ để chiếm dữ liệu của người thuê trung bình? 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, phương pháp cơ sở dữ liệu riêng biệt có lẽ là tốt nhất. (Thật vậy, các yêu cầu lưu trữ dữ liệu có thể buộc bạn phải áp dụng mô hình cơ sở dữ liệu riêng biệt. Nếu vậy, việc thiết kế ứng dụng theo cách đó ngay từ đầu sẽ dễ dàng hơn nhiều so với việc chuyển sang cách tiếp cận cơ sở dữ liệu riêng biệt sau này.)

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

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

CẬP NHẬT: Tiếp tục cập nhật về số lượng khách thuê dự kiến.

Số lượng khách thuê dự kiến ​​(10k) nên loại trừ cách tiếp cận đa cơ sở dữ liệu, trong hầu hết, nếu không phải tất cả các kịch bản. Tôi không nghĩ bạn sẽ thích ý tưởng duy trì 10.000 trường hợp cơ sở dữ liệu và phải tạo ra hàng trăm cái mới mỗi ngày.

Từ tham số đó, có vẻ như cách tiếp cận cơ sở dữ liệu dùng chung, lược đồ đơn là phù hợp nhất. Thực tế là bạn sẽ lưu trữ chỉ khoảng 50Mb mỗi người thuê và sẽ không có tiện ích bổ sung cho mỗi người thuê, làm cho phương pháp này thậm chí còn phù hợp hơn.

Bài báo MSDN được trích dẫn ở trên có đề cập đến ba mẫu bảo mật giải quyết các cân nhắc về bảo mật cho phương pháp cơ sở dữ liệu dùng chung:

• Kết nối cơ sở dữ liệu đáng tin cậy
• Bộ lọc đối tượng thuê
• Mã hóa dữ liệu người thuê

Khi bạn tự tin với các biện pháp an toàn dữ liệu của ứng dụng của mình, bạn sẽ có thể cung cấp cho khách hàng của mình một Cấp độ dịch vụ cung cấp đảm bảo an toàn dữ liệu mạnh mẽ. Trong SLA của bạn, ngoài các bảo đảm, bạn cũng có thể mô tả các biện pháp mà bạn sẽ thực hiện để đảm bảo dữ liệu không bị xâm phạm.

CẬP NHẬT 2: Rõ ràng các anh chàng Microsoft đã chuyển / tạo một bài viết mới về chủ đề này, liên kết ban đầu đã biến mất và đây là một bài mới: Các mẫu thuê cơ sở dữ liệu SaaS nhiều người thuê (kudos cho Shai Kerer)

Kinh nghiệm của tôi (mặc dù SQL Server) là đa cơ sở dữ liệu là con đường để đi, nơi mỗi khách hàng có cơ sở dữ liệu riêng. Vì vậy, mặc dù tôi không có kinh nghiệm myQuery hoặc Ruby On Rails, tôi hy vọng đầu vào của tôi có thể thêm một số giá trị.

Những lý do tại sao bao gồm:

1. bảo mật dữ liệu / khắc phục thảm họa. Mỗi dữ liệu của các công ty được lưu trữ hoàn toàn tách biệt với các dữ liệu khác làm giảm nguy cơ dữ liệu bị xâm phạm (suy nghĩ những điều như nếu bạn giới thiệu một lỗi mã có nghĩa là một cái gì đó nhìn nhầm vào dữ liệu khách hàng khác khi không nên), giảm thiểu khả năng mất cho một khách hàng nếu một cơ sở dữ liệu cụ thể bị hỏng, vv Các lợi ích bảo mật nhận được cho khách hàng thậm chí còn lớn hơn (thêm hiệu ứng phụ tiền thưởng!)
2. khả năng mở rộng. Về cơ bản, bạn sẽ phân vùng dữ liệu của mình để cho phép khả năng mở rộng lớn hơn - ví dụ: cơ sở dữ liệu có thể được đưa vào các đĩa khác nhau, bạn có thể mang nhiều máy chủ cơ sở dữ liệu trực tuyến và di chuyển cơ sở dữ liệu xung quanh dễ dàng hơn để truyền tải.
3. điều chỉnh hiệu suất. Giả sử bạn có một khách hàng rất lớn và một khách hàng rất nhỏ. Mô hình sử dụng, khối lượng dữ liệu, vv có thể thay đổi dữ dội. Bạn có thể điều chỉnh / tối ưu hóa dễ dàng hơn cho mỗi khách hàng nếu bạn cần.

Tôi hy vọng điều này không cung cấp một số đầu vào hữu ích! Có nhiều lý do hơn, nhưng tâm trí tôi trống rỗng. Nếu nó khởi động lại, tôi sẽ cập nhật :)

EDIT:
Vì tôi đã đăng câu trả lời này, giờ đây rõ ràng là chúng tôi đang nói hơn 10.000 người thuê nhà. Kinh nghiệm của tôi là ở hàng trăm cơ sở dữ liệu quy mô lớn - Tôi không nghĩ 10.000 cơ sở dữ liệu riêng biệt sẽ quá dễ quản lý đối với kịch bản của bạn, vì vậy hiện tại tôi không ủng hộ cách tiếp cận đa db cho kịch bản của bạn. Đặc biệt là giờ đây rõ ràng bạn đang nói về khối lượng dữ liệu nhỏ cho mỗi người thuê!

Giữ câu trả lời của tôi ở đây vì dù sao nó cũng có thể được sử dụng cho những người khác trong một chiếc thuyền tương tự (với ít người thuê hơn)

Dưới đây là một liên kết đến một trang giấy trắng trên Salesforce.com về cách họ triển khai nhiều hợp đồng thuê nhà:

http://www.developerforce.com/media/ForcedotcomBookL Library / Force.com_Multitenancy_WP_101508.pdf

Họ có 1 bảng khổng lồ với 500 cột chuỗi (Value0, Value1, ... Value500). Ngày và số được lưu trữ dưới dạng chuỗi trong một định dạng sao cho chúng có thể được chuyển đổi thành các kiểu gốc ở cấp cơ sở dữ liệu. Có các bảng dữ liệu meta xác định hình dạng của mô hình dữ liệu có thể là duy nhất cho mỗi đối tượng thuê. Có các bảng bổ sung để lập chỉ mục, mối quan hệ, giá trị duy nhất, v.v.

Tại sao rắc rối?

Mỗi người thuê có thể tùy chỉnh lược đồ dữ liệu của riêng họ trong thời gian chạy mà không phải thực hiện thay đổi ở cấp cơ sở dữ liệu (bảng thay đổi, v.v.). Đây chắc chắn là cách khó để làm một cái gì đó như thế này nhưng rất linh hoạt.

Như bạn đề cập, một cơ sở dữ liệu cho mỗi người thuê là một tùy chọn và có một số sự đánh đổi lớn hơn với nó. Nó có thể hoạt động tốt ở quy mô nhỏ hơn, chẳng hạn như một chữ số hoặc 10 người thuê thấp, nhưng ngoài ra nó trở nên khó quản lý hơn. Cả hai chỉ di chuyển nhưng cũng chỉ trong việc giữ cho cơ sở dữ liệu và chạy.

Mô hình mỗi lược đồ không chỉ hữu ích cho các lược đồ duy nhất cho mỗi lược đồ, mặc dù việc chạy di chuyển trên tất cả các đối tượng thuê trở nên khó khăn và tại 1000 lược đồ Postgres có thể bắt đầu gặp rắc rối.

Một cách tiếp cận có khả năng mở rộng hơn là hoàn toàn có người thuê được phân phối ngẫu nhiên, được lưu trữ trong cùng một cơ sở dữ liệu, nhưng trên các phân đoạn logic (hoặc bảng ) khác nhau. Tùy thuộc vào ngôn ngữ của bạn, có một số thư viện có thể giúp với điều này. Nếu bạn đang sử dụng Rails, có một thư viện để thực hiện hợp đồng thuê nhà acts_as_tenant, điều đó giúp đảm bảo các truy vấn của người thuê nhà của bạn chỉ lấy lại dữ liệu đó. Ngoài ra còn có một viên ngọc apartment- mặc dù nó sử dụng mô hình lược đồ nhưng nó giúp ích cho việc di chuyển trên tất cả các lược đồ. Nếu bạn đang sử dụng Django, có một số nhưng một trong những cái phổ biến hơn dường như nằm trên các lược đồ . Tất cả những điều này giúp nhiều hơn ở cấp ứng dụng. Nếu bạn đang tìm kiếm một cái gì đó nhiều hơn ở cấp cơ sở dữ liệu trực tiếp, Citus tập trung vào việc tạo ra loại shending này chonhiều người thuê làm việc nhiều hơn với Postgres.