L’histoire méconnue de SQLite

xguru · 2021-07-05T10:21:01+09:00

Résumé d’un podcast d’interview du développeur de SQLite, Richard Hipp (38 min, transcription disponible) Son métier principal était développeur logiciel pour des destroyers de la marine américaine → Informix, utilisé à bord, générait souvent des erreurs, le serveur tombait et les connexions se coupaient → Comme il s’agissait d’un navire de guerre, le système devait continuer à fonctionner de manière robuste même en cas de dommages au combat, sans afficher de popup du type « impossible de se connecter à la BD ». Il n’y avait pas besoin de transactions, mais il fallait pouvoir charger les données en RAM dans toutes les situations → Il a cherché un moteur de BD SQL fonctionnant sans serveur, n’en a trouvé aucun, et a donc décidé d’en créer un lui-même SQLite V1 (2000) Il a conçu un moteur de bytecode qui compile et exécute les requêtes en considérant les instructions SQL comme des programmes Il n’a finalement pas été utilisé dans le projet réel (le client voulait Informix) Il s’en est servi pour le développement, l’a publié sur Internet, et des gens ont commencé à l’utiliser Il a commencé à voir des retours du type « J’ai fait tourner une BD SQL sur un Palm Pilot », ce qui a attiré l’attention et l’a encouragé à poursuivre Motorola Entre 2001 et 2002, Motorola l’a appelé pour dire qu’ils voulaient intégrer SQLite dans leur nouvel OS pour téléphones Ils proposaient de payer si les fonctionnalités nécessaires étaient prises en charge C’est à ce moment-là qu’il a découvert qu’on pouvait gagner de l’argent avec l’open source Environ 80 000 $, une somme qui paraît modeste aujourd’hui, mais qui lui semblait énorme à l’époque Il a mené le projet avec trois collègues, et c’est ainsi que tout a commencé America Online Phones Le contact suivant est venu d’AOL À l’époque où l’on envoyait encore des CD par la poste, il leur fallait une base de données dans le CD Ils voulaient donc embarquer SQLite sur le CD et avaient besoin de nouvelles fonctionnalités Symbian OS et Nokia Il est allé à Londres pour une réunion pendant Thanksgiving (puisqu’au Royaume-Uni, Thanksgiving n’existe pas) Ils voulaient une BD pour Symbian OS, et SQLite s’est retrouvé en concurrence avec d’autres BD (2 open source, 7 commerciales) Les 9 autres ont eu l’occasion d’optimiser leur solution, mais SQLite a fini par l’emporter Bus Factor [1] et le consortium Le bus factor est un indicateur du nombre de personnes qui, si elles se faisaient renverser par un bus, entraîneraient l’arrêt du développement Même s’il travaillait déjà à plein temps avec plusieurs personnes, Symbian a estimé qu’il fallait augmenter ce bus factor L’idée était de lancer le consortium SQLite pour financer le projet et faire en sorte que davantage de personnes s’y impliquent sur le long terme Il a d’abord eu la folle idée de donner un droit de vote à tous les membres du consortium Mitchell Baker, de la fondation Mozilla, en a entendu parler quelque part et l’a appelé → « Richard, vous faites totalement fausse route. Je vais vous expliquer comment créer un consortium. » → Elle a commencé à définir les règles → « Les développeurs doivent garder le contrôle. Leurs décisions doivent être finales. On ne doit pas obtenir un droit de vote juste en adhérant. » → « Les entreprises qui l’utilisent gagnent l’honneur de contribuer financièrement, mais la décision finale doit vous revenir. » → Elle était très ferme et a tout mis en ordre. C’est une avocate Quand Richard a demandé : « Comment convaincre les gens de participer ? Et quelle serait l’incitation ? » → « Ne vous inquiétez pas. Ils participeront. Et si vous faites ça correctement, Mozilla sera membre fondateur. » Avec le soutien de Mozilla, Symbian et Adobe, le consortium a démarré avec ces trois entreprises → Au départ, quand Symbian a dit qu’il fallait un consortium, il ne savait pas du tout comment s’y prendre. Il ne sait toujours pas comment Mitchell Baker en a entendu parler et l’a appelé, mais tout cela a été un parcours incroyable Entrée d’Android : les débuts d’Android Comme tous les smartphones utilisaient SQLite, Richard a pu observer les débuts du smartphone sous tous les angles En 2005, il a eu une réunion avec Android, avant même la sortie d’Android et de l’iPhone Il a débogué SQLite en le connectant à un téléphone ressemblant à un BlackBerry, avec un petit écran en haut et un clavier QWERTY complet Déboguer avec GDB sur un téléphone relié à un vrai réseau en fonctionnement était une expérience incroyable À l’époque, ni Motorola, ni Symbian, ni Nokia ne faisaient ce genre de chose, et c’est là qu’il a compris qu’Android allait devenir énorme Guy, This Is Important : les gars, c’est vraiment important À cette époque, les autres constructeurs avaient des cycles de mise à jour matériel/logiciel très longs, de l’ordre de 30 jours, alors qu’Android installait plusieurs fois par jour un nouvel OS sur de vrais téléphones connectés au réseau Les téléphones Android prototypes reçus sous NDA avaient des boîtiers qui semblaient sortis d’une imprimante 3D, mais restaient transportables → Chez les autres, c’étaient de grosses breadboards et des prototypes, même pas connectés au réseau, impossibles à utiliser comme téléphones Il voulait dire aux équipes de Motorola et Symbian : « C’est important, il faut régler ça », mais il ne pouvait rien dire (à cause du NDA), et c’est ce qui a fait la différence Testing and Aviation Standards : tests et normes de l’avionique Adam (l’intervieweur) : « Aujourd’hui, la BD de Richard est dans un état remarquable. L’équipe est petite mais talentueuse, et c’est une société de conseil logiciel de 1 à 4 personnes qui prend en charge la BD intégrée à tous les téléphones Android. Les développeurs de bases de données sont extrêmement investis et détestent les problèmes de données. » Nous répétions naïvement à tout le monde que SQLite n’avait pas de bugs, mais Android a clairement prouvé que nous avions tort Il pensait possible de faire un logiciel sans bug, mais quand un logiciel est installé sur des millions d’appareils, le nombre de bugs possibles est stupéfiant À cette époque, il travaillait aussi avec Rockwell Collins, une entreprise d’avionique, qui lui a présenté les concepts de DO-178B [2] → DO-178B concerne les normes qualité pour les produits aéronautiques critiques pour la sécurité, et contrairement à beaucoup d’autres normes qualité, celle-ci est « lisible » → Le document coûte quelques centaines de dollars, mais comme il est mince, il recommande vraiment de le lire Ils ont réellement commencé à suivre le processus DO-178B, dont l’un des éléments est une couverture de test MCDC à 100 % MCDC (Modified Condition / Decision Coverage) [3] signifie que les tests doivent couvrir chaque branche individuelle au moins une fois Il a fallu un an à raison de 60 heures par semaine pour amener SQLite à 100 % de MCDC. C’était extrêmement difficile. Il fallait faire 12 heures par jour, et c’était épuisant Atteindre 90 à 95 % de couverture de test est facile ; les 5 % restants sont vraiment durs. Mais après un an d’efforts pour atteindre 100 %, les rapports de bugs venus d’Android ont cessé C’est à partir de là que les choses ont commencé à bien fonctionner, et cela a fait une énorme différence. Ensuite, il n’y a plus eu de bugs pendant 8 à 9 ans Des milliards de tests Le premier jeu de tests a été écrit en TCL (Tool Command Language) et correspondait à des tests de développement classiques Ce premier jeu de tests TCL est toujours maintenu et public. Il n’atteint pas 100 %, mais il teste en détail toutes les fonctionnalités de SQLite La couverture MCDC à 100 % s’appelle TH3 et n’est pas publique (proprietary) Ils ont essayé d’en tirer des revenus en le vendant à des entreprises du secteur aérien, mais n’en ont vendu aucun exemplaire, donc cela n’a servi à rien de ce point de vue… En revanche, cela leur a permis de garder leur produit extrêmement robuste et de livrer plus vite de nouvelles fonctionnalités et des corrections de bugs Il est difficile de compter le nombre de tests, mais environ 100 000 tests individuels sont paramétrés de façon à produire des milliards d’exécutions Il y a une checklist, et avant chaque release ils exécutent les tests pendant au moins 3 jours Ils testent volontairement sur plusieurs OS → Aujourd’hui, presque tous les appareils sont little-endian, mais autrefois les machines big-endian étaient nombreuses. Ils faisaient donc des tests big-endian sur un iBook PowerPC → Plateformes 32 bits, ARM et Intel, plateformes 64 bits, Windows, Linux, Mac, OpenBSD : ils testent sur toutes les plateformes et tous les OS possibles → Il existe plusieurs suites de tests différentes : les tests TCL d’origine, TH3, ainsi qu’un fuzzer exécuté en continu Il existe aussi les tests SQL Logic → Un énorme corpus de requêtes SQL créé il y a 10 ans par Shane Harrelson → Ils l’ont testé sur toutes les BD qu’ils pouvaient toucher, et tous les moteurs de BD échouaient à répondre et finissaient en segmentation fault. SQLite aussi. Sauf Postgres → Seul Postgres produisait toujours un résultat, et ils n’ont pas réussi à lui trouver de défaut. Les développeurs de Postgres ont dit qu’ils n’avaient simplement pas assez essayé… Il aurait peut-être été possible de faire tomber Postgres aussi, mais ils ont été très impressionnés → Même Oracle, en version commerciale, crashait, et DB2 crashait aussi → L’important, c’est qu’ils ont fini par faire en sorte que SQLite donne la même réponse sur toutes ces requêtes Building From First Principles Au départ, quand il a commencé à écrire le projet, il a cherché des références sur la manière de construire un moteur de BD SQL, mais n’en a trouvé aucune. Il a donc dû tout inventer lui-même, de façon totalement indépendante Beaucoup de théorie existaient au MIT, à Harvard et à Berkeley, mais si vous ne fréquentiez pas ces universités, vous ne saviez même pas que ces théories existaient, et vous ne saviez pas non plus comment les trouver Le modèle Volcano utilisé par Postgres et le modèle bytecode utilisé par SQLite convergent, quand on les examine, vers les mêmes idées Ils partent de points très différents, mais convergent vers la même zone lorsqu’il s’agit de rendre les choses plus rapides Il y voit en quelque sorte une validation théorique : deux lignes de développement indépendantes arrivent à la même réponse Par exemple, il ne connaissait absolument pas le covering index, puis il a assisté à une conférence PHP en Allemagne où David Axmark de MySQL donnait aussi une présentation → Lors de cette conférence, David Axmark a expliqué comment MySQL avait mis en place le covering index → Quand un index de BD contient plusieurs colonnes, si une requête ne porte que sur les premières colonnes de l’index et que la réponse se trouve dans les autres colonnes de cet index, la BD peut répondre à partir du seul index sans relire la table d’origine, ce qui accélère le traitement → Sur le vol du retour, comme il n’y avait pas grand monde, il a ouvert son laptop et implémenté le covering index de SQLite au-dessus de l’Atlantique B-Trees and The Art of Computer Programming Il a dû construire beaucoup de choses lui-même. Personne ne lui avait jamais appris les B-trees ; il en avait seulement entendu parler En essayant de développer lui-même un B-tree, il a trouvé dans sa bibliothèque le TAOCP de Don Knuth, a cherché la section sur les B-trees, et Knuth lui en a expliqué les algorithmes Ce qui est amusant, c’est que le livre détaille très bien les algorithmes de recherche et d’insertion des B-trees, mais ne fournit pas l’algorithme de suppression. Celui-ci figure dans les exercices de fin de chapitre, si bien qu’il a dû résoudre le problème lui-même avant de construire son propre B-tree. « Merci Don, vraiment merci. » Selon lui, les gens d’aujourd’hui devraient au moins lire ou parcourir le TAOCP Freedom to Build It Yourself : la liberté de le construire soi-même SQLite ne dépend de rien d’autre que de ce que Richard a lui-même écrit (à part le compilateur C et la libc). Il a même créé son propre système de gestion de versions et son propre bug tracker. Cela lui donne de la liberté La liberté, c’est être capable de prendre soin de soi-même Les gens qui partent en randonnée avec tout le nécessaire sur le dos se disent libres parce qu’ils sont capables de s’occuper d’eux-mêmes Si vous construisez tout vous-même, vous n’êtes attaché à personne, et il y a une forme de liberté là-dedans Imaginons qu’il ait choisi Berkeley DB comme moteur de stockage pour SQLite 2 → À l’époque, Berkeley DB était open source, mais plus tard Oracle l’a racheté et l’a fait basculer vers un modèle propriétaire à double licence, si bien qu’il n’était plus possible d’obtenir le code source de la version la plus récente sans payer de frais de licence Aujourd’hui, le générateur de parseur de SQLite n’utilise ni Yacc ni Bison, mais un outil maison appelé Lemon ; cela lui a permis de le modifier librement quand de nouvelles fonctionnalités de langage ont été nécessaires Au début des années 2000, tous les projets utilisaient CVS, donc il l’utilisait aussi, mais au milieu des années 2000 l’idée du contrôle de version distribué a commencé à émerger Construire Fossil Après avoir étudié Git et Mercurial et formalisé ses besoins, il a décidé de développer lui-même son système de gestion de versions Fossil fonctionne désormais bien et est devenu un projet à part entière Linus Torvalds a créé Git pour soutenir le développement du noyau Linux ; si vous travaillez sur le noyau Linux, Git est donc un système de gestion de versions parfait Fossil est, lui, exactement le système de gestion de versions qu’il faut pour travailler sur SQLite. Comme il l’a créé lui-même, il correspond précisément à ses besoins En le développant lui-même, il garde le contrôle de son destin, dispose de plus de liberté et ne dépend pas de tiers Être autosuffisant Comment appelle-t-on quelqu’un qui quitte la ville pour cultiver sa propre nourriture et vivre par ses propres moyens ? Un survivaliste ? Un prepper ? « Comme vous avez pu le voir même pendant nos échanges, mon Gmail se comporte un peu bizarrement. Mes mails me reviennent sans cesse. Donc je pense créer mon propre serveur mail. Pendant que nous organisions cette rencontre, je prenais déjà des notes à ce sujet. Ce ne sera probablement pas plus difficile que d’écrire un moteur de base de données, mais je ne veux pas être dépendant de Gmail. Je ne veux pas qu’ils contrôlent mon destin. Je ne veux pas qu’ils contrôlent l’historique de toutes mes conversations. Je veux garder le contrôle moi-même, et donc même si ce sera pénible et demandera beaucoup de travail, je vais essayer de trouver une solution que je contrôle directement. Je peux louer une machine virtuelle dans le cloud pour l’exécuter et ainsi ne pas dépendre d’un tiers. » Si quelqu’un vient vous dire « nous allons résoudre votre problème à votre place », il faut comprendre qu’il est aussi en train de vous retirer votre liberté. « Si vous voulez être libre, il faut le faire vous-même » Conseils aux autres J’ai commencé avec cette idée folle : créer un moteur de base de données qui lit et écrit directement sur le disque, sans avoir besoin d’un serveur Si vous demandez à des experts, ils vous diront : « C’est impossible. Ça ne marchera jamais. C’est une idée stupide. » Heureusement, je ne connaissais pas ces experts, alors je l’ai simplement fait, et voilà ce qui s’est passé N’écoutez pas trop les experts ; faites ce qui a du sens. Résolvez votre propre problème -- [1] Bus Factor : indicateur du risque que l’équipe soit mise en danger si un membre se fait renverser par un bus. C’est une mesure du risque lié au manque de partage des informations et des compétences entre les membres de l’équipe. Plus cet indicateur est élevé, plus les connaissances sont partagées et moins le travail repose sur une seule personne. [2] DO-178B : considérations logicielles pour la certification des systèmes et équipements embarqués aéronautiques (Software Considerations in Airborne Systems and Equipment Certification) Adopté par la FAA comme méthode de démonstration de conformité pour la certification des logiciels aéronautiques [3] MCDC : Modified Condition / Decision Coverage Méthode de conception de cas de test qui garantit que, lorsqu’il existe plusieurs conditions, chacune influence indépendamment le résultat global, sans dépendre des autres conditions

