Faits amusants sur SQLite

• SQLite est la base de données la plus déployée et la plus utilisée

  • Plus de 1a0000 milliards de bases de données SQLite sont en service, et elles sont maintenues par trois personnes
  • Les contributions externes ne sont pas acceptées

• SQLite est plus utilisé que tous les autres moteurs de base de données réunis

  • Il existe des milliards de copies de SQLite, et il est présent partout

• SQLite est lun des modules logiciels les plus largement déployés

• Hwaci est lentreprise qui a développé SQLite, et elle sintéresse aussi à la musique

• SQLite est né sur un navire de guerre américain

  • D. Richard Hipp (DRH) développait un logiciel pour le destroyer de lUS Navy USS Oscar Austin
  • Le problème était que le logiciel existant cessait de fonctionner à chaque panne du serveur
  • DRH a imaginé une base de données capable de fonctionner sans serveur

• SQLite nest pas open source au sens juridique du terme

  • Lopen source exige une définition précise et une licence approuvée par lOSI
  • À la place, SQLite relève du domaine public, avec moins de restrictions quune licence open source

• Les contributions externes ne sont pas acceptées

  • Seules les personnes invitées peuvent contribuer, et les contributions doivent être versées au domaine public

• Le code de test de SQLite

  • SQLite compte plus de 600 lignes de code de test pour chaque ligne de code
  • Les tests couvrent 100 % de toutes les branches de la bibliothèque

• Certains tests de SQLite sont propriétaires

  • La suite de tests TH3 est propriétaire, et il faut rejoindre le consortium SQLite pour y accéder

• Le modèle économique de SQLite

  • Il génère des revenus via le support payant, les services de maintenance, ladhésion au consortium et des extensions commerciales

• SQLite a un code déthique plutôt quun code de conduite

• SQLite est très rapide et, dans certains cas dusage, il est 35 % plus rapide quun système de fichiers

• SQLite repose sur un modèle à auteur unique

  • Il nautorise pas plusieurs auteurs simultanément

• Différences avec les autres bases de données

  • Par défaut, il utilise le mode rollback journal, et les clés étrangères sont désactivées
  • Il utilise un typage faible, et le typage fort est optionnel

• Labsence de typage dans SQLite peut être gênante

  • Il est possible dinsérer des données sans contrainte de type

• SQLite accorde une importance extrême à la compatibilité

  • Toutes les versions de SQLite 3 peuvent lire et écrire les fichiers de base de données des premières versions

• DRH, lauteur de SQLite, a développé Fossil après avoir jugé les systèmes de gestion de versions existants inadaptés

• DRH a codé un B-Tree dans un avion à partir des algorithmes du livre TAOCP

• La prononciation recommandée de SQLite est « Ess-Cue-El-Lite », mais il nexiste pas de guide officiel

[dalinaum]

SQLite n’est pas une base de données aussi rapide qu’on pourrait le penser. MongoDB Realm, désormais abandonné, est bien plus rapide. Il semble que, pour les utilisateurs, la vitesse n’ait pas été un critère de choix si important.

[dalinaum]

Il y avait quelqu’un qui avait demandé pourquoi Realm était rapide et réclamé des éléments pour l’expliquer, mais on dirait que MongoDB a supprimé le billet au moment d’annoncer l’arrêt du support.

Du coup, en me basant sur mes souvenirs de l’époque où j’y ai travaillé, je vais essayer d’expliquer les raisons techniques. À mon avis, le principal avantage venait du fait que Realm utilisait moins de mémoire que SQLite et obtenait un meilleur taux de cache hit.

Realm choisit fondamentalement la quantité stockée en mémoire en fonction de la taille réellement utilisée. Ainsi, même si l’utilisateur sélectionne un type de données de grande taille, il est fréquent que la sérialisation se fasse sur quelques bits seulement. La conversion n’a lieu que lorsque l’utilisateur utilise réellement des données plus volumineuses.

Realm regroupe et stocke côte à côte les données d’un même type. En général, les utilisateurs n’accèdent pas à toutes les données d’une table, mais à une partie de ces données de façon continue. Avec l’encodage compact dont je parlais plus haut, cela signifie qu’on peut récupérer bien plus de données d’un seul coup depuis le cache.

