Lancement de DiceDB

 (dicedb.io)
5 points par GN⁺ 2025-03-18 | 1 commentaires | Partager sur WhatsApp
  • DiceDB est une base de données in-memory open source, haute performance et réactive
  • Elle est principalement utilisée comme cache et fournit des mises à jour de données en temps réel via la subscription aux requêtes (query subscription)
  • Optimisée pour le matériel récent, elle offre un débit élevé et une faible latence
  • Elle propose une interface simple à utiliser et familière, tout en étant open source
  • Benchmark de performance
    • Débit et latence GET/SET comparés à d'autres bases de données in-memory sur une machine Hetzner CCX23 (4 vCPU, 16GB RAM)
    • Débit (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

À lire aussi

1 commentaires

 
GN⁺ 2025-03-18
Commentaires sur Hacker News

  • Ce code contient de nombreux bugs

    • Par exemple, la fonction ExpandID ne verrouille pas le mutex global du package lors de la lecture depuis cycleMap
    • La fonction NextID verrouille le mutex global du package lors de l’écriture dans cycleMap
    • Les écritures sont synchronisées entre elles, mais pas avec les lectures, ce qui peut entraîner une condition de course lors d’appels concurrents à ExpandID et NextID
    • C’est acceptable comme projet hobby, mais c’est loin d’un système exploitable en production

  • J’ai quelques questions sur le design en regardant la base de code de DiceDB

    • J’aimerais comprendre les objectifs du projet et la logique derrière sa conception
    • Le stockage principal en mémoire semble être une map Go standard avec verrouillage
    • Je me demande s’il s’agit d’un choix temporaire pour un développement itératif, ou s’il existe un plan à long terme vers une structure de données plus optimisée
    • Le mécanisme réactif de DiceDB, en particulier la réexécution complète des commandes watch, est intéressant
    • La fonction Eval semble exécuter des commandes côté client, ce qui paraît poser les bases pour des commandes watch plus complexes
    • Je me demande quelle est la motivation principale derrière la réexécution complète des commandes
    • Comme la réexécution peut être coûteuse en calcul, je me demande comment les goulets d’étranglement de performance sont traités
    • Je me demande comment cette approche de « réexécution » se compare à d’autres méthodes en matière de scalabilité et de cohérence
    • Je me demande s’il est prévu de prendre en charge des commandes watch plus complexes au-delà de GET.WATCH
    • Je m’interroge sur les compromis de ce choix de conception et sur son alignement avec les objectifs du projet

  • Je me demande s’il y a une phrase qui explique ce qu’est réellement cette technologie

  • C’est amusant d’utiliser un outil du hasard comme nom pour une technologie de stockage de données

  • DiceDB sonne comme le nom d’une base de données blague qui renvoie des résultats aléatoires

  • Les résultats de benchmark en 4 vCPU et num_clients=4 ne sont pas très différents

    • L’aspect réactif semble prometteur, mais l’intérêt pratique comme cache paraît faible
    • Par exemple, je me demande ce qu’il advient de la réactivité si la machine tombe en panne pendant qu’un client est abonné

  • Comparaison des performances entre DiceDB et Redis

    • Le débit de DiceDB est de 15 655 ops par seconde, contre 12 267 ops pour Redis
    • Comparaison des temps de réponse pour GET p50 et p90, ainsi que SET p50 et p90

  • Je ne comprends pas pourquoi une requête GET consomme 20 ms

    • Je n’ai pas beaucoup d’expérience avec les implémentations open source existantes, mais dans mon précédent emploi, les temps de réponse en mémoire étaient de l’ordre de quelques dizaines à quelques centaines de microsecondes
    • Avec io_uring, je m’attendrais à de meilleurs timings
    • Lire depuis du NVMe et effectuer une reprise sur 6 nœuds peut prendre des dizaines de millisecondes
    • Je ne comprends pas comment on obtient de tels chiffres sur une base de données RAM mono-nœud

  • Je me demande si quelqu’un a de l’expérience avec des magasins clé-valeur open source à faible latence et haut débit

    • Je me demande si vous pouvez recommander une implémentation particulière

  • J’aimerais en savoir plus sur les sémantiques de livraison de PubSub

    • Je me demande s’il s’agit d’un best effort / au plus une fois, ou s’il y a des tentatives de retransmission
    • Je me demande dans quels scénarios les messages peuvent être livrés ou échouer

  • 15 655 ops par seconde sur une machine Hetzner CCX23, c’est lent pour une base de données en mémoire

    • On ne peut pas rejeter la faute sur la latence réseau
    • supermassivedb.com est écrit en Go et offre des performances bien supérieures
    • Il faudrait examiner les goulets d’étranglement de Dice

  • Beaucoup plus lent que Nubmq