(corecursive.com)

47 points par xguru 2021-07-05 | 16 commentaires | Partager sur WhatsApp

Résumé d’un podcast d’interview du développeur de SQLite, Richard Hipp (38 min, transcription disponible)
Son métier principal était développeur logiciel pour des destroyers de la marine américaine
→ Informix, utilisé à bord, générait souvent des erreurs, le serveur tombait et les connexions se coupaient
→ Comme il s’agissait d’un navire de guerre, le système devait continuer à fonctionner de manière robuste même en cas de dommages au combat, sans afficher de popup du type « impossible de se connecter à la BD ».
Il n’y avait pas besoin de transactions, mais il fallait pouvoir charger les données en RAM dans toutes les situations
→ Il a cherché un moteur de BD SQL fonctionnant sans serveur, n’en a trouvé aucun, et a donc décidé d’en créer un lui-même

SQLite V1 (2000)

Il a conçu un moteur de bytecode qui compile et exécute les requêtes en considérant les instructions SQL comme des programmes
Il n’a finalement pas été utilisé dans le projet réel (le client voulait Informix)
Il s’en est servi pour le développement, l’a publié sur Internet, et des gens ont commencé à l’utiliser
Il a commencé à voir des retours du type « J’ai fait tourner une BD SQL sur un Palm Pilot », ce qui a attiré l’attention et l’a encouragé à poursuivre

