บทนำ
- ในปี 2017 Discord ได้แบ่งปันวิธีย้ายฐานข้อมูลจาก MongoDB ไปยัง Cassandra เพื่อจัดเก็บข้อความ
- Cassandra มอบความสามารถในการขยายระบบ ความทนทานต่อความขัดข้อง และความง่ายในการดูแลรักษา แต่เมื่อเวลาผ่านไป ปัญหาด้านประสิทธิภาพและภาระในการบำรุงรักษาก็เพิ่มขึ้น
- ในปี 2022 Discord ได้ย้ายฐานข้อมูลอีกครั้งไปยัง ScyllaDB
ปัญหาใน Cassandra
- โครงสร้างการจัดเก็บข้อความ: ข้อความถูกจัดเก็บโดยแบ่งพาร์ทิชันตาม
channel_id และ bucket
- ปัญหา hot partition: เมื่อทราฟฟิกกระจุกตัวอยู่ที่บางช่อง ก็ทำให้ latency ของทั้งฐานข้อมูลเพิ่มขึ้น
- ปัญหาด้านการบำรุงรักษา: ประสิทธิภาพลดลงจากงานบีบอัด SSTable และปัญหา garbage collection ของ JVM
การเปลี่ยนแปลงสถาปัตยกรรม
- การนำ ScyllaDB มาใช้: ฐานข้อมูลที่เข้ากันได้กับ Cassandra และเขียนด้วย C++ ซึ่งช่วยแก้ปัญหา garbage collection
- Data service: วางบริการตัวกลางระหว่าง API กับฐานข้อมูลเพื่อควบคุมทราฟฟิกและเพิ่มประสิทธิภาพ
- การใช้ Rust: ใช้ Rust เพื่อเขียนโค้ด concurrent ที่ปลอดภัยและรวดเร็ว
Data service
- การรวมคำขอ: เมื่อผู้ใช้หลายคนร้องขอข้อมูลเดียวกัน จะ query ฐานข้อมูลเพียงครั้งเดียวแล้วแชร์ผลลัพธ์ร่วมกัน
- การทำ routing ตาม consistent hashing: ส่งคำขอของช่องเดียวกันไปยัง service instance เดียวกันเพื่อลดภาระของฐานข้อมูล
การย้ายระบบขนาดใหญ่
- การสร้างคลัสเตอร์ ScyllaDB: ใช้ local SSD และ RAID เพื่อสร้างระบบจัดเก็บข้อมูลที่รวดเร็วและทนทาน
- การย้ายข้อมูล: ใช้ data migrator ที่เขียนด้วย Rust เพื่อย้ายข้อมูลได้อย่างรวดเร็ว
- การตรวจสอบข้อมูลอัตโนมัติ: ส่งคำขออ่านจำนวนเล็กน้อยไปยังฐานข้อมูลทั้งสองแล้วเปรียบเทียบผลลัพธ์เพื่อตรวจสอบความถูกต้องสมบูรณ์ของข้อมูล
หลายเดือนต่อมา
- ประสิทธิภาพที่ดีขึ้น: ให้ประสิทธิภาพที่ดีกว่า Cassandra โดยใช้จำนวนโหนดน้อยกว่า
- latency ลดลง: ประสิทธิภาพในการดึงและแทรกข้อความดีขึ้นอย่างมาก
- กรณีใช้งานผลิตภัณฑ์ใหม่: การปรับปรุงประสิทธิภาพทำให้สามารถสร้างฟีเจอร์ใหม่ได้
# สรุปโดย GN⁺
- Discord ย้ายฐานข้อมูลไปยัง ScyllaDB เพื่อแก้ปัญหาด้านประสิทธิภาพของ Cassandra
- ผ่าน data service ที่เขียนด้วย Rust และ ScyllaDB ทำให้สามารถจัดการทราฟฟิกได้อย่างมีประสิทธิภาพและเพิ่มสมรรถนะของระบบ
- ในกระบวนการย้ายข้อมูล มีการใช้วิธีที่รวดเร็วและมีประสิทธิภาพจนย้ายเสร็จได้โดยไม่มี downtime
- บทความนี้ว่าด้วยความท้าทายและแนวทางแก้ไขในการย้ายฐานข้อมูลขนาดใหญ่ จึงเป็นประโยชน์สำหรับผู้ที่สนใจการดูแลระบบขนาดใหญ่
1 ความคิดเห็น
ความเห็นจาก Hacker News
แม้โพสต์บล็อกจะตำหนิ GC แต่ปัญหาจริงอยู่ที่วิธีการใช้งาน Cassandra หรือวิธีที่ Cassandra จัดการกับการลบข้อมูลจำนวนมาก
ถ้าใช้โปรโตคอลแชตแบบกระจายศูนย์ ก็คงไม่มีปัญหาแบบนี้
ความเห็นเพิ่มเติมจากผู้ร่วมก่อตั้ง ScyllaDB
tombstone_gc=repairservice layer ทำให้นึกถึง Varnish Cache
การลบข้อความเก่าแทบเป็นไปไม่ได้เลย
เป็นบทความที่เขียนได้ดีมาก
จำนวนโหนดจัดเก็บข้อความของ Discord น้อยกว่าที่คาดไว้
การเก็บข้อมูลกับการทำ data mining เป็นคนละปัญหากัน
ทีม ScyllaDB ให้ความสำคัญกับการเพิ่มประสิทธิภาพ และได้ทำ reverse query ขึ้นมา
การสนทนาเกี่ยวกับ "How Discord Stores Trillions of Messages"