System Design: ทำความรู้จัก Sharding ทางออกสุดท้ายของฐานข้อมูล

เมื่อเซิร์ฟเวอร์ฐานข้อมูลเครื่องเดียวเริ่มมีข้อจำกัด การเพิ่มขนาดเครื่องหรือ Vertical Scaling จะไปถึงจุดตันในที่สุด การเพิ่ม Read Replicas ช่วยให้อ่านข้อมูลได้รวดเร็วขึ้นแต่ไม่ช่วยเรื่องการเขียนข้อมูล เพราะทุกคำสั่งเขียนยังคงวิ่งเข้าสู่ Primary Server ตัวเดียว เมื่อปริมาณข้อมูลเกินกว่าดิสก์ของเครื่องเดียวจะรับไหว หรืออัตราการเขียนเกินความสามารถของ CPU ทางออกสุดท้ายที่เหลืออยู่คือการแยกฐานข้อมูลออกเป็นหลายๆ เครื่อง โดยแต่ละเครื่องจะรับผิดชอบข้อมูลคนละส่วน กระบวนการนี้เรียกว่า Sharding ซึ่งถือเป็นกลไกการขยายระบบที่ทรงพลังที่สุดและมีต้นทุนสูงสุดเช่นกัน

บทความนี้เป็นส่วนที่ 3 ของซีรีส์ System Design, Plainly ที่นำเสนอแนวคิดทีละเรื่องเข้าใจง่ายพร้อมตัวเลขและกรณีศึกษา โดยจะพาไปทำความรู้จัก Sharding แนวทางการแบ่งข้อมูลทั้ง 4 แบบ เหตุผลที่ทำให้ Shard Key เป็นการตัดสินใจครั้งสำคัญที่สุด รวมถึง 3 ต้นทุนหลัก ได้แก่ คำสั่งข้าม Shard การปรับสมดุล และปัญหา Hot Key ที่จะเป็นตัวตัดสินว่าการทำ Sharding นั้นคุ้มค่าหรือไม่

เพื่อให้เห็นภาพชัดเจน ลองจินตนาการถึงห้องสมุดที่มีบรรณารักษ์เพียงคนเดียว เธอย่อมจัดเก็บหนังสือและให้บริการยืมคืนได้ในจำนวนที่จำกัด เมื่อห้องสมุดเติบโตขึ้น คิวย่อมยาวขึ้น การจ้างบรรณารักษ์ที่ทำงานเร็วจนถึงขีดสุดก็ยังไม่เพียงพอต่อความต้องการ

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

ทางออกคือการแบ่งห้องสมุดออกเป็น 10 สาขา โดยแต่ละสาขาจะมีส่วนของหนังสือและบรรณารักษ์เป็นของตัวเอง ทำให้สามารถให้บริการยืมคืนพร้อมกันได้ 10 เท่า และรองรับคลังหนังสือที่ใหญ่ขึ้นสิบเท่า แต่ปัญหารูปแบบใหม่ 3 ประการก็จะตามมา

ปัญหาแรกคือการกำหนดกฎเกณฑ์ว่าจะให้สาขาใดเก็บหนังสือเล่มใด เช่น เรียงตามตัวอักษร ชื่อผู้แต่ง หรือหมวดหมู่ กฎข้อนี้เรียกว่า Shard Key ซึ่งเป็นตัวกำหนดว่าข้อมูลจะกระจายตัวสม่ำเสมอแค่ไหน การค้นหาจะรวดเร็วเพียงใด และจะมีสาขาใดที่ต้องแบกรับหนังสือยอดฮิตทั้งหมดในขณะที่สาขาอื่นว่างงานหรือไม่