Motorola

Entre 2001 et 2002, Motorola l’a appelé pour dire qu’ils voulaient intégrer SQLite dans leur nouvel OS pour téléphones
Ils proposaient de payer si les fonctionnalités nécessaires étaient prises en charge
C’est à ce moment-là qu’il a découvert qu’on pouvait gagner de l’argent avec l’open source
Environ 80 000 $, une somme qui paraît modeste aujourd’hui, mais qui lui semblait énorme à l’époque
Il a mené le projet avec trois collègues, et c’est ainsi que tout a commencé

America Online Phones

Le contact suivant est venu d’AOL
À l’époque où l’on envoyait encore des CD par la poste, il leur fallait une base de données dans le CD
Ils voulaient donc embarquer SQLite sur le CD et avaient besoin de nouvelles fonctionnalités

Symbian OS et Nokia

Il est allé à Londres pour une réunion pendant Thanksgiving (puisqu’au Royaume-Uni, Thanksgiving n’existe pas)
Ils voulaient une BD pour Symbian OS, et SQLite s’est retrouvé en concurrence avec d’autres BD (2 open source, 7 commerciales)
Les 9 autres ont eu l’occasion d’optimiser leur solution, mais SQLite a fini par l’emporter

Bus Factor [1] et le consortium

Le bus factor est un indicateur du nombre de personnes qui, si elles se faisaient renverser par un bus, entraîneraient l’arrêt du développement
Même s’il travaillait déjà à plein temps avec plusieurs personnes, Symbian a estimé qu’il fallait augmenter ce bus factor
L’idée était de lancer le consortium SQLite pour financer le projet et faire en sorte que davantage de personnes s’y impliquent sur le long terme
Il a d’abord eu la folle idée de donner un droit de vote à tous les membres du consortium
Mitchell Baker, de la fondation Mozilla, en a entendu parler quelque part et l’a appelé
→ « Richard, vous faites totalement fausse route. Je vais vous expliquer comment créer un consortium. »
→ Elle a commencé à définir les règles
→ « Les développeurs doivent garder le contrôle. Leurs décisions doivent être finales. On ne doit pas obtenir un droit de vote juste en adhérant. »
→ « Les entreprises qui l’utilisent gagnent l’honneur de contribuer financièrement, mais la décision finale doit vous revenir. »
→ Elle était très ferme et a tout mis en ordre. C’est une avocate
Quand Richard a demandé : « Comment convaincre les gens de participer ? Et quelle serait l’incitation ? »
→ « Ne vous inquiétez pas. Ils participeront. Et si vous faites ça correctement, Mozilla sera membre fondateur. »
Avec le soutien de Mozilla, Symbian et Adobe, le consortium a démarré avec ces trois entreprises
→ Au départ, quand Symbian a dit qu’il fallait un consortium, il ne savait pas du tout comment s’y prendre. Il ne sait toujours pas comment Mitchell Baker en a entendu parler et l’a appelé, mais tout cela a été un parcours incroyable

