← Back to list

The Postgres Guide Part 3: Sharding — ทะลายขีดจำกัด สเกลระบบสู่ระดับโลก

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

Pakkapon Chomchoey · 2026-05-15 03:10 · 0 claps · 2.3 min read
#sharding
Open on Medium ↗

The Postgres Guide Part 3: Sharding — ทะลายขีดจำกัด สเกลระบบสู่ระดับโลก

ถ้าลองหั่นตารางก็แล้ว ใช้ Server สเปกเทพที่สุดก็แล้ว แต่ยังเอาไม่อยู่? ถึงเวลาขยายสาขาด้วย Sharding เพื่อกระจายข้อมูลไปหลายเครื่อง (Scale-out) รองรับ Traffic และ Storage ระดับโลกใน Part นี้ครับ

Sharding

เป็นการแบ่งกลุ่มในระดับ Database เป็นเทคนิคการ Scale Database ให้มี Perf ในการ Read และ Write ที่มากขึ้น แบ่ง database ออกมา เพื่อแบ่ง table เป็นส่วนเล็ก ๆ db ที่แยกไป จะมี table เหมือนกันหมด เหมือนเป็นการแบ่ง ข้อมูล ในแต่ะ table ออกไปเก็บในแต่ละ db เพื่อเพิ่ม performance

Sharding สามารถทำ Replication ได้ ถ้าเกิด Sharding A ล่ม ก็ไปใช้ Sharding B หรือทำ Master-Slave ก็ได้

แต่ละ Shard รันแยก Node (Server) แต่ Shared Schema เดียวกัน

Node (Server) จะเรียกว่า Physical Shard Shard จะเรียกว่า Logical Shard

Physical Shard มีได้หลาย Logical Shard

บาง Database ทำ Sharding ให้ บางอันไม่มี เราก็ต้องมาเขียนเอง

Postgres จะไม่มี Auto-Sharding ให้ ต้องลง Extensions เพิ่มเอง อย่าง Citus มันจะเปลี่ยน Postgres ให้กลายเป็น Distributed Database

ตัวอย่างการแบ่ง Shard ระหว่างช่วงตัวอักษรตัวแรกของ name

ตัวอย่างการแบ่ง Shard ระหว่างช่วงตัวอักษรตัวแรกของ name

เราต้องมาเลือก Field ที่จะทำเป็น Shard Key

โดยจะเอา Shard Key มา Hash แล้วเก็บใน Hash Table เพื่อ Access ไปหา Shard ต่าง ๆ ที่ ข้อมูลใน Row นั้นอยู่

  • ต้องดูจำนวนความเป็นไปได้ของ field ด้วย ถ้ามีแค่ Yes/No ก็ไม่ควรจะเอามาทำเป็น Key

Shard Method

  • Range-Based Sharding
  • Hash Sharding
  • Directory Sharding
  • Geo Sharding

Range-Based Sharding

แบ่งข้อมูลตามช่วงของค่า key เช่น ตัวอักษร A-I ไป Shard 1, J-S ไป Shard 2

Hash Sharding

ใช้ฟังก์ชัน hash ของ key เพื่อกระจายข้อมูลไป Shard ต่าง ๆ อย่างสม่ำเสมอ ถ้าต้องการ READ มันก็จะรัน func hash เพื่อหา ซึ่งเสียเวลา ถ้ามี Shard เพิ่ม มันต้อง Rebalance shard ต้อง hash ใหม่หมด

Directory Sharding

ใช้ตาราง lookup เพื่อ map key ไปยัง Shard ที่ต้องการ เพิ่ม Shard ได้ง่าย

หา customer_id 33 เจอที่ shard_2

หา customer_id 33 เจอที่ shard_2

เพิ่ม Shard Key ใหม่ 405 ก็จะเพิ่ม shard_3 ขึ้นมาใหม่

เพิ่ม Shard Key ใหม่ 405 ก็จะเพิ่ม shard_3 ขึ้นมาใหม่

Geo Sharding

แบ่งข้อมูลตามตำแหน่งทางภูมิศาสตร์ของผู้ใช้ เพื่อลด latency

ถ้า User อยู่ US ก็จะไปใช้ shard_us

ถ้า User อยู่ US ก็จะไปใช้ shard_us

ถ้า User อยู่ TH ก็จะไปใช้ shard_th

ถ้า User อยู่ TH ก็จะไปใช้ shard_th

ถ้านี้การเลือก Shard Key นั้นสำคัญมาก ไม่งั้นมันจะเกิด Hot Shard

Hot Shard คือ Shard ใด Shard หนึ่งต้องรับภาระหนักกว่าชาวบ้าน ซึ่งอาจจะเกิดจากการเลือก Shard Key ไม่ดี

Join DB ข้าม Shard ไม่ดี

เมื่อไหร่ไม่ควรใช้ Shard

ถ้า Vertical Scale ยัง Work อยู่

ถ้าทำ Read Replica ยังมี Read Speed ที่ดีอยู่

Cache ยังทำให้เร็วอยู่

Data น้อยกว่า 5TB

ความแตกต่างระหว่าง Partition กับ Sharding

  • Partition: “หนึ่งเครื่อง หลายตาราง” (ช่วยเรื่อง Manage ข้อมูล และ Scan เฉพาะส่วน)
  • Sharding: “หลายเครื่อง หลายตาราง” (ช่วยเรื่อง Scale ทะลุขีดจำกัดของ Hardware เครื่องเดียว)

메타데이터
post_id
dcbbae99f60f
slug
the-postgres-guide-part-3-sharding-ทะลายขีดจำกัด-สเกลระบบสู่ระดับโลก-dcbbae99f60f
url
https://medium.com/@pakkapon-chomchoey/the-postgres-guide-part-3-sharding-%E0%B8%97%E0%B8%B0%E0%B8%A5%E0%B8%B2%E0%B8%A2%E0%B8%82%E0%B8%B5%E0%B8%94%E0%B8%88%E0%B8%B3%E0%B8%81%E0%B8%B1%E0%B8%94-%E0%B8%AA%E0%B9%80%E0%B8%81%E0%B8%A5%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B8%AA%E0%B8%B9%E0%B9%88%E0%B8%A3%E0%B8%B0%E0%B8%94%E0%B8%B1%E0%B8%9A%E0%B9%82%E0%B8%A5%E0%B8%81-dcbbae99f60f
canonical_url
https://medium.com/@pakkapon-chomchoey/the-postgres-guide-part-3-sharding-%E0%B8%97%E0%B8%B0%E0%B8%A5%E0%B8%B2%E0%B8%A2%E0%B8%82%E0%B8%B5%E0%B8%94%E0%B8%88%E0%B8%B3%E0%B8%81%E0%B8%B1%E0%B8%94-%E0%B8%AA%E0%B9%80%E0%B8%81%E0%B8%A5%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B8%AA%E0%B8%B9%E0%B9%88%E0%B8%A3%E0%B8%B0%E0%B8%94%E0%B8%B1%E0%B8%9A%E0%B9%82%E0%B8%A5%E0%B8%81-dcbbae99f60f
author_url
https://medium.com/@pakkapon-chomchoey
status
ok
fetched_at
2026-06-09 15:37:30