Database

Database Sharding Partitioning Guide

📅 2026-02-09 | โดย อ.บอม กิตติทัศน์ เจริญพนาสิทธิ์ — SiamCafe.net Since 1997

Database Sharding Partitioning Guide คืออะไร / ทำไมถึงสำคัญ

น้องๆ เคยเจอปัญหา database อืดไหม? สมัยผมทำร้านเน็ต SiamCafe.net เนี่ย เจอบ่อยมาก! ยิ่งลูกค้าเยอะ data ก็ยิ่งบาน พอ data บาน query ก็ช้า คนเล่นเกมส์ก็หัวร้อน... Sharding กับ Partitioning เนี่ยแหละ ตัวช่วย!

ง่ายๆ Sharding คือการ "แบ่ง" database ออกเป็นส่วนๆ กระจายไปไว้หลายๆ เครื่อง (server) ส่วน Partitioning คือการ "หั่น" ตาราง (table) ใหญ่ๆ ออกเป็นส่วนย่อยๆ ภายใน database เดียวกัน

ทำไมถึงสำคัญ? ก็เพราะมันช่วยให้เรา scale database ได้ไง! แทนที่จะต้อง upgrade server ตัวเดียวให้แรงสุดๆ เราก็แบ่งงานให้หลายๆ server ช่วยกันทำได้ แถมยังช่วยให้ query เร็วขึ้นด้วยนะ เพราะแต่ละ server ไม่ต้องแบก data ทั้งหมด

พื้นฐานที่ต้องรู้

ก่อนจะไปลงมือทำ Sharding หรือ Partitioning เราต้องเข้าใจพื้นฐานพวกนี้ก่อนนะ ไม่งั้นอาจจะงงๆ ได้

Key Space

Key Space คือ "ช่วง" ของข้อมูลที่เราจะใช้ในการแบ่ง Shard หรือ Partition เช่น ถ้าเรา Shard database users โดยใช้ user_id เป็น key space เราก็อาจจะแบ่งเป็นช่วงๆ เช่น user_id 1-1000 ไป Shard 1, user_id 1001-2000 ไป Shard 2 เป็นต้น

Shard Key / Partition Key

Shard Key คือ field ที่เราใช้ในการกำหนดว่า data จะไปอยู่ Shard ไหน ส่วน Partition Key ก็คือ field ที่เราใช้ในการกำหนดว่า data จะไปอยู่ใน Partition ไหน Key ที่เราเลือกต้องกระจาย data ได้ดีนะ ไม่งั้น Shard นึงอาจจะ load เยอะกว่า Shard อื่นๆ

สมัยผมทำร้านเน็ต เคยเจอเคสที่เลือก key ไม่ดี Shard นึง overload อีก Shard นึงแทบไม่ได้ใช้เลย ต้องมานั่ง redesign กันใหม่ เสียเวลามากๆ

วิธีใช้งาน / เริ่มต้นยังไง

เอาล่ะ ทีนี้มาดูวิธีใช้งาน Sharding กับ Partitioning กันบ้าง จริงๆ มันมีหลาย approach นะ แต่ผมจะเล่าแบบง่ายๆ ที่เคยใช้แล้วได้ผล

ขั้นตอนปฏิบัติจริง

Horizontal Sharding

Horizontal Sharding คือการแบ่ง database ออกเป็น Shard โดยที่แต่ละ Shard มี schema เหมือนกันเป๊ะๆ แต่มี data คนละส่วนกัน เช่น Shard นึงเก็บข้อมูล users A-M อีก Shard นึงเก็บข้อมูล users N-Z

-- สมมติเรามี database users
-- สร้าง Shard 1
CREATE DATABASE users_shard1;
USE users_shard1;
CREATE TABLE users (
    user_id INT PRIMARY KEY,
    username VARCHAR(255),
    email VARCHAR(255)
);

-- สร้าง Shard 2
CREATE DATABASE users_shard2;
USE users_shard2;
CREATE TABLE users (
    user_id INT PRIMARY KEY,
    username VARCHAR(255),
    email VARCHAR(255)
);

-- Application จะต้องรู้ว่า user_id ช่วงไหนอยู่ Shard ไหน
-- เช่น ถ้า user_id ขึ้นต้นด้วย A-M ให้ query ไปที่ users_shard1

Range Partitioning

Range Partitioning คือการแบ่ง table ออกเป็น partition โดยใช้ช่วงของค่าใน field ใด field หนึ่ง เช่น แบ่ง table orders ตามวันที่ order โดยที่แต่ละ partition เก็บ orders ในช่วงวันที่ต่างกัน

-- สมมติเรามี table orders
-- สร้าง partition สำหรับเดือนมกราคม 2024
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    order_date DATE,
    customer_id INT
)
PARTITION BY RANGE (YEAR(order_date)*100 + MONTH(order_date)) (
    PARTITION p202401 VALUES LESS THAN (202402)
);

-- สร้าง partition สำหรับเดือนกุมภาพันธ์ 2024
ALTER TABLE orders ADD PARTITION (PARTITION p202402 VALUES LESS THAN (202403));

ข้อดีของ Range Partitioning คือ query ที่ filter ตามช่วงวันที่ จะเร็วมากๆ เพราะ database จะ scan เฉพาะ partition ที่เกี่ยวข้องเท่านั้น

น้องๆ ลองเอา code snippet พวกนี้ไปปรับใช้ดูนะ แต่ก่อนจะทำจริง อย่าลืม backup database ก่อนนะ เดี๋ยวพลาดมาจะหาว่าพี่ไม่เตือน!

เปรียบเทียบกับทางเลือกอื่น

Sharding กับ Partitioning ไม่ใช่ทางออกเดียวในการแก้ปัญหา database อืด ยังมีทางเลือกอื่นๆ อีกนะ เช่น Vertical Scaling (upgrade server ให้แรงขึ้น) หรือ Read Replicas (สร้าง copies ของ database เพื่อรองรับ read queries)

แต่ละทางเลือกก็มีข้อดีข้อเสียต่างกัน เราต้องเลือกให้เหมาะกับ use case ของเรา

สมัยผมทำร้านเน็ต เคยลองมาหมดแล้ว ทั้ง Vertical Scaling, Read Replicas, Sharding, Partitioning สุดท้ายก็พบว่า Sharding กับ Partitioning ตอบโจทย์ที่สุด เพราะมัน scale ได้ยืดหยุ่น และช่วยให้ query เร็วขึ้นได้จริงๆ

ทางเลือก	ข้อดี	ข้อเสีย	เหมาะกับ
Vertical Scaling	ง่าย, ไม่ต้องเปลี่ยน code	มีขีดจำกัด, ราคาแพง	load ไม่เยอะมาก
Read Replicas	ช่วยลด load บน database หลัก	data อาจจะไม่ consistent	read-heavy workloads
Sharding	scale ได้ไม่จำกัด, query เร็ว	ซับซ้อน, ต้องเปลี่ยน code	data เยอะมากๆ
Partitioning	query เร็ว, manage data ง่าย	มีข้อจำกัด, ต้องออกแบบ partition key ดีๆ	table ใหญ่มากๆ

ถ้าอยากรู้เรื่องพวกนี้ลึกๆ ลองเข้าไปอ่านบทความอื่นๆ ใน SiamCafe Blog ดูนะ มีเรื่อง IT ที่น่าสนใจอีกเยอะเลย

สุดท้ายนี้ อยากฝากน้องๆ ว่า เทคโนโลยีมันเปลี่ยนไปเรื่อยๆ เราต้องเรียนรู้ตลอดเวลา อย่าหยุดที่จะพัฒนาตัวเองนะ แล้วน้องๆ จะเก่งขึ้นเรื่อยๆ เอง

SiamCafe Blog ยังมีบทความดีๆ อีกเพียบ ลองเข้าไปอ่านกันนะ!

Best Practices / เคล็ดลับจากประสบการณ์

เอาล่ะน้องๆ มาถึงส่วนสำคัญแล้ว ผมจะเล่าจากประสบการณ์จริงที่เจอมาตอนทำร้านเน็ต SiamCafe สมัยก่อนนะ Database สำคัญมาก ยิ่งร้านใหญ่ ข้อมูลยิ่งเยอะ ถ้าไม่จัดการดีๆ พังแน่นอน

Sharding และ Partitioning ไม่ใช่ยาวิเศษที่แก้ได้ทุกโรค ต้องเข้าใจข้อดีข้อเสียของมันก่อนเลือกใช้ อย่าสักแต่ว่าตามคนอื่น

3-4 เทคนิคที่ใช้ได้จริง

1. เลือก Sharding Key ให้ดี: สมัยก่อนผมพลาดตรงนี้บ่อยมาก Sharding Key คือหัวใจ ถ้าเลือกไม่ดี ข้อมูลจะกระจุกตัวอยู่ที่ Shard เดียว ทำให้ Shard นั้นทำงานหนัก ส่วน Shard อื่นๆ ว่างเปล่า