Realm n’hydrate pas les objets POJO et transmet les données au moment voulu via les getter et setter. Pour cela, dans le cas de Java, il effectue des manipulations au niveau du bytecode. Si des formats comme Protobuf étaient utilisés à l’époque dans le client de l’application Facebook de Meta, c’est parce que cette étape d’hydratation constituait un gros désavantage en matière de performances, et que le fait de n’accéder qu’aux données nécessaires présentait un avantage.

Realm était bien plus rapide que SQLite dans la plupart des scénarios, mais je ne pense pas que cet aspect ait été le facteur décisif sur le marché.

Si je me souviens bien, le principal concurrent de Realm était Parse, créé par Facebook. Ensuite, le concurrent est devenu Firebase de Google. Aucun des deux n’est une base de données mobile locale, mais plutôt un service permettant de stocker simplement des données à distance. On peut se demander comment ces deux-là pouvaient concurrencer Realm, mais en pratique, les utilisateurs voulaient surtout pouvoir stocker leurs données quelque part, et la vitesse ne semblait pas si importante.

Puis, après l’investissement d’Ericsson, le périmètre de Realm s’est réduit. Ericsson constatait que Realm détenait déjà une certaine part sur iOS, mais ne comprenait pas l’intérêt de développer davantage de fonctionnalités. En revanche, l’entreprise reconnaissait davantage sa valeur comme solution de synchronisation. Par la suite, Realm a été intégré à MongoDB.

[aer0700]

Je crois que 80 % de la raison pour laquelle j’avais choisi SQLite, c’était sa facilité de prise en main.

[dalinaum]

Je pense que c’est aussi l’une des raisons importantes. Realm proposait un mode d’utilisation basé sur le thread local, fournissait une mise à jour automatique, et expliquait qu’en relançant une requête depuis un autre thread, on pouvait transmettre les mêmes données à très faible coût. Il recommandait aussi de ne pas transférer les données vers un autre thread, mais il n’était pas facile d’expliquer tout cela.

[sanggi]

On dirait que SQLite est vraiment utilisé dans toutes sortes d’endroits !

[xguru]

Histoires méconnues sur SQLite

[GN⁺]

Commentaire Hacker News

• Certains estiment que l’OSI ne constitue pas la référence en matière d’open source. La définition de l’open source de l’OSI est utile, mais elle fait aussi l’objet de critiques et de controverses. Affirmer que SQLite n’est pas juridiquement open source est une assertion erronée

  • Il n’est pas souhaitable de dépendre de l’approbation de l’OSI. La liste des licences approuvées par l’OSI ne reflète qu’une histoire à la fois pratique et politique
  • Le caractère open source de SQLite fait débat. La mise dans le domaine public n’est pas une licence, donc elle ne satisfait pas l’OSD, mais elle est encore plus ouverte

• Le blog semble chercher à générer des vues et de l’engagement en recyclant de vieux arguments sur un sujet populaire

  • Les précédents billets du blog manquent de profondeur technique et contiennent beaucoup d’exagérations

• SQLite dispose d’un code d’éthique (CoE) plutôt que d’un code de conduite (CoC). Le CoC est utilisé comme un outil pour encadrer le comportement des contributeurs externes, tandis que le CoE est une déclaration du comportement que les développeurs de SQLite entendent adopter envers les autres

• Il existe une confusion sur la prononciation de SQLite. On dit que cela se prononce "Ess-Cue-El-Lite", mais certaines personnes disent aussi "S-Q-L-ite"

• SQLite prend en charge, de manière optionnelle, les tables strictes. Il est possible d’imposer les types avec CREATE TABLE name (stuff TEXT) STRICT

• SQLite peut servir non seulement de base de données SQL, mais aussi de base NoSQL. Le stockage des données via des colonnes JSON est une approche utile

• Quelqu’un a déjà travaillé sur un projet avec Richard Hipp. Il tire des revenus stables grâce à des contrats de support

• Lors d’une des versions de SQLite, de nombreuses micro-optimisations ont permis d’améliorer les performances de 50 %

• SQLite est utilisé pour le prototypage rapide et les dumps de logs, mais cela devient difficile quand on veut plusieurs écrivains. C’est l’une des principales raisons qui poussent à quitter SQLite

• SQLite repose sur un modèle à un seul écrivain. Redis fonctionne aussi sur un modèle mono-thread

• L’un des faits amusants à propos de SQLite est qu’ils ont dû changer le préfixe par défaut de sqlite_ à etilqs_ lorsque des utilisateurs ont commencé à appeler les développeurs en pleine nuit