IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

SQLite Discussion :

SQLite est 35 % plus rapide que le système de fichiers lorsqu'il s'agit du stockage de petits blobs


Sujet :

SQLite

  1. #1
    Expert éminent sénior
    Avatar de Coriolan
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2016
    Messages
    701
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2016
    Messages : 701
    Points : 51 811
    Points
    51 811
    Par défaut SQLite est 35 % plus rapide que le système de fichiers lorsqu'il s'agit du stockage de petits blobs
    SQLite est 35 % plus rapide que le système de fichiers
    Selon les tests des développeurs du moteur de base de données

    Alors que la version 3.19.3 de SQLite a été rendue disponible en ce début de mois, les développeurs de ce moteur de base de données ont publié une série de mesures et tests montrant que SQLite est 35 % plus rapide que le système de fichiers. La latence read/write du SQLite rivalise avec la latence de fichiers individuels sur disque. Souvent, SQLite est plus rapide, ce qui prouve qu’une base de données relationnelle n’est pas forcément toujours plus lente qu’un système de fichiers I/O.

    SQLite peut lire des petits blobs (par exemple des aperçus d’images) à une vitesse 35 % plus rapide que les mêmes blobs peuvent être lus ou écrits dans des fichiers individuels en utilisant fread() ou fwrite(). De plus, une seule base de données SQLite contenant 10 kilobytes de blobs occupe 20 % moins d’espace sur disque que si elle stocke des blobs dans des fichiers individuels.

    Cette différence de performance provient selon les auteurs du fait que les appels open() et close() sont invoqués une seule fois quand le travail est fait à partir d’une base de données SQLite. Alors que open() et close() sont invoqués une fois pour chaque blob quand ces blobs sont stockés dans des fichiers individuels. La réduction de la taille de l’espace du disque occupée provient elle du fait que les blobs sont rangés de façon compacte dans une base de données SQLite.

    Ces mesures qui ont été réalisées durant la première semaine de ce mois et concernent toutes les versions entre 3.19.2 et 3.20.0. Le chiffre de 35 % reste approximatif, en effet, la vitesse peut varier d’une machine à une autre et selon l’OS. Quelques utilisateurs ont rapporté que SQLite a une latence plus importante que l’I/O direct dans leurs systèmes.

    SQLite fait partie des bases de données les plus utilisées de la planète. Elle est réputée par sa facilité d’utilisation et sa qualité excellente. Contrairement aux serveurs de bases de données traditionnels, comme MySQL ou PostgreSQL, sa particularité est de ne pas reproduire le schéma habituel client-serveur, mais d'être directement intégrée aux programmes. L'intégralité de la base de données (déclarations, tables, index et données) est stockée dans un fichier indépendant de la plateforme.

    Les auteurs des tests ont trouvé les résultats suivants :

    1. SQLite est plus compétitive et généralement plus rapide que les blobs stockés en fichiers séparés sur disque, que ça soit pour la vitesse de lecture et d’écriture ;
    2. SQLite est beaucoup plus rapide que les écritures directes sur disque quand la protection antivirus est activée sur Windows. Puisque l’antivirus est installé par défaut sur Windows, cela veut dire que SQLite est généralement plus rapide que les écritures directes sur l’OS de Microsoft ;
    3. La lecture est plus rapide que l’écriture pour tous les systèmes (la différence est d’un ordre de magnitude) ;
    4. La performance I/O varie largement selon le système d’exploitation et le matériel ;
    5. D’autres vendeurs de moteurs de bases de données préconisent à ce que les développeurs stockent les blobs dans des fichiers séparés, puis stocker le nom de fichier dans la base de données. Dans ce cas, la base de données doit être consultée au préalable pour trouver le nom de fichier avant de l’ouvrir et le lire. Mais le fait de simplement stocker le blob entier dans la base de données permet une performance de lecture et d’écriture meilleure avec SQLite.


    Source : sqlite.org

    Et vous ?

    Qu'en pensez-vous ?

  2. #2
    Membre chevronné

    Homme Profil pro
    Mentaliste
    Inscrit en
    Mars 2008
    Messages
    872
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Mentaliste
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2008
    Messages : 872
    Points : 1 816
    Points
    1 816
    Par défaut
    J'adore ! Quand je fais un nouveau site avec Django, je n'utilise que du SQLlite. J'ai fait des tests de performance, c'est énorme. Je garantis que sur Cogofly on peut monter sans problème jusqu'à 10000 utilisateurs inscrits + suivi de news, like, et messages sans problème. La base fait à peine 30 Mo avec 4000 utilisateurs et pas mal actifs, et mes tests sont montés avec une base jusqu'à 2Go sans souci de ralentissement. Probablement plus de 10000 utilisateurs, mais bref, j'ai de quoi voir venir.

    Donc bien sûr, si vous voulez faire du Web rapidement pour faire des démos et vendre, foncez sur SQLite, après vous faites un export + ré-injection dans une base plus lourde comme PostGreSQL si votre projet grossit vraiment (et c'est tout le mal que je vous souhaite ).

Discussions similaires

  1. multipathd et oracleasm : l'un est plus rapide que l'autre
    Par exanlb dans le forum Administration
    Réponses: 0
    Dernier message: 04/04/2012, 16h54
  2. Réponses: 2
    Dernier message: 07/03/2012, 18h53
  3. Réponses: 5
    Dernier message: 10/02/2011, 16h29
  4. Réponses: 0
    Dernier message: 08/02/2011, 11h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo