Pourquoi les fichiers de base de données et les fichiers multimédias se comportent-ils différemment sur un NAS domestique ?

Les fichiers de base de données et les fichiers multimédias se comportent différemment sur un NAS domestique car l’un est une collection mutable de pages tandis que l’autre est généralement un flux d’octets stable.

Les bases de données effectuent de petites lectures aléatoires, ajoutent des journaux de récupération, mettent à jour des index et attendent des validations durables. La lecture multimédia lit de longues plages dans l’ordre et peut précharger les données. Les deux peuvent occuper le même nombre de gigaoctets, mais ils sollicitent la latence, le cache, les enregistrements du système de fichiers et les files d’attente du disque de manière très différente.

Les fichiers de base de données sont des pages mutables ; les fichiers multimédias sont des flux stables

Un moteur de base de données traite ses fichiers comme des pages structurées. Une requête peut récupérer une page d’index étroite, puis passer à plusieurs pages de données non liées. Une mise à jour peut toucher les données, l’index, le journal des transactions, puis plus tard un point de contrôle. Un aperçu concis des modèles d’E/S de base de données explique pourquoi les journaux et les fichiers de données peuvent avoir des profils de latence différents dans un même moteur.

Un fichier de film ou de musique finalisé est généralement immuable pendant la lecture. Le lecteur avance à travers de longues plages et a rarement besoin de réécrire des octets précédents. Cette prévisibilité permet au système d’exploitation et au dispositif de stockage de combiner les requêtes et de précharger les données à venir.

La durabilité fait attendre les écritures de la base de données

De nombreuses bases de données utilisent la journalisation anticipée : un enregistrement de modification doit atteindre un stockage stable avant que la page de données modifiée puisse être considérée comme validée en toute sécurité. La séquence de journalisation anticipée montre pourquoi un petit ajout séquentiel au journal peut se trouver sur le chemin critique même lorsque sa bande passante est minime.

Les points de contrôle flushent ensuite les pages modifiées par lots, ajoutant une seconde forme d’E/S. Cela signifie qu’une base de données peut alterner entre des validations courtes sensibles à fsync et des écritures en arrière-plan lourdes. Un SSD peut améliorer les deux, mais les chiffres de débit multimédia ne prédisent toujours pas le temps de réponse de la base de données car celle-ci attend souvent la latence de complétion plutôt que les mégaoctets par seconde.

La lecture multimédia profite du préchargement et de l’accès par plages

La détection séquentielle permet au noyau de récupérer les données avant que le lecteur ne les demande. Dans un exemple NFS, l’augmentation du préchargement du système de fichiers réseau a considérablement augmenté le débit pour les gros fichiers séquentiels, tandis que l’auteur avertit aussi qu’un préchargement excessif peut gaspiller des ressources lors d’un accès semi-aléatoire.

Les lecteurs peuvent aussi demander des plages d’octets sélectionnées au démarrage ou lors d’une recherche. Une explication pratique des requêtes par plages vidéo montre comment le client saute à une portion d’un gros fichier sans tout télécharger avant. Ces requêtes sont plus grandes et plus prévisibles qu’une navigation dans un index de base de données, même lorsque les deux arrivent par le réseau.

Les bibliothèques multimédias génèrent toujours un travail annexe de type base de données

La charge utile multimédia peut être séquentielle, mais la bibliothèque autour ne l’est pas. Affiches, vignettes, sous-titres, historique de visionnage, index de recherche et bases de données de métadonnées créent une activité de petits fichiers et de base de données. Un balayage peut lire chaque en-tête multimédia tout en écrivant des milliers de dérivés minuscules.

Cela explique pourquoi la lecture peut être fluide alors que la navigation dans la bibliothèque ou la génération de vignettes semble lente. Le chemin des gros fichiers est sain ; la base de données annexe attend des E/S aléatoires ou un journal occupé. Tester une seule copie de film ne reflète pas la charge de travail avec laquelle les utilisateurs interagissent réellement.

Un NAS peut servir les deux, mais le goulot d’étranglement change

Utilisez des ensembles de données ou volumes spécifiques à la charge de travail lorsque la plateforme les supporte. Les gros enregistrements et le préchargement conviennent aux médias stables, tandis que le stockage de base de données bénéficie d’une faible latence, d’un alignement de page adapté, d’un cache conservateur et d’écritures synchrones fiables. Des pools physiques séparés offrent une isolation plus forte quand un balayage multimédia bloque à répétition le travail de la base de données.

Ne vous fiez pas uniquement aux extensions de fichiers pour régler les paramètres. Mesurez la latence de validation de la base de données et les ratés de cache à côté du débit de lecture multimédia et de la mise en tampon. Une comparaison actuelle du réglage du préchargement rend la distinction utile : les sauvegardes séquentielles et les charges vidéo peuvent bénéficier d’un préchargement plus important, tandis que l’accès aléatoire aux bases de données peut gaspiller de la bande passante si la même politique est appliquée sans discernement.

FAQ

Un benchmark NAS séquentiel rapide prouve-t-il qu’une base de données sera rapide ?

Non. Il mesure une charge de travail plus proche du transfert multimédia. Les performances de la base de données dépendent fortement des IOPS aléatoires, de la mise en file d’attente, de la latence fsync, du comportement du cache et des interférences des points de contrôle.

Les fichiers multimédias et de base de données doivent-ils toujours utiliser des SSD séparés ?

Pas toujours. Les charges légères peuvent coexister. La séparation devient utile lorsque les balayages, transcodages ou transferts provoquent des pics de latence répétitifs dans la base de données que la planification et les politiques d’ensemble de données ne peuvent pas contrôler.

Pourquoi la navigation multimédia peut-elle être lente alors que la lecture est fluide ?

La navigation interroge souvent une base de données et ouvre de nombreuses vignettes ou fichiers annexes. La lecture lit généralement quelques longues plages et précharge, sollicitant donc une partie différente du chemin de stockage.