MULTI TENANT LÀ GÌ

Gần phía trên mình tham gia cải cách và phát triển một thương mại dịch vụ kiểu Multi-tenant Software as a Service nên cũng dành khá các thời gian mày mò cách kiến tạo DB mang đến nó. Theo đánh giá chủ quan tiền thì kiểu áp dụng này thời hạn tới sẽ ngày dần phổ biến. Thực tế lâu nay đã có khá nhiều phần mượt web based theo kiểu multitenancy này rồi.

Bạn đang xem: Multi tenant là gì

Để gồm cái quan sát tổng quan liêu về multi-tenant, tiếng hãy tưởng tượng bạn có một website app, bạn muốn bán nó mang lại vài doanh nghiệp khác cùng áp dụng và đóng logo của mình lên đó. Cách thiết đặt đơn giản nhất là copy thành nhiều phiên bản sao, từng ông cần sử dụng một phiên bản độc lập nhau. Cứ có người tiêu dùng mới là lại copy cả code, cà database ra rồi cài đặt riêng đến ông khách đó, bên trên 1 hay các server tùy bạn. Vấn đề nảy sinh khi chúng ta cần update hay sửa lỗi gì gì đó, bạn sẽ phải cách xử lý trên từng phiên bản sao, cho từng quý khách một. Quá trình update đó lặp đi lặp lại, càng nhiều khách thì càng buốn chán và dễ sai sót. Đến bây giờ thì chúng ta nên suy nghĩ biến áp dụng SaaS của bản thân thành dạng multi-tenant.


*

Multi-tenancy nghĩa là có nhiều tenant (khách mướn – hoàn toàn có thể là công ty, tổ chức) với tương đối nhiều user sẽ thuộc sử dụng phần mềm của bạn. Khi làm ứng dụng multi tenant, chúng ta chỉ thực hiện nó một lần chứ không hẳn là coppy ra một mớ. Chúng ta có thể update tiện ích một phát cho cả đám tenant và vấn đề triển khai thương mại dịch vụ cũng đơn giản và dễ dàng hơn. Nói tầm thường multi tenant bây giờ thành xu cầm rồi, chả kị được. Thời trước làm phần mềm ra ngừng đem sở hữu lên vật dụng của khách rồi chạy đi chạy lại bảo trì, càng lắm khách thì sẽ càng chạy nhiều. Rồi đến lúc đưa lên web, thì sao ra cho từng ông 1 virtual host hoặc server riêng, không phải chạy nhưng thống trị cũng mệt nhọc chả kém. Bây chừ làm thứ hạng multi tenant thì gồm thể chỉ cần deploy 1 lần lên 1 đám server, tuy thế làm DB, code kiếc lại thêm phức tạp.

Phức tạp là vì tất cả khách thuộc chạy thông thường server, tầm thường code, rất có thể chung cả DB. Vậy làm sao để bảo đảm an toàn cô lập dữ liệu các khách hàng với nhau? Cứ chạy riêng biệt rẽ như xưa thì dễ dàng rồi, ông nào biết ông đấy thôi! nội dung bài viết này mình sẽ reviews 3 cách thi công Database – thành phần quan trọng đặc biệt nhất – cơ mà mình nhặt nhạnh được trường đoản cú Internet. Phần này vẫn chỉ nói đến cách xây đắp DB, code sẽ được trình làng trong những bài tiếp theo.

Thiết kế cơ sở dữ liệu cho Multi-Tenant SaaS Application

Như vẫn đề cập, Database là thành phần quan trọng đặc biệt nhất trong phong cách thiết kế multi-tenant. Có 3 sự việc cần thân thiện khi thiết kế DB:

Mức độ cô lập tài liệu (tenant data isolation)Khả năng sao lưu và phục hồi từng tenantKhả năng mã hóa dữ liệu tenant

Bạn bao gồm thể lựa chọn một trong 3 giải pháp sau để gây ra DB cho vận dụng của mình.

từng tenant cần sử dụng một database riêng biệt. Dùng chung database nhưng chia cho từng tenant một schema riêng biệt hoặc table riêng rẽ (nếu DB bạn chọn không tồn tại schema).Dùng chung tất, cả database lẫn schema hay table

Giờ chúng ta sẽ bàn chi tiết từng thiết kế.

Mỗi Tenant một Database

Ưu điểm lớn nhất của bí quyết làm này là bảo đảm an toàn mức độ bình an dữ liệu cao nhất cho từng tenant. Database được cô lập tại mức tối đa, nếu cần phải có thể bỏ lên các vps khác nhau, cho nên vì vậy tenant này không thể truy vấn được dữ liệu của tenant khác.


*

Ưu điểm trang bị hai là tính linh hoạt. Thử nghĩ coi, tài liệu của doanh nghiệp chính là tài sản, bạn nắm giữ gia tài của họ. Trường hợp tenant làm sao đó ước ao bạn mã hóa tài liệu (để kiêng rò rỉ do các bạn bị tấn công hoặc bởi vì nhân viên của khách hàng lấy đi), trong những lúc người khác lại không bao gồm nhu cầu. Các bạn sẽ không tốn chi phí để mã hóa toàn bộ, chỉ việc thực hiện trên tenant cụ thể vì bọn chúng đã trả toàn tự do với nhau.

Việc tự do database cũng giúp việc sao giữ và phục hồi dữ liệu thuận tiện hơn bao giờ hết. Bạn cũng có thể backup riêng rẽ tenant db mỗi ngày thậm chí mặt hàng giờ, tùy thuộc dịch vụ theo nhóm mà người sử dụng đã mua, khi cần thì restore quá sức dễ dàng dàng.