Entrée d’Android : les débuts d’Android

Comme tous les smartphones utilisaient SQLite, Richard a pu observer les débuts du smartphone sous tous les angles
En 2005, il a eu une réunion avec Android, avant même la sortie d’Android et de l’iPhone
Il a débogué SQLite en le connectant à un téléphone ressemblant à un BlackBerry, avec un petit écran en haut et un clavier QWERTY complet
Déboguer avec GDB sur un téléphone relié à un vrai réseau en fonctionnement était une expérience incroyable
À l’époque, ni Motorola, ni Symbian, ni Nokia ne faisaient ce genre de chose, et c’est là qu’il a compris qu’Android allait devenir énorme

Guy, This Is Important : les gars, c’est vraiment important

À cette époque, les autres constructeurs avaient des cycles de mise à jour matériel/logiciel très longs, de l’ordre de 30 jours, alors qu’Android installait plusieurs fois par jour un nouvel OS sur de vrais téléphones connectés au réseau
Les téléphones Android prototypes reçus sous NDA avaient des boîtiers qui semblaient sortis d’une imprimante 3D, mais restaient transportables
→ Chez les autres, c’étaient de grosses breadboards et des prototypes, même pas connectés au réseau, impossibles à utiliser comme téléphones
Il voulait dire aux équipes de Motorola et Symbian : « C’est important, il faut régler ça », mais il ne pouvait rien dire (à cause du NDA), et c’est ce qui a fait la différence

