MySQL riêng vs SQLite theo từng tenant: chọn cách tách database cho WordPress

Chọn cách tách dữ liệu cho từng tenant là quyết định quan trọng nhất khi xây dựng hệ thống WordPress multi-tenancy. Nó quyết định trần cách ly bạn đạt được, sàn chi phí vận hành bạn phải chịu, và mức độ linh hoạt khi cần dời tenant sau này. GrabWP Tenancy Pro cho bạn ba lựa chọn database theo tenant, và đáp án đúng tuỳ vào đặc điểm của tenant chứ không theo lý thuyết. Bài viết này đi qua từng phương án: nó cách ly được gì, khi nào nên dùng, và vì sao bạn không bao giờ bị lock-in vào lựa chọn ban đầu.

Ba phương án và mức cách ly tương ứng

GrabWP Tenancy Pro hỗ trợ ba cách lưu dữ liệu tenant, sắp theo mức cách ly tăng dần.

MySQL dùng chung với prefix riêng. Tất cả tenant nằm chung một database MySQL, phân biệt bằng prefix bảng riêng. Bảng của Tenant A và Tenant B nằm cạnh nhau, chỉ khác nhau ở tên. Đây là cách ly một phần: dữ liệu tách về mặt logic nhưng vật lý vẫn chung database, chung connection pool, chung phạm vi ảnh hưởng khi có sự cố. Phương án này tốn ít chi phí nhất và là chế độ cách ly duy nhất trong plugin GrabWP Tenancy miễn phí (kèm cách ly uploads).

Database MySQL riêng cho mỗi tenant. Mỗi tenant có database MySQL của riêng mình. Đây là cách ly hoàn toàn, không có rủi ro dữ liệu lẫn sang tenant khác: query trong tenant này không thể chạm bảng của tenant kia vì chúng nằm ở database khác nhau, thường kèm credentials riêng. Bạn giữ nguyên toàn bộ tính năng MySQL: backup, replication, monitoring, tooling chuẩn đều dùng được.

SQLite theo tenant. Dữ liệu mỗi tenant nằm trong file SQLite riêng. Cũng cho cách ly hoàn toàn, không rủi ro dữ liệu chéo, nhưng không cần dựng thêm database server. Thư viện tích hợp SQLite đã đi kèm bản Pro, không cần cài thêm plugin, và tuỳ chọn Isolated SQLite luôn sẵn sàng. Tên file được hash theo tenant để đảm bảo bảo mật và tương thích, đồng thời phần xử lý lỗi SQLite sẽ tắt các thông báo HTML dài dòng, chỉ ghi log query lỗi.

Tóm lại: MySQL riêng và SQLite đều cho cách ly hoàn toàn. Prefix dùng chung đánh đổi mức cách ly để lấy chi phí vận hành thấp nhất. Phần lớn thời gian, lựa chọn thực sự của bạn là giữa hai engine cách ly hoàn toàn.

Khi nào nên chọn SQLite theo tenant

SQLite là phương án đơn giản nhất, không cần bàn thêm. Không cần cài, bảo mật, tinh chỉnh hay duy trì database server. Một tenant chỉ là một file duy nhất, nên provisioning gần như tức thì và di chuyển cực kỳ dễ: copy, clone hay archive một tenant chỉ là thao tác file, không phải dump rồi restore database. Tính năng clone tenant cũng hoạt động tốt với nguồn SQLite, nên tạo tenant mới từ tenant có sẵn vẫn nhanh và khép kín.

Hãy chọn SQLite khi:

• Tenant nhỏ hoặc ít ghi đồng thời. SQLite rất mạnh khi write không dồn dập. Với các site giới thiệu, microsite khách hàng, portfolio, hay tenant ít traffic thì SQLite thừa sức đáp ứng.
• Tính di động là ưu tiên. Mỗi tenant chỉ là một file hash duy nhất, dễ dàng chuyển giữa các server, snapshot hay bàn giao. Không có state phía database server nào đi kèm.
• Bạn muốn provisioning tối giản. Không tạo MySQL user, không tạo database, không quản lý credentials cho từng tenant. Engine đã tích hợp sẵn trong Pro, dùng được ngay.

SQLite là lựa chọn mặc định thực tế cho các hệ thống có nhiều tenant nhỏ, nơi sự đơn giản vận hành và tính di động của từng tenant quan trọng hơn throughput ghi đồng thời.

Khi nào MySQL riêng tốt hơn

MySQL riêng là lựa chọn mạnh nhất cho các tenant có traffic cao và ghi nhiều. MySQL sinh ra để xử lý concurrent connection và concurrent write, nên tenant nào có nhiều comment, thanh toán WooCommerce liên tục, xuất bản thường xuyên, hoặc đông người dùng đăng nhập cùng lúc thì nên nằm trên database MySQL riêng thay vì gói trong một file.

Hãy chọn MySQL riêng khi:

• Tenant ghi nhiều hoặc traffic cao. Concurrent write chính là lúc một database server thực sự phát huy giá trị. SQLite serialize write, MySQL thì không.
• Bạn dựa vào tooling chuẩn. Point-in-time backup, replication, read replica, slow query log, và toàn bộ hệ sinh thái monitoring, quản trị MySQL đều hoạt động ngay. Nếu đội ops của bạn đang vận hành MySQL, thêm một database riêng cho mỗi tenant sẽ khớp hoàn toàn với quy trình hiện tại.
• Bạn cần credentials và quota riêng cho từng tenant. Database riêng giúp phân quyền truy cập và kiểm soát từng tenant ở cấp server dễ dàng hơn nhiều.

