Pourquoi les métadonnées d’Immich augmentent-elles lors de la sauvegarde des photos de famille ?

Les métadonnées d’Immich augmentent lors de la sauvegarde des photos familiales, car chaque original crée des enregistrements d’application et peut également créer des miniatures, des vecteurs de recherche, des données faciales et d’autres états dérivés.

Cette croissance ne correspond pas à un pourcentage uniforme de la bibliothèque originale. Un foyer contenant de nombreuses petites images, de longues vidéos, de nombreux visages ou un traitement de recherche intensif peut générer un profil de surcharge différent de celui d’une autre famille disposant des mêmes téraoctets de sources. Distinguez l’état de la base de données des fichiers générés avant de déterminer si la croissance est normale.

Chaque élément ajoute des enregistrements d’application persistants

La base de données doit contenir des enregistrements reliant un élément à son propriétaire, son chemin, ses horodatages, ses albums, ses autorisations et d’autres propriétés visibles dans l’application. À mesure que le nombre d’éléments et de relations augmente, cet état persistant augmente lui aussi, même lorsque les fichiers originaux sont stockés ailleurs.

Un aperçu du dimensionnement du stockage qui distingue la surcharge de la base de données des miniatures et des originaux est utile, car ces éléments évoluent différemment. Les chiffres donnés en exemple doivent être considérés comme des observations propres à un déploiement, et non comme un ratio garanti pour une autre bibliothèque familiale.

Le nombre d’éléments constitue donc un meilleur point de départ que les gigaoctets de sources pour certaines questions relatives aux métadonnées. Dix mille grandes vidéos et dix mille petites photos peuvent occuper des capacités originales très différentes, tout en nécessitant toutes deux des enregistrements et des relations au niveau des éléments dans la base de données de l’application.

Les fichiers générés pour la navigation ajoutent une courbe de stockage distincte

La navigation dans la chronologie repose sur des représentations plus petites, plus rapides à afficher que l’ouverture de chaque original. Ces fichiers générés ne sont pas des métadonnées de base de données au sens strict, mais ils sont souvent perçus comme une « surcharge d’Immich », car ils augmentent avec la bibliothèque et sont gérés par l’application.

La répartition du stockage en quatre services présentée dans un déploiement de laboratoire domestique distingue les photos, les médias générés et l’emplacement de la base de données. Cette séparation est importante sur le plan opérationnel, car les fichiers dérivés à forte rotation et l’état critique de la base de données n’ont pas le même rôle en matière de sauvegarde ou de performances.

Ne déduisez pas cette courbe uniquement à partir de la taille des originaux. Le nombre de miniatures dépend du nombre d’éléments et des tailles activées, tandis que les fichiers vidéo encodés dépendent de la compatibilité des vidéos et des paramètres de transcodage. Mesurez chaque répertoire généré séparément, une fois le traitement du même groupe terminé.

La recherche et les fonctions faciales ajoutent un état d’indexation

La recherche sémantique et les fonctions de reconnaissance faciale créent des représentations numériques et des relations qui rendent les contenus visuels accessibles sans réécrire l’image originale. Un plus grand nombre d’éléments traités, de visages détectés et de fonctions d’analyse activées ajoute donc progressivement un état lié à la base de données et aux modèles.

L’explication des représentations sémantiques montre pourquoi un index de recherche visuelle peut augmenter même lorsque les noms de fichiers et les dossiers restent inchangés. Le modèle transforme chaque image admissible en une représentation réutilisable, ensuite disponible pour des comparaisons avec des requêtes textuelles.

Cet état ne doit pas être confondu avec une seconde copie en pleine résolution. Si la croissance de la base de données liée à la recherche se poursuit rapidement alors que le nombre d’éléments, les paramètres des fonctions et l’inventaire des modèles restent stables, recherchez un problème de maintenance, un traitement en double ou un autre mécanisme de la base de données au lieu de supposer qu’une indexation normale l’explique.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

L’organisation familiale ajoute des relations, pas seulement des fichiers

Les albums, les noms de personnes, les relations de partage, les favoris, les modifications et les autres actions des utilisateurs peuvent accroître les métadonnées de l’application indépendamment des nouveaux originaux. Deux familles disposant de médias identiques peuvent donc avoir des empreintes de base de données différentes, car l’une utilise davantage de fonctions d’organisation et de partage.

La présentation par ZimaSpace de l’organisation des photos met en évidence la distinction entre les originaux centralisés et les personnes, lieux, événements et albums consultables qui leur sont superposés. Ces relations font partie de l’expérience utilisateur et doivent être prises en compte dans la planification de la récupération.

Ce mécanisme n’explique plus une croissance importante et inexpliquée des journaux, des couches inscriptibles des conteneurs, des fichiers temporaires ou des éléments sources en double. Ces catégories ont des causes différentes et doivent être mesurées en dehors du modèle base de données-fichiers dérivés, plutôt que regroupées dans un seul chiffre de « métadonnées ».

Mesurez la croissance par rôle de stockage

Établissez une référence avant une importation représentative : octets et nombre de médias originaux, taille de la base de données, stockage des miniatures ou des aperçus, stockage des vidéos encodées, cache des modèles, sauvegardes et espace réservé aux fichiers temporaires ou aux journaux. Répétez la mesure une fois que le même groupe a terminé ses tâches d’arrière-plan activées, puis de nouveau après une utilisation familiale normale.

Un flux de sauvegarde familial de ZimaSpace rappelle pourquoi les originaux et l’état essentiel de l’application doivent être protégés ensemble, tandis que les éléments régénérables peuvent être traités différemment. La comptabilisation du stockage doit tenir compte de la valeur de récupération autant que du nombre d’octets.

Acceptez la croissance lorsque la variation peut être rapprochée des nouveaux éléments, des fichiers dérivés, des enregistrements de la base de données et des fonctions activées. Recherchez davantage lorsque l’un des rôles augmente sans activité correspondante au niveau des éléments ou des fonctions, ou lorsque le total mesuré s’écarte sensiblement de la somme des rôles de stockage connus.