Je développe toujours des applications web en tenant compte des performances énergétiques. Et je m’arrange toujours pour qu’elles consomment le moins de ressources possible. Pour certaines applications pensées en mode « single », je vais même jusqu’à imposer qu’elles puissent tourner sur des Raspberry Pi. Mais comme j’aime que ce soit simple à utiliser, il faut inclure aussi « simple à installer ».
La méthode de base est « décompresser et utiliser ». Ce qui implique l’usage de fichiers gérés en local plutôt qu’une base de données. Tout d’abord parce qu’une base de données nécessite plus de ressources pour fonctionner (daemon, écoute de port, etc.) mais aussi plus de complications au moment de l’installation et configuration (mot de passe, définition de ports).
C’était l’idée de départ que j’avais pour deux applications en cours de développement : EntropyCMS et FINT. Les développements commençaient bien, mais rapidement, les premières limitations sont apparues.
Atomicité
Pour gérer des informations simplement, il faut les stocker dans un format atomique qui servira ensuite de source à des structures plus complexes. Cela évite la multitude de fichiers à structures complexes, souvent plus difficiles à gérer car il faut, en définitive, les transformer pour en extraire les informations utiles.
L’usage de transformations XSL est bien sur le papier, mais inexploitable sur un Rapberry Pi car trop lourd/lent à exécuter.
Le format atomique a la propriété d’être plus versatile, mais plus le nombre de types d’informations augmente, plus le nombre de fichiers atomiques se multiplie. Et le problème survient lorsqu’il faut faire des jointures entre chaque fichier pour retrouver une référence associée à une autre.
Même sur des systèmes de fichiers performants, la multiplication des fichiers tend à ralentir l’application.
En règle générale, pour conserver la performance, il faut multiplier les petites structures atomiques, ce qui revient à diminuer les performances générales (plus de fichiers au niveau du système de fichiers), accroît la complexité (plus de fichiers à gérer au niveau de l’application), diminue la lisibilité de l’application (développements, débogage) et augmente l’entropie puisque la même information est très souvent dupliquée.
Pensez par exemple que le format de la date n’est pas le même pour un flux Atom et un flux RSS et que les balises ne sont pas les mêmes non plus. Ce qui implique deux structures différentes.
Verrous
Lorsque vous utilisez des fichiers et que vous avez prévu que plusieurs personnes puissent utiliser l’application en même temps sur les mêmes données, alors il faut prévoir un système de verrous pour éviter que l’un puisse écraser le travail d’un autre.
Toutes ces problématiques sont complexes dans une application fondée sur des fichiers, mais très performantes et simples dans une base de données. Les données sont stockées dans une structure neutre, avec des jointures faciles à faire, performantes et indexées. Les différents types de structures ne sont générées qu’à la fin, à l’aide de quelques jointures optimalisées et une requête pour formater convenablement le tout.
Mais utiliser une base de données revient au problème de départ : l’usage de ressources non utiles.
Vers un modèle hybride
Il convient donc d’améliorer le principe, non pas en choisissant l’une ou l’autre de ces deux orientations technologiques, mais en étudiant une troisième voie : tenter de réunir le meilleur des deux mondes.
Un moteur hybride consiste à utiliser une base de données pour simplifier toutes les parties relationnelles, en limitant son expansion le plus possible afin de la garder performante sur des configuration peu puissante, notamment si on veut la charger complètement en RAM.
Les parties à mettre en base de données seront donc, naturellement, la gestion des comptes et utilisateurs, ainsi que les droits, les types, les configurations.
En dehors : les logs, les données volumineuses (photos, vidéos), les historiques et archives. Tout ce qui n’est pas utilisé au bout d’un certain temps devra être archivé en dehors de la base afin de limiter son expansion le plus possible. Seules doivent persister des données réellement opérationnelles.
La donnée réelle (la page web dans le cas d’un site web), quant à elle, aura un statut hybride qui permettra soit de l’utiliser à l’extérieur de la base, sous forme de fichier, soit à l’intérieur, pour améliorer les performances. Il est aussi possible d’utiliser un serveur de cache extérieur.
Tout ça, c’est bien beau sur le papier (enfin : le cybercarnet), mais il faut une condition sine qua non : peut-on installer PostgreSQL simplement sur une Raspberry (avec des performances acceptables) ?
Il n'y a qu'une seule façon de le savoir : il faut essayer.