เปิดตัว DiceDB

 (dicedb.io)
5 คะแนน โดย GN⁺ 2025-03-18 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • DiceDB เป็นฐานข้อมูล in-memory แบบโอเพนซอร์ส ประสิทธิภาพสูง และตอบสนองได้รวดเร็ว
  • ใช้งานหลักเป็น แคช และให้ การอัปเดตข้อมูลแบบเรียลไทม์ ผ่าน query subscription
  • ปรับแต่งมาสำหรับฮาร์ดแวร์สมัยใหม่ จึงให้ทั้ง throughput สูงและ latency ต่ำ
  • ใช้งานง่าย มีอินเทอร์เฟซที่คุ้นเคย และเป็นโอเพนซอร์ส
  • เกณฑ์วัดประสิทธิภาพ
    • เปรียบเทียบ throughput และค่า latency ของ GET/SET กับฐานข้อมูล in-memory อื่น ๆ บนเครื่อง Hetzner CCX23 (4 vCPU, RAM 16GB)
    • throughput (ops/sec): DiceDB 15655, Redis 12267
    • GET p50(ms): DiceDB 0.227327, Redis 0.270335
    • GET p90(ms): DiceDB 0.337919, Redis 0.329727
    • SET p50(ms): DiceDB 0.230399, Redis 0.272383
    • SET p90(ms): DiceDB 0.339967, Redis 0.331775

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-03-18
ความคิดเห็นบน Hacker News

  • โค้ดนี้มีบั๊กอยู่มาก

    • ตัวอย่างเช่น ฟังก์ชัน ExpandID ไม่ได้ล็อก mutex ระดับแพ็กเกจตอนอ่านจาก cycleMap
    • ฟังก์ชัน NextID ล็อก mutex ระดับแพ็กเกจตอนเขียนลง cycleMap
    • การเขียนมีการซิงโครไนซ์กันเอง แต่ไม่ได้ซิงโครไนซ์กับการอ่าน จึงอาจเกิด race condition ได้เมื่อมีการเรียก ExpandID และ NextID พร้อมกัน
    • สำหรับโปรเจกต์งานอดิเรกก็พอใช้ได้ แต่ยังห่างไกลจากระบบที่พร้อมใช้งานจริง

  • มีคำถามบางอย่างเกี่ยวกับการออกแบบหลังจากดูโค้ดเบสของ DiceDB

    • อยากทำความเข้าใจเป้าหมายของโปรเจกต์นี้และเหตุผลเบื้องหลังการออกแบบ
    • ที่เก็บข้อมูลในหน่วยความจำหลักดูเหมือนจะเป็น Go map มาตรฐานที่มีการล็อก
    • เลยสงสัยว่านี่เป็นทางเลือกชั่วคราวเพื่อการพัฒนาแบบวนซ้ำ หรือมีแผนระยะยาวจะย้ายไปใช้โครงสร้างข้อมูลที่เหมาะสมกว่านี้
    • กลไก reactive ของ DiceDB โดยเฉพาะการรันคำสั่ง watch ทั้งชุดซ้ำอีกครั้งนั้นน่าสนใจ
    • ฟังก์ชัน Eval ดูเหมือนจะใช้รันคำสั่งฝั่งไคลเอนต์ ซึ่งดูเหมือนเป็นการวางรากฐานสำหรับคำสั่ง watch ที่ซับซ้อนขึ้น
    • อยากรู้ว่าแรงจูงใจหลักของการรันคำสั่งทั้งหมดซ้ำคืออะไร
    • การรันซ้ำอาจเป็นงานที่มีต้นทุนการคำนวณสูง เลยสงสัยว่าจะแก้ปัญหาคอขวดด้านประสิทธิภาพอย่างไร
    • อยากรู้ว่าแนวทาง "รันซ้ำ" นี้เมื่อเทียบกับวิธีอื่น ๆ เป็นอย่างไรในแง่ของการขยายระบบและความสม่ำเสมอ
    • อยากรู้ว่ามีแผนรองรับคำสั่ง watch ที่ซับซ้อนกว่า GET.WATCH หรือไม่
    • อยากรู้ถึง trade-off ของทางเลือกการออกแบบนี้ และมันสอดคล้องกับเป้าหมายของโปรเจกต์หรือไม่

  • สงสัยว่ามีประโยคที่อธิบายหรือไม่ว่าเทคโนโลยีนี้จริง ๆ แล้วคืออะไร

  • ขำดีที่เอาเครื่องมือแห่งความบังเอิญมาตั้งชื่อเป็นเทคโนโลยีจัดเก็บข้อมูล

  • DiceDB ฟังดูเหมือนชื่อฐานข้อมูลมุกตลกที่คืนค่าผลลัพธ์แบบสุ่ม

  • ผลเบนช์มาร์กบน 4vCPU และ num_clients=4 ดูไม่ต่างกันมาก

    • ความเป็น reactive ดูมีอนาคต แต่การใช้งานจริงในฐานะแคชดูไม่น่าจะเหมาะนัก
    • ตัวอย่างเช่น ถ้าเครื่องล่มตอนที่ไคลเอนต์กำลัง subscribe อยู่ จะยังคงความ reactive อย่างไร

  • การเปรียบเทียบประสิทธิภาพระหว่าง DiceDB กับ Redis

    • throughput ของ DiceDB อยู่ที่ 15655 ops ต่อวินาที ส่วน Redis อยู่ที่ 12267 ops
    • การเปรียบเทียบเวลา response ของ GET p50 และ p90, SET p50 และ p90

  • ไม่เข้าใจว่าทำไมคำขอ GET ถึงใช้เวลา 20ms

    • แม้จะไม่ได้มีประสบการณ์มากกับ implementation โอเพนซอร์สที่มีอยู่ แต่ที่ทำงานก่อนหน้านี้เวลา response แบบ in-memory อยู่ในระดับหลายสิบถึงหลายร้อยไมโครวินาที
    • ถ้าใช้ io_uring ก็น่าจะได้เวลาออกมาดีกว่านี้
    • หากอ่านจาก NVMe และทำ recovery จาก 6 โหนด ก็อาจใช้เวลาหลายสิบมิลลิวินาที
    • แต่ไม่เข้าใจว่าทำไมฐานข้อมูล RAM แบบโหนดเดียวถึงได้ตัวเลขแบบนี้

  • อยากรู้ว่ามีใครมีประสบการณ์กับคีย์-แวลูสโตร์โอเพนซอร์สที่ latency ต่ำและ throughput สูงบ้างไหม

    • อยากรู้ว่าสามารถแนะนำ implementation ไหนเป็นพิเศษได้บ้าง

  • อยากรู้เกี่ยวกับ semantics ของการส่ง PubSub

    • สงสัยว่าเป็นแบบ best-effort / at-most-once หรือมีการ retry
    • อยากรู้ว่ามีสถานการณ์ใดบ้างที่ข้อความจะถูกส่งถึงหรือส่งไม่สำเร็จ

  • 15655 ops ต่อวินาทีบนเครื่อง Hetzner CCX23 ถือว่าช้าสำหรับฐานข้อมูล in-memory

    • โทษ latency ของเครือข่ายไม่ได้
    • supermassivedb.com เขียนด้วย Go และทำประสิทธิภาพได้สูงกว่านี้มาก
    • ควรตรวจสอบคอขวดของ Dice

  • ช้ากว่า Nubmq มาก