Linux: rsync

ในฐานะ System Specialist และ Senior Database Architect เราทราบดีว่าการถ่ายโอนข้อมูลขนาดใหญ่ (Data Synchronization) อย่างมีประสิทธิภาพคือหัวใจของการดูแลระบบ ไม่ว่าจะเป็นการสำรองข้อมูล การทำ Disaster Recovery หรือการอัปเดตข้อมูลข้าม Environment แม้ว่าเครื่องมือ rsync จะถูกออกแบบมาเพื่อซิงค์ไฟล์ในระดับ Operating System แต่หลักการทำงานของมัน—คือการส่งเฉพาะส่วนที่เปลี่ยนแปลง (Delta Transfer)—นั้นเป็นแนวคิดทางสถาปัตยกรรมที่ทรงพลัง ซึ่งสามารถนำมาประยุกต์ใช้กับการจัดการข้อมูลในฐานข้อมูลเชิงสัมพันธ์อย่าง PostgreSQL ได้อย่างสมบูรณ์

บทความนี้จะเจาะลึกถึงหลักการ Delta Synchronization โดยเปลี่ยนมุมมองจาก File System ไปสู่ระดับ SQL Query เพื่อให้เห็นภาพว่าการเปรียบเทียบและถ่ายโอนเฉพาะส่วนที่เปลี่ยนแปลง (Change Data Capture – CDC) สามารถทำได้อย่างไรใน PostgreSQL ด้วยประสิทธิภาพสูงสุด

หลักการ Delta Synchronization ใน PostgreSQL

หัวใจสำคัญของ rsync คือ Algorithm ที่คำนวณหาความแตกต่าง (Delta) ระหว่าง Source และ Destination โดยไม่จำเป็นต้องส่งข้อมูลทั้งหมดมาใหม่ เมื่อนำแนวคิดนี้มาใช้กับ PostgreSQL เราจะต้องใช้วิธีการเปรียบเทียบสถานะของแถว (Row Comparison) หรือคอลัมน์ที่เปลี่ยนแปลงไป เพื่อให้มั่นใจว่าข้อมูลปลายทางมีความสมบูรณ์และทันสมัยที่สุด การทำเช่นนี้ช่วยลดปริมาณ I/O, ลดภาระเครือข่าย และประหยัดเวลาในการซิงค์ข้อมูลได้อย่างมหาศาล

การตรวจจับความแตกต่างด้วย SQL (Delta Detection)

เราสามารถจำลองกระบวนการเปรียบเทียบของ rsync ได้โดยใช้ Common Table Expressions (CTEs) และการ Join ใน PostgreSQL เพื่อระบุ 3 สถานะหลัก:

1. New Records (Insert): แถวที่มีอยู่ใน Source แต่ไม่มีใน Target
2. Modified Records (Update): แถวที่มีอยู่ในทั้งสองที่ แต่มีค่าคอลัมน์ที่แตกต่างกัน (เช่น last_updated)
3. Deleted Records (Delete): แถวที่มีอยู่ใน Target แต่ไม่มีใน Source

ตัวอย่างการตรวจจับแถวที่เปลี่ยนแปลงหรือขาดหายไป:

SQL

-- CTEs เพื่อแยก Source และ Target Data สำหรับการเปรียบเทียบสถานะ (State Comparison) --
WITH source_data AS (
    SELECT id, data_field, last_updated FROM source_table WHERE is_active = TRUE
), 
target_data AS (
    SELECT id, data_field, last_updated FROM target_table
)
-- 1. หาแถวที่ถูกเพิ่มใหม่ (New Records)
SELECT s.* FROM source_data s LEFT JOIN target_data t ON s.id = t.id WHERE t.id IS NULL;
-- 2. หาแถวที่มีการเปลี่ยนแปลง (Modified Records) หรือลบออก
SELECT * FROM source_data s JOIN target_data t ON s.id = t.id WHERE s.last_updated > t.last_updated OR s.data_field != t.data_field;

กระบวนการซิงค์ข้อมูลแบบ Transactional (The Full Sync Cycle)

ในการจำลองคำสั่ง rsync --delete ในระดับฐานข้อมูล เราต้องดำเนินการทั้ง 3 ขั้นตอน (Delete, Update, Insert) ภายใน Transaction Block เพื่อให้มั่นใจในความสมบูรณ์ของข้อมูล (Atomicity) เสมอ:

SQL

BEGIN; 
-- Step 1: ลบข้อมูลปลายทางที่ไม่มีในแหล่งข้อมูล (The Delete Action)
DELETE FROM target_table WHERE id NOT IN (SELECT id FROM source_table);

-- Step 2: อัปเดตข้อมูลที่มีการเปลี่ยนแปลง (The Update/Sync Action)
UPDATE target_table t SET data_field = s.data_field, last_updated = NOW() 
FROM source_table s WHERE t.id = s.id AND s.last_updated > t.last_updated;

-- Step 3: แทรกข้อมูลใหม่ (The Insert Action)
INSERT INTO target_table (id, data_field, last_updated) SELECT id, data_field, NOW() FROM source_table WHERE NOT EXISTS (SELECT 1 FROM target_table WHERE target_table.id = source_table.id);

COMMIT;

ข้อควรระวังทางสถาปัตยกรรม (Architectural Considerations)

การทำ Delta Sync ในระบบ Production ต้องคำนึงถึงปัจจัยเหล่านี้:

• Transaction Control: การใช้ BEGIN; และ COMMIT; เป็นสิ่งจำเป็นสูงสุด เพื่อให้การซิงค์ทั้งหมดเป็นไปอย่างสำเร็จหรือล้มเหลวพร้อมกัน (All or Nothing)
• Indexing: ต้องมั่นใจว่าคอลัมน์ที่ใช้ในการเปรียบเทียบ (เช่น Primary Key หรือ last_updated) มี Index ที่เหมาะสม เพื่อให้ Query ทำงานได้อย่างรวดเร็วที่สุด
• Concurrency: หากมีการซิงค์ข้อมูลในขณะที่มีผู้ใช้งานเขียนข้อมูลอยู่ ต้องใช้กลไกอย่าง Trigger หรือ Change Data Capture (CDC) Tools เช่น Debezium เพื่อลดโอกาสเกิด Race Condition

สรุป

แม้ว่า rsync จะเป็นเครื่องมือระดับ OS แต่หลักการ Delta Synchronization ของมันคือแนวคิดพื้นฐานที่สำคัญที่สุดในการออกแบบ Data Pipeline สมัยใหม่ การทำความเข้าใจกระบวนการนี้ด้วย SQL Query ที่ซับซ้อน เช่น CTEs, Transaction Control และการเปรียบเทียบสถานะข้อมูล จะช่วยให้เราสามารถสร้างระบบ Data Integration ที่มีประสิทธิภาพสูง ทนทานต่อข้อผิดพลาด และประหยัดทรัพยากรได้อย่างแท้จริงในสถาปัตยกรรม PostgreSQL