ยกตัวอย่างง่ายๆ ถ้าทำระบบสมาชิก อย่าใช้ ID สมาชิกเรียงตามลำดับในการ Shard เพราะสมาชิกใหม่ๆ จะไปกองอยู่ที่ Shard สุดท้าย ทำให้ Shard นั้นโหลดหนัก ควรใช้ Hash Function กระจายข้อมูลให้ทั่วถึง

// ตัวอย่าง PHP (อย่าลืมปรับให้เข้ากับภาษาที่ใช้)
function shardKey($userID, $numShards) {
  return $userID % $numShards;
}

2. Replication สำคัญกว่าที่คิด: Sharding ช่วยเรื่อง Scale แต่ไม่ได้ช่วยเรื่อง High Availability ถ้า Shard ใด Shard หนึ่ง Down ระบบทั้งหมดก็เจ๊ง Replication คือการทำสำเนาข้อมูลไปไว้ที่ Shard อื่นๆ ถ้า Shard หลักมีปัญหา เราก็สลับไปใช้ Shard สำรองได้ทันที

3. Transaction Management: อันนี้ซับซ้อนหน่อย ถ้าข้อมูลที่ต้อง Update อยู่คนละ Shard จะเกิดปัญหาเรื่อง Transaction ข้อมูลอาจจะไม่ Consistent กัน ต้องใช้ Two-Phase Commit หรือ SAGA Pattern เพื่อจัดการ Transaction ข้าม Shard

4. Monitoring is KEY: ติดตั้งระบบ Monitoring ที่ดี เพื่อคอยดู Performance ของแต่ละ Shard CPU, Memory, Disk I/O ต้องดูให้หมด ถ้า Shard ไหนโหลดเกิน ก็ต้องรีบแก้ไขก่อนที่จะเกิดปัญหา

iCafeForex

FAQ คำถามที่พบบ่อย

Sharding กับ Partitioning ต่างกันยังไง?

ง่ายๆ เลย Partitioning คือการแบ่ง Table เดียวออกเป็นส่วนๆ โดยที่ Table ยังอยู่บน Database Server ตัวเดิม ส่วน Sharding คือการแบ่ง Database ออกเป็นส่วนๆ แล้วกระจายไปไว้บน Server หลายๆ ตัว Partitioning เหมาะกับ Table ที่มีขนาดใหญ่มากๆ ส่วน Sharding เหมาะกับระบบที่ต้องการ Scale Out

ต้องทำ Sharding ตั้งแต่แรกเลยไหม?

ไม่จำเป็น! เริ่มจาก Database Server ตัวเดียวไปก่อน แล้วค่อยทำ Sharding เมื่อระบบเริ่มมี Traffic เยอะๆ การทำ Sharding เร็วจนเกินไปจะทำให้ระบบซับซ้อนโดยใช่เหตุ

ถ้าทำ Sharding แล้ว จะย้อนกลับได้ไหม?

ยากมาก! การย้ายข้อมูลจาก Shard หลายๆ ตัวกลับมารวมกันเป็น Database เดียวเป็นงานที่ซับซ้อนและใช้เวลานานมาก คิดให้ดีก่อนตัดสินใจทำ Sharding

Sharding ช่วยเรื่อง Security ไหม?

ช่วยได้บ้าง แต่ไม่ใช่ประเด็นหลัก Sharding ช่วยลดความเสี่ยงที่ Hacker จะเข้าถึงข้อมูลทั้งหมดได้ในคราวเดียว เพราะข้อมูลถูกกระจายไปอยู่บน Server หลายๆ ตัว แต่ยังไงก็ต้องมีมาตรการ Security อื่นๆ เพิ่มเติมด้วย

สรุป

Sharding และ Partitioning เป็นเครื่องมือที่มีประโยชน์มากในการจัดการ Database ขนาดใหญ่ แต่ต้องศึกษาและวางแผนให้ดีก่อนนำไปใช้จริง อย่าลืมว่าไม่มีวิธีไหนที่เหมาะกับทุกสถานการณ์ ต้องปรับให้เข้ากับ Use Case ของตัวเอง

หวังว่าบทความนี้จะเป็นประโยชน์กับน้องๆ นะครับ ถ้ามีคำถามเพิ่มเติม ถามมาได้เลย ยินดีตอบเสมอ แล้วเจอกันใหม่ที่ SiamCafe Blog ครับ