Contexte et exigences
Les modèles de recommandation modernes traitent des historiques d’utilisateurs très longs et riches en attributs. Cette caractéristique impose des mises à jour continues de petite taille tout en exigeant des lectures massives de séquences complètes. L’asymétrie ainsi créée entre écriture (fréquente, petite) et lecture (volumineuse, répétée) devient un goulet d’étranglement pour les systèmes de stockage classiques, notamment lorsqu’ils doivent alimenter à la fois les pipelines d’inférence en temps réel et les jobs de formation batch.
Architecture de USDB
USDB (Unified Sequence DataBase) introduit une chaîne de compaction dite CascadeLSM, où chaque étape est déclenchée par le temps écoulé plutôt que par la taille du fichier. Cette approche matérialise des historiques spécifiques à l’application, tout en conservant des répliques différenciées qui partagent les fichiers persistants. Les « partial dumps » permettent de reconstruire les entrées d’inférence à partir d’un état récent capturé et d’un historique versionné. Enfin, un format hybride columnar accélère les lectures projetées en limitant le volume de données à scanner. L’ensemble de ces mécanismes est réutilisé lors de l’ingestion, de l’inférence et de la formation, évitant ainsi des traitements redondants.
Performances et bénéfices
Les mesures de migration en production indiquent une réduction de 85,8 % de la latence moyenne d’écriture et une baisse de 42,1 % du coût d’infrastructure normalisé. Comparé à une base RocksDB optimisée pour les séquences, USDB offre des lectures plus rapides sur des historiques longs, tant pour les projections que sous des charges client variées. L’agrégation poussée (« aggregation pushdown ») maintient un débit 8,5 fois supérieur à celui des lectures classiques lorsqu’un budget de réception est limité. Ces gains se traduisent par une capacité à servir des recommandations fraîches tout en conservant un accès efficace aux données historiques.
Implications et limites
Le partage de la maintenance des séquences entre ingestion, inference et entraînement montre que la même infrastructure peut supporter des exigences de fraîcheur et de réutilisation massive. Cependant, la complexité introduite par la compaction temporelle et le versionnage des historiques peut augmenter la charge de métadonnées et requérir une surveillance fine des seuils de déclenchement. De plus, l’étude ne fournit pas de métriques détaillées sur la consommation CPU ou la latence de reconstruction, ce qui limite l’évaluation complète de l’impact sur les environnements à forte contrainte de ressources.
