murrdb/murr - Cache sub-milliseconde pour les workloads ML/IA

• Cache NVMe/S3 basé sur RocksDB visant les workloads d’inférence IA, pouvant remplacer Redis
  • Optimisé pour des lectures et écritures zero-copy à faible latence en mode batch
• Couche de data serving située entre les pipelines de données batch et les applications d’inférence, avec entrée Parquet et sortie Arrow-Flight
• Stockage hiérarchisé (tiered storage) avec données chaudes en mémoire, données froides sur disque, et réplication basée sur S3
• Fonctionne en entrée batch / sortie batch au-dessus d’un stockage colonnaire, sans surcoût ligne par ligne, avec possibilité d’envoyer directement des fichiers Parquet/Arrow de 1 Go dans l’API d’ingestion
• Grâce à un protocole réseau zero-copy, les réponses API peuvent être construites en np.ndarray / pd.DataFrame / pt.Tensor sans conversion
• Architecture stateless conservant tout l’état dans S3, avec auto-amorçage depuis le stockage bloc, permettant la reprise même lors de l’éviction d’un nœud
• Support Python de premier plan avec mapping zero-copy pour les tableaux Numpy/Pandas/Polars/Pytorch, et Sparse columns où les colonnes sans données occupent 0 octet
• Cas où Murr est pertinent
  • Lorsque les données sont volumineuses et tabulaires, comme de gros dumps Parquet sur S3
  • Lorsque les lectures se font par batch : par exemple récupérer 100 colonnes sur 1000 documents
  • Dans les contextes sensibles aux coûts, l’offload vers disque/S3 est plus simple à exploiter et moins cher qu’un Redis fortement dimensionné en mémoire
• Points forts face aux technologies concurrentes
  • Face à Redis : persistance basée sur S3 et possibilité de déporter les données froides vers le NVMe local
  • Face à RocksDB embarqué : pas besoin de construire soi-même la synchronisation des données entre producteurs et nœuds d’inférence, le système est distribué dès l’origine
  • Face à DynamoDB : facturation sur le CPU/RAM plutôt que par requête, pour un coût annoncé d’environ 10 fois inférieur
• D’après les benchmarks, environ 3 fois plus rapide que Redis en lecture de packed blobs, et environ 12 fois plus rapide qu’un HSET de style Feast, avec une consommation RAM environ 3 fois plus faible que HSET
• Ce n’est pas une base de données généraliste : pour l’OLTP, Postgres est recommandé ; pour l’analytique, Clickhouse/BigQuery/Snowflake ; pour le caching généraliste, Redis
• Licence Apache 2.0