Comment Plaud a fait évoluer son architecture de données au-delà de 300 millions de lignes

Le fabricant de matériels IA Plaud a restructuré l'architecture de ses données backend après que sa configuration relationnelle initiale a rencontré des goulots d'étranglement d'évolutivité aux alentours de 300 millions de lignes. En migrant sa couche de métadonnées structurées vers TiDB, l'équipe a levé les contraintes sur les modifications de schéma et augmenté sa capacité de requêtes tout en conservant une latence P95 inférieure à 10 millisecondes.

Le goulot d'étranglement du stockage séparé des transcriptions

Plaud avait initialement mis en œuvre un modèle classique de stockage à deux niveaux, plaçant les métadonnées structurées dans MySQL et les fichiers audio bruts ou transcriptions dans Amazon S3. Bien qu'efficace pour démarrer, la séparation des métadonnées et des contenus a créé des défis architecturaux. En l'absence de frontière transactionnelle partagée entre ces deux emplacements, la cohérence des données reposait sur la logique de réconciliation au niveau de la couche applicative.

À mesure que le nombre d'accès simultanés augmentait, s'appuyer sur le stockage objet comme canal principal pour des contenus de plusieurs mégaoctets a généré une latence de récupération variable. De plus, des pics de latence et des retards de réplication risquaient de créer des écarts temporaires de cohérence, où les métadonnées indiquaient qu'une transcription était prête avant même que l'objet S3 correspondant ne soit accessible.

Contraintes de schéma à 300 millions de lignes

Lorsque le magasin de métadonnées MySQL monoposte a atteint environ 300 millions de lignes, les modifications de schéma sont devenues de plus en plus risquées. Les opérations de langage de définition de données (DDL) nécessitaient des verrouillages de tables et provoquaient une forte pression sur la réplication, contraignant l'équipe d'ingénierie à planifier les mises à jour lors de fenêtres de maintenance dédiées.

Ce plafond imposé par la base de données a impacté la livraison des fonctionnalités. Des modifications de routine, telles que l'ajout de colonnes ou la modification d'index, se sont retrouvées liées aux cycles de maintenance opérationnelle plutôt qu'à un calendrier de déploiement flexible.

Migration des métadonnées vers le SQL distribué

Afin de lever cette limite d'évolutivité, Plaud a migré sa couche de métadonnées structurées vers TiDB, une base de données SQL distribuée, tout en conservant les fichiers audio volumineux dans le stockage objet. Cette architecture actualisée a rendu possible l'exécution de DDL en ligne, permettant d'effectuer des mises à jour de schéma sans nécessiter d'interruption de service.

La migration a multiplié par dix environ la capacité de traitement des requêtes par seconde de Plaud, tout en maintenant la latence maximale sous le seuil des 10 millisecondes. Cela a empêché les délais de récupération de données de dégrader l'expérience de l'utilisateur final.

Illustration éditoriale générée par IA ; ce n’est pas une photographie documentaire.

Source: The Database Is the Product: What Breaks When Memory Devices Scale