Share
Multi Tenant là một giải pháp thiết kế phần mềm với chỉ một phiên bản ứng dụng nhưng vẫn có cơ sở dữ liệu phục vụ cho nhiều khách hàng cùng lúc. Dữ liệu của từng khách hàng sẽ độc lập, tách biệt với nhau.
Single Tenant vs Muti Tenant
Trong thực tế, có rất nhiều hệ thống sử dụng multi-tenancy model. Ví dụ như những hệ thống kiến trúc nhiều người thuê: Github, Hubspot, Salesforce, Slack, Jira, Office 365,…
Dễ dàng tìm ra những ưu điểm khi sử dụng Multi Tenant như sau:
Lưu trữ, quản lý đơn giản hơn;
Bảo mật hệ thống tốt hơn;
Dễ dàng nâng cấp, đồng bộ cấu trúc hơn.
Khó backup databaѕe riêng lẻ từng tenant;
Dữ liệu phình to nhanh chóng, khó khăn khi ѕcale hệ thống.
Một số vấn đề cần quan tâm khi thiết kế database:
Mức độ độc lập của dữ liệu;
Khả năng backup và sao lưu dữ liệu của từng tenant.
Tùy vào nhu cầu sử dụng chúng ta có 3 cách để triển khai cơ sở dữ liệu:
Mỗi tenant sử dụng một database riêng biệt;
Sử dụng chung database nhưng chia tách table hoặc schema cho từng tenant;
Sử dụng chung cả database và schema.
Mỗi Tenant một Database
Hệ thống sẽ có 1 database chính (lưu trữ danh sách tenant, thông tin của các tenant,...), và các database tenant có cấu trúc giống nhau.
Người dùng khách sẽ có quyền truy cập vào database tenant của họ.
Ưu điểm lớn nhất của cách làm này là đảm bảo mức độ an toàn dữ liệu cao nhất cho từng tenant. Database được hoàn toàn độc lập với nhau giữa các tenant.
Tuy nhiên đây là một cách làm tốn kém, chỉ phù hợp nếu tập khách hàng có yêu cầu đặc biệt và sẵn sàng chịu chi.
Cách thiết kế này sử dụng một cơ sở dữ liệu, mỗi Tenant tương ứng 1 Schema. Sử dụng 1 Schema chung để quản lý những thông tin chi tiết, danh sách của các Tenants. Các Tenants sẽ có cấu trúc table giống như nhau.
1 schema với cấu trúc table chuẩn để từ đó tạo ra tenant mới trong quá trình hoạt động hệ thống.
Vì chỉ sử dụng 1 Database duy nhất nên cách làm này sẽ khá tiết kiệm chi phí.
Vấn đề khôi phục, backup dữ liệu sẽ là nhược điểm của cách thiết kế này khi mà DBMS không hỗ trợ khôi phục từng schema, khi đó chúng ta sẽ phải restore toàn bộ database, những tenants không liên quan vẫn sẽ bị ảnh hưởng khi đang restore dữ liệu.
Dùng chung Database và Schema cho tất cả Tenant
Với cách làm này thì tất cả dữ liệu của tenants sẽ lưu chung trong cùng table, và sẽ chỉ phân biệt nhau thông qua cột định danh ví dụ: tenant_id. Cách này sẽ hạn chế được vấn đề khi phải đồng bộ cấu trúc bảng của hệ thống.
Tuy nhiên nó sẽ có những nhược điểm sau:
Database của các tenant sẽ không độc lập, gây nguy cơ bảo mật.
Bắt buộc phải backup, restore tất cả tenants.
Database nhanh chóng phình to, scale hệ thống sẽ gặp nhiều khó khăn.
Trên đây, Rabiloo đã giới thiệu cho các bạn về kiến trúc Multi Tenant. Tùy vào nhu cầu sử dụng của ứng dụng, và ưu nhược của các phương pháp triển khai bạn có thể cân nhắc lựa chọn ra cách triển khai phù hợp nhất với dự án của mình.
Rabiloo là công ty công nghệ có 5 năm kinh nghiệm phát triển web app. Chúng tôi đã nghiên cứu và phát triển thành công ứng dụng nhắn tin, ứng dụng đặt chỗ, ứng dụng học tiếng Anh,... tại Nhật Bản. Chúng tôi lấy việc nghiên cứu nhu cầu người dùng và ứng dụng trí tuệ nhân tạo vào sản phẩm làm sự khác biệt.
Kiến thức miền của chúng tôi không quá rộng nhưng đủ sâu về giáo dục, bán lẻ, thương mại điện tử. Nếu bạn đang kinh doanh trong nhóm lĩnh vực trên, chúng tôi tự tin có đủ kiến thức và kinh nghiệm để đồng hành cùng bạn. Nếu không, chúng tôi sẵn sàng nghiên cứu những kiến thức mới và làm tốt nhất có thể trong phạm vi năng lực.
80% dự án của chúng tôi đến từ nhóm khách hàng có tiêu chuẩn cao nhất về chất lượng trên thế giới - Nhật Bản.
Chúng tôi đã xây dựng thành công hơn 150 dự án thành công, dài hạn, cho khách hàng tại Nhật Bản, Mỹ, Châu Âu, Singapore, Việt Nam, và hơn thế nữa.
Hãy cho Rabiloo biết chúng tôi có thể đóng góp gì cho sự thành công của dự án công nghệ sắp tới của bạn. Nếu bạn vẫn chưa chắc chắn về khả năng của nhóm lập trình viên, hãy để chúng tôi chứng minh.
ĐẶT LỊCH TƯ VẤN & KIỂM TRA NĂNG LỰC MIỄN PHÍ
Share
