Idée reçue sur SQLite-on-the-Server : mieux adapté à l’hyper-scale qu’aux petites applications

• Beaucoup de développeurs pensent que l’utilisation de SQLite sur un serveur ne convient qu’aux applications de petite taille
• Les raisons invoquées sont les suivantes :
  • Faible coût d’infrastructure : aucun serveur de base de données séparé n’est nécessaire (fonctionne sous forme de fichier unique)
  • Simplicité du développement et des tests : le même fichier de base de données peut être utilisé côté client et côté serveur
  • Charge d’administration minimale : pas de configuration complexe ni de gestion de daemon
  • Grande fiabilité : SQLite est la base de données la plus déployée au monde et offre une forte durabilité
• Des outils comme LiteFS, Litestream, rqlite, Dqlite, Bedrock ajoutent la réplication et la haute disponibilité (HA) à SQLite, ce qui le rend adapté aux petits déploiements

Mais cet article explore le potentiel de SQLite non pas pour les petites applications, mais pour les applications à très grande échelle (hyper-scale)

Les limites de la montée en charge des grandes bases de données traditionnelles

• Les grandes applications ont généralement du mal à conserver PostgreSQL ou MySQL comme base unique, et utilisent donc des bases de données shardées
• Exemples : Cassandra, ScyllaDB, DynamoDB, Vitess (MySQL shardé), Citus (Postgres shardé)
• Les bases de données shardées présentent les avantages suivants :
  • Optimisation des lectures par lot (Batch Read) grâce au partitionnement des données
  • Scalabilité horizontale
  • Haute performance en écriture

Mais les solutions de partitionnement actuelles présentent les inconvénients suivants

• Schémas rigides : elles ne prennent pas en charge des requêtes flexibles comme MySQL ou Postgres
• Évolution du schéma difficile : ajouter un index ou modifier des relations représente une lourde charge opérationnelle
• Opérations inter-partitions complexes : il est difficile de conserver des transactions ACID, ce qui nécessite des techniques complexes comme le two-phase commit (2PC)
• Problèmes d’incohérence des données : il est difficile d’appliquer de fortes contraintes entre partitions, avec un risque élevé de perte de cohérence

Le potentiel des bases de données hyper-scale fondées sur SQLite

• Cloudflare Durable Objects et Turso montrent une manière de concevoir des applications hyper-scale à partir de SQLite
• Ces systèmes offrent les points forts suivants :
  • Mise à l’échelle dynamique (Dynamic Scaling) : création d’une base de données par entité (Entity), ce qui réduit la complexité de l’infrastructure
  • Un nombre illimité de bases de données à faible coût : au lieu d’imposer un partitionnement comme dans le sharding classique, on peut créer une nouvelle instance SQLite à la demande
  • Distribution mondiale (Global Distribution) : placement des bases de données au plus près des utilisateurs pour améliorer les performances
  • Réplication et durabilité intégrées (Built-in Replication & Durability) : contrairement au SQLite classique, les données sont répliquées sur plusieurs régions afin de maintenir une haute disponibilité
• Une approche alternative au sharding avec SQLite (via Cloudflare Durable Objects & Turso)
  • Dans un modèle de sharding classique, plusieurs journaux de discussion sont stockés dans une même partition de base de données
  • Avec SQLite, il devient possible de créer une base de données SQLite indépendante pour chaque canal, avec un schéma bien plus flexible
  • Structure d’exemple
    • Sharding classique : table des journaux de discussion + clé de partition
    • Approche fondée sur SQLite : base SQLite distincte par canal (journaux de discussion, participants, réactions inclus)
• Cette approche avec SQLite présente les avantages suivants :
  • Conservation des transactions ACID locales : les transactions peuvent être exécutées dans chaque base individuelle sans problème inter-partitions
  • I/O haute performance : SQLite étant une base de données en fichier unique, les performances en lecture et en écriture sont excellentes
  • Accès aux extensions SQL :
    • FTS5 (Full-Text Search) : amélioration des performances de recherche
    • JSON1 : prise en charge du stockage et des requêtes sur des données JSON
    • R*Tree, SpatiaLite : possibilité d’utiliser des données spatiales
  • Prise en charge des migrations SQL : compatible avec des outils de migration existants comme Prisma et Drizzle
  • Prise en charge des migrations de schéma paresseuses (lazy) :
    • il n’est pas nécessaire d’exécuter immédiatement les migrations ; on peut effectuer une migration légère à l’ouverture de chaque instance SQLite

