Un développeur évoque cinq raisons pour vous faire utiliser SQLite en 2016

**Stéphane le calme** · 08/01/2016, 08h24

Un développeur évoque cinq raisons pour vous faire utiliser SQLite en 2016,
que pensez-vous de ses arguments ?

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 - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
from 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, func

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT hostname(mytable.url), COUNT(mytable.id) AS ct
FROM mytable
GROUP BY hostname(mytable.url)
ORDER BY ct DESC;

Les 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.

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 - Visualiser dans une fenêtre à part
```
1
2
3
4
5
Journal mode = "delete" (the default):
 
Writer: BEGIN EXCLUSIVE
Reader: BEGIN
Reader: SELECT * FROM foo; Error: database is locked
```
Code : Sélectionner tout - Visualiser dans une fenêtre à part
```
1
2
3
4
5
Journal mode = "wal":
 
Writer: BEGIN EXCLUSIVE
Reader: BEGIN
Reader: SELECT * FROM foo; Returns table contents
```
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.

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 ?

**RyzenOC** · 08/01/2016, 09h14

L'intérêt pour moi de sqlite c'est qu'il est supporter par beaucoup de langage (php, python java...), mais surtout il n'a pas besoin de serveur pour fonctionner.
SQlite ne remplaceras pas MySQL/Maria/PostgresSQL ou Oracle, ce n'est pas son objectif.

Il est conçue pour s'intégrer facilement à des logiciels, et il répond parfaitement à ce besoin.
Je l'utilise dans mes projets python pour sauvegarder des données.

**Nerothos** · 08/01/2016, 09h42

J'ai récemment utiliser SQLite pour la première fois pour faire un rendus client sans que celui-ci ne doive installer une base de donnée et je pense que je réutiliserais plus souvent cette base. Le seul "défaut" que je lui ai trouvé lors de la migration de MySQL à SQLite est le manque de mysql_num_row si on en a besoin avant de boucler.
Le fais qu'elle soit composée que de fichier rends la chose très intéressante lorsqu'on à besoin de mobilité.

**AoCannaille** · 08/01/2016, 09h59

Envoyé par sazearte

L'intérêt pour moi de sqlite c'est qu'il est supporter par beaucoup de langage (php, python java...), mais surtout il n'a pas besoin de serveur pour fonctionner.
SQlite ne remplaceras pas MySQL/Maria/PostgresSQL ou Oracle, ce n'est pas son objectif.

C'est sûr, ça n'a rien à voir et ils ne sont même pas concurrent pour moi étant donné que SQLite est monoutilisateur (en fait pas vraiment mais les perfs sont catastrophiques, le deuxieme utilisateur à vouloir modifier la base doit attendre que le premier aie fini, même si ils agissent sur des tables 100% différentes).

D'ailleurs je ne connais que SQLite pour faire des Bases de données relationnelles orientée application (mono-utilisateur donc), est-ce que SQLite à un concurrent? Si ce n'est pas le cas l'article ne sert à rien ^^

**Bono_BX** · 08/01/2016, 10h16

Envoyé par AoCannaille

D'ailleurs je ne connais que SQLite pour faire des Bases de données relationnelles orientée application (mono-utilisateur donc), est-ce que SQLite à un concurrent? Si ce n'est pas le cas l'article ne sert à rien ^^

Il y a Firebird, qui peut fonctionner de la même manière, et qui est très efficace.

Invité · 08/01/2016, 10h30

L'un des avantages de SQLite, c'est la license : domaine publique, fais-en ce que tu veux. De plus, son code source tiens dans un seul fichier C de taille assez limitée, ce qui peut convenir dans le cas d'application embarquées. Enfin, il existe des api pour manipuler une BDD dans à peut près n'importe quel langage (à part des trucs comme le brainf*ck).

Perso je m'en sers comme d'un système de stockage, surtout quand j'ai besoin d'organiser des données sans passer par des fichiers XML.

**AoCannaille** · 08/01/2016, 10h43

Envoyé par Bono_BX

Il y a Firebird, qui peut fonctionner de la même manière, et qui est très efficace.

Merci de cette info

J'avais entendu parlé de firebird mais j'avais gardé en tête que c'était plus un access like. à tort donc.

D'après ce comparatif (http://database-management.softwarei...bird-vs-SQLite) firebird présente plus d'options.
Et d'après des données ci-et là SQLite est légerement plus rapide mais beaucoup moins gourmand en espace disque.

**Mouke** · 08/01/2016, 10h57

Je m'en étais servi premier semestre 2014 : j'avais un projet scolaire Android avec contrainte d'application hors ligne. Je devais convertir une DB MySQL distante en SQLite pour garder les données dispo sans internet.

J'ai pas trop vu d'intérêt à SQLite en soi. C'est vrai que le fichier .db était vraiment peu volumineux. Sinon bah du requêtage basique quoi...

**AoCannaille** · 08/01/2016, 11h10

Envoyé par Mouke

