Rilis DiceDB

• DiceDB adalah database in-memory open source, berkinerja tinggi, dan reaktif
• Utamanya digunakan sebagai cache, serta menyediakan pembaruan data real-time melalui langganan kueri (query subscription)
• Dioptimalkan untuk perangkat keras modern sehingga menawarkan throughput tinggi dan latensi rendah
• Menyediakan antarmuka yang mudah digunakan dan familier, serta bersifat open source
• Benchmark performa
  • Throughput dan latensi GET/SET dibandingkan dengan database in-memory lain pada mesin Hetzner CCX23 (4 vCPU, 16GB RAM)
  • 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

[GN⁺]

Komentar Hacker News

• Ada banyak bug di kode ini

  • Misalnya, fungsi ExpandID tidak mengunci mutex global paket saat membaca dari cycleMap
  • Fungsi NextID mengunci mutex global paket saat menulis ke cycleMap
  • Penulisan memang tersinkronisasi satu sama lain, tetapi tidak tersinkronisasi dengan pembacaan, sehingga ada kemungkinan terjadi race condition saat ExpandID dan NextID dipanggil secara bersamaan
  • Untuk proyek hobi ini masih oke, tetapi masih jauh dari sistem yang layak diproduksi

• Saya punya beberapa pertanyaan soal desain setelah melihat codebase DiceDB

  • Saya ingin memahami tujuan proyek ini dan logika di balik desainnya
  • Penyimpanan utama di memori tampaknya berupa map Go standar yang memakai locking
  • Saya penasaran apakah ini pilihan sementara untuk pengembangan iteratif, atau ada rencana jangka panjang untuk beralih ke struktur data yang lebih optimal
  • Mekanisme reaktivitas DiceDB menarik, khususnya eksekusi ulang seluruh perintah watch
  • Fungsi Eval tampaknya menjalankan perintah di sisi klien, dan ini terlihat seperti fondasi untuk perintah watch yang lebih kompleks
  • Saya ingin tahu apa motivasi utama di balik mengeksekusi ulang seluruh perintah
  • Eksekusi ulang bisa menjadi operasi yang mahal secara komputasi, jadi saya penasaran bagaimana bottleneck performanya ditangani
  • Saya juga ingin tahu bagaimana pendekatan "eksekusi ulang" ini dibandingkan dengan metode lain dari sisi skalabilitas dan konsistensi
  • Saya penasaran apakah ada rencana mendukung perintah watch yang lebih kompleks selain GET.WATCH
  • Saya ingin tahu trade-off dari pilihan desain ini dan apakah ia selaras dengan tujuan proyek

• Saya penasaran apakah ada kalimat yang menjelaskan sebenarnya teknologi ini itu apa

• Lucu juga memakai alat kebetulan sebagai nama teknologi penyimpanan data

• DiceDB terdengar seperti nama database bercanda yang mengembalikan hasil acak

• Hasil benchmark pada 4vCPU dan num_clients=4 tidak terlalu berbeda jauh

  • Sisi reaktifnya terlihat menjanjikan, tetapi kegunaan praktisnya sebagai cache tampak rendah
  • Misalnya, saya penasaran bagaimana reaktivitasnya jika mesin mati saat klien sedang berlangganan

• Perbandingan performa DiceDB dan Redis

  • Throughput DiceDB adalah 15655 ops per detik, Redis 12267 ops
  • Perbandingan waktu respons GET p50 dan p90, serta SET p50 dan p90

• Saya tidak paham kenapa request GET memakan 20ms

  • Saya memang tidak punya banyak pengalaman dengan implementasi open source yang sudah ada, tetapi waktu respons in-memory di tempat kerja saya sebelumnya ada di kisaran puluhan hingga ratusan mikrodetik
  • Saya menduga dengan memakai io_uring hasil timing bisa lebih baik
  • Jika membaca dari NVMe dan melakukan pemulihan di 6 node, itu bisa memakan puluhan milidetik
  • Saya tidak paham kenapa angka seperti ini muncul pada RAM DB single-node

• Saya penasaran apakah ada yang punya pengalaman dengan key-value store open source berlatensi rendah dan throughput tinggi

  • Saya juga ingin tahu apakah ada implementasi tertentu yang bisa direkomendasikan

• Saya ingin tahu semantik pengiriman PubSub

  • Apakah best effort/at-most-once, atau ada retry
  • Saya penasaran dalam skenario seperti apa pesan bisa terkirim atau gagal

• 15655 ops per detik di mesin Hetzner CCX23 tergolong lambat untuk database in-memory

  • Tidak bisa menyalahkan latensi jaringan
  • supermassivedb.com ditulis dalam Go dan performanya jauh lebih tinggi
  • Bottleneck Dice perlu diselidiki

• Jauh lebih lambat daripada Nubmq