เมื่อใดไม่ควรแบ่งข้อมูล
แบบจำลองสำหรับอ่าน การแบ่งพาร์ทิชัน และเครื่องที่มีขนาดใหญ่ขึ้นแก้ปัญหาการขยายระบบส่วนใหญ่ได้ — เรียนรู้ว่าเมื่อใดการแบ่งข้อมูลไม่ใช่คำตอบที่เหมาะสม
เมื่อใดไม่ควรแบ่งข้อมูล เป็นบทเรียน SQL Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน SQL Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน
Sharding ควรเป็นทางเลือกสุดท้าย
Sharding เพิ่มความซับซ้อนด้านการปฏิบัติการเป็นทวีคูณ แอปส่วนใหญ่ไม่จำเป็นต้องใช้ จงใช้ทางเลือกที่ง่ายกว่าทั้งหมดให้หมดเสียก่อน
ขั้นที่ 1: การขยายระบบในแนวตั้ง
ใช้เครื่องที่ใหญ่ขึ้น อินสแตนซ์คลาวด์สมัยใหม่รองรับได้อย่างสบาย:
- 128 คอร์
- 1 TB RAM
- 50,000 IOPS NVMe
นั่นหมายถึง 100k-500k QPS บนโหนด PostgreSQL เดียว แอปส่วนใหญ่ใช้งานได้อย่างสบาย
ขั้นที่ 2: Read Replica
หากการอ่านเป็นภาระหลัก ให้เพิ่ม replica โดย primary หนึ่งตัวและ replica สามตัวสามารถรองรับการอ่านได้มากขึ้น 10 เท่า
ขั้นที่ 3: การแคช
วาง Redis/memcached ไว้หน้าคำสั่ง query ที่มีการใช้งานสูง มักเป็นวิธีเพิ่มประสิทธิภาพที่คุ้มค่าที่สุด
ขั้นที่ 4: การแบ่งพาร์ทิชัน
การแบ่งพาร์ทิชันแบบประกาศของ PG ที่มีมาให้ในตัวช่วยแก้ปัญหา "ตารางใหญ่เกินไป" ภายในเซิร์ฟเวอร์เดียว และมักง่ายกว่า Sharding ถึง 100 เท่า
ขั้นที่ 5: การแยกบริการ
ย้ายโดเมนต่าง ๆ ไปยังฐานข้อมูลต่างกัน เช่น ฐานข้อมูลคำสั่งซื้อ ฐานข้อมูลผู้ใช้ และฐานข้อมูลการวิเคราะห์ แต่ละฐานข้อมูลจึงขยายระบบได้อย่างอิสระ
ขั้นที่ 6: ย้ายงานวิเคราะห์ออก
Query แบบ OLTP → PostgreSQL ส่วน query เชิงวิเคราะห์ → ClickHouse / BigQuery / Snowflake เรื่องราวที่ว่า "เราต้องทำ Sharding" จำนวนมาก แท้จริงแล้วคือ "งานวิเคราะห์กำลังกินทรัพยากร OLTP ของเรา"
จากนั้นค่อยพิจารณา Sharding
หากข้อมูล OLTP อย่างเดียวของคุณยังแตะขีดจำกัดที่ 50TB และภาระงานต้องการการเขียนที่เซิร์ฟเวอร์เดียวรองรับไม่ไหว ให้เริ่มวางแผนแบ่งชาร์ด
ต้นทุนด้านการปฏิบัติการของ Sharding
- มีเซิร์ฟเวอร์ที่ต้องตรวจสอบและติดตั้งแพตช์มากขึ้น
- ต้องประสานงานการสำรองข้อมูลระหว่างชาร์ด
- Query ข้ามชาร์ดจะตกเป็นภาระของโค้ดแอป
- การแบ่งชาร์ดใหม่ทำได้ยาก
- ชาร์ดร้อนต้องมีการปรับสมดุลอย่างต่อเนื่อง
กลยุทธ์ "แบ่งชาร์ดเมื่อจำเป็น"
สร้างระบบด้วยรูปแบบที่รองรับ Sharding เช่น ใส่ tenant_id เสมอ และไม่ใช้ตัวนับที่เพิ่มขึ้นทั่วทั้งระบบ เพื่อให้คุณ CAN ทำ Sharding ได้ในภายหลัง แต่อย่าเพิ่งแบ่งชาร์ดจนกว่าจะถูกบังคับให้ทำ
สคีมาที่รองรับ Sharding
แม้คุณจะยังใช้โหนดเดียว ให้ออกแบบราวกับว่าอาจต้องแบ่งชาร์ด:
- มี Tenant_id ในทุกแถว
- ใช้ UUID หรือ ID แบบกระจาย (ไม่ใช้การเพิ่มค่าอัตโนมัติ)
- ไม่มีลำดับหมายเลขที่ไม่ซ้ำกันทั่วทั้งระบบ
- คีย์ภายนอกอยู่ภายในขอบเขตของผู้เช่าแต่ละราย
ยอมรับข้อแลกเปลี่ยน
Sharding เพิ่มความจุโดยแลกกับความสามารถ JOIN ธุรกรรม และ query จะทำได้ยากขึ้น ตรวจสอบให้แน่ใจว่าประโยชน์ที่ได้คุ้มค่ากับสิ่งที่เสียไป
สรุป
Sharding แก้ปัญหาที่มีอยู่จริง แต่เป็นวิธีที่มีภาระสูง
- ขยายระบบในแนวตั้งก่อน
- ใช้ Read Replica และการแคช
- แบ่งพาร์ทิชันก่อนทำ Sharding
- ย้ายงานวิเคราะห์ออกจาก OLTP
- ออกแบบให้รองรับการแบ่งชาร์ด และเลื่อนการแบ่งชาร์ดจริงออกไป
ตรวจสอบความเข้าใจอย่างรวดเร็ว
คุณกำลังพิจารณา Sharding เพราะ query แบบ OLTP ทำงานช้า ก่อนทำ Sharding ขั้นตอนใดมีแนวโน้มจะช่วยได้มากที่สุด
คำถามที่พบบ่อย
บทเรียน “เมื่อใดไม่ควรแบ่งข้อมูล” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “เมื่อใดไม่ควรแบ่งข้อมูล” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส SQL Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส SQL Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “เมื่อใดไม่ควรแบ่งข้อมูล”
แบบจำลองสำหรับอ่าน การแบ่งพาร์ทิชัน และเครื่องที่มีขนาดใหญ่ขึ้นแก้ปัญหาการขยายระบบส่วนใหญ่ได้ — เรียนรู้ว่าเมื่อใดการแบ่งข้อมูลไม่ใช่คำตอบที่เหมาะสม คุณปฏิบัติ SQL Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน SQL Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน SQL Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “เมื่อใดไม่ควรแบ่งข้อมูล” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน SQL Academy นี้ได้ไหม
ได้ บทเรียน SQL Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- กลยุทธ์การแบ่งข้อมูล: แบบช่วง แบบแฮช และแบบไดเรกทอรี
- คำสั่งค้นหาข้ามส่วนข้อมูล: ปัญหาที่ยากที่สุด
- Citus และ Postgres แบบกระจาย
- เมื่อใดไม่ควรแบ่งข้อมูล