MyDMAM : les bases de données d’un MAM

Cet article fait parti d’une série d’articles de présentation d’un projet libre et expérimental que j’ai écris. Je vais parler ici de la logique de base de donnée du projet, et de ce que cela permet.

Publié le

La technologie de base de donnée dans un MAM est fondamentale, autant que pour le stockage, car elle est indispensable et trop souvent considérée comme n’étant pas stratégique : on la voit comme un mal nécessaire.

Ce qui relie virtuellement un élément physique (fichier vidéo, audio, photo, projet, modèle…) à un élément virtuel est un asset (que l’on peut rechercher, indexer, trier et abstraire en base de donnée). C’est aussi appelé un média, un item, un pivot ou autre nom qui corresponds au métier et au type d’élément. 

Chaque appel à la base de donnée pour remonter une information, c’est un appel de moins sur le fichier physique.

La base permet surtout de remonter des informations issues d’index et donc de retrouver de profondes informations parmi un grand nombre de médias. Par exemple, essayez de vous représentez le travail qu’il faudrait pour sortir toutes les photos prises dans une zone géographique précise : extraire les info GPS des métadonnées de chaque photo, calculer la distance relative par rapport au point demandé, puis comparer ces informations une à une pour les trier. Si la base de donnée a déjà ces informations et si elle est capable de faire ces calculs, le résultat sera très rapide à obtenir. La preuve, n’importe quel smartphone est capable de placer toutes les photos qu’il a pris sur une carte…

MyDMAM est un logiciel libre, y compris dans l’approche avec les bases de données :

  • La liberté dans la structure : vous pouvez ajouter vos éléments manuellement et agir sur ceux déjà présents sans forcément passer par une API. Ajoutez aussi des champs et des tables si cela vous chante. MyDMAM n’utilise que ce qu’il à besoin. Le reste est ignoré.
  • Les bases de données utilisées sont des logiciels libres et gratuits. Pas de licences stupides, mais vous pouvez toujours souscrire un support auprès des sociétés qui les développent.
  • La liberté de topologie : vous choisissez le nombre de serveurs, d’instances, leurs localisations… Du moment que vous répondez aux pré-requis ; le minimum, c’est un Raspberry Pi.
  • La scalabilité, c’est à dire la possibilité de monter à l’échelle en terme de performances globales, pour passer progressivement d’une petite installation à une grande sans devoir tout casser. C’est la grande promesse du Cloud. C’est aussi la possibilité d’agrandir une installation petit à petit suivant les besoins, sans être obligé dès le départ de sortir la grosse artillerie.
  • La tolérance aux pannes ; un serveur tombe : combien de personnes au chômage technique ? Peut-on encore se le permettre pour un simple serveur ? Ou pour un cluster pas vraiment redondant ? Les bases de données utilisées par MyDMAM sont résiliantes, à partir du moment où la topologie est correcte.
  • Reposer sur des technologies qui on fait leurs preuves. Je choisi toujours une technologie sûr qui les plus grosses structures les on validés. Si Netflix, Facebook, GitHub ou Ebay s’en servent en production, c’est que je peut le faire.

Un mot sur les métadonnées

Toutes les informations de métadonnée a stocker ont cet inconvénient de ne jamais avoir de structure de données prédéfinie, en tout cas supposé d’avance : quasiment toutes les métadonnées d’une photo sont incompatibles avec celles d’un fichier audio. MyDMAM n’oblige ni interdit la présence de certaines métadonnées. Pour se faire, elles sont stockées par moteur d’extradition, chacun ayant une structure qui lui est propre. Pour remonter/rechercher une donnée spécifique, il faut la réclamer dans le ou les enregistrements produits par les moteurs qui peuvent l’avoir extraite.

De même on distingue la notion de metadonnée technique (format, résolution, codec), celle intégrée au fichier par un humain (titre, auteur…), et l’étiquette que l’on va coller sur le média, virtuellement dans la base et sans altérer le média.

Dit comme cela, ça semble lourd et long, mais avec une approche NoSQL et plus exactement de bases de donnée orientée document, on se libère des contraintes de tables à schéma fixe et de jointures, et c’est extrêmement rapide.

L’approche BigData/NoSQL vs le bon vieux SQL.

Les technologies basés sur le SQL (ou plutôt les bases de donnée relationnelles) à on cela pour elles : on en a fait suffisamment le tour pour savoir que ce l’on peut faire et comment.

Mais les limites du SQL sont réelles et on à fait mieux depuis : le principal besoin du BigData (si ce n’est sa définition), c’est de gérer de grandes quantités de données sans limites artificielles comme un nombre non limité de lignes, de champs, de tables, d’accès simultanés, de serveurs… Dans tous les cas, la base doit être capable de s’adapter aux données qu’on lui envoie.

Ce qu’utilise MyDMAM

J’ai choisi Cassandra, imaginé par Google, écrit par Facebook, soutenu par le projet Apache et supporté par DataStax. Pas de limites réelles du nombre de lignes ou de colonnes. Un fonctionnement en grappe à haute disponibilité. Cassandra est très puissant et très rapide. Je m’en sert pour plein de petites choses comme la gestion des taches et la configuration utilisateur.

Ensuite, j’utilise comme base d’index média Elasticsearch, supporté et développé par Elastic. C’est un moteur de recherche et une base de donnée orientée document, toujours dans la mouvance NoSQL, et fonctionnant la aussi en grappe, à haute disponibilité, tout en restant très puissant et très rapide.

Très rapide, c’est sans aucune mesure par rapport à une base SQL du même type. J’ai en test une base média de plus de 1 500 000 éléments. Je suis capable en moins de 300 ms de remonter les 10 meilleurs résultats dans un millier de réponses potentielles par rapport à un mot clé, et il me faut même pas 10 minutes pour refaire un index global.

Avec Cassandra, il me faut quelques secondes pour pousser les données de plus de 10 000 fiches simples. La génération de ces fiches m’on demandé plusieurs minutes à un serveur MySQL plus puissant, en terme matériel, que ma VM Cassandra.

Ce n’est peut être pas très parlant, mais avec de petites VM, je n’ai pas encore réussi à mettre a genoux un Cassandra ou un Elasticsearch avec des requêtes normales car les données a envoyer ou récupérer sont toujours plus lente coté production/consommation (limité par le réseau ou les IO) que coté base de donnée.

La stabilité de ces technologies est impressionnante. Je n’ai jamais réussi à les crasher, malgré des requêtes douteuses ou un serveur qui manquait de RAM. Avec du SQL, je pense que j’aurai déjà rencontré plein de problèmes de fragmentation de table avec tout ces ajouts et ces suppressions de lignes en simultané. Là, je ne ne fait jamais de maintenance sur mes bases (même si il existe des procédures pour, et ça reste dans les prérequis d’admin de ces bases).

Ces deux bases permettent de remplir toutes les fonctions gestion de médias librement et rapidement.

Cependant, j’utilise encore du SQL (SQLite et H2 DB) pour gérer les droits des utilisateurs avec des tables, des schemas, et des requêtes minuscules. Pourquoi ? Dans l’optique de rester simple et sûr ; on ne plaisante pas avec la gestion des droits d’accès, surtout quand il y a déjà une très bonne intégration avec le serveur web (et là c’est pratique car ça ne demande pas de perdre du temps pour ça).

Enfin, MyDMAM, pour ses besoins, produit et utilise du XML, du JSON et du YAML, un dérivé du JSON, qui permet des fichiers de configuration simples et clairs.

La suite : MyDMAM : gérer les fichiers d’un DMAM.