Posted inMySQL

Kiến trúc Multi-tenant trong MySQL: Từ kinh nghiệm ‘xương máu’ đến hệ thống SaaS nghìn user

MySQL tutorial - IT technology blog
MySQL tutorial - IT technology blog

Bài toán ‘dữ liệu của ai người nấy dùng’ trong SaaS

Hồi mình mới làm dự án SaaS đầu tiên về quản lý bán hàng, mình đã có một kỷ niệm nhớ đời. Để triển khai nhanh, mình tống toàn bộ dữ liệu của tất cả cửa hàng vào chung một database. Các bảng đều phân biệt bằng cột tenant_id.

Mọi chuyện trơn tru cho đến khi hệ thống chạm mốc 500 khách hàng. Một ngày nọ, một cộng sự trong team viết thiếu điều kiện WHERE tenant_id = ? khi chạy lệnh UPDATE giá sản phẩm. Chỉ trong 1 giây, toàn bộ đơn hàng của khách A biến thành tên khách B. Đêm đó mình phải thức trắng để restore lại 200GB dữ liệu. Bài học rút ra: Nếu không chọn đúng kiến trúc Multi-tenant từ đầu, bạn đang xây nhà trên cát.

Tại sao chúng ta phải đau đầu vì Multi-tenancy?

Trong thế giới SaaS, mỗi khách hàng là một “Tenant”. Thách thức lớn nhất không chỉ là ngăn Tenant A xem trộm dữ liệu Tenant B. Bạn còn phải cân bằng giữa ba yếu tố: bảo mật tuyệt đối, dễ bảo trì và chi phí vận hành (CPU, RAM).

Thực tế cho thấy không có một kiến trúc hoàn hảo cho mọi trường hợp. Tùy vào việc bạn đang làm app cho 10 khách hàng lớn hay 10.000 shop nhỏ mà cách tiếp cận sẽ khác hẳn nhau.

3 Phương pháp phân tách dữ liệu thực chiến trong MySQL

1. Database-per-Tenant (Mỗi khách hàng một database)

Đây là phương pháp ưu tiên tính biệt lập. Mỗi khi có khách hàng mới, hệ thống sẽ tự động thực thi lệnh CREATE DATABASE db_tenant_id.

  • Ưu điểm: Bảo mật cấp độ cao nhất. Bạn có thể backup riêng cho từng khách hàng theo yêu cầu. Nếu database của tenant A hỏng, tenant B vẫn hoạt động bình thường.
  • Nhược điểm: Ngốn tài nguyên kinh khủng. MySQL thường gặp vấn đề về quản lý bộ nhớ đệm (InnoDB Buffer Pool) và giới hạn file descriptor khi số lượng database vượt quá con số 1.000. Việc chạy migration cho 1.000 database cùng lúc cũng là một thử thách lớn về thời gian.

2. Schema-per-Tenant (Dùng chung Instance, khác Schema)

Trong MySQL, DATABASE và SCHEMA thực tế là một. Tuy nhiên, ở các hệ quản trị như PostgreSQL, chúng được tách biệt rõ ràng hơn. Với MySQL, phương pháp này thường được áp dụng bằng cách sử dụng chung một Database Instance nhưng chia nhỏ các Table Prefix hoặc chia cụm logic để quản lý.

3. Shared Database, Shared Schema (Dùng chung tất cả)

Các startup thường chọn cách này để tiết kiệm chi phí server. Mọi tenant dùng chung bộ bảng, phân biệt qua cột định danh.

CREATE TABLE orders (
    id INT AUTO_INCREMENT PRIMARY KEY,
    tenant_id INT NOT NULL,
    customer_name VARCHAR(255),
    total_amount DECIMAL(10, 2),
    INDEX (tenant_id) -- Bắt buộc phải có index để tránh full table scan
);

Lưu ý về hiệu năng: Khi bảng orders vượt ngưỡng 20-30 triệu dòng, tốc độ truy vấn sẽ giảm sút thấy rõ. Lúc này, Index đơn lẻ trên tenant_id là chưa đủ. Bạn cần các Composite Index để tối ưu hóa.

Giải pháp chống ‘quên’ điều kiện WHERE

Để tránh lỗi ngớ ngẩn như mình đã gặp, bạn có thể áp dụng hai kỹ thuật sau:

Kỹ thuật 1: Sử dụng MySQL Views

Bạn tạo một View riêng cho từng khách hàng. Code backend sẽ kết nối trực tiếp vào View thay vì bảng gốc. Cách này an toàn nhưng sẽ khiến danh sách View trong Database phình to, khó quản lý thủ công.

Kỹ thuật 2: Giả lập Row-Level Security (RLS) bằng Session Variables

Dù MySQL không có RLS xịn như Postgres, chúng ta vẫn có thể “lách” bằng cách set session variable ngay khi mở connection:

SET @current_tenant_id = 101;

Sau đó, hãy truy vấn thông qua một View chung có logic lọc tự động:

CREATE VIEW v_tenant_orders AS
SELECT * FROM orders WHERE tenant_id = @current_tenant_id;

Cách này giúp tầng code backend cực kỳ sạch sẽ. Bạn chỉ cần gọi SELECT * FROM v_tenant_orders mà không bao giờ lo lộ dữ liệu chéo.

Mẹo tối ưu khi hệ thống phình to

Khi dữ liệu lớn dần, hiện tượng “Noisy Neighbor” (một khách hàng dùng quá nhiều tài nguyên gây ảnh hưởng người khác) sẽ xuất hiện. Đây là cách mình xử lý:

  • Composite Index: Luôn ưu tiên tenant_id đứng đầu trong index phức hợp, ví dụ: (tenant_id, status, created_at).
  • Table Partitioning: Sử dụng PARTITION BY LIST(tenant_id). MySQL sẽ chỉ quét đúng phân vùng chứa dữ liệu của tenant đó, thay vì quét toàn bộ bảng 50GB.
  • Database Sharding: Khi một server đạt ngưỡng 80% CPU thường xuyên, hãy chia tenant ra các server vật lý khác nhau. Nhóm 1-500 ở Server Á, nhóm 501-1000 ở Server Âu.

Nên chọn hướng đi nào cho dự án của bạn?

Dựa trên kinh nghiệm của mình, hãy cân nhắc hai kịch bản:

  1. Chọn Shared Schema (Cách 3): Nếu bạn làm ứng dụng phổ thông, cần tối ưu chi phí và scale nhanh. Hãy dùng thêm các thư viện ORM hỗ trợ Global Scopes để tự động chèn tenant_id vào query.
  2. Chọn Database-per-Tenant (Cách 1): Nếu khách hàng là khối ngân hàng hoặc chính phủ. Họ yêu cầu dữ liệu phải nằm riêng biệt trên ổ cứng để đáp ứng các tiêu chuẩn bảo mật khắt khe.

Mình thường ưu tiên giải pháp Hybrid (Lai). Khách hàng dùng thử (Free trial) sẽ ở chung một database lớn. Những khách hàng VIP trả phí cao sẽ được “dọn nhà” sang một database riêng biệt. Cách này vừa cân bằng được chi phí, vừa giữ chân được những khách hàng quan trọng nhất.

Thiết kế database cho SaaS là một hành trình dài. Đừng đợi đến khi dữ liệu rối tung mới đi tìm giải pháp. Hy vọng những chia sẻ này giúp anh em né được những cú ‘vấp’ không đáng có!

Share:
Tags: