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

Le , par Stéphane le calme

286PARTAGES

7  0 
Avez-vous déjà utilisé SQLite ?
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.

  1. 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.
  2. 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 ».
  3. 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
    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
    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.
  4. 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.
  5. 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
    5
    Journal mode = "delete" (the default):
    
    Writer: BEGIN EXCLUSIVE
    Reader: BEGIN
    Reader: SELECT * FROM foo; Error: database is locked
    Code : Sélectionner tout
    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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de RyzenOC
Inactif https://www.developpez.com
Le 08/01/2016 à 9:14
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.
6  4 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 09/01/2016 à 15:45
Citation Envoyé par SQLpro Voir le message
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 +
Oui enfin SQL CE, pour l'avoir utilisé assez intensivement, c'est un peu de la m***e. Ça n'a de SQL Server que le nom, et à peu près aucune des features. De plus il n'y a toujours pas de version compatible WinRT/UWP, donc ce n'est plus utilisable pour des applis mobiles modernes. Même Microsoft recommande SQLite pour ces applis. Et même Erik Ejlskov Jensen, qui est un peu LE gourou de SQL CE, s'est fendu d'un post pour expliquer comment utiliser SQLite dans une appli WinRT: http://erikej.blogspot.fr/2012/08/ge...n-windows.html

Pour ce qui est de la montée en charge, c'est vrai, mais ce n'est pas prévu pour. Si tu fais une appli mobile, tu n'as certainement pas besoin de monter en charge. Pour une appli desktop, ça dépend, mais bien souvent SQLite est amplement suffisant. Si tu fais une appli web qui va potentiellement avoir beaucoup d'utilisateurs, là tu prendras un SQL Server, PostgreSQL ou autre SGBD serveur.
3  0 
Avatar de Nerothos
Membre régulier https://www.developpez.com
Le 08/01/2016 à 9:42
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é.
2  1 
Avatar de AoCannaille
Membre émérite https://www.developpez.com
Le 08/01/2016 à 9:59
Citation Envoyé par sazearte Voir le message
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 ^^
2  0 
Avatar de Bono_BX
Membre confirmé https://www.developpez.com
Le 08/01/2016 à 10:16
Citation Envoyé par AoCannaille Voir le message
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.
2  0 
Avatar de Cxx-waves
Nouveau membre du Club https://www.developpez.com
Le 08/01/2016 à 10:30
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.
2  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 08/01/2016 à 12:01
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
2  0 
Avatar de vanquish
Membre éprouvé https://www.developpez.com
Le 12/01/2016 à 11:06
Citation Envoyé par SQLpro Voir le message

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 !!!!!
Je vous suis à 100% sur le point noir que représente cette incapacité de monté en charge de SQLite.
C'est sans importance dans certaines utilisations, mais plus problématique dans d'autres et mérite d'être méditée.

Le monde Microsoft offre effectivement une évolutivité maximale ; une documentation solide et de nombreux exemples.

Mais 3 bémols :
  • même en LocalDB, MS-SQL est plus lourd qu'une simple DLL à copier dans le dossier de l'application.
  • dès qu'on tape dans une limite (10Go + 1 octet), il faut passer à la licence du dessus et là c'est plus du tout gratuit. Parfois, il faut même changer de Windows car la licence du MS-SQL dont ont a besoin ne tourne pas sur la version de Windows actuel (vécu sur Web Edition qui n'existe plus, je crois). On comprend qu'une base de 10 Mo et une base de 11Go ne coute pas le même prix, mais c'est le passage de la limite qui est brutal.
  • univers Microsoft uniquement.


C'est pourquoi je préfère Firebird déjà cité.
Je ne veux en aucun cas, le comparer à MS-SQL en tant que SGBD, mais comme alternative à SQLite.

Firebird :
  • est très léger et peut se limiter à quelques fichiers copié dans le dossier de l'appli (une DLL en version 3).
  • Reste gratuit et avec une licence très souple quelque soit la charge.
  • Comme SQLite, tourne sur de nombreux systèmes (Windows, Linux, Mac OS)


Le seul point faible de Firebird par rapport à SQLite reste le nombre de plate-formes où il est disponible.
Même s'il existe un build Android de Firebird, SQLite reste le champion pour ce qui est du nombre de platte-formes supportés.
2  0 
Avatar de AoCannaille
Membre émérite https://www.developpez.com
Le 08/01/2016 à 10:43
Citation Envoyé par Bono_BX Voir le message
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.
1  0 
Avatar de AoCannaille
Membre émérite https://www.developpez.com
Le 08/01/2016 à 11:10
Citation Envoyé par Mouke Voir le message

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.
1  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web