Utilisation des requêtes graphiques SurrealDB pour alimenter les recommandations vidéo

Notre logique de recommandation chez ViralVidVault était autrefois une requête SQLite de 280 lignes avec six auto-jointures. Chaque fois qu’un visiteur européen terminait un clip viral, nous voulions répondre à une question : que devrait-on jouer ensuite ? La version honnête de cette question est un parcours graphique — « trouver les vidéos regardées par les personnes qui ont regardé cette vidéo, pondérées par récence et région » – mais nous l'avons forcé via un moteur relationnel qui traite les relations comme des tables de jointure. La requête a pris 400 ms sur un cache chaud et a expiré sur les caches froids. Pire encore, l'ajout d'un nouveau signal (affinité du créateur, chevauchement des balises, taux d'achèvement de la surveillance) signifiait une autre jointure et 50 ms supplémentaires.

Le modèle relationnel n’était pas erroné, il n’était simplement pas adapté à la forme des données. Les recommandations sont intrinsèquement un problème de graphique : les utilisateurs, les vidéos, les créateurs et les balises sont des nœuds, et "regardés", "publiés" et "marqués" sont des bords que vous souhaitez parcourir. Nous avons donc déplacé ce sous-système vers SurrealDB, conservé tout le reste sur notre pile PHP 8.4 / SQLite WAL, et la requête de la vidéo suivante est tombée à un délai cohérent de 12 à 30 ms. Cet article est la version pratique de la façon dont cela fonctionne, y compris les contraintes du RGPD qui ont façonné le schéma.

Pourquoi une base de données de graphiques pour « à regarder ensuite »

Le modèle de recommandation principal est le filtrage collaboratif par traversée. Étant donné la vidéo A, vous voulez :

• Utilisateurs qui ont regardé A (un saut)
• Autres vidéos regardées par ces utilisateurs (deuxième saut)
• Classés selon leur fréquence de cooccurrence, leur récence et leur pertinence régionale

En SQL, cela représente deux jointures via unmontrestableau plus agrégation. Dans une base de données graphique, il s'agit d'une expression de parcours unique, car les arêtes sont l'index. SurrealDB est intéressant ici spécifiquement parce qu'il est multi-modèle - il vous donne des bords de graphique (SE RAPPORTER), les champs de document et les requêtes de type SQL dans un seul moteur, via une API HTTP qui s'intègre dans une application PHP sans nouvel écosystème de pilotes.

Au-delà de la vitesse brute, certaines choses comptaient pour nous :

• Les arêtes portent des propriétés. Leregardémagasins de pointeachèvement,région, et un horodatage grossier, de sorte que le parcours lui-même puisse filtrer et pondérer san...
  [Courte citation de 8% de l'article original]