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, Chroniqueur Actualités
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de RyzenOC 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.
Avatar de Nerothos 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é.
Avatar de AoCannaille AoCannaille - Membre chevronné 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 ^^
Avatar de Bono_BX 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.
Avatar de Cxx-waves 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.
Avatar de AoCannaille AoCannaille - Membre chevronné 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.
Avatar de Mouke Mouke - Membre averti https://www.developpez.com
le 08/01/2016 à 10:57
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...
Avatar de AoCannaille AoCannaille - Membre chevronné 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.
Avatar de tomlev tomlev - Rédacteur/Modérateur https://www.developpez.com
le 08/01/2016 à 11:31
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...
Avatar de Aiekick Aiekick - Membre chevronné https://www.developpez.com
le 08/01/2016 à 11:33
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
Contacter le responsable de la rubrique Accueil