murrdb/murr - Caché submilisegundo para cargas de trabajo de ML/AI

• Caché NVMe/S3 basado en RocksDB orientado a cargas de trabajo de inferencia de IA, capaz de reemplazar a Redis
  • Optimizado para lecturas y escrituras de baja latencia con zero-copy mediante procesamiento por lotes
• Capa de serving de datos ubicada entre pipelines de datos por lotes y apps de inferencia, con entrada Parquet y salida Arrow-Flight
• Almacenamiento por niveles (tiered storage) que mantiene los datos calientes en memoria, los fríos en disco, y aplica replicación basada en S3
• Funciona con entrada por lotes y salida por lotes sobre almacenamiento columnar sin sobrecarga por fila, y permite enviar archivos Parquet/Arrow de 1GB directamente al Ingestion API
• Con un protocolo de red zero-copy, permite construir np.ndarray/pd.DataFrame/pt.Tensor desde respuestas de API sin conversiones
• Diseño sin estado (stateless) que conserva todo el estado en S3 y hace bootstrap por sí mismo desde block storage, por lo que puede recuperarse incluso cuando se expulsa un nodo
• Soporte de primera clase para Python con mapeo zero-copy para arreglos de Numpy/Pandas/Polars/Pytorch; las columnas sparse ocupan 0 bytes cuando no tienen datos
• Casos en los que Murr encaja bien
  • Cuando los datos son pesados y tabulares, como grandes volcados de Parquet sobre S3
  • Cuando las lecturas se hacen por lotes: por ejemplo, traer 100 columnas a través de 1000 documentos
  • En escenarios sensibles al costo, descargar datos a disco/S3 es operativamente más simple y más barato que usar un Redis grande en memoria
• Ventajas frente a tecnologías competidoras
  • Frente a Redis: ofrece persistencia basada en S3 y permite descargar datos fríos a NVMe local
  • Frente a RocksDB embebido: no hace falta construir manualmente la sincronización de datos entre nodos productores y de inferencia; fue diseñado como distribuido desde el inicio
  • Frente a DynamoDB: cobra solo por CPU/RAM y no por consulta, por lo que resulta alrededor de 10 veces más barato
• En benchmarks, es aproximadamente 3 veces más rápido que Redis en lecturas de packed-blob y unas 12 veces más rápido que Feast-style HSET, usando además cerca de 3 veces menos RAM que HSET
• No es una base de datos de propósito general, por lo que se recomienda Postgres para OLTP, Clickhouse/BigQuery/Snowflake para analítica y Redis para caché general
• Licencia Apache 2.0