เส้นทางการขยายระบบของ Pinterest
การขยายระบบของ Pinterest แบ่งออกเป็น 4 ช่วง:
- ยุคแห่งการค้นหาตัวตน: ทีมวิศวกรขนาดเล็กดูแลการทำต้นแบบอย่างรวดเร็วและความต้องการของผลิตภัณฑ์ที่เปลี่ยนแปลงอยู่ตลอดเวลา
- ยุคแห่งการทดลอง: จำนวนผู้ใช้เพิ่มขึ้นอย่างรวดเร็ว ทำให้ต้องเร่งขยายระบบ แต่ก็นำไปสู่ระบบที่ซับซ้อนและเปราะบาง
- ยุคแห่งความเป็นผู้ใหญ่: ทำให้สถาปัตยกรรมเรียบง่ายขึ้นด้วยการใช้เทคโนโลยีที่เติบโตเต็มที่และขยายได้ เช่น MySQL, Memcache และ Redis
- ยุคแห่งการถอยกลับ: หลังจากมีสถาปัตยกรรมที่เหมาะสมแล้ว ก็ขยายแบบแนวนอนเพื่อรองรับการเติบโตต่อเนื่อง
เทคโนโลยีหลัก
Pinterest ให้ความสำคัญกับเทคโนโลยีที่เน้นความเชื่อถือได้ ความเข้าใจง่าย และความสามารถในการขยายระบบ:
- MySQL: ฐานข้อมูลเชิงสัมพันธ์ที่เสถียรและดูแลรักษาง่าย
- Memcache: แคชข้อมูลที่ถูกเข้าถึงบ่อยไว้ในหน่วยความจำเพื่อลดภาระการอ่านจากฐานข้อมูล
- Redis: ที่เก็บข้อมูลแบบยืดหยุ่นซึ่งรองรับโครงสร้างข้อมูลได้หลากหลาย
- Solr: แพลตฟอร์มค้นหาที่นำมาใช้งานได้อย่างรวดเร็ว
การขยายฐานข้อมูล: คลัสเตอริง vs ชาร์ดดิง
Pinterest พิจารณา 2 แนวทางในการกระจายการประมวลผลฐานข้อมูล:
คลัสเตอริง
- เมื่อข้อมูลเข้ามา ระบบจะตัดสินใจเลือกโหนดที่เหมาะสมที่สุดและทำสำเนาข้อมูลไปยังหลายโหนด
- มีข้อดี เช่น ขยายระบบอัตโนมัติ ตั้งค่าได้ง่าย และรับประกันความพร้อมใช้งานของข้อมูล แต่ก็มีข้อเสีย เช่น ความซับซ้อน ความไม่สุกงอมของเทคโนโลยี และความยากในการอัปเกรด
ชาร์ดดิง
- แบ่งข้อมูลออกเป็นชิ้นเล็ก ๆ แล้วนำแต่ละชิ้นไปไว้บนเซิร์ฟเวอร์ที่เป็นอิสระต่อกัน
- มีข้อดี เช่น สถาปัตยกรรมเรียบง่าย ขยายได้อย่างอิสระ และมีความเป็นเจ้าของข้อมูลที่ชัดเจน แต่ก็มีข้อเสีย เช่น ไม่สามารถทำ join และ transaction ในระดับฐานข้อมูลได้ และทำให้ความซับซ้อนของแอปพลิเคชันเพิ่มขึ้น
Pinterest เลือกใช้ชาร์ดดิงเนื่องจากมีประสบการณ์ด้านลบกับคลัสเตอริง
การเปลี่ยนผ่านสู่สถาปัตยกรรมแบบชาร์ดดิง
Pinterest ค่อย ๆ เปลี่ยนไปใช้ชาร์ดดิงในช่วงที่หยุดเพิ่มฟีเจอร์ชั่วคราว:
- ตัดการใช้ join: เลิกใช้ MySQL join ทั้งหมด และใช้การทำข้อมูลซ้ำแบบ denormalization ร่วมกับการแคช
- ชาร์ดดิงตาม ID: ชาร์ดตาม ID แบบ 64 บิต เพื่อให้การกำหนดเส้นทางข้อมูลเรียบง่ายขึ้น
ข้อเสียของชาร์ดดิงและแนวทางแก้ไข
- สคริปต์ย้ายข้อมูล: การส่งข้อมูลไปยังโครงสร้างพื้นฐานแบบชาร์ดดิงใช้เวลามาก
- ลอจิกของแอปพลิเคชัน: ต้องรักษาความสอดคล้องของข้อมูลเอง เนื่องจากไม่มี join และ transaction ในระดับฐานข้อมูล
- การแก้ไขสคีมา: ต้องวางแผนและนำการเปลี่ยนแปลงสคีมาไปใช้กับทุกชาร์ด
- การสร้างรายงาน: ต้องรวมข้อมูลจากหลายชาร์ดเพื่อสร้างรายงาน
บทเรียน
บทเรียนสำคัญจากเส้นทางการขยายระบบของ Pinterest:
- ความเรียบง่ายสำคัญ: การเลือกเทคโนโลยีที่เข้าใจง่ายช่วยให้แก้ปัญหาได้ดีขึ้นและลดความเสี่ยง
- ให้ความสำคัญกับการขยายระบบก่อน: ในสภาพแวดล้อมที่เติบโตอย่างรวดเร็ว ควรให้ความสำคัญกับการขยายระบบ แม้จะต้องแลกกับความสามารถบางอย่างของฐานข้อมูล
- ออกแบบเพื่อการขยายแบบแนวนอน: เลือกสถาปัตยกรรมที่สามารถเพิ่มทรัพยากรได้ตามการขยายตัวของฐานผู้ใช้
ยังไม่มีความคิดเห็น