Pour l'ingénieur logiciel Charles Leifer, le moteur de bases de données SQLite possède de nombreux atouts qui peuvent s'avérer très utiles en environnement de production. Il a mis en exergue cinq raisons pour lesquelles il pense que vous devriez passer à SQLite.- Simple à gérer : pour ceux qui ont déjà utilisé le système de gestion de bases de données relationnelles et objet PostgreSQL, Leifer rappelle qu’ils doivent s’assurer de comprendre un certain nombre de notions pour s’assurer que le serveur est convenablement configuré. De plus, la mise à jour peut s’avérer être un « processus effrayant » qui pourrait vous amener à déconnecter votre base de données, exécuter un programme pour en effectuer la mise à jour, et « espérer que ça marche lorsque vous reconnecterez votre base de données ».
SQLite pour sa part est simple à gérer étant donné qu’il est constitué d’un seul fichier (ou quelquefois d’un fichier et d’un journal de transactions). Le format de fichier est stable dans les principales versions. Aussi, si vous avez un fichier de base de données SQLite dans la version 3.0.0 (qui date de 2004), vous pourrez le lire en vous servant de la version la plus récente SQLite 3.10.0. Une caractéristique qui facilite bien des choses : vous pouvez par exemple envoyer une copie à un collègue pour qu’il effectue une analyse des données et il pourra directement l’utiliser.
De plus, SQLite est très facile à configurer étant donné que ses fonctionnalités sont gérées de deux manières : les drapeaux de compilation et les déclarations PRAGMA (configuration run-time). « Il n’y a pas de configuration de fichiers à proprement parler, il suffit de construire les bibliothèques avec les fonctionnalités que vous désirez, puis de concevoir les options de l’environnement d’exécution à la création d’une connexion à la base de données. - En évolution constante : récemment, SQLite a ajouté le support des données JSON via l’extension json1. SQLite a également déployé une version améliorée de son extension de recherche de texte qui inclut un classement des résultats faisant appel à l’algorithme BM25 (en recherche d’information, BM25 – Best Matching – est une fonction de classement utilisée par les moteurs de recherche pour classer les documents en fonction de leur pertinence à une requête).
En plus d’ajouter de nouvelles fonctionnalités, les développeurs SQLite s’attèlent à rendre la bibliothèque plus performante. Par exemple, dans la version 3.8.11, il est mentionné que « SQLite s’exécute désormais deux fois plus vite que la version 3.8.0 et trois fois plus vite que la version 3.3.9 ». - Extensible : parce que SQLite est intégré à votre application, il fonctionne dans le même espace d’adressage. Pysqlite, une bibliothèque Python standard pour SQLite, et apsw fournissent des API pour définir des fonctions personnalisées SQL, des fonctions d’agrégation. Apsw va un peu plus loin et fournit des API pour définir des tables virtuelles et des systèmes virtuels de fichiers.
Comme exemple pratique, supposons que vous avez une colonne dans une table qui enregistre les URL et que vous souhaitez déterminer quels sont les noms de domaine les plus utilisés. Au lieu d’utiliser une regex compliquée comme vous auriez pu le faire avec un système différent, avec SQLite, vous pouvez définir une fonction hostname dans Python puis l’utiliser pour créer une simple requête COUNT.Code : Sélectionner tout 1
2
3
4
5
6
7from urlparse import urlparse def hostname(url): return urlparse(url).netloc conn = sqlite3.connect('my-database.db') conn.create_function('hostname', 1, hostname) # name, num_params, funcLes tables virtuelles, qui sont actuellement supportées par apsw, vous permettent de définir une table dans le code et y effectuer une requête comme s’il s’agissait de tables SQL ordinaires.Code : Sélectionner tout 1
2
3
4SELECT hostname(mytable.url), COUNT(mytable.id) AS ct FROM mytable GROUP BY hostname(mytable.url) ORDER BY ct DESC;
- Très rapide : étant donné qu’il s’exécute sur la même machine, pas besoin de passer par un réseau lorsqu’il est question d’exécuter des requêtes ou de lire des résultats. Étant donné qu’il s’exécute dans le même espace d’adressage, pas besoin de sérialisation ou de besoin de communication via des sockets Unix. SQLite s’exécute sur des dispositifs mobiles où les ressources sont rares et l’efficacité est cruciale. SQLite supporte également un grand nombre de drapeaux de compilation qui vous permettent d’enlever des fonctionnalités que vous n’avez pas l’intention d’utiliser.
- Le mode WAL (Write-Ahead Logging) : avec la sortie de la version 3.7.0 est arrivée une nouvelle méthode de journalisation. Par défaut, la méthode par laquelle SQLite implémentait les validations et les annulations à un niveau atomique était via un journal de restauration. Avec ce mode WAL vient plus de concurrence étant donné que la lecture ne bloque pas l’écriture et l’écriture ne bloque pas la lecture ; les deux peuvent se faire en parallèle. Il faut préciser qu’avant l’arrivée de ce mode, pour pouvoir écrire dans la base de données, l’accès devait être exclusif et aucune lecture ne pouvait être faite jusqu’à ce que l’écriture soit finie.
Comment fonctionne le mode WAL ? Le journal de restauration traditionnelle fonctionne en écrivant une copie du contenu de la base originale inchangée dans un fichier séparé de journal de restauration puis en écrivant les changements directement dans le fichier de base de données. Dans le cas d'un accident ou ROLLBACK, le contenu original figurant dans le journal de restauration est lu dans le fichier de base de données afin de restaurer le fichier de base de données à son état original. Le COMMIT se produit lorsque le journal de restauration est supprimé.
L'approche WAL inverse cela. Le contenu original est conservé dans le fichier de base de données et les modifications sont ajoutées dans un fichier séparé WAL. Un COMMIT se produit quand un enregistrement spécial indiquant une validation est ajouté à WAL. Ainsi, un COMMIT peut arriver sans jamais écrire à la base de données d'origine, ce qui permet aux lectures de continuer à fonctionner sur la base de données originale non modifiée tandis que les changements sont simultanément effectués dans le fichier WAL. Plusieurs transactions peuvent être ajoutées à la fin d'un seul fichier WAL.
Pour illustrer la différence entre les deux modes, Leifer a proposé de supposer que nous avons en face de nous deux processus, un processus d’écriture et un processus de lecture. Le processus d’écriture ouvre une transaction exclusive (indiquant son intention d’écrire). Par la suite, le processus de lecture ouvre une transaction et essaie d’émettre une instruction SELECT :Code : Sélectionner tout 1
2
3
4
5Journal mode = "delete" (the default): Writer: BEGIN EXCLUSIVE Reader: BEGIN Reader: SELECT * FROM foo; Error: database is locked
Enfin BerkleyDB : son intégration à SQLite peut donner aux développeurs d’applications qui ont besoin d’avoir accès à une base de données de façon concurrente une meilleure performance parce qu’au lieu de verrouiller la base de données entière, BerkleyDB n’a besoin que de verrouiller des pages individuelles. Ce qui lui permet d’échelonner plus efficacement la charge sous la base de données concurrente, à condition que les transactions ne soient pas en conflit pour la même page de données. BerkleyDB supporte également le MVCC (multi-version concurrency control), qui permet aux opérations de lecture de continuer à s’exécuter sur une page de données exploitée par une transaction d’écriture. De plus BerkleyDB utilise moins de ressources système et exécute peu d’appels système.Code : Sélectionner tout 1
2
3
4
5Journal mode = "wal": Writer: BEGIN EXCLUSIVE Reader: BEGIN Reader: SELECT * FROM foo; Returns table contents
Il faut préciser que son blog se sert également de SQLite.
Source : blog Charles Leifer, SQLite (WAL)
Et vous ?
Que pensez-vous de ses arguments ? Pouvez-vous en apporter plus (ou étayer les siens) pour expliquer que SQLite est un incontournable en production ? Pensez-vous à une autre solution qui ferait mieux ? Laquelle ? En quoi ? 
Envoyé par SQLpro
