- SQLite est extrêmement rapide. Il peut soutenir simultanément ~168 000 lectures et ~8 000 écritures sur un serveur standard à ~40 €/mois.
- Comme il s’agit d’une bibliothèque embarquée conçue pour des applications côté client comme les systèmes embarqués, les téléphones ou les applications desktop, la base SQLite doit être co-localisée avec le serveur applicatif et ne peut pas être accessible via le réseau.
- Que faire avec SQLite quand la situation exige plus d’une machine ?
- Un projet de week-end peut devenir viral et devoir monter en charge rapidement.
- L’une des exigences du CTO peut être de déployer un service hautement disponible sur au moins deux centres de données distincts.
- Ces dernières années, plusieurs projets ont émergé pour adapter SQLite en base de données backend pour des applications backend.
- Cet article cherche à déterminer s’il s’agit d’un changement de paradigme permettant aux organisations d’offrir une meilleure expérience utilisateur plus rapidement, ou d’un simple battage marketing poussé par des entreprises voulant gonfler leur « proposition de valeur unique » (
Unique Selling Proposition).
Utiliser SQLite comme base de données edge
- SQLite est promu non pas comme une simple base de données backend, mais comme une base de données edge.
- Les acteurs les plus représentatifs sont Cloudflare D1, fly.io avec LiteFS, et Turso.
- La plupart des dérivés de SQLite fonctionnent de manière similaire.
- Il existe une base principale qui accepte les écritures quelque part, puis celles-ci sont répliquées de façon asynchrone vers d’autres régions.
- La réplication se fait principalement en diffusant le journal de toutes les transactions exécutées dans la base, à savoir le Write-Ahead Log de SQLite.
- Dans cette architecture, les lectures peuvent en théorie être servies depuis des data centers edge, mais les écritures doivent toujours être envoyées vers un emplacement central.
- En pratique, personne ne veut qu’un client finalise une commande sur une application e-commerce, que la commande soit bien validée dans la base SQLite principale, mais qu’une réplique locale en lecture soit en retard, n’ait pas encore reçu la donnée mise à jour, et affiche un message d’erreur indiquant qu’elle est introuvable.
- Bienvenue dans le « monde douloureux de l’eventual consistency ».
La solution de LiteFS et ses limites
- LiteFS propose une solution bricolée. L’application définit un cookie
__txidpour suivre la dernière transaction détenue par la réplique locale, et si celle-ci est trop en retard, la requête de lecture est redirigée vers la base principale. - L’application se retrouve alors fortement couplée à la base de données et au reverse proxy.
- LiteFS ne mentionne pas qu’il ne prend en charge qu’environ 100 écritures par seconde.
Principaux inconvénients de la plupart des systèmes SQLite distribués
- La plupart des systèmes SQLite distribués ne prennent pas en charge les transactions interactives, c’est-à-dire celles où l’on effectue des calculs entre différentes requêtes d’une même transaction.
- Une seule transaction d’écriture peut être active à la fois. Dans une base SQLite classique, ce n’est généralement pas un problème, car la plupart des écritures ne durent pas plus de quelques dizaines de microsecondes.
- Mais dès qu’on introduit de la latence réseau entre l’application et la base SQLite, le système s’effondre. La base reste verrouillée pendant toute la durée de l’aller-retour de la transaction, ce qui limite le système à seulement quelques écritures par seconde.
- Turso « résout » cela avec le batching. Il permet de regrouper plusieurs requêtes dans un lot exécuté comme une transaction unique. Cloudflare D1 « résout » le problème avec des batchs et des procédures stockées.
Et s’il existait une solution plus simple ?
- Pour les applications web, il existe déjà une méthode très simple et puissante pour être très rapide à l’échelle mondiale : le cache HTTP avec les en-têtes
Cache-ControletETag. - Le cache HTTP évite d’avoir recours à des techniques proches de celles des bases à cohérence faible, ce qui empêche les applications web de devenir trop complexes ou vulnérables aux race conditions.
- L’auteur de cet article consacre une large part de son nouveau livre, « Cloudflare for Speed and Security », à expliquer différentes stratégies de cache qui permettent non seulement d’accélérer les applications web, mais aussi de gérer de très nombreux utilisateurs simultanés avec un minimum de ressources.
La base de données comme abstraction
- La latence n’était pas le seul problème que SQLite distribué tentait de résoudre. L’autre était la complexité opérationnelle.
- Gérer un cluster de serveurs interconnectés est difficile et entraîne souvent des interruptions de service et des pertes de revenus. Sans même parler de l’administration des bases de données, qui exige une supervision permanente et une excellente culture de la sécurité pour éviter des catastrophes comme celle qu’a connue GitLab en 2017.
- L’idée est donc de livrer la base de données avec l’application et de tout déployer sur un seul serveur.
- C’est très bien quand on est développeur solo, mais dans une grande organisation, il existe généralement une personne ou une équipe dédiée à la maintenance des serveurs de base de données.
- C’est précisément pour cela qu’une base accessible via un socket plutôt qu’une bibliothèque embarquée constitue une excellente abstraction : non pas une abstraction technique, mais une abstraction organisationnelle. En développement, cela peut être un simple conteneur tournant sur la machine du développeur ; en production, cela peut être n’importe quoi, depuis un conteneur sur le même serveur que l’application jusqu’à un cluster distribué accessible via le réseau. Le développeur n’a qu’à remplacer une seule variable de configuration,
DATABASE_URL, et l’équipe ops s’occupe de tout le reste. - À l’inverse, le système de fichiers Unix traditionnel était une abstraction mal adaptée à l’informatique distribuée. Bien sûr, NFS (Network File System) existe, mais ses performances restent médiocres parce que le système de fichiers Unix a été conçu pour un accès sur une seule machine. En revanche, le protocole S3 constitue une très bonne abstraction pour stocker de grands volumes de données non structurées de manière efficace, scalable et fiable. Les développeurs n’ont qu’à utiliser un SDK compatible S3 et à l’oublier ; l’équipe ops ou le fournisseur cloud gère tout le reste, qu’il s’agisse des performances, de la durabilité ou de la fiabilité.
Conclusion
- SQLite est une base de données vraiment remarquable, mais pour la plupart des équipes, il vaut mieux éviter SQLite et choisir PostgreSQL à la place.
- D’innombrables heures d’ingénierie ont été consacrées à faire de PostgreSQL la meilleure base de données backend. En choisissant SQLite, on finit inévitablement par réinventer, de manière fragile et boguée, ce que PostgreSQL possède depuis longtemps.
- Selon l’auteur, le mouvement actuel visant à faire de SQLite une base de données backend n’est rien d’autre qu’un coup marketing de sociétés vendant des infrastructures edge computing, qui ont réalisé que l’informatique n’est rien sans stockage des données. Son conseil (non sollicité) à leur intention est d’investir dans le cache HTTP plutôt que de construire des CDN et d’imposer de la complexité aux applications. Les résultats sont bien meilleurs.
- À cause de la complexité induite, 99,9 % des applications backend ne verront aucun bénéfice à migrer vers l’edge et devraient plutôt se concentrer sur le déploiement de bonnes stratégies de cache pour offrir partout dans le monde une excellente expérience en moins de 100 ms.
- Et c’est là que s’arrête l’expérience de SQLite pour les applications server-side. Victoire de PostgreSQL.
-
« Les amateurs parlent tactique, les professionnels parlent logistique. (Amateurs discuss tactics. Professionals discuss logistics.) »
Cela signifie que, pour réussir, les systèmes et processus de soutien — la logistique et la gestion — comptent davantage que les décisions tactiques prises sur le terrain.
L’avis de GN⁺
- Comme le soutient l’auteur, utiliser SQLite dans la plupart des applications backend semble surtout ajouter de la complexité sans apporter d’avantage concret. Il serait sans doute préférable d’utiliser une base déjà éprouvée et mature comme PostgreSQL.
- Le fait que les fournisseurs d’infrastructures edge computing poussent SQLite semble davantage relever d’une stratégie marketing que d’un réel avantage technique. Il serait plus utile pour les développeurs d’applications qu’ils investissent davantage dans le cache HTTP et les CDN.
- La plupart des applications backend peuvent déjà fournir un service suffisamment rapide et scalable avec une stratégie de cache appropriée. Sauf nécessité absolue d’edge computing, il vaut mieux éviter une complexité excessive.
- SQLite distribué peut être utile dans certains cas d’usage spécifiques, mais il semble encore limité pour servir de solution généraliste. Il ne sera pas simple de concilier facilité de développement, performances et cohérence.
- Au final, le plus important est de choisir une technologie adaptée aux besoins de l’application et aux capacités de l’équipe. Mieux vaut analyser soigneusement les avantages et les inconvénients et décider avec prudence que suivre une mode.
- L’auteur insiste sur le fait que SQLite présente encore beaucoup de limites comme base de données backend, mais cela ne signifie pas qu’il faille l’écarter totalement, car il peut exister d’autres cas d’usage où ses atouts sont pertinents.
3 commentaires
Plutôt que de se demander ce qui est le mieux entre Postgres et sqlite,
ne vaudrait-il pas mieux réfléchir à lequel des deux convient le mieux à sa situation ?
Après tout, la meilleure option dépend du contexte.
Avis sur Hacker News