- เมื่อ Discord เติบโตขึ้น ก็เปลี่ยนฐานข้อมูลสำหรับจัดเก็บข้อความอย่างต่อเนื่อง
- ช่วงแรกใช้ MongoDB แบบเครื่องเดียว แต่เมื่อจำนวนข้อความเพิ่มเป็น 100 ล้านข้อความในเดือนพฤศจิกายน 2015 ข้อจำกัดของ MongoDB ก็เริ่มชัดเจน
- ในปี 2017 จึงย้ายไปใช้ Cassandra แบบคลัสเตอร์ 12 โหนด เพื่อจัดเก็บข้อความระดับหลายพันล้านข้อความ
- ในปี 2022 จำนวนข้อความพุ่งขึ้นเป็นระดับหลายล้านล้าน ทำให้อินฟราสตรักเจอร์ขยายใหญ่ถึง 177 โหนด ความหน่วงคาดเดาได้ยาก และค่าบำรุงรักษาสูงมาก
- ปัญหาของ Discord บน Cassandra คือ Hot Partition
- บางส่วนของ DB ถูกใช้งานหนักเกินไป จนทำให้ประสิทธิภาพของแอปพลิเคชันโดยรวมลดลง
- เนื่องจากโครงสร้างข้อมูลภายในของ Cassandra ใช้ LSM tree ต้นทุนการอ่านจึงสูงกว่าการเขียน และการอ่านพร้อมกันของผู้ใช้หลายคนบนเซิร์ฟเวอร์เดียวสามารถสร้าง hotspot และนำไปสู่ประสิทธิภาพที่ลดลง
- งานบำรุงรักษาอย่างการบีบอัด SSTable ส่งผลต่อประสิทธิภาพโดยรวมและยิ่งทำให้ปัญหารุนแรงขึ้น
- ดังนั้นจึงเริ่มออกแบบสถาปัตยกรรมใหม่โดยรวมองค์ประกอบหลายส่วนเข้าด้วยกัน
- ใช้ทั้ง monolithic API, data service ที่พัฒนาด้วย Rust และระบบสตอเรจบนพื้นฐานของ ScyllaDB (ฐานข้อมูลที่เข้ากันได้กับ Cassandra ซึ่งพัฒนาด้วย C++)
- หลังจากนำ ScyllaDB มาใช้ ก็เกิดการปรับปรุงอย่างมีนัยสำคัญ
- p99 read latency ลดลงเหลือ 15ms เทียบกับ 40~125ms ของ Cassandra
- p99 write latency ลดลงเหลือ 5ms เทียบกับ 5~70ms ของ Cassandra
- วิศวกรของ Discord เขียน data service ด้วย Rust
- ใช้ความสามารถ Fearless Concurrency ของ Rust เพื่อควบคุมทราฟฟิกพร้อมกันที่เกิดกับ hot partition
- ไลบรารีและความสามารถด้าน concurrency ของ Rust เหมาะกับข้อกำหนดของ Discord อย่างมาก
- data service ทำหน้าที่เป็นบริการตัวกลางระหว่าง API monolith กับคลัสเตอร์ฐานข้อมูล
3 ความคิดเห็น
กำลังสนใจศึกษาสตैकเทคโนโลยีของ Discord อยู่พอดี ขอบคุณครับ!
วิธีที่ Discord จัดเก็บข้อความนับพันล้านรายการ
GC ของ Go มีโอเวอร์เฮดค่อนข้างสูง จึงมีการเพิ่มวิธีปรับจูนอย่างต่อเนื่อง รวมถึงมีการนำ memory arena มาใช้ด้วย
ทำไมควรเลือก ScyllaDB เป็นตัวแทนของ Cassandra
Discord ลดเวลาแฝงของดิสก์บนเครือข่ายให้ต่ำที่สุดได้อย่างไร