DiceDB veröffentlicht

 (dicedb.io)
5 Punkte von GN⁺ 2025-03-18 | 1 Kommentare | Auf WhatsApp teilen
  • DiceDB ist eine Open-Source-, hochperformante und reaktive In-Memory-Datenbank
  • Wird hauptsächlich als Cache verwendet und bietet über Query Subscription Echtzeit-Datenupdates
  • Für moderne Hardware optimiert und bietet hohen Durchsatz sowie niedrige Latenz
  • Bietet eine einfach zu nutzende und vertraute Oberfläche und ist Open Source
  • Performance-Benchmarks
    • Vergleich von Durchsatz sowie GET/SET-Latenzen mit anderen In-Memory-Datenbanken auf einer Hetzner-CCX23-Maschine (4 vCPU, 16 GB RAM)
    • Durchsatz (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

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-18
Hacker-News-Kommentare

  • Dieser Code enthält viele Bugs

    • Zum Beispiel sperrt die Funktion ExpandID beim Lesen aus cycleMap nicht den paketweiten globalen Mutex
    • Die Funktion NextID sperrt den paketweiten globalen Mutex beim Schreiben in cycleMap
    • Schreibzugriffe werden zwar untereinander synchronisiert, aber nicht mit Lesezugriffen; daher kann es bei gleichzeitigen Aufrufen von ExpandID und NextID zu Race Conditions kommen
    • Für ein Hobbyprojekt ist das in Ordnung, aber von einem produktionsreifen System ist es weit entfernt

  • Beim Blick auf die DiceDB-Codebasis habe ich einige Fragen zum Design

    • Ich möchte die Ziele dieses Projekts und die Logik hinter dem Design verstehen
    • Der primäre In-Memory-Store scheint eine Standard-Go-Map mit Sperren zu sein
    • Ich frage mich, ob das eine vorübergehende Entscheidung für die iterative Entwicklung ist oder ob es langfristige Pläne für eine stärker optimierte Datenstruktur gibt
    • Der reaktive Mechanismus von DiceDB ist interessant, insbesondere die erneute Ausführung kompletter Watch-Befehle
    • Die Eval-Funktion scheint clientseitige Befehle auszuführen; das wirkt wie eine Grundlage für komplexere Watch-Befehle
    • Ich frage mich, was die Hauptmotivation für die erneute Ausführung des vollständigen Befehls ist
    • Da die erneute Ausführung rechnerisch teuer sein kann, frage ich mich, wie Performance-Engpässe gelöst werden
    • Ich frage mich, wie sich dieser Ansatz der „erneuten Ausführung“ im Hinblick auf Skalierbarkeit und Konsistenz mit anderen Methoden vergleichen lässt
    • Ich frage mich, ob neben GET.WATCH auch komplexere Watch-Befehle unterstützt werden sollen
    • Ich frage mich nach den Trade-offs dieser Designentscheidung und danach, ob sie zu den Zielen des Projekts passt

  • Ich frage mich, ob es irgendwo einen Satz gibt, der erklärt, was diese Technologie eigentlich ist

  • Es ist lustig, ein Werkzeug des Zufalls als Namen für eine Datenspeichertechnologie zu verwenden

  • DiceDB klingt wie der Name einer Scherz-Datenbank, die zufällige Ergebnisse zurückgibt

  • Die Benchmark-Ergebnisse bei 4 vCPU und num_clients=4 unterscheiden sich nicht besonders stark

    • Das Reaktive wirkt vielversprechend, aber als Cache scheint es wenig praxisnah
    • Ich frage mich zum Beispiel, was mit der Reaktivität passiert, wenn der Rechner ausfällt, während ein Client abonniert ist

  • Leistungsvergleich zwischen DiceDB und Redis

    • Der Durchsatz von DiceDB liegt bei 15655 ops pro Sekunde, Redis bei 12267 ops
    • Vergleich der Antwortzeiten für GET p50 und p90 sowie SET p50 und p90

  • Ich verstehe nicht, warum ein GET-Request 20 ms braucht

    • Ich habe nicht viel Erfahrung mit bestehenden Open-Source-Implementierungen, aber bei meinem früheren Arbeitgeber lagen In-Memory-Antwortzeiten im Bereich von einigen Dutzend bis einigen Hundert Mikrosekunden
    • Mit io_uring würde ich bessere Timings erwarten
    • Wenn man von NVMe liest und eine Wiederherstellung über 6 Nodes durchführt, kann das einige Dutzend Millisekunden dauern
    • Ich verstehe nicht, wie solche Zahlen bei einer Single-Node-RAM-DB zustande kommen

  • Ich frage mich, ob jemand Erfahrung mit Open-Source-Key-Value-Stores mit geringer Latenz und hohem Durchsatz hat

    • Ich frage mich, ob jemand eine bestimmte Implementierung empfehlen kann

  • Ich würde gern etwas über die Zustellsemantik von PubSub wissen

    • Ich frage mich, ob es Best-Effort-/At-Most-Once-Zustellung ist oder ob es Retries gibt
    • Ich frage mich, in welchen Szenarien Nachrichten zugestellt werden oder fehlschlagen können

  • 15655 ops pro Sekunde auf einer Hetzner-CCX23-Maschine sind für eine In-Memory-Datenbank langsam

    • Man kann dafür nicht die Netzwerklatenz verantwortlich machen
    • supermassivedb.com ist in Go geschrieben und liefert deutlich mehr Performance
    • Die Bottlenecks von Dice sollten untersucht werden

  • Viel langsamer als Nubmq