J'ai pas trop vu d'intérêt à SQLite en soi. C'est vrai que le fichier .db était vraiment peu volumineux. Sinon bah du requêtage basique quoi...

C'est justement ça l’intérêt : Un fichier simple, pas besoin de serveur ou de droits admins pour l'utiliser, tu cale ton fichier à coté de ton exécutable et voilà. Et c'est un fichier réutilisable, pas un export binaire des données de l'appli et spécifique à l'appli, ça s'interroge grâce au SQL. C'est parce que c'est "du requêtage basique" que SQLite est intéressant.

**tomlev** · 08/01/2016, 11h31

C'est sûr que SQLite est un super SGBD, mais il ne convient pas à toutes les utilisations. En gros c'est bien pour des applis desktop ou mobiles qui ont besoin d'une DB locale, mais pour un site web avec une charge non négligeable, c'est complètement inadapté. Et puis les features sont quand même assez limitées par rapport à un MySQL, PostgreSQL, SQL Server ou Oracle...

Perso c'est surtout l'aspect "1 seul fichier, 0 configuration" que je trouve super pratique. Maintenant j'aimerais bien trouver une DB NoSQL avec les même caractéristiques...

**Aiekick** · 08/01/2016, 11h33

ya gigabase aussi qui est très bon, mais beaucoup moins répandu, et supporté que par C, C++, C#, Java, PHP and Perl API

**grunk** · 08/01/2016, 12h01

Pour des applications qui ont un besoin de BDD locale c'est vraiment efficace.
Il on une extension (payante) pour utiliser la base comme un conteneur crypté (AES) de manière complètement transparente , c'est vraiment top.

J'ai déjà travailler avec des bases sqlite de plusieurs Go et quelques millions de ligne sans aucun souçis, donc c'est du tout bon

**Issam** · 08/01/2016, 14h24

Envoyé par AoCannaille

Merci de cette info

J'avais entendu parlé de firebird mais j'avais gardé en tête que c'était plus un access like. à tort donc.

ah non, firebird est un vrai sgbdr, en plus il offre l'option embedded a la sqlite .

**TiranusKBX** · 08/01/2016, 16h37

ha SQLite, ou comment déplacer une base de donnée pour les flemmards

mais aussi le second avantage, si tu à perdus ton fichier de base, c'est pas grave ton programme le réécris (enfin si l'on à été suffisamment prévoyant

)
ça évite aussi un réglage part-feu

**mangobango** · 08/01/2016, 18h07

Il y a quelques temps les accès en écriture concurrentiels étaient problématiques (je ne me rappelle plus de l'erreur mais c'était du style "too many requests" ou quelque chose comme ça). Est-ce qu'il y a eu des progrès là-dessus? Ou doit-on sérialiser nous mêmes les écritures à Sqlite pour se protéger de ces erreurs?

Daniel

**TiranusKBX** · 08/01/2016, 19h24

Lis mieux

Envoyé par Stéphane le calme

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.

**RyzenOC** · 08/01/2016, 20h27

J'ai déjà travailler avec des bases sqlite de plusieurs Go et quelques millions de ligne sans aucun souçis, donc c'est du tout bon

Combien faisait la taille des fichiers ?
Je suis jamais aller au delà de 400mo, quelle est la limite (avec des perf acceptable) de sqlite en taille de fichier ?

J'avais vue (il y'a 2ans) qu'au delà d'1Go il valait mieux utiliser autre chose que sqlite.

**mangobango** · 08/01/2016, 22h06

Envoyé par TiranusKBX

Lit mieux

J'ai fait ça ^^

Sur la page https://www.sqlite.org/wal.html

Writers merely append new content to the end of the WAL file. Because writers do nothing that would interfere with the actions of readers, writers and readers can run at the same time. However, since there is only one WAL file, there can only be one writer at a time.

Donc, sauf à mal comprendre : il faut toujours sérialiser les opérations d'écritures si on a des écritures concurrentielles.

Daniel

**SQLpro** · 09/01/2016, 07h58

Envoyé par AoCannaille

C'est sûr, ça n'a rien à voir et ils ne sont même pas concurrent pour moi étant donné que SQLite est monoutilisateur (en fait pas vraiment mais les perfs sont catastrophiques, le deuxieme utilisateur à vouloir modifier la base doit attendre que le premier aie fini, même si ils agissent sur des tables 100% différentes).

D'ailleurs je ne connais que SQLite pour faire des Bases de données relationnelles orientée application (mono-utilisateur donc), est-ce que SQLite à un concurrent? Si ce n'est pas le cas l'article ne sert à rien ^^

Oui, par exemple LocalDB de Microsoft, c'est un SQL Server sous forme de DLL mono utilisateur...
A lire :
http://blogs.msdn.com/b/jerrynixon/a...t-edition.aspx
En sus MS SQL Server offre différentes autres versions : CE pour les smartphones, EXPRESS pour les petites applications, WEB en mode SPLA pour les appli WEB, Standard et Enterprise pour les entreprises.....
Alors que SQL lite n'offre que le Lite donc incapacilté à monter en charge !!!!!

A +