Testing and Aviation Standards : tests et normes de l’avionique

Adam (l’intervieweur) : « Aujourd’hui, la BD de Richard est dans un état remarquable. L’équipe est petite mais talentueuse, et c’est une société de conseil logiciel de 1 à 4 personnes qui prend en charge la BD intégrée à tous les téléphones Android. Les développeurs de bases de données sont extrêmement investis et détestent les problèmes de données. »
Nous répétions naïvement à tout le monde que SQLite n’avait pas de bugs, mais Android a clairement prouvé que nous avions tort
Il pensait possible de faire un logiciel sans bug, mais quand un logiciel est installé sur des millions d’appareils, le nombre de bugs possibles est stupéfiant
À cette époque, il travaillait aussi avec Rockwell Collins, une entreprise d’avionique, qui lui a présenté les concepts de DO-178B [2]
→ DO-178B concerne les normes qualité pour les produits aéronautiques critiques pour la sécurité, et contrairement à beaucoup d’autres normes qualité, celle-ci est « lisible »
→ Le document coûte quelques centaines de dollars, mais comme il est mince, il recommande vraiment de le lire
Ils ont réellement commencé à suivre le processus DO-178B, dont l’un des éléments est une couverture de test MCDC à 100 %
MCDC (Modified Condition / Decision Coverage) [3] signifie que les tests doivent couvrir chaque branche individuelle au moins une fois
Il a fallu un an à raison de 60 heures par semaine pour amener SQLite à 100 % de MCDC. C’était extrêmement difficile. Il fallait faire 12 heures par jour, et c’était épuisant
Atteindre 90 à 95 % de couverture de test est facile ; les 5 % restants sont vraiment durs. Mais après un an d’efforts pour atteindre 100 %, les rapports de bugs venus d’Android ont cessé
C’est à partir de là que les choses ont commencé à bien fonctionner, et cela a fait une énorme différence. Ensuite, il n’y a plus eu de bugs pendant 8 à 9 ans

