Lanzamiento de DiceDB

 (dicedb.io)
5 puntos por GN⁺ 2025-03-18 | 1 comentarios | Compartir por WhatsApp
  • DiceDB es una base de datos en memoria (in-memory) de código abierto, de alto rendimiento y reactiva
  • Se usa principalmente como caché y ofrece actualizaciones de datos en tiempo real mediante suscripción a consultas (query subscription)
  • Está optimizada para hardware moderno y ofrece alto rendimiento y baja latencia
  • Proporciona una interfaz fácil de usar y familiar, y es de código abierto
  • Benchmark de rendimiento
    • Comparación del rendimiento y la latencia de GET/SET frente a otras bases de datos en memoria en una máquina Hetzner CCX23 (4 vCPU, 16 GB RAM)
    • Rendimiento (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

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-03-18
Comentarios de Hacker News

  • Este código tiene muchos errores

    • Por ejemplo, la función ExpandID no bloquea el mutex global del paquete al leer de cycleMap
    • La función NextID sí bloquea el mutex global del paquete al escribir en cycleMap
    • Las escrituras se sincronizan entre sí, pero no con las lecturas, así que puede haber una condición de carrera si ExpandID y NextID se llaman al mismo tiempo
    • Está bien como proyecto hobby, pero está muy lejos de ser un sistema listo para producción

  • Tengo algunas preguntas sobre el diseño al ver el codebase de DiceDB

    • Quiero entender el objetivo de este proyecto y la lógica detrás del diseño
    • El almacenamiento principal en memoria parece ser un mapa estándar de Go con bloqueo
    • Me pregunto si esta es una elección temporal para desarrollo iterativo o si hay un plan a largo plazo para pasar a una estructura de datos más optimizada
    • El mecanismo reactivo de DiceDB, en particular la reejecución de comandos completos de observación, me parece interesante
    • La función Eval parece ejecutar comandos del lado del cliente, y eso da la impresión de estar sentando las bases para comandos de observación más complejos
    • Me pregunto cuál es la motivación principal para reejecutar el comando completo
    • Como la reejecución puede ser una operación costosa en términos de cómputo, me pregunto cómo se resuelven los cuellos de botella de rendimiento
    • Me pregunto cómo se compara este enfoque de "reejecución" con otros métodos en términos de escalabilidad y consistencia
    • Me pregunto si hay planes para soportar comandos de observación más complejos además de GET.WATCH
    • Me interesan los trade-offs de esta elección de diseño y si está alineada con los objetivos del proyecto

  • Me pregunto si hay alguna frase que explique qué es realmente esta tecnología

  • Es gracioso usar una herramienta de azar como nombre para una tecnología de almacenamiento de datos

  • DiceDB suena como el nombre de una base de datos en broma que devuelve resultados aleatorios

  • Los resultados del benchmark con 4vCPU y num_clients=4 no son muy distintos

    • Lo reactivo se ve prometedor, pero no parece muy práctico como caché
    • Por ejemplo, me pregunto qué pasa con la reactividad si la máquina se cae mientras el cliente está suscrito

  • Comparación de rendimiento entre DiceDB y Redis

    • El throughput de DiceDB es de 15655 ops por segundo, Redis de 12267 ops
    • Comparación de tiempos de respuesta de GET p50 y p90, y de SET p50 y p90

  • No entiendo por qué una solicitud GET consume 20ms

    • No tengo mucha experiencia con implementaciones open source existentes, pero en mi trabajo anterior los tiempos de respuesta en memoria eran de decenas a cientos de microsegundos
    • Esperaría mejores tiempos usando io_uring
    • Leer desde NVMe y hacer recuperación en 6 nodos puede tomar decenas de milisegundos
    • No entiendo cómo salen esos números en una DB en RAM de un solo nodo

  • Me pregunto si alguien tiene experiencia con almacenes clave-valor open source de alta concurrencia y baja latencia

    • Me pregunto si pueden recomendar una implementación específica

  • Quiero saber sobre la semántica de entrega de PubSub

    • Me pregunto si es best effort / entrega como máximo una vez, o si hay reintentos
    • Me pregunto en qué escenarios un mensaje puede entregarse o fallar

  • 15655 ops por segundo en una máquina Hetzner CCX23 es lento para una base de datos en memoria

    • No se puede culpar a la latencia de red
    • supermassivedb.com está escrito en Go y ofrece mucho más rendimiento
    • Hay que investigar los cuellos de botella de Dice

  • Es mucho más lento que Nubmq