Le moteur de blog sur lequel tourne ce site, Blogotext, était à l’origine basé sur un stockage en fichiers XML (un sorte de balisage à la XML, plutôt).
Aujourd’hui j’utilise à la fois SQLite et le stockage sous forme de fichier contenant des données sérialisées.

En relisant l’article de Matronix sur Pluxml qui devient un peu plus lent quand le nombre d’articles s’accumulent, je me suis décidé à dresser un petit comparatif et un retour sur les formats de stockage pour un moteur de blog : XML, base64-serialisé, SQLite, MySQL.

XML, texte Base64-sérialisé

Ces deux formats reposent sur de simples fichiers texte : il est donc plutôt passe partout, y compris sur les rares hébergeurs qui ne proposent aucun système de base de donnée (mais parfois interdits par les hébergeurs car assez gourmands en ressources).

Le format est également adapté quand la quantité de données reste limitée : pour un blog avec des articles longs, il est préférable de s’abstenir.

Pour des liens partagés courts, force est de constater que ça reste rapide, mais je suis quand même curieux de connaître la limite de ce système. Tous les systèmes ont tendances à s’embourber quand la quantité de données devient importante, mais certains résistent mieux que d’autres (et surtout, passer de 1 ms à 2 ms pour une requête, c’est doubler le temps mais ça reste totalement invisible, alors que passer de 1 s à 2 s, ça l’est beaucoup moins).

Ces formats conviennent très bien pour les petits blogs sans commentaires, et pour tout autre gestion de donnée sans associativité entre les données (les commentaires sont en effet associés à un article et nécessitent un tri — spécifique et très long — à cause de ça).

En revanche, pour un moteur de blog, avec fonction de listage des articles, commentaires associés ou fonction de recherche, ça devient rapidement très lent au fur et à mesure que le nombre d’articles augmente.
Quand j’utilisais les fichiers XML sur ce site, avec 5000 commentaires, le temps de génération d’une page prenait jusqu’à 500 millisecondes. Ça semble rien, mais c’est énorme (c’est 20 à 100 fois la durée actuelle de génération d’une page, alors que le nombre d’articles et commentaires à triplé).

J’avais un jour testé l’utilisation d’un fichier sérialisé pour le blog : la page prenait 800 millisecondes à charger. Là aussi, c’est bien trop long, pour le visiteur qui doit attendre et pour le serveur qui est trop sollicité. C’était impensable.

SQLite & MySQL

Ces systèmes contiennent une véritable gestion des données : ils les stockent bien-sûr, mais ils peuvent aussi les trier, ordonner, rechercher et créer des liaisons (articles/commentaires) : SQL est spécifiquement fait pour ça. C’est donc parfait pour le stockage de données qui sont susceptibles de changer, d’être triées ou d’êtres liées à d’autres données de façon dynamique.

Mon blog a tourné sous MySQL à un moment, mais je suis très vite revenu à SQLite, après avoir appris à optimiser quelques trucs.
Le résultat est celui que vous voyez là : ce site tourne avec 1100 articles, 16 000 commentaires et 16 000 liens partagés, et je suis en mutualisé (donc le serveur gère également plein d’autres sites en parallèle).

Tout a été ici une question d’optimisation : choix des indexes, gestion du cache et de la mémoire, et de la façon dont on l’utilise. En PHP par exemple : une bonne gestion des boucles fait beaucoup de choses. Le nombre de requêtes SQL est également à prendre en compte : une requête pour sortir 50 articles sera largement plus rapide que 50 requêtes.

SQLite est pratique car il très simple à utiliser : pas de mot de passe, pas d’installation, pas de système client/serveur (contrairement à MySQL) : la bibliothèque logicielle pour utiliser SQLite peut être incluse dans les logiciels et être utilisée à la volée (Firefox le fait, par exemple). Il suffit de l’utiliser comme n’importe quelle fonction.
MySQL a la réputation d’être un peu plus rapide et plus complet.

Meewan me fait remarquer très justement que SQLite a un défaut par rapport au reste, c’est qu’on ne peut écrire qu’une seule chose à la fois dans la base de données SQLite. Une opération doit se terminer complètement avant que la suivante ne puisse se faire. Ceci concerne uniquement l’écriture dans la base de données (pas la lecture). En pratique, sur un blog comme le miens, ce n’est pas un problème du tout, mais sur les sites (beaucoup) plus gros où des dizaines de commentaires peuvent être écrits en même temps, cela pose problème. Il est ainsi impensable d’avoir un système similaire à Twitter, ou bien un tchat, utilisant SQLite.

Pour conclure

Je pense évidemment que chaque application a ses besoins spécifiques.

À mon niveau cependant, je n’ai pas encore eu de situations où SQLite ne suffisait pas (ceci mis à part car ça a été résolu depuis) : son avantage est d’être utilisable dans énormément de langages (que ce soit côté serveur (PHP), côté client (JS, HTML5?) et en local (Python, SH…)) et très simplement, sans gestion de mot de passe ou de nom de serveur, le tout avec une portabilité très simple puisqu’il s’agit d’un seul fichier à copier-coller.

Dans certains cas, où le nombre de données n’est pas emmené à varier beaucoup, les fichiers textes sérialisés ou le XML/Json (voire les fichiers de configuration INI ou INF) suffisent.

Note : cet article a été initialement écrit en 2015. Je l’ai déterré pour un lecteur qui m’avait demandé mon avis entre les différents formats. Les chiffres sont mis à jour et correspondent à ceux de la date de publication.