Des milliards de tests

Le premier jeu de tests a été écrit en TCL (Tool Command Language) et correspondait à des tests de développement classiques
Ce premier jeu de tests TCL est toujours maintenu et public. Il n’atteint pas 100 %, mais il teste en détail toutes les fonctionnalités de SQLite
La couverture MCDC à 100 % s’appelle TH3 et n’est pas publique (proprietary)
Ils ont essayé d’en tirer des revenus en le vendant à des entreprises du secteur aérien, mais n’en ont vendu aucun exemplaire, donc cela n’a servi à rien de ce point de vue…
En revanche, cela leur a permis de garder leur produit extrêmement robuste et de livrer plus vite de nouvelles fonctionnalités et des corrections de bugs
Il est difficile de compter le nombre de tests, mais environ 100 000 tests individuels sont paramétrés de façon à produire des milliards d’exécutions
Il y a une checklist, et avant chaque release ils exécutent les tests pendant au moins 3 jours
Ils testent volontairement sur plusieurs OS
→ Aujourd’hui, presque tous les appareils sont little-endian, mais autrefois les machines big-endian étaient nombreuses. Ils faisaient donc des tests big-endian sur un iBook PowerPC
→ Plateformes 32 bits, ARM et Intel, plateformes 64 bits, Windows, Linux, Mac, OpenBSD : ils testent sur toutes les plateformes et tous les OS possibles
→ Il existe plusieurs suites de tests différentes : les tests TCL d’origine, TH3, ainsi qu’un fuzzer exécuté en continu
Il existe aussi les tests SQL Logic
→ Un énorme corpus de requêtes SQL créé il y a 10 ans par Shane Harrelson
→ Ils l’ont testé sur toutes les BD qu’ils pouvaient toucher, et tous les moteurs de BD échouaient à répondre et finissaient en segmentation fault. SQLite aussi. Sauf Postgres
→ Seul Postgres produisait toujours un résultat, et ils n’ont pas réussi à lui trouver de défaut. Les développeurs de Postgres ont dit qu’ils n’avaient simplement pas assez essayé… Il aurait peut-être été possible de faire tomber Postgres aussi, mais ils ont été très impressionnés
→ Même Oracle, en version commerciale, crashait, et DB2 crashait aussi
→ L’important, c’est qu’ils ont fini par faire en sorte que SQLite donne la même réponse sur toutes ces requêtes

Building From First Principles

