2 คะแนน โดย GN⁺ 2024-09-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

บทนำ

  • ในปี 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 ความคิดเห็น

 
GN⁺ 2024-09-29
ความเห็นจาก Hacker News
  • แม้โพสต์บล็อกจะตำหนิ GC แต่ปัญหาจริงอยู่ที่วิธีการใช้งาน Cassandra หรือวิธีที่ Cassandra จัดการกับการลบข้อมูลจำนวนมาก

    • "เมื่อมีการลบข้อความหลายล้านข้อความผ่าน API, Cassandra ต้องสแกน tombstone หลายล้านรายการ"
    • มีการพูดถึงการปรับแต่ง GC แต่จริง ๆ แล้วกำลังใช้ Cassandra และ JVM เวอร์ชันเก่า
  • ถ้าใช้โปรโตคอลแชตแบบกระจายศูนย์ ก็คงไม่มีปัญหาแบบนี้

    • มีทั้งสเปกแบบเปิดและหลาย implementation เช่น IRC, Matrix, XMPP
    • ยากที่จะเข้าใจว่า Discord ครองตลาดได้อย่างไร
  • ความเห็นเพิ่มเติมจากผู้ร่วมก่อตั้ง ScyllaDB

    • Discord ไม่สามารถทำ repair ให้เสร็จบน Cassandra ได้ แต่ทำได้บน Scylla
    • Scylla มีหลายอย่างร่วมกับ Cassandra แต่จัดลำดับความสำคัญของคิวรีผ่าน CPU และ IO scheduler ของตัวเอง
    • Scylla มีโหมดใหม่ tombstone_gc=repair
    • สถาปัตยกรรม Raft และ tablet แบบใหม่ของ Scylla เพิ่งเปิดตัวไม่นานนี้
  • service layer ทำให้นึกถึง Varnish Cache

    • แม้จะไม่ได้พูดถึงการแคช แต่คล้ายกับ "grace mode" ของ Varnish
    • เป็นเรื่องดีที่ได้เห็น consistent hashing ปรากฏขึ้นซ้ำ ๆ
  • การลบข้อความเก่าแทบเป็นไปไม่ได้เลย

    • นี่คือฝันร้ายด้านความเป็นส่วนตัว และน่าสงสัยว่าทำไม EU ถึงยังไม่เข้ามาจัดการ
  • เป็นบทความที่เขียนได้ดีมาก

    • การย้ายจาก Cassandra ไป Scylla ก็เป็นส่วนหนึ่งของแนวทางแก้ปัญหา
  • จำนวนโหนดจัดเก็บข้อความของ Discord น้อยกว่าที่คาดไว้

    • เดิมคิดว่าน่าจะมีสถาปัตยกรรมที่ซับซ้อนกว่านี้ แต่จริง ๆ ใช้เพียง 200 โหนด
    • ดูเหมือนว่าสถาปัตยกรรมคลาวด์สมัยใหม่จะถูกออกแบบเกินความจำเป็น
  • การเก็บข้อมูลกับการทำ data mining เป็นคนละปัญหากัน

  • ทีม ScyllaDB ให้ความสำคัญกับการเพิ่มประสิทธิภาพ และได้ทำ reverse query ขึ้นมา

    • สงสัยว่าก่อนจะใช้ ScyllaDB ต้องจ่ายไปมากแค่ไหน
  • การสนทนาเกี่ยวกับ "How Discord Stores Trillions of Messages"

    • ในเดือนมีนาคม 2023 มีความคิดเห็น 10 รายการ