Với chừng ấy tác dụng thì nghe có vẻ như đây là phương án ngon ăn. Tuy thế giả sử chúng ta không có khách hàng nào VIP mang đến độ phải mã hóa cùng backup sản phẩm giờ, thì việc triển khai đó lại trở cần tốn kém. Cứ mang đến là tài liệu còn bé, hoàn toàn có thể chạy tầm thường DB server, tuy nhiên nó vẫn bươi thêm quá trình quản trị, vận hành…

Nhìn chung đây là một biện pháp làm tốn kém, chỉ phù hợp nếu tập quý khách có yêu thương cầu đặc trưng và sẵn sàng chuẩn bị chịu chi. Giờ họ nói về phương án rẻ hơn nhưng mà vẫn đảm bảo một phần tính cô lập dữ liệu: mỗi Tenant một Schema riêng.

Mỗi Tenant một Schema

Cách làm này giảm đáng kể bỏ ra phí, ứng dụng của các bạn sẽ chỉ liên kết đến 1 Database duy nhất. Mỗi tenant sẽ có một schema riêng rẽ (với những table bắt buộc thiết) thay bởi dùng cả database. Với gần như DBMS không cung ứng multi schema, bạn cũng có thể triển khai bằng phương pháp đặt tên table dĩ nhiên tiền tố để phân biệt những tenant (VD: tenantA_product, tenantA_order…). Bằng cách này chúng ta có thể giảm bớt chi tiêu quản trị hoặc duy trì server.

Nhược điểm của thi công này là sự việc backup – restore. Nếu như nếu cần restore riêng rẽ 1 tenant mà DBMS không hỗ trợ restore từng schema, bạn sẽ phải restore toàn thể DB, những người khác vẫn bị ảnh hưởng bởi downtime. Cùng để tránh bài toán restore ghi đè cả DB, bạn sẽ có các việc rất cần phải làm! ví dụ như restore vào 1 DB khác, lấy tài liệu của schema đề xuất xử lý ra, rồi bưng phần này vào DB sẽ chạy. Nghe cầm chứ có tác dụng thật chưa có thể đã dễ!

Việc bóc tách schema chỉ đảm bảo an toàn được một trong những phần tính xa lánh dữ liệu người sử dụng nhưng là phương pháp rẻ hơn bóc tách database. Cá thể tôi thấy thiết kế này rất là hợp lý, thăng bằng giữa lợi ích, ngân sách chi tiêu và độ phức tạp. Bây giờ ta chuyển qua cách sản phẩm công nghệ 3: Nhồi hết vào 1 chỗ!

Dùng thông thường Schema cho toàn bộ Tenant

Nếu bạn chọn DBMS không có schema thì tất cả sẽ dùng bình thường database. Biện pháp này rất đơn giản triển khai, ít nhất là trong giai đoạn đầu của dự án, hoặc sống thời điềm mà bạn còn chưa từng nghĩ sẽ làm cho multi tenant! Vì tài liệu của toàn bộ tenant sẽ được lưu trong thuộc 1 bảng, chúng ta cũng có thể chỉ yêu cầu thêm vào 1 trường để rõ ràng tenant là đầy đủ (như tenant_id chẳng hạn).

Làm vẻ bên ngoài này cũng có cái hay. Bạn không cần thiết phải tạo schema rồi khởi tạo các table cho từng tenant, không cần lo quản lý schema nào của tenant nào, cũng chả buộc phải can thiệp gì vào database.


*

Thế còn mẫu dở của quy mô này? Giờ nếu như bạn làm ăn tốt, người tiêu dùng tăng trưởng từng ngày, dữ liệu cũng tăng theo. Khi ấy table của bạn sẽ ngày càng to ra, việc thao tác làm việc trên dữ liệu sẽ dần trở nên khó khăn và lờ lững chạp. Trớ trêu là có những tenant ít tài liệu lại chịu thông thường cảnh rùa trườn với đều thằng to. Điều này mang lại trải nghiệm không tốt ho gì. Bao gồm nhiều cách để cải thiện hiệu năng nhưng mà dù sao dòng gì cũng có thể có giới hạn của nó. Đến lúc các bạn sẽ phải tách vài ông lớn to ra chạy DB khác. Cũng ko sao, miễn là giải quyết và xử lý được vấn đề! Chỉ có điều vấn đề lọc lấy dữ liệu để tách bóc ra chưa phải một mau chóng một chiều mà kết thúc ngay được, trong khi downtime thì có hạn! Lại còn cả vụ việc backup – restore nữa.

Xem thêm: Tất Đá Bóng Xịn - Cao Cấp, Giá Cạnh Tranh, Thanh Toán Khi

Túm lại thì thiết kế nào cũng có cái hay và cái trắc trở của nó. Chúng ta nên xem xét thấu đáo từng kỹ lưỡng và đặt lên trên bàn cân để mang ra chọn lựa cho riêng rẽ mình. Theo tôi đánh giá thì phương pháp chia Schema là cân đối nhất thân mức độ an toàn, độ tinh vi khi tiến hành và giá cả vận sản phẩm database, tôi cũng đã chọn cách này mang đến vài dự án công trình của mình. Còn bạn, các bạn chọn phương án nào? Hoặc trường hợp cần đàm đạo thêm, hãy nhằm lại comment vì phần lớn điều trên chắc chắn rằng chưa đủ.

Hình hình ảnh lấy tự Internet, thấy nhiều bài bác dùng yêu cầu không biết của ai mà ghi nguồn!


ByĐiệp Liên Tú
*

Related Posts

*
*
*