Au départ, quand il a commencé à écrire le projet, il a cherché des références sur la manière de construire un moteur de BD SQL, mais n’en a trouvé aucune. Il a donc dû tout inventer lui-même, de façon totalement indépendante
Beaucoup de théorie existaient au MIT, à Harvard et à Berkeley, mais si vous ne fréquentiez pas ces universités, vous ne saviez même pas que ces théories existaient, et vous ne saviez pas non plus comment les trouver
Le modèle Volcano utilisé par Postgres et le modèle bytecode utilisé par SQLite convergent, quand on les examine, vers les mêmes idées
Ils partent de points très différents, mais convergent vers la même zone lorsqu’il s’agit de rendre les choses plus rapides
Il y voit en quelque sorte une validation théorique : deux lignes de développement indépendantes arrivent à la même réponse
Par exemple, il ne connaissait absolument pas le covering index, puis il a assisté à une conférence PHP en Allemagne où David Axmark de MySQL donnait aussi une présentation
→ Lors de cette conférence, David Axmark a expliqué comment MySQL avait mis en place le covering index
→ Quand un index de BD contient plusieurs colonnes, si une requête ne porte que sur les premières colonnes de l’index et que la réponse se trouve dans les autres colonnes de cet index, la BD peut répondre à partir du seul index sans relire la table d’origine, ce qui accélère le traitement
→ Sur le vol du retour, comme il n’y avait pas grand monde, il a ouvert son laptop et implémenté le covering index de SQLite au-dessus de l’Atlantique

B-Trees and The Art of Computer Programming

Il a dû construire beaucoup de choses lui-même. Personne ne lui avait jamais appris les B-trees ; il en avait seulement entendu parler
En essayant de développer lui-même un B-tree, il a trouvé dans sa bibliothèque le TAOCP de Don Knuth, a cherché la section sur les B-trees, et Knuth lui en a expliqué les algorithmes
Ce qui est amusant, c’est que le livre détaille très bien les algorithmes de recherche et d’insertion des B-trees, mais ne fournit pas l’algorithme de suppression. Celui-ci figure dans les exercices de fin de chapitre, si bien qu’il a dû résoudre le problème lui-même avant de construire son propre B-tree. « Merci Don, vraiment merci. »
Selon lui, les gens d’aujourd’hui devraient au moins lire ou parcourir le TAOCP

Freedom to Build It Yourself : la liberté de le construire soi-même

SQLite ne dépend de rien d’autre que de ce que Richard a lui-même écrit (à part le compilateur C et la libc). Il a même créé son propre système de gestion de versions et son propre bug tracker. Cela lui donne de la liberté
La liberté, c’est être capable de prendre soin de soi-même
Les gens qui partent en randonnée avec tout le nécessaire sur le dos se disent libres parce qu’ils sont capables de s’occuper d’eux-mêmes
Si vous construisez tout vous-même, vous n’êtes attaché à personne, et il y a une forme de liberté là-dedans
Imaginons qu’il ait choisi Berkeley DB comme moteur de stockage pour SQLite 2
→ À l’époque, Berkeley DB était open source, mais plus tard Oracle l’a racheté et l’a fait basculer vers un modèle propriétaire à double licence, si bien qu’il n’était plus possible d’obtenir le code source de la version la plus récente sans payer de frais de licence
Aujourd’hui, le générateur de parseur de SQLite n’utilise ni Yacc ni Bison, mais un outil maison appelé Lemon ; cela lui a permis de le modifier librement quand de nouvelles fonctionnalités de langage ont été nécessaires
Au début des années 2000, tous les projets utilisaient CVS, donc il l’utilisait aussi, mais au milieu des années 2000 l’idée du contrôle de version distribué a commencé à émerger

Construire Fossil

Après avoir étudié Git et Mercurial et formalisé ses besoins, il a décidé de développer lui-même son système de gestion de versions
Fossil fonctionne désormais bien et est devenu un projet à part entière
Linus Torvalds a créé Git pour soutenir le développement du noyau Linux ; si vous travaillez sur le noyau Linux, Git est donc un système de gestion de versions parfait
Fossil est, lui, exactement le système de gestion de versions qu’il faut pour travailler sur SQLite. Comme il l’a créé lui-même, il correspond précisément à ses besoins
En le développant lui-même, il garde le contrôle de son destin, dispose de plus de liberté et ne dépend pas de tiers

Être autosuffisant

