ในยุคของ Software as a Service (SaaS) แพลตฟอร์มที่ต้องรองรับลูกค้าจำนวนมาก (Multi-tenancy) คือมาตรฐานใหม่ของการพัฒนาซอฟต์แวร์ ความท้าทายที่สำคัญที่สุดไม่ใช่แค่การเก็บข้อมูลจำนวนมาก แต่คือการรับประกันว่าข้อมูลของผู้เช่า (Tenant) แต่ละรายจะถูกแยกออกจากกันอย่างเด็ดขาด เพื่อป้องกันการรั่วไหลของข้อมูล (Data Leakage) และรักษาความเป็นส่วนตัวของลูกค้า
การเลือกกลไกการแยกพื้นที่ (Isolation) ที่เหมาะสมจึงเป็นหัวใจของการออกแบบสถาปัตยกรรมระบบขนาดใหญ่ บทความนี้จะเจาะลึกการเปรียบเทียบระหว่างการแยกข้อมูลในระดับฐานข้อมูลทั้งหมด (Database Isolation) และการแยกในระดับ Schema ภายในฐานข้อมูลเดียวกัน (Schema Isolation) โดยเน้นการใช้งานเฉพาะในระบบ PostgreSQL ซึ่งเป็นระบบที่ให้ความยืดหยุ่นสูง
Database Isolation vs Schema Isolation: ข้อดีข้อเสีย
แนวคิดในการแยกพื้นที่ข้อมูลมี 2 รูปแบบหลัก ซึ่งแต่ละแบบมีผลกระทบต่อความปลอดภัยและประสิทธิภาพที่แตกต่างกัน:
1. Database per Tenant (การแยกฐานข้อมูลทั้งหมด)
หลักการ: ผู้เช่าแต่ละรายจะมีฐานข้อมูล PostgreSQL เป็นของตัวเองโดยสมบูรณ์ (Dedicated Database) ทำให้การแยกข้อมูลมีความมั่นใจสูงสุด (Maximum Isolation) เพราะไม่มีโอกาสที่ข้อมูลจะปะปนกันในระดับ Physical Database
ข้อดี: ความปลอดภัยสูงมาก, ง่ายต่อการสำรองข้อมูล (Backup) และการจัดการสิทธิ์ในระดับสูงสุด
ข้อเสีย: มี Overhead ในการบริหารจัดการฐานข้อมูลจำนวนมาก (Database Sprawl), การอัปเดต Schema ต้องทำซ้ำๆ กันหลายครั้ง, และการใช้ทรัพยากร (Resource Usage) อาจกระจายตัวและจัดการยาก
2. Schema per Tenant (การแยก Schema ภายในฐานข้อมูล)
หลักการ: ผู้เช่าทั้งหมดแชร์ Physical Database เดียวกัน แต่จะถูกจัดเก็บข้อมูลใน Schema ที่ถูกกำหนดขอบเขตไว้สำหรับผู้เช่าแต่ละราย (Tenant-specific Schema) PostgreSQL รองรับการนี้โดยธรรมชาติ ทำให้เป็นทางเลือกที่สมดุลระหว่างประสิทธิภาพและความปลอดภัย
ข้อดี: ประสิทธิภาพสูงกว่าเพราะแชร์ทรัพยากรเดียวกัน, ลด Overhead ในการจัดการฐานข้อมูลจำนวนมาก, และง่ายต่อการจัดการการอัปเดต Schema (ทำครั้งเดียวใช้ได้กับทุก Tenant)
ข้อเสีย: ต้องอาศัยการควบคุมโค้ด (Application Logic) ที่เข้มงวดมากเพื่อป้องกันการ Query ข้าม Schema โดยไม่ได้ตั้งใจ
การประยุกต์ใช้ด้วย PostgreSQL: ตัวอย่างโค้ด
ในทางปฏิบัติสำหรับระบบ SaaS ส่วนใหญ่ การใช้ Schema per Tenant ถือเป็นจุดสมดุลที่ยอดเยี่ยมที่สุด เนื่องจากยังคงความปลอดภัยสูงและมีประสิทธิภาพในการ Scale สูง เราสามารถใช้คำสั่ง SQL ของ PostgreSQL เพื่อสร้างโครงสร้างนี้ได้:
SQL
-- 1. สร้างฐานข้อมูลหลักสำหรับ Multi-tenant System (Shared DB) </code>
CREATE DATABASE saas_platform;
-- 2. เชื่อมต่อเข้าสู่ฐานข้อมูลหลัก
-- 3. สร้าง Schema สำหรับ Tenant A
CREATE SCHEMA tenant_a;
-- 4. สร้างตารางข้อมูลสินค้า (Product) ภายใน Schema ของ Tenant A
CREATE TABLE tenant_a.products (
product_id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
sku VARCHAR(50) UNIQUE
);
-- 5. แทรกข้อมูลตัวอย่างสำหรับ Tenant A
SET search_path TO tenant_a;
INSERT INTO products (name, sku) VALUES ('Laptop X', 'LX-100');
-- 6. สร้าง Schema สำหรับ Tenant B
CREATE SCHEMA tenant_b;
-- 7. แทรกข้อมูลตัวอย่างสำหรับ Tenant B (โดยการเปลี่ยน search_path)
SET search_path TO tenant_b;
INSERT INTO products (name, sku) VALUES ('Monitor Y', 'MY-200');
-- การ Query ข้อมูลของ Tenant A ต้องระบุ Schema อย่างชัดเจน: SELECT * FROM tenant_a.products;
บทสรุป: เมื่อไหร่ควรเลือกอะไร?
การตัดสินใจระหว่าง Database per Tenant และ Schema per Tenant ขึ้นอยู่กับข้อจำกัดทางธุรกิจและความสำคัญด้านความปลอดภัย (Security Compliance) หากคุณอยู่ในอุตสาหกรรมที่มีข้อกำหนดด้านกฎหมายที่เข้มงวดมาก (เช่น การเงินระดับสูง) และต้องการการแยกข้อมูลที่สมบูรณ์แบบที่สุด (Absolute Isolation) การใช้ Database per Tenant อาจเป็นทางเลือกที่ปลอดภัยที่สุด
อย่างไรก็ตาม สำหรับโครงการ SaaS ส่วนใหญ่ที่ต้องการความยืดหยุ่นในการ Scale และการบริหารจัดการทรัพยากรอย่างมีประสิทธิภาพ Schema per Tenant คือสถาปัตยกรรมที่แนะนำที่สุดใน PostgreSQL เพราะมันให้ความสมดุลระหว่างความปลอดภัยระดับสูงและประสิทธิภาพในการดำเนินงานในระยะยาว