Les limites de l’utilisation de SQLite sur un serveur

• Manque de solutions open source et auto-hébergeables
• Absence de prise en charge des requêtes cross-database → un data lake séparé est nécessaire pour l’analytique
• Outillage limité autour des bases de données (navigateur SQL, pipelines ETL, monitoring, sauvegarde)
  • StarbaseDB travaille à résoudre ce problème sur la base de Cloudflare Durable Objects + SQLite
• Manque d’un protocole standard unifié
  • PostgreSQL, MySQL et Cassandra utilisent des protocoles standardisés, mais les serveurs SQLite manquent encore d’un protocole réseau standardisé
• Peu de cas d’usage à grande échelle avec SQLite en hyper-scale
  • Il existe moins d’études de cas que pour Cassandra ou DynamoDB, mais cela pourrait évoluer avec le temps

Conclusion : SQLite n’est pas seulement une base locale simple, mais aussi une option solide pour les applications à très grande échelle

• SQLite n’est pas seulement une base de données pour de petits projets, mais aussi un outil puissant capable de remplacer les approches de sharding traditionnelles dans des applications hyper-scale
• En s’appuyant sur Cloudflare Durable Objects & Turso, il devient possible de partitionner la base de données par entité tout en conservant la puissance de SQL et les transactions ACID, avec une bonne capacité de montée en charge
• Il a de fortes chances de s’imposer comme une alternative plus souple et plus simple à administrer que les bases de données shardées traditionnelles

[pcj9024]

Qui oserait volontiers utiliser sqlite à une échelle hyper-scale capable d’absorber un très grand nombre de requêtes…

[GN⁺]

Avis Hacker News

• Un utilisateur envisage de remplacer une base de données sur mesure par une base SQL

  • Sqlite3 est envisagé comme candidat car il s’exécute sur un seul serveur
  • La base de données effectue principalement des opérations de lecture, ce qui favorise Sqlite3
  • La base de données sur mesure est très rapide sur certaines tâches, mais le choix est complexe
  • Des tests de benchmark sont menés pour comparer Sqlite3 et Postgresql
  • Sqlite3 est environ deux fois plus rapide que Postgresql sur toutes les tâches
  • La base de données sur mesure est 100 à 1 000 fois plus rapide que Sqlite3 pour l’accès à un enregistrement unique

• Un utilisateur développe une application web local-first et pense que SQLite est bien adapté

  • Il souhaite un moyen simple de synchroniser l’état de la base SQLite avec un service cloud
  • Turso et SQLite Cloud semblent être des options prometteuses
  • Il envisage une approche simple permettant aux utilisateurs de pousser vers un stockage S3

• Discussion sur les avantages de SQLite-Per-Partition

  • Il existe des limites dans les situations où des tables globales sont nécessaires
  • Divers retours d’expérience sur des projets utilisant SQLite sont partagés

• Dans un environnement multi-utilisateur, SQLite rencontre des difficultés en raison de l’absence de MVCC

  • Des questions sont posées sur des implémentations et extensions compatibles sqlite qui ajouteraient MVCC

• La sortie de Ruby on Rails 8.0 étend la prise en charge de SQLite

  • Cela remplace les composants de cache et de file de tâches et le rend adapté aux applications web classiques

• Un utilisateur peu familier avec Vitess ou Citus a du mal à comprendre le contenu de l’article

  • Il s’interroge sur la différence entre Sharded Sqlite et Sharded Postgres

• Un utilisateur ne souhaitait pas d’hébergement VPS et a créé une page web avec SQLite

  • La base de données est téléchargée sur l’appareil de l’utilisateur pour être utilisée

• Un utilisateur ayant rencontré des difficultés pour configurer un contrôleur Ubiquiti suggère d’utiliser SQLite

  • Il pense que l’utilisation de SQLite à la place de MongoDB offrirait une meilleure expérience

• Apple exploitait environ 300 000 instances Cassandra/ScyllaDB en 2022

  • L’approche DB-per-tenant est considérée comme allant dans une meilleure direction

• TDLib (la bibliothèque de base de données de Telegram) utilise SQLite

  • Chaque instance de TDLib gère simultanément plus de 24 000 bots actifs