Comment appelle-t-on quelqu’un qui quitte la ville pour cultiver sa propre nourriture et vivre par ses propres moyens ? Un survivaliste ? Un prepper ?
« Comme vous avez pu le voir même pendant nos échanges, mon Gmail se comporte un peu bizarrement. Mes mails me reviennent sans cesse. Donc je pense créer mon propre serveur mail. Pendant que nous organisions cette rencontre, je prenais déjà des notes à ce sujet. Ce ne sera probablement pas plus difficile que d’écrire un moteur de base de données, mais je ne veux pas être dépendant de Gmail. Je ne veux pas qu’ils contrôlent mon destin. Je ne veux pas qu’ils contrôlent l’historique de toutes mes conversations. Je veux garder le contrôle moi-même, et donc même si ce sera pénible et demandera beaucoup de travail, je vais essayer de trouver une solution que je contrôle directement. Je peux louer une machine virtuelle dans le cloud pour l’exécuter et ainsi ne pas dépendre d’un tiers. »
Si quelqu’un vient vous dire « nous allons résoudre votre problème à votre place », il faut comprendre qu’il est aussi en train de vous retirer votre liberté. « Si vous voulez être libre, il faut le faire vous-même »

Conseils aux autres

J’ai commencé avec cette idée folle : créer un moteur de base de données qui lit et écrit directement sur le disque, sans avoir besoin d’un serveur
Si vous demandez à des experts, ils vous diront : « C’est impossible. Ça ne marchera jamais. C’est une idée stupide. »
Heureusement, je ne connaissais pas ces experts, alors je l’ai simplement fait, et voilà ce qui s’est passé
N’écoutez pas trop les experts ; faites ce qui a du sens. Résolvez votre propre problème

[1] Bus Factor : indicateur du risque que l’équipe soit mise en danger si un membre se fait renverser par un bus.

C’est une mesure du risque lié au manque de partage des informations et des compétences entre les membres de l’équipe.
Plus cet indicateur est élevé, plus les connaissances sont partagées et moins le travail repose sur une seule personne.

[2] DO-178B : considérations logicielles pour la certification des systèmes et équipements embarqués aéronautiques (Software Considerations in Airborne Systems and Equipment Certification)

Adopté par la FAA comme méthode de démonstration de conformité pour la certification des logiciels aéronautiques

[3] MCDC : Modified Condition / Decision Coverage

Méthode de conception de cas de test qui garantit que, lorsqu’il existe plusieurs conditions, chacune influence indépendamment le résultat global, sans dépendre des autres conditions

16 commentaires

enowy 2025-08-07

Je ne savais pas qu’il y avait un texte aussi bon. Heureusement qu’on peut le lire en traduction.

mkeasy 2021-07-08

C’est le genre d’article qu’on relit encore et encore. Merci.

Si vous voulez être libre, vous devez le faire vous-même.

Faites quelque chose qui a du sens.

Résolvez votre propre problème.

edunga1 2021-07-05

C’est vraiment un article passionnant !

« Une couverture de tests de 90 à 95 % est facile à atteindre, mais les 5 % restants sont vraiment difficiles. Pourtant, en procédant ainsi pendant un an, ils ont finalement atteint 100 %, et les rapports de bugs en provenance d’Android ont cessé d’arriver. »

C’est incroyable.

panarch 2021-07-05

J’ai bien lu. Merci !

jsryu 2021-07-05

J’ai beaucoup aimé cette lecture. Merci.

falconer 2021-07-05

J’ai bien lu.

gmlwo530 2021-07-05

J’ai pris beaucoup de plaisir à le lire !

kwangyeol 2021-07-05

J’ai pris beaucoup de plaisir à le lire. Merci.

baeba 2021-07-05

Je l’ai lu avec beaucoup d’intérêt.

J’ai l’impression que faire un résumé organisé serait encore plus difficile.

shaichoi 2021-07-05

J’ai bien lu. Cela donne beaucoup à réfléchir. Merci :)

fureweb 2021-07-05

Très bonne lecture. Merci !

kalihman 2021-07-05

Je l’ai lu avec plaisir.

jongpak 2021-07-05

Je l’ai lu sans voir le temps passer haha

J’ai presque honte d’avoir sous-estimé SQLite en le prenant pour une simple petite base de données embarquée ^^;

sixmen 2021-07-05

Je l’utilisais en pensant que ce n’était qu’un simple SGBD local pour le développement, mais en fait, ce n’est pas du tout si simple !!

nicewook 2021-07-05

J’ai pris énormément de plaisir à le lire.

xguru 2021-07-05

SQLite actuellement déployé dans le monde dépasse les 1 000 milliards d’instances.

tous les smartphones, soit plus de 4 milliards d’appareils (Android, iOS)
Mac/Windows
les navigateurs FF/Chrome/Safari
PHP/Python
Skype/iTunes/Dropbox/Turbotax
la plupart des décodeurs et téléviseurs
les systèmes multimédias de la plupart des voitures

https://www.sqlite.org/mostdeployed.html