Bạn vẫn được cách ly hoàn toàn như SQLite, nhưng có thêm headroom về throughput và sự trưởng thành vận hành của một database server đầy đủ. Đổi lại, bạn phải provisioning nhiều hơn: mỗi tenant cần một database và thường là credentials đi kèm.

Khi nào prefix dùng chung là đủ

Prefix dùng chung không phải là sai, mà là đánh đổi có chủ đích. Phương án này cho chi phí vận hành thấp nhất: một database, một connection, không cần provisioning gì thêm ngoài một prefix. Trong đúng bối cảnh, điều đó thực sự có giá trị.

Prefix dùng chung phù hợp khi:

• Các tenant ít rủi ro và đáng tin. Ví dụ site nội bộ, môi trường staging, hay các tenant cùng một chủ sở hữu mà ranh giới pháp lý, bảo mật giữa chúng không quá gắt.
• Bạn ưu tiên mật độ và sự đơn giản. Gom nhiều tenant nhỏ vào một database giữ footprint thấp, setup tối giản.
• Bạn đang dùng plugin miễn phí. Plugin GrabWP Tenancy bản free đi kèm prefix dùng chung và cách ly uploads, là điểm khởi đầu tốt để thử nghiệm mô hình multi-tenant trước khi nâng cấp.

Hãy nhìn nhận đúng bản chất: đây là cách ly một phần. Dữ liệu tách logic nhưng vẫn dùng chung database vật lý, nên không có mức zero cross-tenant risk như database riêng hay file SQLite. Nếu các tenant là khách hàng độc lập với yêu cầu cách ly thực sự, hãy chuyển lên engine cách ly hoàn toàn.

Bạn không bị khoá cứng: migration xuyên engine

Điều thoải mái nhất trong toàn bộ quyết định này: lựa chọn đầu tiên không phải là vĩnh viễn. GrabWP Tenancy Pro hỗ trợ migration xuyên engine, cho phép bạn restore tenant qua lại giữa các loại engine. Bạn có thể chuyển tenant giữa MySQL dùng chung, MySQL riêng và SQLite theo bất kỳ hướng nào.

Điều này thay đổi hoàn toàn mức độ quan trọng của quyết định. Khởi tạo tenant mới trên SQLite cho đơn giản, khi traffic và lượng write tăng thì migrate sang MySQL riêng. Gom những database riêng ít hoạt động về file SQLite để giảm bề mặt vận hành. Nâng tenant prefix dùng chung lên cách ly hoàn toàn khi nó tốt nghiệp giai đoạn thử nghiệm để lên production. Vì migration thực chất là restore qua engine khác, bạn chỉ đang chọn điểm xuất phát chứ không phải cam kết suốt đời.

Kết hợp với tính năng backup và clone, mỗi tenant trở thành một đơn vị di động: bạn có thể dời, snapshot, đổi chỗ ở bất cứ lúc nào nhu cầu thay đổi. Về phần backup, tham khảo bài chiến lược backup tenant cho WordPress multi-tenant. Về mô hình cách ly tổng thể không cần Multisite, xem bài cách ly site khách hàng WordPress không cần Multisite.

Khung ra quyết định

Đi theo danh sách dưới đây, dừng lại ở điều kiện đầu tiên đúng với bạn:

1. Tenant có cần cách ly hoàn toàn, zero cross-tenant risk không? Nếu không (nội bộ, tin cậy, ít rủi ro), prefix dùng chung là đủ và rẻ nhất. Nếu có, đi tiếp.
2. Tenant ghi nhiều, traffic cao, hoặc đội ops phụ thuộc vào tooling MySQL? Nếu có, dùng database MySQL riêng cho mỗi tenant. Concurrent write và tooling chuẩn chính là thế mạnh.
3. Tenant nhỏ, ít concurrent, ưu tiên đơn giản và di động? Nếu có, dùng SQLite. Không cần server, mỗi tenant một file hash, dễ dời và clone.
4. Chưa chắc, hoặc dự kiến tenant sẽ lớn dần? Bắt đầu bằng SQLite cho đơn giản, migrate sang MySQL riêng khi cần. Migration xuyên engine nghĩa là quyết định này hoàn toàn đảo ngược được.

Một pattern thực tế cho hệ thống hỗn hợp: mặc định SQLite cho nhóm long-tail các tenant nhỏ, MySQL riêng cho nhóm nhỏ tenant nặng, prefix dùng chung chỉ dành cho site nội bộ tin cậy. Vì có thể migrate giữa các engine, bạn cứ cho mỗi tenant bắt đầu đơn giản, rồi nâng lên engine mạnh hơn khi tải thực sự đòi hỏi.

Bắt đầu ngay

Plugin GrabWP Tenancy miễn phí cung cấp cách ly bằng prefix dùng chung và cách ly uploads để bạn thử nghiệm setup multi-tenant. Khi cần cách ly hoàn toàn cho từng tenant, engine MySQL hoặc SQLite riêng, và migration xuyên engine, GrabWP Tenancy Pro cho bạn dùng cả ba tuỳ chọn database với giá $9.99/tháng. Chọn đúng engine cho đúng tenant, và chuyển đổi bất cứ lúc nào nhu cầu thay đổi.